assembly in future C standard HCF Gerry Wheeler

c

    Sponsored Links

    Next

  • 1. BOOKS ON C
    What is a good book to purchase that will give me a good foundation on learning C? I currently have Teach Yourself C. By Herbert Schildt.
  • 2. question about directives
    I just wrote a simple directive to test if the casting of a class pointer has the proper member variable setting. So, for the class (this is pseudo code) class foo { public: foo() {type=enumFooClass;} int type; }; instead of saying a = (foo*)val; my directive would be used like a = fooPtr(val); and look like this: #define fooPtr(f) (f!=NULL && (f)->type==enumFooClass) ? (foo*)f : NULL) So, if the type var checks out, things get cast as expected. If the type var has the wrong setting, the directive returns NULL and a low memory address condition exists (this is much more easily detected by the debugger I'm using than an invalid cast). I implemented this and it works great, but what I didn't see coming is when I use a function call as the directive variable, it gets called everytime "f" is referenced. E.g., fooPtr(bar(a)) gets implemented as (bar(a)!=NULL && bar(a)->type==enumFooClass)..... this can be a real problem if repeated calls to "bar(a)" perform an operation, such as popping the variable off a stack, which is the problem I'm having. How do you write a directive such as this that will accomodate a function call in the parens? I could just use an inline function, but I'd rather not if I can do this with directives. Thanks, Rich
  • 3. UTF-8 locales
    As I understand it (correct me, if I am wrong) Unicode came into picture so that a document containing multiple language characters can be supported like somebody can write a document comparing Korean and Chinese in French language. Now, I am looking at all UNIX platforms and seems like all Unix (AIX, HP, Solaris) platforms support Unicode by supporting language/region specific UTF-8 locales like fr_FR.UTF-8, ja_JP.UTF-8, ko_KR.UTF-8 etc. Now in order to use UTF-8 for Japanese, I have to set locale to ja_JP.UTF-8. To use UTF-8 for Korean, I have to set locale to ko_KR.UTF-8. With this approach it's not possible to mix multiple language characters. Doesn't this defeat the whole purpose of Unicode ? Am I missing something ? Thanks in advance for any insight you can provide.

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