assembly in future C standard

Discussion in 'C Programming' started by fermineutron, Oct 28, 2006.

  1. fermineutron

    fermineutron 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.
    fermineutron, Oct 28, 2006
    #1
    1. Advertising

  2. fermineutron said:

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


    No.

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


    No.

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


    Yes.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Oct 28, 2006
    #2
    1. Advertising

  3. On Sat, 2006-10-28 at 09:01 -0700, fermineutron wrote:
    > 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.
    >


    I'd say no, but the fact that system() is a part of the C standard
    makes that answer questionable.

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


    It's 100% non-portable among different architectures, which is contrary
    to the spirit of C.

    --
    Andrew Poelstra <http://www.wpsoftware.net/projects/>
    Andrew Poelstra, Oct 28, 2006
    #3
  4. "fermineutron" <> writes:
    > Is there a good reason why __asm is not a part of current C standard?


    It'll make C language not portable.

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
    Michal Nazarewicz, Oct 28, 2006
    #4
  5. fermineutron

    Guest

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

    Yes. There's no portable assembly, using it makes your code
    non-portable between different implementations.

    Even on the same OS and hardware assembly language may differ. e.g. on
    Windows, Microsoft VC++ uses the MASM:

    mov ebx, eax

    (AKA "Intel syntax")

    while gcc uses the AT&T-style:

    movl %eax, %ebx

    (AKA "AT&T syntax")

    The instruction name, register ordering, and register syntax are all
    different. And that's on the same OS & architecture. If you change
    chips, the target assembly language won't even bear the superficial
    simlarities seen here. To standardize __asm or __asm__ even only on
    one platform would mean standardizing the entire assembly language for
    that platform too, and even then it wouldn't result in code being
    portable to other hardware.
    , Oct 28, 2006
    #5
  6. fermineutron 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 good reason why __asm is not a part of current C standard?


    As everyone else has pointed out, you can't portably specify the output
    of a program that contains any call to __asm{} and so it isn't in the
    proper domain of the C standard.

    The C standard does specify that __asm is in the implementation
    namespace. This means that an implementation can choose to specify what
    __asm{} does, without causing any name clashes with portable code, and
    presumably without any conflicts with subsequent versions of the
    Standard. That's about all you *can* guarantee for raw assembly code,
    and it is quite a useful guarantee.

    -thomas
    Thomas Lumley, Oct 28, 2006
    #6
  7. fermineutron

    jacob navia Guest

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

    >
    > Yes. There's no portable assembly, using it makes your code
    > non-portable between different implementations.
    >


    My qfloat package has been ported to linux/windows/ and it will run
    (unmodified) under Solaris, Mac (x86) and aix (x86).

    Assembly is quite portable between OSes, but not within
    different processors
    jacob navia, Oct 28, 2006
    #7
  8. fermineutron

    fermineutron Guest

    jacob navia wrote:
    > My qfloat package has been ported to linux/windows/ and it will run
    > (unmodified) under Solaris, Mac (x86) and aix (x86).
    >
    > Assembly is quite portable between OSes, but not within
    > different processors



    Makes sense.

    I guess portability of C is a bigger Ace than the gain from clock-cyle
    level of the CPU controll.
    fermineutron, Oct 28, 2006
    #8
  9. fermineutron said:

    >
    > jacob navia wrote:
    >>
    >> Assembly is quite portable between OSes, but not within
    >> different processors

    >
    > Makes sense.


    Would that it were true - but it isn't. There is no such thing as "assembly
    language". There are, rather, a great many assembly languages. One
    particular assembly language may well be portable between two or even more
    OSs, and yet not be portable between two different assemblers on the same
    OS. One assembly language may be portable between two different assemblers
    on the same OS, and yet not be portable to some other OS.

    > I guess portability of C is a bigger Ace than the gain from clock-cyle
    > level of the CPU controll.


    It depends what you need. But the best solution to your immediate problem -
    that of performance - lies in choosing better, faster algorithms and
    implementing them well. You have a great many gains to realise from doing
    this; if you do it well, you may well decide that you have no need for any
    assembly language after all. Implementing your current algorithms in some
    assembly language or other is unlikely to result in significant performance
    improvements.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Oct 28, 2006
    #9
  10. fermineutron

    Eric Sosman Guest

    fermineutron wrote:

    > jacob navia wrote:
    >
    >>My qfloat package has been ported to linux/windows/ and it will run
    >>(unmodified) under Solaris, Mac (x86) and aix (x86).
    >>
    >>Assembly is quite portable between OSes, but not within
    >>different processors

    >
    >
    >
    > Makes sense.
    >
    > I guess portability of C is a bigger Ace than the gain from clock-cyle
    > level of the CPU controll.


    Inserting assembly language into the middle of C code (if
    the compiler permits it) is rarely the road to a noticeable
    performance improvement. It may even disimprove performance by
    creating an "opaque" section whose purpose the compiler cannot
    fathom, thus inhibiting optimizations that would span the area
    of impenetrable code. Once in a very great while, embedded
    assembly is the cat's pajamas -- but most of the time the cat
    sleeps nude.

    A more usual motivation is to make use of special machine
    instructions the compiler would not generate on its own. If
    you need to fetch a value with "cache-bypass load" or execute
    the "refresh TLB tag bits" instruction, injecting assembly into
    the middle of the C source may be attractive. But even in such
    cases it is usually cleaner to package the screwball instructions
    in external functions that are themselves written in assembly,
    and write an ordinary function call in the C code. This has the
    benefit of pulling the machine-dependent stuff out of the main
    stream of your program, making it easier to substitute "morally
    equivalent" external functions when porting the code to new
    platforms. You are almost always better off writing and calling
    an AtomicIncrementInt() function than trying to embed assembly
    for a compare-and-swap loop.

    --
    Eric Sosman
    lid
    Eric Sosman, Oct 28, 2006
    #10
  11. fermineutron

    Chris Torek Guest

    In article <>
    Eric Sosman <> wrote:
    > A more usual motivation is to make use of special machine
    >instructions the compiler would not generate on its own. If
    >you need to fetch a value with "cache-bypass load" or execute
    >the "refresh TLB tag bits" instruction, injecting assembly into
    >the middle of the C source may be attractive. But even in such
    >cases it is usually cleaner to package the screwball instructions
    >in external functions that are themselves written in assembly,
    >and write an ordinary function call in the C code. This has the
    >benefit of pulling the machine-dependent stuff out of the main
    >stream of your program, making it easier to substitute "morally
    >equivalent" external functions when porting the code to new
    >platforms. You are almost always better off writing and calling
    >an AtomicIncrementInt() function than trying to embed assembly
    >for a compare-and-swap loop.


    I agree with all of this; however, in some (sometimes significant)
    cases (e.g., the actual implementation for a mutex), you may want
    to have an inline expansion of the underlying atomic operation,
    typically via a macro. For instance, if you have a mutex construct
    that -- at least in the uncontested case -- is just a (possibly
    locked) compare-and-swap, you may want the x86-specific version
    of:

    MUTEX_GET(mutex_ptr);

    to turn into the assembly equivalent of:

    if (compare_and_exchange(mutex_ptr->key, __self()->key) != SUCCEEDED)
    mutex_get_contested(mutex_ptr); /* blocks until success */

    The tricky part lies not only in arranging for the assembly equivalent
    to be inserted inline, but in *also* informing the compiler that
    it must not move certain memory operations across the "special"
    instruction(s). That is, if the mutex protects a data structure,
    the compiler *must not* turn:

    MUTEX_GET(&data->mutex);
    data->field = newvalue;
    MUTEX_RELEASE(&data->mutex);

    into, e.g.:

    data->field = newvalue;
    MUTEX_GET(&data->mutex);
    MUTEX_RELEASE(&data->mutex);

    The compiler may think the second version is superior (because it
    uses less CPU time overall, e.g., due to reduced register pressure
    or because it schedules better), but in fact, it is not. :)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Oct 28, 2006
    #11
  12. fermineutron

    fermineutron Guest

    Richard Heathfield wrote:

    > It depends what you need. But the best solution to your immediate problem -
    > that of performance - lies in choosing better, faster algorithms and
    > implementing them well. You have a great many gains to realise from doing
    > this; if you do it well, you may well decide that you have no need for any
    > assembly language after all. Implementing your current algorithms in some
    > assembly language or other is unlikely to result in significant performance
    > improvements.



    Well, it seems to me that it is not so much the speed gain as a
    functionality gain that can be realized from assembly language. For
    example, a while back i wrote a simple C profiler, which parces C file
    and inserts RDTSC statements before and after each C statement, hence
    determining the number of clock cycles it took to execute that line of
    code. Now the only compiler that my profiler will work with is lcc
    because the RDTSC is a part of intrinsics library of LCC, but it is not
    a part of BC++ 5.02 for example. Had there been a full support for
    assembly code within C I could have used inline assembly to do this and
    not rely on intrinsics library of LCC.

    To the best of my knowlege most of modern C compilers produce assembly
    code whih is as good as one could optimize it by hand, so clearly there
    is no speed gain from asm for a general purpose code.

    Speaking of speed gains:
    Richard, you may be pleased to hear that after reworking my code for
    calculation of factorials of large numbers, to not use the stack space
    but to use malloc instead, i realized a performance gain of about 60
    times. So a correctly writtec C code does not loose to correctly
    writtem asm code in speed, but it is somewhat limited in CPU control.

    Theoretically it seems possible to develop a subset of assembly
    languages which are used by motern CPUs and include in a C standard a C
    library which would allow user to use the assembly subset. Since it is
    a limited subset and its sintax is goverened by C it should not present
    portability challenges with possible exception of older systems. any
    thoughts about this?
    fermineutron, Oct 29, 2006
    #12
  13. >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?


    NO. And I believe the same applies to __COBOL{}.

    >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 my opinion, you should write a function in pure asm, assemble
    it separately, and link it with the C program. That requires you
    to know things like function linkage conventions, symbol naming
    conventions, etc.

    If you write inline assembly, how does the assembly talk to the
    non-assembly part, as far as passing data between them? The part
    about function linkage conventions and symbol naming conventions
    aren't enough. You have to have "unwarranted chumminess with the
    compiler" to know what register the compiler puts stuff in.

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


    There's no way to describe what the stuff in the {} DOES in any
    reasonable way. There are, for example, often several
    mutually-incompatible assembly languages for the *SAME* CPU.
    And, unlike system(), you can't generate the assembly-language
    code at runtime for the purpose of passing data to it.

    >I have bumped into compilers that support and others that ignore __asm
    >statement so obviously it is still not a part of C standard.
    Gordon Burditt, Oct 29, 2006
    #13
  14. Gordon Burditt wrote:
    > > Is there a good reason why __asm is not a part of current C standard?

    >
    > There's no way to describe what the stuff in the {} DOES in any
    > reasonable way.


    There doesn't actually need to be. C++ has...

    An asm declaration has the form

    asm-definition:
    asm ( stringliteral ) ;

    The meaning of an asm declaration is implementation defined.

    The question is better asked in comp.std.c. But as I see it, the
    purpose
    of standardisation is to bring common elements into line. But trying
    to bring into line a can of worms can be difficult. I know of many C++
    implementations that don't support the standard form of asm, but have
    retained their own syntax.

    Looking back, I imagine many prestandard compilers already had their
    own inline assembler syntax and that those implementations, as today,
    varied wildly.

    > There are, for example, often several mutually-incompatible assembly
    > languages for the *SAME* CPU.


    True, but system() is often subject to the same problems. [Generate a
    command that calls a function and pipes the output to a given name
    and it will work under one implementation and not others, even on
    the same platform. Quoting arguments that contain whitespace can
    be handled differently by different implementations on the same
    platform.]

    Perhaps the most non-portable programming that is in the standard is
    support for locales.

    > And, unlike system(), you can't generate the assembly-language
    > code at runtime for the purpose of passing data to it.


    Some old implementations allowed you to put machine code into an
    unsigned char and 'call' that code like a function. However there are
    problems on modern machines, e.g. instruction caching, and code
    data lying in non-executable segments.

    The system() function brings up the topic of command line options.
    Lot's of programs use argc/argv, but their use itself is inherently
    (even if not dramatically) non-portable. For example, some
    implementations will perform wildcard replacement for you, others
    won't.

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


    Contrary to Richard Heathfield's categorical statement, it is not an
    absolute given that there will never be an asm keyword in C. But it
    is unlikely because it's already clear that the asm keyword in C++ has
    not served to truly standardise the syntax of inline assembly.

    At the end of the day, the committee could probably spend many man
    weeks deciding issues on an __asm keyword, but for what? Most
    implementations will keep their existing syntax, and most programmers
    who use inline assembly will no doubt continue to prefer the localised
    syntax because it's less cumbersome than any standard syntax.

    --
    Peter
    Peter Nilsson, Oct 29, 2006
    #14
  15. Peter Nilsson <> wrote:

    (Crossposted to comp.std.c, with followups directed there, hopefully
    appropriately. The original post discussed the possibility of whether
    __asm or something similar to it would be added to the C standard.)

    > Contrary to Richard Heathfield's categorical statement, it is not an
    > absolute given that there will never be an asm keyword in C. But it
    > is unlikely because it's already clear that the asm keyword in C++ has
    > not served to truly standardise the syntax of inline assembly.


    One idea that was not mentioned in the original thread (I imagine for
    good reason, because it's a half-baked and probably stupid idea that
    occurred to me reading your post) would be to allow for some kind of
    conditional assembly, just perhaps something like

    #pragma assemble
    #pragma X86 /* Inner pragma's implementation-defined */
    /* Inline assembly, which the implementation can ignore or not */
    #pragma no-assemble
    /* Stock C code for implementations that can't or won't accept the
    * assemble pragma: */
    for( i=1; i < 10; i++ ) {
    foo();
    /* ... */
    }
    #pragma end-assemble

    The end result would be something like "If the implementation attempts
    to inline the assembly code contained within a #pragma assemble
    directive, the behavior is implementation-defined. Otherwise the
    assembly code shall be ignored and the C code contained within any
    corresponding #pragma no-assemble directive shall be compiled as
    though no directives were present." It would require adding some
    duties to the #pragma directive, but it would allow implementors to
    take a reasonable shot at using targetted assembly instructions when
    appropriate and available, and reverting to ordinary C otherwise.

    I'm sure there are reasons why this is stupid and/or impossible, or it
    would have been done already :)

    > At the end of the day, the committee could probably spend many man
    > weeks deciding issues on an __asm keyword, but for what? Most
    > implementations will keep their existing syntax, and most programmers
    > who use inline assembly will no doubt continue to prefer the localised
    > syntax because it's less cumbersome than any standard syntax.


    Indeed, but it's an interesting thought experiment to consider how the
    committee *might* add assembly to C if they chose to do so. (Well,
    interesting to me, at least.)

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Oct 29, 2006
    #15
  16. "Peter Nilsson" <> writes:
    [...]
    > Contrary to Richard Heathfield's categorical statement, it is not an
    > absolute given that there will never be an asm keyword in C. But it
    > is unlikely because it's already clear that the asm keyword in C++ has
    > not served to truly standardise the syntax of inline assembly.
    >
    > At the end of the day, the committee could probably spend many man
    > weeks deciding issues on an __asm keyword, but for what? Most
    > implementations will keep their existing syntax, and most programmers
    > who use inline assembly will no doubt continue to prefer the localised
    > syntax because it's less cumbersome than any standard syntax.


    C99 Annex J (J.5.10) shows "asm" as a common extension:

    J.5.10 The asm keyword

    The asm keyword may be used to insert assembly language directly
    into the translator output (6.8). The most common implementation
    is via a statement of the form:

    asm ( character-string-literal );

    Of course, such an extension would render the implementation
    non-conforming, since it would break some strictly conforming
    programs.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Oct 29, 2006
    #16
  17. fermineutron said:

    >
    > Richard Heathfield wrote:
    >
    >> Implementing your current algorithms in
    >> some assembly language or other is unlikely to result in significant
    >> performance improvements.

    >
    >
    > Well, it seems to me that it is not so much the speed gain as a
    > functionality gain that can be realized from assembly language.


    Um, *what*?

    > For
    > example, a while back i wrote a simple C profiler, which parces C file
    > and inserts RDTSC statements before and after each C statement,


    Note that the term "RDTSC" is meaningless unless you happen to be using an
    Intel processor in the x86 family, from the Pentium onwards, or a clone
    thereof. Any code you write that relies on an RDTSC instruction is
    inherently non-portable.

    > hence
    > determining the number of clock cycles it took to execute that line of
    > code. Now the only compiler that my profiler will work with is lcc
    > because the RDTSC is a part of intrinsics library of LCC, but it is not
    > a part of BC++ 5.02 for example. Had there been a full support for
    > assembly code within C I could have used inline assembly to do this and
    > not rely on intrinsics library of LCC.


    BC++ 5.02 supports inline assembly language. So does Visual C++. Both are C
    compilers if you tickle them properly. In both it is possible to access the
    RDTSC by using the inline assembly language supported by that
    implementation. It is also possible to access the RDTSC through inline
    assembly language in gcc, which exists for your platform. But since inline
    assembly language itself is not standardised, you may well end up having to
    rewrite the program for each new platform. If you don't like this, complain
    simultaneously to every assembly language designer in the world.

    > To the best of my knowlege most of modern C compilers produce assembly
    > code whih is as good as one could optimize it by hand, so clearly there
    > is no speed gain from asm for a general purpose code.
    >
    > Speaking of speed gains:
    > Richard, you may be pleased to hear that after reworking my code for
    > calculation of factorials of large numbers, to not use the stack space
    > but to use malloc instead, i realized a performance gain of about 60
    > times.


    I am delighted to hear it, but it would have been wiser to fix the bugs
    first. Still, okay, you've got the speed somewhere approaching sensible, so
    - better late than never, and now would therefore be a good time to fix
    those bugs.

    > So a correctly writtec C code does not loose to correctly
    > writtem asm code in speed, but it is somewhat limited in CPU control.


    It is certainly true that correctly written C code can be of comparable
    performance to correctly written assembly language code, but with the added
    advantage that it can run on any computer. Weighing C down with some way of
    tickling the frobnitz might sound attractive to those with a frobnitz-based
    machine, but everyone else is bound to see it as pointless fluff.

    > Theoretically it seems possible to develop a subset of assembly
    > languages which are used by motern CPUs


    Feel free to try. Don't forget to include CPUs manufactured by Cray, Unisys,
    the mainframe division of IBM, Analog, Motorola... and many many more
    besides. Once you see how long the list is, and how many different assembly
    languages with different syntaxes are out there, you'll realise why nobody
    is doing this.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Oct 29, 2006
    #17
  18. fermineutron

    Guest

    jacob navia wrote:
    > wrote:
    > > fermineutron wrote:
    > >
    > >>Is there a good reason why __asm is not a part of current C standard?
    > >>

    > >
    > > Yes. There's no portable assembly, using it makes your code
    > > non-portable between different implementations.
    > >

    >
    > My qfloat package has been ported to linux/windows/ and it will run
    > (unmodified) under Solaris, Mac (x86) and aix (x86).
    >
    > Assembly is quite portable between OSes, but not within
    > different processors


    Seems like you're using an odd definition of "portable" here. On
    common platforms assembly is not portable between different
    compilers/assemblers on the same OS and architecture, let alone between
    OSes. Certainly on a single architecture it's possible to write an
    assembler that runs under many OSes, but having just one standard
    assembly language even in one OS is _not_ the current state of the
    world on everyday architectures--witness the x86 example I gave in the
    message you replied to.
    , Oct 29, 2006
    #18
  19. "fermineutron" <> wrote in message
    news:...
    > Theoretically it seems possible to develop a subset of assembly
    > languages which are used by motern CPUs and include in a C standard a C
    > library which would allow user to use the assembly subset. Since it is
    > a limited subset and its sintax is goverened by C it should not present
    > portability challenges with possible exception of older systems. any
    > thoughts about this?
    >


    You should ignore any response Healthfield gives to your question.

    This problem was solved in the very first assembly language:
    http://en.wikipedia.org/wiki/Autocode

    A modern version is available here:
    http://microautocode.sourceforge.net/

    It has also been solved by many other languages, the most effectively by
    FORTH and C. If hadn't been solved, the basic features of the C language
    wouldn't be portable (at all):

    constants
    variables
    simple flow control (if,while,etc)
    complex flow control (procedures, setjmp)
    arithmetic (addition, bitshifts)
    pointers

    The above functionality of C can be represented by 16 "actions" and 20
    arithmetic operations. That means that C can be written on an interpreter.
    The highly portable QEMU emulator reduces host specific CPU instructions to
    "micro-ops" for a virtual machine. Those "micro-ops" could be considered to
    be a portable assembly. Research into the FORTH language, shows that the
    _entire_ functionality of FORTH language (which is just as powerful as C)
    reduces to 13 "primitives." Many years ago, I personally reduced the full
    functionality 6502 instruction set (56) to minimal set of 13. Betov, the
    nemesis of Randall Hyde, has reduced the x86 instruction to a minimal set
    for his own use.

    The table I compiled (below) is a basic comparison of the required
    functionality of various FORTH's, C libraries (including Plauger, Redhat),
    OS's (GNU, HURD) , and Java.

    The following table lists these:
    1) primitives - smallest FORTH instructions, coded in assembly
    2) functions - FORTH functions, coded in FORTH
    3) syscalls - OS specific system calls, usually through an interrupt
    interface
    4) bytecodes - interpreter functions

    Note that primitives and functions are small routines in assembly and FORTH
    respectively, while the other two are large assembly routines.

    3 primitives - Frank Sargent's "3 Instruction Forth"
    13 primitives - theoretical minimum needed to implement full FORTH
    16,29 primitives - CH Moore's word set for the F21 CPU (minimal or full)
    18 syscalls - OS specific functions required by P.J. Plauger's Standard
    C Library
    19 syscalls - OS specific functions required by Redhat's newlib
    20 primitives - Philip Koopman's "dynamic instruction frequencies"
    25 primitives - CH Moore's instruction set for MuP21 CPU
    36 primitives - Dr. CH Ting's eForth, a highly portable forth
    40 syscalls - Linux v0.01 (67 total, 13 unimplemented, 14 minimally, 40
    moderately)
    46 primitives - GNU's GFORTH for 8086
    58-255 functions - FORTH-83 Standard (255 defined, 132 required, 58 nucleus)
    60-63 primitives - considered the essence of FORTH by CH Moore
    72 primitives - Brad Rodriguez's 6809 CamelForth
    74-236 functions - FORTH-79 Standard (236 defined, 147 required, 74 nucleus)
    94-229 functions - fig-FORTH Std. (229 defined, 117 required, 94 level zero)
    ~120 syscalls - OpenWATCOM v1.3, calls DOS, BIOS, DPMI for PM DOS apps.
    133-? functions - ANS-FORTH Standard (? defined, 133 required, 133 core)
    150 syscalls - GNU HURD kernel
    170 syscalls - DJGPP v2.03, calls DOS, BIOS, DPMI for PM DOS apps.
    200 functions - FORTH 1970, the original Forth by CH Moore
    200 syscalls - Linux Kernel (POSIX.1)
    206 bytecodes - Java Virtual Machine bytecodes
    240 functions - MVP-FORTH (FORTH-79)
    ~1000 functions - F83 FORTH
    ~2500 functions - F-PC FORTH



    Rod Pemberton
    Rod Pemberton, Oct 29, 2006
    #19
  20. "Rod Pemberton" <> writes:
    > "fermineutron" <> wrote in message
    > news:...
    >> Theoretically it seems possible to develop a subset of assembly
    >> languages which are used by motern CPUs and include in a C standard a C
    >> library which would allow user to use the assembly subset. Since it is
    >> a limited subset and its sintax is goverened by C it should not present
    >> portability challenges with possible exception of older systems. any
    >> thoughts about this?

    >
    > You should ignore any response Healthfield gives to your question.

    [snip]

    That's really bad advice.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Oct 29, 2006
    #20
    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. Tricky
    Replies:
    4
    Views:
    663
    JimLewis
    Sep 21, 2010
  2. Beinan Li

    Future standard GUI library

    Beinan Li, May 18, 2013, in forum: Python
    Replies:
    51
    Views:
    556
    Chris Angelico
    Jun 15, 2013
  3. Terry Jan Reedy

    Re: Future standard GUI library

    Terry Jan Reedy, May 18, 2013, in forum: Python
    Replies:
    0
    Views:
    93
    Terry Jan Reedy
    May 18, 2013
  4. Vito De Tullio

    Re: Future standard GUI library

    Vito De Tullio, May 20, 2013, in forum: Python
    Replies:
    1
    Views:
    90
    Kevin Walzer
    May 20, 2013
  5. Terry Jan Reedy

    Re: Future standard GUI library

    Terry Jan Reedy, May 20, 2013, in forum: Python
    Replies:
    1
    Views:
    70
    Grant Edwards
    May 20, 2013
Loading...

Share This Page