assembly in future C standard HCF Gerry Wheeler


    Sponsored Links


  • 1. assignment from incompatible pointer type
    No entiendo cual es el problema, trato de agregar un solo entero al final y el compilador me avisa de ese error. Tambien tengo una pregunta dentro de la funcion: struct _nodo { int dato; struct nodo *sig; }; typedef struct _nodo nodo; /* ual es exactamente la diferencia entre **nodo y *nodo Veo que muchos abajo del anterior typedef crean algo asi typedef *nodo NODO; */ int esta_vacia(nodo *lista) { return (lista==NULL); } void insertar_dato(nodo **lista, int dato) { nodo *antes, *despues, *nuevo; nuevo= (nodo*)malloc(sizeof(nodo)); nuevo->dato = dato; if (esta_vacia(*lista)) *lista=nuevo; else { antes = *lista; despues = antes->sig; while (despues != NULL) { antes = despues; despues = despues->sig; } antes->sig = nuevo; nuevo->sig = NULL; } }
  • 2. assignment suppression in sscanf
    I noticed that the following line sscanf(buf, "%*d %lf %lf %*lf", VX+n, VY+n); leads to the following gcc warning: warning: use of assignment suppression and length modifier together in gnu_scanf format I would assume this is due to the %*lf format specifier. To solve the problem, i noticed that changing the line to sscanf(buf, "%*d %lf %lf %*f", VX+n, VY+n); makes the warning go away. It appears that %*lf is something 'bad' to use, but why? Is my solution indeed the best way to get rid of this warning and make my code more C89 compliant? Thanks, Bart -- "Share what you know. Learn what you don't."
  • 3. cast
    I have written this wrapper function that seems to compile into an object file just fine. #include "main.h" struct addrinfo ad, *adp; static int stat; struct addrinfo **ginfo(char *port) { memset(&ad, '\0', sizeof ad); ad.ai_family = AF_INET; ad.ai_socktype = SOCK_STREAM; ad.ai_flags = AI_PASSIVE; if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) { fprintf(stderr, "Error: %s\n", gai_strerror(stat)); exit(EXIT_FAILURE); } return (struct addrinfo **)stat; } Just above is the code in question. I had to make this cast to return my function's return type because stat is an int. I was told that when code is written right; casts shouldn't be neccesary. Should I make any changes to this? Is what I just stated about casts correct? Bill

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 23 guest