Xref: utzoo comp.sys.amiga:46178 comp.sys.amiga.tech:8953
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!w-edwinh
From: w-edwinh@microsoft.UUCP (Edwin Hoogerbeets)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: __chip keyword is evil (was Re: Lattice bugs still?)
Keywords: __chip NOT ANSI
Message-ID: <10011@microsoft.UUCP>
Date: 20 Dec 89 18:19:39 GMT
References: <10415@etana.tut.fi> <9532@microsoft.UUCP> <411@enuxha.eas.asu.edu> <3756@quanta.eng.ohio-state.edu>
Reply-To: w-edwinh@microsoft.UUCP (Edwin Hoogerbeets)
Followup-To: comp.sys.amiga.tech
Organization: Microsoft Corp., Redmond WA
Lines: 111
Summary:

dirks@phao.eng.ohio-state.edu (William R.Dirks) writes:
% The following is quoted from the Lattice Amiga Compiler User's Guide
% page G51 without permission.  (I hope they don't get mad at me. ;) )
% 
%   "The chip, far, huge, and near keywords are extensions to the ANSI
%   standard.  The standard requires that each keyword extensions [sic]
%   be preceded by a double underscore, such as __near.  The Lattice 
%   compiler accepts the extended keywords in this form as well as in
%   the more natural form without the double underscores."
% 
% I guess "__chip" is ANSI, but "chip" breaks the rules.

Well, ANSI specifies that identifier names beginning with a double
underscore are not within the defined name space of C. This means that
if you should want to add an *extension* to the language, use the double
underscore method. The double underscore identifiers simply do not
violate ANSI.

It does NOT specify that __chip, __far, __huge or __near are reserved
keywords. If I were writing an ANSI Unix compiler, I would not have to 
support these.

This lack of specification means that they are not portable. 

I don't know if anyone would want to port code that needs chip memory to
a Unix box, but I'm quite sure that the same code might be "Manxified."

If Manx does not support __chip, but has a pragma instead, I'll be
happy.  (Any comments from those beta testers out there?)

martin@enuxha.eas.asu.edu (Ross D. Martin) writes:
% I don't see what you have against __chip.  

It is a pollution of the C language. 

C was designed to be a small language, and as such, it embodies the
"small is beautiful" philosophy quite well. Adding [non-portable] 
keywords to the language should not be done lightly, especially with
keywords like __chip, which do not have any semantic effect on the
code.

This is part of the reason Dennis Ritchie vetoed the "noalias" keyword.

% 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.

% Pragmas involve more typing to get less clear, clean code.  Not a good idea
% in my book.

Pragmas take more typing? A quicksort takes more typing than a nice little
bubblesort, but that is no reason to use the bubblesort all the time.
Programmer convenience should not override more important issues (IMHO)
like portability, efficiency, or esthetics. And especially
maintainability.

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.  

As another example of keywords growing wild:

peter@cbmvax.commodore.com (Peter Cherna) writes:
[good discussion of amiga shared libraries deleted - Thanks Peter!]
% char * __saveds __asm LIB_foo(register __d0 int i, register __a0 long *lptr)
% 
% The __saveds instructs Lattice to set up your data area (off A4) when
% anybody calls your function.  The __asm keyword states that you intend
% to specify which registers receive which parameters, as shown above.

__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.

Are there not pragmas for these, either?

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.

% Now, assuming I've convinced you we should be using #pragma, what should
% the syntax of such a #pragma be?
% 
% Proposal :
%   #pragma chip (identifier1 [, identifier2 ...])

Sounds about right. 

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.)

Followups directed to comp.sys.amiga.tech.

Edwin