assembly in future C standard HCF Gerry Wheeler

c

    Sponsored Links

    Next

  • 1. Could somebody tell me the difference?
    between printf("hello, world\n"); and printf("goodbye, universe\n"); ?
  • 2. printf and size_t
    Should the following work *if* I have a c99 compiler please? #include <stdio.h> int main(void) { size_t t = 42; # if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* C99, so it should support %zu? */ printf("%zu", t); # else /* Not a C99 compiler - use lu. */ printf("%lu", (unsigned long)t); # endif return 0; } I'm using gcc 3.4.2 and the output is zu, this, I believe, shows that the printf supplied doesn't recognize %zu as a valid format specifier? BTW, where would you use plain ol' %z, vs. %zu, i.e, for what data type? Ta, rayw
  • 3. scanf %[] information
    Hi. I'm trying to find some tutorial-type information on using scanf's regular-expression subset for parsing - to no avail so far. I've looked through quite a few posts to clc, but none that have helped me understand what's really allowed, also, the c-faq - when searched for scanf regular (using google site-search) didn't help. Does anyone know of some source - preferably web-based with examples - that could help me understand what's allowed (e.g., subset of normal regular-expression syntax is valid)? Thanks danny
  • 4. calloc()
    Hi, What would cause calloc() to return a NULL pointer? Is the system simply out of memory? Regards, Michael
  • 5. naming convetions
    Hi I have problems giving my structs good names, I usually name them after what they are (of course) so if I have, say, a window struct, I name it struct window, I usually don't bother typedefing them. But now I can't use the window as variable name (yes, I know I *can*, but I won't, I don't want to be confused by using the same name for both struct and variable). I can use the name w for the variable in functions that do operations on the window, that works, but if I add a struct widget, I don't want that to also have the name w in function. I want to be consistent in my variable naming in the function arguments, and it would be confusing to use w for both windows and widgets. Of course I can just use wt or anything as a variable name, but I thought maybe I should change the name of the struct so that I can freely choose the names of the variables. Maybe prefixing or postfixing the structname, I've seen names ending with _t for type, but that violates the standard, right? Maybe _s is a good choice? So what I'm asking for is your opinions on how I should name things. I understand that there are many different styles and tastes of this, and that I have to choose myself, but I'll gladly take any opinions from you. I want to know if there is any common or pouplar way to name things. Thank you!na

Re: assembly in future C standard HCF Gerry Wheeler

Postby Walter Banks » Sat, 04 Nov 2006 22:35:39 GMT

As this thread wanders off topic this industry was introduced to a new
mnemonic in Byte article about decoding the undocumented
Motorola 6800 instructions. The HCF (Halt Catch Fire) opcode $DD
or $D9. HFC locked up the processor and cycled the address bus
The author of that article was Gerry Wheeler.

Gerry Wheeler, 54, died October 15, 2006, advanced non-Hodgkins
lymphoma cancer. Gerry made significant contributions to the technology
of the embedded systems world and was a key part of the development
of many household name products.

Programmer, Ham KG4NBB, author, father, husband, active commuity
participant Gerry will be missed by all.

w..


Similar Threads:

1.assembly in future C standard

Peter Nilsson < XXXX@XXXXX.COM > 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.



Return to c

 

Who is online

Users browsing this forum: No registered users and 38 guest