assembly in future C standard HCF Gerry Wheeler


    Sponsored Links


  • 1. printing a block of text
    Hi, Could you tell me what the equivalent of this perl code would be in C please? print EOT<< I want to print over multiple lines in c without doing lots of printfs EOT Thanks! Ed.
  • 2. bool variable.(a non-standard question)
    I have code which says #define MYBOOL int This code is very old. people who have written is not avaible. I was thinking what could be reason. 1) bool datatype was not available that time (10 years back: correct me if i am wrong) 2) int was word aligned (16bit and 32bit). Writter of above code doesnt want to give choice to compiler. if we say bool , compiler can represent this on his way (again,correct me if i am wrong) This much i can think of it. even in many books, i have seen author using int as a flag. example Richard Stevens, "advance programming in unix environment" . and this book uses 'restrict' keyword. Now, i have to change it for 64bit arch. In my system, performance is more important thn anything else. I thought of changing it to long on 64arch. #define MYBOOL long Any comment on this will be appreciated.
  • 3. data stucture using c
    i m in touch with c from last 1yr now just started data stucture in c and i have a problem in linear search and binary search if any one could explain with one example each thanks in advance
  • 4. sequence points and evaluation order
    I've been playing with splint, which returns the following warning for the code below: statlib.c: (in function log_norm_pdf) statlib.c(1054,31): Expression has undefined behavior (left operand uses errno, modified by right operand): (log(x) - mu) * (log(x) - mu) Code has unspecified behavior. Order of evaluation of function parameters or subexpressions is not defined, so if a value is used and modified in different places not separated by a sequence point constraining evaluation order, then the result of the expression is unspecified. How can the offending expression be written so that the order of evaluation is properly specified? Can t2num be assigned the value of any single expression equivalent to ((log(x)-mu) ^ 2) * -1.0? /* Return log normal probability density at x. mu=a_mean(ln(X)); sigma=s_stdev(ln(X)) (output OK) */ double log_norm_pdf(double x, double mu, double sigma) { double t1, t2num, t2den; if(x <= 0.0) return 0.0; t1 = 1.0 / (sqrt(2.0 * PI) * sigma * x); t2num = -((log(x) - mu) * (log(x) - mu)); /* problem here */ t2den = (2.0 * (sigma * sigma)); return t1 * exp(t2num / t2den); } BTW: this function has been rigorously tested.

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.


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++ ) {
    /* ... */
#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)      | don't, I need to know.  Flames welcome.

Return to c


Who is online

Users browsing this forum: No registered users and 30 guest