assembly in future C standard HCF Gerry Wheeler

c

    Sponsored Links

    Next

  • 1. passing parameter to thread
    How do I pass parameters to created thread..here is the code(but it can't pass data..it uses global variable) #include <windows.h> #include <stdio.h> DWORD Sum; DWORD WINAPI Summation(LPVOID Param) { DWORD Upper = *(DWORD*)Param; for(DWORD i=0; i<= Upper; i++) Sum += i; return 0; } int main(int argc, char *argv[]) { DWORD ThreadId; HANDLE ThreadHandle; int Param; if(argc != 2) { fprintf(stderr, "usage : %s number", argv[0]); return 1; } Param = atoi(argv[1]); if( Param < 0) { fprintf(stderr, "an integer >= 0 is required\n"); return 1; } ThreadHandle = CreateThread( NULL, //default security attributes 0, //default stack size Summation, //thread function &Param, //parameter to thread function 0, //default creation flags &ThreadId); //returns the thread identifier if (ThreadHandle != NULL) { //wait for thread to finish WaitForSingleObject(ThreadHandle, INFINITE); //close the thread handle CloseHandle(ThreadHandle); printf("sum = %d\n",Sum); } }
  • 2. Question about compiling files
    Hello, all. I meet a question about compiling files. Eg., I have three files named myfile.h, myfile.c and the main.c file, and there is a function, ex, void myfun(...). If I put myfun(...) in the main.c file like the following, .... void myfun(...) { .... } int main(void) { ... } it works well. But when I move myfun(...) to the file of myfile.c, and a make error message appears when the same command "make" runs, although I have declear the myfun(...) function in the main function. The message seems that the myfun(...) is not decleared before used. And this is my Makefile: #test Makefile objects=main.o test:$(objects) cc -o test $(objects) -lgsl -lgslcblas -lm .PHONY:clean clean: rm test $(objects) My code may be not very clear, so I don't attach it here. I just move a function from one file to another, and give some declearation in the header and main files. But it cann't work. It will be appreciate for you help. Thanks.
  • 3. Union In C
    Hi All, have some experience in C prog language. I have small doubt abt using unions in C language. Here is a small programm in vc++: union a{ int b; char c; }d; int main () { d.b=360; d.c=1; printf("%d %d ",d.b ,d.c,); } In union largest sized member memory is reserved by union . but for a sake if i declare this way then i've seen the d.b value is showing 257 in output window and if i declare d.b =255 or below 255 that then it is showing the what is last defined for d.c, means value is =1 for all variables. So Here for first time how the memory is overwritten? Please let me know on this . I am looking forward to you . Thanks Chinmoy
  • 4. Using timersub on Ubuntu Linux
    I'm trying to use the timersub macro on Ubuntu Linux. When I compile I get the error: <file>.c:<line #>: warning: implicit declaration of function 'timersub' Where <file> is the file name and <line #> is the line number. I take that to mean I that the timersub macro hasn't been #included. My code looks about like this: #include <time.h> #include <sys/time.h> struct timeval *time_start, *time_end, *time_diff; gettimeofday(time_start); // some stuff runs gettimeofday(time_end); timersub(time_start, time_end, time_diff); What am I doing wrong? -Aaron
  • 5. Size of file
    off_t fgetstat(const char * pathname) { struct stat * stbuf; if (lstat(pathname, stbuf) == -1) { fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno)); exit(EXIT_FAILURE); } return stbuf.st_size; }

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