«

On Thu, 6 Mar 2008 18:22:38 +0100 (CET), CJ <> wrote in
comp.lang.c:

> Some compilers support __asm{ } statement which allows integration of C
> and raw assembly code. A while back I asked a question about such
> syntax and was told that __asm is not a part of a C standard. My
> question now is:
>
> Is there a chance that such statement will become a part of C standard
> in the future? In some cases using asm language is the best way to
> acomplish some small task, hence integration of C and asm would greatly
> enhence C, or atleast it would in my opinion.

Once upon a time, before the first ANSI standard in 1989, some
implementations of C supported an "asm" keyword. The original C
standard committee decided not to standardize that as part of the
language. Google the C Rationale to read their reasons.

Interestingly enough, a certain vendor that repeatedly behaves in a
way that could be interpreted as an attempt at user lock-in, added
assembly language inclusion to its compiler, with a completely
different syntax than that of the C compilers I was familiar with.

Later on, the C++ standard did include the "asm" keyword, with exactly
the same syntax that was common among early C compilers. So now this
certain vendor had __asm which is non-standard in both C and C++.

> Is there a good reason why __asm is not a part of current C standard?

Yes.

> I have bumped into compilers that support and others that ignore __asm
> statement so obviously it is still not a part of C standard.

You can bump into all sorts of non-standard extensions in compilers
without even trying very hard.

> Putting it in the C standard would let programmers include assembly for
> optimization while maintaining maximal portability.

You have no concept of what you are talking about. There is no
portability in assembly language. Not even for the same processor
under the same operating system.

How portable do you think asm("MOV EAX,EBX") is going to be in a C
compiler for an ARM, of which there is one in just about every cell
phone made?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

>Is there a chance that such statement will become a part of C standard
>in the future? In some cases using asm language is the best way to
>acomplish some small task, hence integration of C and asm would greatly
>enhence C, or atleast it would in my opinion.

In some cases using asm language to write asm subroutines is
the best way to accomplish some small task (say, setting or loading
some wierd processor register that, say, contains a high-resolution
timer). Why not use an entire file with some asm subroutines in it?

>Is there a good reason why __asm is not a part of current C standard?

Yes. There's absolutely no standardization of what goes in its
argument. Some examples:

- Name a register, if this CPU even has them. There isn't even agreement
on how to write the names of registers for a Pentium III processor
with a specific serial number.
- Which registers are in use by the compiler and which do not have to
be saved/restored if you use them?
- Where do you put an integer result you want returned from a function?
How about a pointer? a double?
- Assuming you passed in an integer parameter to load into the CPU
finklesnort lookabove buffer, where can you *find* that value to put
in the instruction "movl finklesnortlb, ______________"
- Where are local (auto) variables stored?
- Which register is the stack frame pointer, if there are registers
and if there is a stack frame pointer?

Actually, GCC has some answers to issues of referencing C variables
with assembly language. I haven't seen anything else like it in
another compiler.


>Putting it in the C standard would let programmers include assembly for
>optimization while maintaining maximal portability.

Maximal portability? You probably don't even get pessimal portability
on a dual-booted system using the same physical CPU.

"Default User" <> wrote:

> True. Here's what the C++ standard says:
>
> An asm declaration has the form
> asm-definition:
> asm ( string-literal ) ;
> The meaning of an asm declaration is implementation-defined. [Note:
> Typically it is used to pass information through the implementation to
> an assembler. ]
>
> I'm not sure how that's any more useful than leaving it out and
> allowing implementations that wish to have assembly support to offer it
> strictly as an extension.

It is, in any case, less useful than the already existing possibility of
linking foreign object files into the C program, and only declaring
their contents in C. That way, we can separate the assembly from the C
entirely, and make the C as portable as possible while keeping the, by
necessity unportable, assembly neatly separated.

Richard

There is no intention to support assembler in the C Standard. And
there is no standard practice, so we will never get something
standardised in that area. When I thought about it (probably the
previous time this come up here), I thought the following would be
quite useful:

Definition:
<asm_token> = "Any C preprocessor token except { } [ ] ( ) < > "

<asm_text> = <empty>
<asm_text> = <asm_token>
<asm_text> = { <asm_text> }
<asm_text> = [ <asm_text> ]
<asm_text> = ( <asm_text> )
<asm_text> = < <asm_text> >
<asm_text> = <asm_text> <asm_text>

<asm_variant> = <string_literal>
<asm_variant> = <asm_variant> , <string_literal>

<asm_parts> = asm <string_literal> { <asm_text> }
<asm_parts> = <asm_parts> <string_literal> { <asm_text> }
<asm_statement> = <asm_parts>>
<asm_statement> = <asm_parts> default <block_statement>

Now what does it mean:

First, <asm_text> is any sequence of preprocessor tokens with matching
brackets using [] {} () and <>. "Preprocessor token" gives a bit more
freedom than using C tokens. Most assembler languages can be expressed
that way.

An assembler statement is supposed to be equivalent to a block
statement. The string literals identify variants of assembler
languages. Manufacturers have to agree between each other what string
to use to identify which variants. And a C implementation defines
which variants it supports, and in which order they are preferred - it
may support no variant at all.

When the compiler encounters the asm statement, it can find out which
variants the programmer used and which token sequences were given, and
whether there was a default in C. The compiler checks the syntax for
all variants that it supports, and checks the syntax of the C default,
if there was one. Unsupported variants are completely ignored. Then it
checks if the programmer used any supported assembler variant; in that
case it translates the variant that it prefers. If there is no
supported variant but a default statement then it translates the
default statement. If there is no supported assembler and no default
statement then it reports an error.

So as a programmer you can replace any single statement with
assembler. You can supply assembler in any number of variants to
support more than one available assembler. You also supply C code,
which serves as documentation and fallback if the compiler doesn't
understand any of the supplied variants. Your code will run anywhere,
as long as manufacturers don't use the same string literals to
identify different syntax.

Example:

static int my_assembler_function (int x, int y) {
++x;
asm "linux_x86", "microsoft_x86" { .... }
"macosx_ppc" { ... }
default { return x * y; }
}

This would be no big problem for compilers; a compiler only needs to
skip all the tokens and then translate a plain old C compound
statement if it doesn't want to produce more useful support.

Richard Bos wrote, On 07/03/08 09:46:
> "Default User" <> wrote:
>
>> True. Here's what the C++ standard says:
>>
>> An asm declaration has the form
>> asm-definition:
>> asm ( string-literal ) ;
>> The meaning of an asm declaration is implementation-defined. [Note:
>> Typically it is used to pass information through the implementation to
>> an assembler. ]
>>
>> I'm not sure how that's any more useful than leaving it out and
>> allowing implementations that wish to have assembly support to offer it
>> strictly as an extension.
>
> It is, in any case, less useful than the already existing possibility of
> linking foreign object files into the C program, and only declaring
> their contents in C. That way, we can separate the assembly from the C
> entirely, and make the C as portable as possible while keeping the, by
> necessity unportable, assembly neatly separated.

For small stuff what I have done in embedded work is provided a header
file with #defines for the non-portable embedded assembler. The overhead
of a function call is a bit daft when you only want to execute one
assembler instruction! A typical example was something like:
#define INT_ENABLE() __asm("eint")
It is a long time since I did it so the details are almost certainly
completely wrong, but the principal is correct. It also keeps the
non-portable assembly just as seperated as your example (you do provide
a header file declaring your assembler function, don't you?)
--
Flash Gordon