Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!sun-barr!decwrl!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (With friends like these, who needs hallucinations) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: __chip keyword is evil (was Re: Lattice bugs still?) Message-ID: Date: 21 Dec 89 19:52:24 GMT References: <10415@etana.tut.fi> <9532@microsoft.UUCP> <411@enuxha.eas.asu.edu> <3756@quanta.eng.ohio-state.edu> <10011@microsoft.UUCP> Sender: news@decwrl.dec.com Followup-To: comp.sys.amiga.tech Organization: Missionaria Phonibalonica Lines: 131 In-reply-to: w-edwinh@microsoft.UUCP's message of 20 Dec 89 18:19:39 GMT 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 #else #define CHIP Error_No_Chip #endif is so much worse than: #if defined(LATTICE) #pragam #elif defined(MANX) #pragma chip #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.