assembly in future C standard HCF Gerry Wheeler

c

    Sponsored Links

    Next

  • 1. What does Kernighan and Ritchie mean by 'trailing'?
    This isn't entirely related to C, but Kernighan and Ritchie asks in Execise 1-18 of their C programming language book to 'Write a program to remove trailing blanks and tabs from each line of input, and to delete entirely blank lines'. What do they mean by trailing?
  • 2. Error Occured during compilation
    Hi, I am compiling code for nanosleep in CYGWIN. During compilation i get the following error Socket.cc: In method `bool Socket::hangOnConnection(int = 0)': Socket.cc:338: aggregate `struct timespec tmsp' has incomplete type and cannot b e initialized The Source realted to it is bool Socket :: hangOnConnection (int nNanoSecond) { struct timespec tmsp; /*tmsp.tv_sec = (time_t) 0; if (nNanoSecond) tmsp.tv_nsec = nNanoSecond; else tmsp.tv_nsec = 110; if (nanosleep (&tmsp, NULL) < 0) { DEBUG_MSG ("Error occured during hangOn"); return false; }*/ return true; } "struct timespec" is defined in <sys/types.h> Please suggest me how to debug it Best Regards, Abdur
  • 3. Input line reverser (2)
    Sorry to all in previous topic - I decided to start a fresh one about the same thing because the old one was getting a bit 'busy'. I've 'desk-checked' and I still can't figure out why if I enter 'he' it outputs 'ee'. Could you give me another hint? I've updated the program: #include <stdio.h> #define MAXINPUT 256 void reverse(char[], int); main() { int c; int number = 0; char s[MAXINPUT]; int i; for (i=0; (i<MAXINPUT-1) && ((c = getchar()) != '\n') && (c!=EOF); i++) { s[i] = c; ++number; } reverse(s, number); for (i=0; i<=number-1; i++) putchar(s[i]); return 0; } void reverse(char s[], int num_elements) { int i, j; for (i=0,j=num_elements-1; (i<=num_elements-1) && (j>=0); i++,j--) s[i] = s[j]; }
  • 4. PRIVATE PUBLIC macros [OT]
    Richard Heathfield a rit : > Flash Gordon said: > > >><OT> >>[Macros] are also used because sometimes for using non-standard >>things like DLLs you have to use non-standard things like >>__declspec(dllexport) where on other systems you don't. >></OT> > > > I don't know of any system where _declspec(dllexport) *must* be used in DLL > code. It's certainly not the case in Windows. I've written loads of - well, > quite a few - Windows DLLs with nary a declwhatever in sight, and they > ported perfectly well to, say, Linux without changing a single line of > source. And no, I wasn't hiding everything behind macros either. You *do > not need* to write convoluted junk in a Windows DLL. (That doesn't mean you > can't, obviously.) > If you do not use __declspec(dllexport) how does the linker know which symbols to export? Obviously it soesn't, so that exports everything. This works, but is inneficient, and can lead to name conflicts. It is better to export only those names that you need to export from a dll.
  • 5. creating a linked list - trivial :( question
    Hello, I'm a beginner in C programming and I have a problem that probably will seem trivial to most of you, however I can't find a solution... So, I have to write a data base - program should ask the user about the data and then do some operations like sorting etc. I decided to use a linked list. The code looks as follows: #include<stdio.h> #include<string.h> #include<stdlib.h> #include<ctype.h> struct somestruct { int field1; char field2[15]; struct somestruct *nextp; }; typedef struct somestruct DATA; DATA enter_data () // function that asks the user for the data { DATA temp_somestruct; printf ("field1: "); scanf ("%s", &(temp_somestruct.field1)); getchar(); printf ("field2: "); scanf ("%d", &(temp_somestruct.field2)); getchar(); return temp_somestruct; } int main (void) { enter_data(); return 0; } I want the program to use this data for creating a linked list.. then I would ask the user for next data and add this to this list.. I guess I should now create a pointer to the structure temp_somestruct (how?) and assign it to some pointer, let's say frstp (for first pointer), which at the beginnig should be 'equal' NULL... best regards, a.

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