Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga.tech
Subject: Re: __chip keyword is evil (was Re: Lattice bugs still?)
Keywords: __chip NOT ANSI
Message-ID: <1402@sas.UUCP>
Date: 22 Dec 89 21:05:24 GMT
References: <10415@etana.tut.fi> <9532@microsoft.UUCP> <411@enuxha.eas.asu.edu> <3756@quanta.eng.ohio-state.edu> <10011@microsoft.UUCP>
Reply-To: walker@sas.UUCP (Doug Walker)
Organization: SAS Institute Inc, Cary NC
Lines: 97

In article <10011@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes:
>dirks@phao.eng.ohio-state.edu (William R.Dirks) writes:
>% It is portable.  Just #define
>% it to something harmless to do a port.  I believe you can #define something
>% to a null string, can't you?  If not, there are several do-little modifiers
>% out there that should work ok.  Perhaps #define __chip static?
>
>This is not a good solution. It would be nice to be able to write code
>for the Amiga, to be compiled with either of the ANSI compliant compilers
>[soon for Manx 8-)]... with NO changes necessary to "port" between them.

You are more likely to be able to port with no changes by using the
keyword method than the #pragma method.  If you choose a name for a #pragma 
that another compiler implementation has chosen, you have an instant problem.
However, you can easily put a header in some include file like

#ifdef LATTICE
#define CHIP __chip
#else
#define CHIP
#endif

This only relies on no other vendors' compilers defining the symbol LATTICE.
The #pragma relies on each different #pragma syntax being unique among all
vendors.  This is ALREADY not the case with a couple of vendors in the 
MS-DOS marketplace.


>As for clean and clear code how about:
>
>char array[10];      
>
>as opposed to
>
>__chip char array[10];
>
>Which is more clear and/or clean?  I'd say the first example.  

I'd say the SECOND one is more clear.  Because if you use the #pragma way,
you have to correlate the declaration of the variable and the declaration
of the #pragma, which might be in another file somewhere.  Tell me which is
clearer the first time you mismatch the variable name with the #pragma name
in some header file or at the top of your .c file.  As to 'clean', seeing
the __chip doesn't really bother me, maybe that's just personal preference.

>As another example of keywords growing wild:
>
>% char * __saveds __asm LIB_foo(register __d0 int i, register __a0 long *lptr)
>
>__saveds? __asm? __d0? __a0?
>
>Please don't tell me these are clear. Peter even had to tell us what all
>these keywords were for! The function declaration is rather obsured.

So nobody would have to tell you what the #pragma definitions were for?
There is a LOT of additional information going on here.  Without the 
additional keywords, you are declaring a function that takes an integer and
a pointer to a long and returns a pointer to char.  WITH the definition,
you are declaring a function that preserves A4, takes an integer parameter
in register d0 and a pointer to a long parameter in register a0 and returns
a pointer to char.  Just look at the English description, and come up with
a more concise way of doing this.  Any #pragma construct to declare this
kind of information would also be wordy, and at least as hard to read.

>w-stephm@microsoft.UUCP (Stephan Mueller) writes:
>% On a more philosophical level, the __chip stuff has nothing to do
>% with any data structure or any algorithm.  It is a code generation
>% detail, and so, doesn't belong in the body of a C program which is
>% supposed to be a high-level description of the program.
>
>Yes! Good point.

No.  __chip is an attribute of the object being declared.  You tell the
compiler to put things in global data with the 'static' keyword; You tell
it the data is read-only with 'const';  you tell it it should not be
optimized with 'volatile';  you tell it to put it in CHIP memory with 
'__chip'.  I do not believe it is appropriate to put this information in
a preprocessor directive, which may be widely seperated from the definition
of the object it pertains to.

>How about it, Doug and John? (Actually, I don't know why I'm arguing
>this point, since I don't own Lattice... I guess the argument is more 
>on philosophical grounds.)

There is no way the __chip keyword will be removed - that would break
too much code, plus there is a large contingent that considers it useful.
If there is enough demand, we could implement #pragmas to duplicate the
results of #chip, but it would be at the cost of development time that,
in my opinion, could be better spent elsewhere.


  *****
=*|_o_o|\\=====Doug Walker, Software Distiller=======================
 *|. o.| ||
  | o  |//     "READY!   FIRE!   AIM!   (Software under development!)
  ======
usenet: ...mcnc!rti!sas!walker   plink: dwalker  bix: djwalker