🚀 go-pugleaf

I'm rather surprised - Edwin usually does better.

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

Let's see - you have code with a __chip keyword in it, and you compile
it. The code will give you an error and fail to compile. You run an
editor on it and change the keyword to whatever is appropriate.

Now, assume the keyword is a pragma. If you're lucky, either the
compiler will give you an error, or it'll give you a warning and
you'll notice it. In either case, you run an editor and fix the
problem. If you're not lucky, you'll try running the compiled program
without noticing that something failed, and get garbage results. You
now get to enter the debug cycle. This is supposed to be an
improvement?

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

This should be compared to to the "pragma" construct, which allows for
doing pretty much arbitrary things to the language, and have an
arbitrary structure. Of course, they aren't part of the _language_
proper, so you can ignore them. But doing so could make debugging code
that depends on them that much harder.

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

Could you explain why:

#if defined(LATTICE)
#define CHIP	__chip
#elif defined(MANX)
#define CHIP	<whatever>
#else
#define CHIP	Error_No_Chip
#endif

is so much worse than:

#if defined(LATTICE)
#pragam <whatever>
#elif defined(MANX)
#pragma chip <list>
#endif

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

Methinks you're dreaming. But, assuming that Manx actually gets
something that looks ANSIish out the door, you'll be able to do that
with the exising compilers - except, of course, for having to have
different makefile (or whatever you want to call them) for the two
systems. Both compilers allow you to compile a file such that
everything in it lands in chip memory. So the code file doesn't have
anything in it indicating that it's in chip memory; it's all in the
makefiles.

As an aside, I consider this solution intermediate between the #pragma
that lists objects to be put in chip and a chip keyword. The reason is
locality of reference. A chip keyword requires that the information
that this object is going to be in chip memory be associated with the
object (you could implement it so this wasn't required; not clear that
that's a good idea). The makefile approach means you can find all such
information in one place, even though it isn't local. The chip pragam
to make things local means you can make make such information local,
but makes doing so hard - and requires that you check all include
files to see if one of makes this object chip.

If you really want to use pragmas, I'd suggest:

#pragma chip

which puts the next defined object in chip memory. This gives back the
locality of information property of keyword.

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

Nope. Lattice doesn't believe in using pragmas for changing the
semantics of the code. Of course, you can get the same effect without
using any of those keywords by combining the correct compiler flags
with an understanding of how it allocates arguments to registers. 6.0
is going to make all of this much, much easier.

BTW, how would you specify pragmas to cause the code to compile with
the arguments as specified?

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

This comment applies to _pragmas_ - of any kind - as well. You
shouldn't use them in code that you want to be portable.  They should
be used to control things other than the semantics of the program, and
don't beling in the body of a C program.

I agree that __chip & etc. are ugly. However, pragmas are worse. They
shouldn't change the semantics of the program - which you're trying to
make them do. From a programming standpoint, they allow for text far
removed from code to cause that code to break, which is a bad thing.
It's part of the reason Dennis Ritchie vetoed the "noalias" keyword.

	<mike
--
I went down to the hiring fair,				Mike Meyer
For to sell my labor.					mwm@berkeley.edu
I noticed a maid in the very next row,			ucbvax!mwm
I hoped she'd be my neighbor.				mwm@ucbjade.BITNET