assembly in future C standard HCF Gerry Wheeler


    Sponsored Links


  • 1. Reuse allocated memory
    Hi, I have a bulk of data available in safearray pointer. I want to copy that data to another pointer. I tried using malloc for new variable and memcopy. But due to virtual memory restrictions the allocation failed. This is because the system memory can not allocate another volume of memory. My requirement is , without allocating the new memory, how can I copy the data from safe array to my variable. Since after copying I dont need the safearray data anyway. so during memcopy process itself it can be cleared. So that with less free memory i should be able to copy the whole content from safe array to my long pointer variable. Or even I can use the same data in safearray memory to my new pointer and safearray poiner can be cleared. Is there any functions or api's or your idea available? Please let me know. -Thanks in advance santhakumar
  • 2. Do input functions use fgetc inside them or read()
    Do the "larger" input functions like scanf, gets, fgets use fgetc to take input or an operating system call function like read() (I know it could be any "way", but I'm trying to find out how it's best to "think of it")? I've seen some explain it as if they call fgetc internally, then I've seen some people explain it as if they call some lower level OS system call like read(). I've even seen some older posts talk about a input functions interacting directly with drivers (tty comes up a lot). I've been searching through the deja/google archives and there is a mixture of "ways of thinking how larger input functions operate." This is important to figure out little nook and crany issues like the eof/error post recently that made me more confused than I've ever been before about input. This is a sticking point in my journey to understand these topics on my own- so pls try not to give me RTFM answers :-). I also understand many things I'm talking about are not part of the C standard, but they are interfaces to the C standard and many C gurus have brought these topics up in previous posts because I think it helps understand these standard input functions. Side note: So far this is how I picture the things in my head. scanf/gets | | \ / fgetc | | \ / read() (system call) | | \ / driver (like tty)
  • 3. init pointer
    Hi, small question concerning pointer: How do I allocate and have access to this pointer in C: float **x; such that I can work with it like an array, e.g. x[0][0]? Thanks a lot.
  • 4. get number at end of string
    Here is a function I have to get a number at the end of a string. I'm posting this in case it proves helpful to someone. Comments are welcome. int getnum(char *str) { char buffer[BUFSIZE]; char *buf = buffer; int i; for (i = 0; i < BUFSIZE-1; i++) { if (str[i] == '\0') break; if (!isdigit(str[i])) continue; *(buf++) = str[i]; } *buf = '\0'; if (buffer[0] != '\0') { return atoi(buffer); } else { return -1; } }
  • 5. creating a pthread
    I have an incomplete pthread_create function that looks like this: pthread_create(pthread * thread, pthread_attr_t *attr, void * (*start_routine)(void *), void *arg){ } The third parameter is where my new thread will start to execute: void * start_routine(void *param){ } my questions is: Will the fourth parameter (void * arg) be the parameter send to the start_routine function?? JS

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