Assembly in C Standard

Discussion in 'C Programming' started by CJ, Mar 6, 2008.

  1. CJ

    CJ Guest

    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.
    CJ, Mar 6, 2008
    #1
    1. Advertising

  2. CJ

    santosh Guest

    CJ wrote:

    > 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.
    santosh, Mar 6, 2008
    #2
    1. Advertising

  3. In article <>, CJ <> wrote:
    >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)"
    --
    "To all, to each! a fair good-night,
    And pleasing dreams, and slumbers light" -- Sir Walter Scott
    Walter Roberson, Mar 6, 2008
    #3
  4. CJ

    Willem Guest

    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
    Willem, Mar 6, 2008
    #4
  5. 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:>
    Kenneth Brody, Mar 6, 2008
    #5
  6. CJ

    CBFalconer Guest

    CJ wrote:
    >

    .... 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 6, 2008
    #6
  7. CJ

    Default User Guest

    santosh wrote:

    > CJ wrote:
    >
    > > 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.


    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, Mar 6, 2008
    #7
  8. CJ

    Default User Guest

    Kenneth Brody wrote:

    > 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
    Default User, Mar 6, 2008
    #8
  9. "Default User" <> writes:

    > 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,

    --
    Jean-Marc
    Jean-Marc Bourguet, Mar 6, 2008
    #9
  10. On Thu, 06 Mar 2008 15:10:16 -0500, CBFalconer wrote:
    > CJ wrote:
    >>

    > ... 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.


    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.
    Harald van Dijk, Mar 6, 2008
    #10
  11. CJ

    Jack Klein Guest

    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
    Jack Klein, Mar 7, 2008
    #11
  12. >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.
    Gordon Burditt, Mar 7, 2008
    #12
  13. CJ

    Richard Bos Guest

    "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
    Richard Bos, Mar 7, 2008
    #13
  14. 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.
    christian.bau, Mar 7, 2008
    #14
  15. CJ

    Flash Gordon Guest

    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
    Flash Gordon, Mar 8, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Prasanna Padmanabhan
    Replies:
    1
    Views:
    800
    Mattias Sjögren
    Nov 19, 2003
  2. Brent
    Replies:
    1
    Views:
    1,345
    Brent
    Jan 23, 2004
  3. SA
    Replies:
    0
    Views:
    458
  4. Horatiu Margavan via .NET 247

    Assembly's manifest definition does not match the assembly reference.

    Horatiu Margavan via .NET 247, Aug 30, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    3,592
    Horatiu Margavan via .NET 247
    Aug 30, 2004
  5. Grant Merwitz
    Replies:
    3
    Views:
    9,001
    Grant Merwitz
    Sep 15, 2005
Loading...

Share This Page