assembly in future C standard HCF Gerry Wheeler


    Sponsored Links


  • 1. arrays of strings and pointers
    I have the following code: char buf[10][10000]; printf("%lp\n", buf); printf("%lp\n", &buf[0]); printf("%lp\n", buf[0]); printf("%lp\n", buf[1]); printf("%d\n", buf[1]-buf[0]); The first 3 printfs give the same result and the last 2 show that buf[1] is 10000 away from buf[0]. Is this the expected result? I had assumed that the result would have been: buf: This should be a pointer to the first of a set of 10 pointers. These pointers would be accessed by buf[0] ... buf[9]. They would point to the 10 10000 char strings (which are a single block of memory). &buf[0] This should be the same as above. buf[0] is the same as *(buf+0), so &buf[0] is &(*(buf+0)) which should be just buf. buf[0] This should point to the first string. It shouldn't be the same as &buf[0]. buf[1] This is as expected 10000 higher than buf[0]. I have a function that takes as its input an array of pointers: void funct(char **base); I had assumed that I could just pass buf to it, is it necessary to create the 10 array of pointers manually ? However, it looks like buf is of type pointer to a char rather than pointer to a pointer to a char.
  • 2. scan: which format for a long long int
    Which format I have to use in scanf, to format a long long int (64bits int __int64 in MS VC++). Thanks in advance
  • 3. How is this useful ???
    hi all I was just browsing some code(actually apache) and i found this : typedef struct apr_pool_t apr_pool_t How this is usefull?? Thanx in advance Aman Aggarwal
  • 4. manipulate string
    LS, I've a problem to get the year, month and day from the following string: "20051027" #include <stdio.h> #include <string.h> char str[9]="20051027"; char year[5], month[3], day[3]; int main(void){ printf("String str: %s\n",str); strncpy(year, str, 4); year[4] = '\0'; printf("%s\n", year); //But how to get the month in the string 'str'? printf("Year:%s\n",year); printf("Month:%s\n",month); printf("Day:%s\n",day); getchar(); return 0; } PS. It is not a problem to concert it to integers. Greetz, Marcel
  • 5. [OT] Trouble using recursion in functions
    Skarmander wrote: > Eric Sosman wrote: >> [...] > Eww, degenerate for-loop with error handling inside. I'd expend a > separate boolean for that one. Years ago I read an article by Knuth (not "Structured Programming with Goto," but something else) where he made the case for a more generalized looping construct than most languages provide as built-in. His proposal, IIRC, allowed both the test-and-terminate and the advance-to-next pieces to appear anywhere within the iteratively-executed body. I'm sorry I don't recall the examples he provided (nor where I saw the article), and can't give more detail. Anyhow, a problem with C's `for' is that the advance-to- next and the test-and-terminate pieces must be adjacent in the execution sequence; there's no way to separate them. In many situations this leads to extra flag variables or to repetition of the code, both of which I find distasteful. An empty for(;;) seems to me less than ideal, but better than one can do with the more "regular" loop forms C provides. Remember: "De gustibus non disputandum est." (That's Latin for "There's no point in arguing with Gus.") -- Eric Sosman XXXX@XXXXX.COM

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