Assembly in C Standard

[CJ]

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.

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

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

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

 

[santosh]

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?

I don't think so, at least from the reactions I got when I brought up
this subject a while back.

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.

That's the problem. Not everyone views adding an "asm" keyword as a
great enhancement to C. The fact is, even if the *keyword* were added,
most other details about it's actual usage might not be easily
standardisable. This is because:

1. Assembler is inherently different (syntactically and semantically for
different architectures)

2. Most complers already have an "asm" extensions which is well
understood and has been used a good deal. Thus any standardisation
would have to take care to not break the preexisting usages.

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

One reason that was given was that the details are too different and
system specific and the benefit of standardising a keyword too little
to be worth the effort.

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

Yes. But C++ has an asm keyword.

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

Maximal portability in what way. Unless it's *usage* details are also
fairly rigorously and exhaustively specified, I don't see how one
instance of an "asm" block for one compiler is going to be "maximally
portable" to another.

The usage of an asm block is going to remain tightly system specific, so
the benefit of standardising the construct is not going to be very
significant. That's why in current code, we have conditional
compilation blocks specifying separate asm blocks for each compiler
targeted.

 

[Walter Roberson]

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?

Personally, I would think it -highly- unlikely. The C89 Rationale
says,

The keywords entry, fortran, and asm have not been included
since they were either never used, or are not portable. Uses of
fortran and asm as keywords are noted as common extensions.

Thus the matter was evaluated 20 years ago and found not
persuasive then, at a time when there were fewer architectures to
consider and at a time when C compiler optimization was much
weaker and so there was much more to gain by including assembly.
If it was not persuasive then, then it is even less persuasive now.

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.

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

Standardizing asm or __asm would require defining the interaction
between C compilers and assembly. For example, some model would
have to be developed and adhered to by compilers in order to
allow assembly statements to locate and reference variables
(the internal mechanisms for which can vary according to optimization
level, program size, and the scope of the variable). This must
be done because, by definition, the assembly statements will
each consist of -single- assembly statements, each of which will
need to know exactly which addressing mode to specify to reference
the variable. The alternative, that would allow the asm (or __asm)
statements to generate all necessary prologs to load the value
of the variable, would imply that asm (or __asm) would no longer
be coded in assembler and would instead be coded in a macro language...
and then you have to define the characteristics of the macro language
and you have to lock down which machine registers are available to
the macro language to create the steps to load variables properly,
and so on.

It would, in short, be a mess, and would have the perverse effect
of requiring the generated code to *not* be as optimized as it
would otherwise be. Keep in mind sequence points and as-if rules
and movement of variables completely into registers, and
code movement out of loops, and so on: having asm (or __asm)
present would have to require that such optimizations be
turned off in the compiler, or else that a flexible asm macro
language be provided that had access to meta information about
which optimizations had been performed and which not so that it
would know which exact assembler statements to generate.

IMHO, "This Is A Bad Idea (TM)"

 

[Willem]

santosh wrote:
) 1. Assembler is inherently different (syntactically and semantically for
) different architectures)

Even for different compilers on the same architecture.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Kenneth Brody]

CJ wrote:
[...]

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

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

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

Consider that, even if it were to be part of the Standard, I can't
imagine it saying anything beyond:

The syntax is:

asm {
implementation-specific code
};

Given that everything between "asm {" and "};" is 100% implementation-
specific, I don't see what it gains, and I certainly don't see how it
can "maintain maximal portability". You will already need to #if the
source to select the proper assembly code, so what does it gain to
have the syntax standardized?

In other words, is it really "better" to have:

asm {
#if PLATFORM == SYSTEM1
... Code for System 1 here ...
#elif PLATFORM == SYSTEM2
... Code for System 2 here ...
#endif
};

as opposed to:

#if PLATFORM == SYSTEM1
asm {
... Code for System 1 here ...
}
#elif PLATFORM == SYSTEM2
__asm (
... Code for System 2 here ...
);
#endif

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

.... snip ...

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

Yes. Assembly language is system peculiar. C is system independent.

 

[Default User]

I don't think so, at least from the reactions I got when I brought up
this subject a while back.


That's the problem. Not everyone views adding an "asm" keyword as a
great enhancement to C. The fact is, even if the keyword were added,
most other details about it's actual usage might not be easily
standardisable. This is because:

1. Assembler is inherently different (syntactically and semantically
for different architectures)

2. Most complers already have an "asm" extensions which is well
understood and has been used a good deal. Thus any standardisation
would have to take care to not break the preexisting usages.


One reason that was given was that the details are too different and
system specific and the benefit of standardising a keyword too little
to be worth the effort.


Yes. But C++ has an asm keyword.

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.




Brian

 

[Default User]

CJ wrote:
[...]

Is there a good reason why __asm is not a part of current C
standard?
Putting it in the C standard would let programmers include assembly
for optimization while maintaining maximal portability.

Consider that, even if it were to be part of the Standard, I can't
imagine it saying anything beyond:

The syntax is:

asm {
implementation-specific code
};

Given that everything between "asm {" and "};" is 100% implementation-
specific, I don't see what it gains, and I certainly don't see how it
can "maintain maximal portability". You will already need to #if the
source to select the proper assembly code, so what does it gain to
have the syntax standardized?

That's basically the approach C++ took (see my reply to Santosh).
Minimal standardization or no standardization, I'm not sure what the
real difference is.




Brian

 

[Jean-Marc Bourguet]

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.

Not much but it reserves the keyword and probably describing an existing
usage at the time of standardization. BTW, don't forget the catch 22
situation: you don't want to standardize something which is not already a
common usage, you don't want to use something which is not standardized.

Yours,

 

[Harald van Dijk]

Yes. Assembly language is system peculiar. C is system independent.

C is not system independent. There is a system independent subset of C,
but C contains a lot of system dependent areas. For the easiest example,
look at the system function.

 

[Jack Klein]

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

 

[Gordon Burditt]

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.

 

[Richard Bos]

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

 

[christian.bau]

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.

 

[Flash Gordon]

Richard Bos wrote, On 07/03/08 09:46:

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?)