w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (12/21/89)
In article <1388@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: % #pragma is extremely non-portable. Each compiler can implement any #pragma % keyword any way they wish, and you cannot #define a #pragma away. You can % get rid of __chip simply by defining it to nothing. ??? If a compiler comes across a pragma that it doesn't recognize, it should skip it. All you have to do is put in the #pragmas for each compiler and leave the actual C code alone. That's portable, isn't it? Ignoring pragmas was for portability, wasn't it? This ignoring of unknown data is the reason that IFF is so neat. If an IFF reader comes across a FORM that it doesn't understand, it gets the length of that FORM (since the FORM header is standard) and merely skips it. Forwards compatibility. Any program can read that IFF file, and extract only that information useful to it. % And then what would the code look like? #pragma chip(NormalArrayHere) /* put it in chip mem */ #pragma saveds(NormalFunctionHere) /* index off a4 */ #pragma asm d0 NormalFunctionHere(a0,a1) /* specify register calling */ /* conventions? */ char NormalArrayHere[10]; int NormalFunctionHere(int arg1, int arg2) { blah blah blah; NormalArrayHere; } And if you want, put all the pragmas in pragma.h, and have unadulterated C code in the actual .c file. Doesn't look too bad, does it? % Actually, now that I think about it there is a portable way to define a non- % portable feature. If every compiler variant had an assigned identifier, % the #pragma directive could have been implemented % % #pragma <compiler-id> <pp-tokens> <newline> % % But there would be a question of who would define the compiler id's. % In any case, ANSI did not define it this way, so there you are. That's not a bad idea actually! But as you say, it's not in there. You could do: #ifdef LATTICE #pragma foo #else #pragma bar #endif If you don't like to have your pragmas automatically ignored. davewt@NCoast.ORG (David Wright) writes: % There is nothing wrong with using keywords like __chip or % __fast in a C program. True, they are not portable, but SO WHAT?? No other % system NEEDS them. If you could guarantee that every possible C routine that uses __chip under the Amiga's OS is not useful on, let's say, Amix (also on the Amiga) or any other operating system (Minix on the Amiga? Heck, how about on a 386 box running OS/2 and custom hardware), then I'll stop complaining. % They fill a need on the Amiga, and there is no way % to make them portable. Making them portable can be done with pragmas. % specify WHICH type of memory a certain segment belongs in. You can't use % ANY of the ANSI definitions (or the Microcrud either), as these are also ^^^^^^^^^ - ahem - % implemented on the Amiga and are used for different reasons. % There is absolutely NOTHING wrong with putting in non-portable % keywords or definitions in ANY C program, when it is done for these % reasons, and when it is so easy to remove when transfering code to % another machine. Okay. What if other compiler writers define their own keywords for MS-DOS, or OS/2, or Unix, or Mac, or the ST, or even Amiga Manx? You would end up with "portable" abominations like this: #ifdef a lot of stuff #define __VariousThings /* NULL */ #elif other stuff #define __VariousThings /* NULL */ #endif int __chipmem __chip __asm __far * __registers __saveds __based RegisterFunction(register __a0 __ax int arg1, register __a1 __dx int arg2) { } Tell me: is that clear? Edwin
duncant@mbunix.mitre.org (Thomson) (12/28/89)
Those (misguided) individuals in favor of keywords such as __chip should check the ANSI standard. They will find that, in ANSI C, there is no such thing as __chip, and therefore a program which uses it is not an ANSI C program, and a compiler which accepts it is actually a compiler for a superset of ANSI C. On the other hand, the standard does include a #pragma keyword, and it seems clear that this is the method intended by the ANSI comittee for compilers to implement such gross things as specifying which type of memory some data structure should go in. Of course there will always be those who don't care about whether they are writing in "standard" C. As long as their code compiles with their compiler they are happy. This is OK for code which will never be distrubuted, but if you intend to pass your code arouknd PLEASE make an effort to conform to the standard. Regarding portability, the real problem here is a minor disgustingness with the Amiga architecture. It's a bit gross to only have part of the machine's address space accessible to the display hardware. It seems to me that the best way to solve the problem is not to use static allocation for structures which must be in chip memory. Instead, call AllocMem and ask for chip memory. This won't be portable to any other system which doesn't have an AllocMem routine, but at least it would be portable to any C compiler for the Amiga, and you don't have to use any #pragmas. But if you really want to have static allocation, #pragma is clearly the standard way to go. At least with #pragma someone reading the code knows that this is some implementation defined thing which can be ignored when attempting to understand the meaning of the code. By the way, I don't see anything in the ANSI standard which indicates that #pragma is not supposed to be used for anything which would alter the semantics of the program. (I've got a fairly old draft, maybe something was added??) Duncan Thomson
peter@sugar.hackercorp.com (Peter da Silva) (12/28/89)
In article <85006@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: > Those (misguided) individuals in favor of keywords such as __chip > should check the ANSI standard. Names beginning with two underscores or one underscore and an uppercase letter are reserved to the implementation and may be used for any purpose the implementer desires. Names beginning with one underscore and anything but an uppercase letter may be used with file scope, but as externals are reserved to the implementation. Examples discussed on the net have included new keywords (__near, __far, etc), as well as more mundane things like hiding library routines (_write) and stuff in headers (_IOB). Programs that USE them are not portable programs, but the semantics being discussed are machine specific anyway. On the other hand #pragma is not allowed to change the semantics of a program. A compiler is free to ignore any #pragma so long as the semantics of the resulting program are retained. #pragma CHIP(whatever) doesn't fulfill this restriction. Examples of legal pragmas include: #pragma line(45) #pragma list(on) #pragma builtin(strcpy) so long as the builtin version is identical to the subroutine. Interestingly enough, the latter can also be achieved by using reserved keywords: #define strcpy _BUILTIN_strcpy has been brought up as an example. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
jac@muslix.llnl.gov (James Crotinger) (12/31/89)
I guess I'll give up and add my two cents to the __chip vs. #pragma argument. I'm in favor of __chip (and all of Lattice's other "pollution") for the following reason: it localizes important information about the variable. Putting all these into #pragma's in a pragma.h file is a software engineering nightmare! Especially the _d0 type of stuff, where if you try to call that function from another file, and haven't properly prototyped the function (by forgeting to type all the #pragmas), then you'll be wrong. Sure, you can localize the #pragmas, but I think: #pragma chip foo long foo[100]; #pragma chip bar long bar[30]; is much uglier than using __chip. Jim
deven@rpi.edu (Deven T. Corzine) (01/04/90)
On 28 Dec 89 00:02:37 GMT, duncant@mbunix.mitre.org (Thomson) said: Thomson> Of course there will always be those who don't care about Thomson> whether they are writing in "standard" C. As long as their Thomson> code compiles with their compiler they are happy. This is OK Thomson> for code which will never be distrubuted, but if you intend Thomson> to pass your code around PLEASE make an effort to conform to Thomson> the standard. Um, excuse me, but what point is there in using "standard" C when there's no way the code will be portable? Chip memory is specific to the Amiga architecture; anything which must be in chip memory won't run on another machine anyhow. At least __chip is more logical than adding another bizarre #pragma syntax. Any special graphics and sound programs you write for the Amiga certainly aren't going to run unmodified on a Unix box. If portability among Amiga compilers is a concern, then by all means, use AllocMem. But, if other Amiga compiler-writers were to follow Lattice's example and incorporate __chip, it wouldn't be a problem. Certainly a far better solution than all those old "fixhunk" programs to run on binaries... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
duncant@mbunix.mitre.org (Thomson) (01/09/90)
In article <4839@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Names beginning with two underscores or one underscore and an uppercase >letter are reserved to the implementation and may be used for any purpose >the implementer desires. Names beginning with one underscore and anything >but an uppercase letter may be used with file scope, but as externals are >reserved to the implementation. > Section 4.1.2 of (my draft of) the ANSI standard states that "All external identifiers that begin with an underscore and iether an upper-case letter or another underscore are reserved." However, this simply means that these identifiers may be defined in standard header files, so the user should not use these names. The standard does NOT say that the implementor may use these identifiers to change the syntax of the C language, as you are doing when you introduce things like "__chip". >as well as more mundane things like hiding library routines (_write) and stuff >On the other hand #pragma is not allowed to change the semantics of a program. I'm sorry, but I can't find this in the standard. Can you direct me to the appropriate paragraph? Or perhaps this is something from the "Rationale"? Again, I think that you guys are missing the point. It seems to me that the ANSI committee provided #pragma exactly for handling non-standard things, such as "__chip", which can't otherwise be done in the language. Duncan Thomson
giguere@aries5.uucp (Eric Giguere) (01/09/90)
In article <86113@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: >Again, I think that you guys are missing the point. It seems to me that the >ANSI committee provided #pragma exactly for handling non-standard things, >such as "__chip", which can't otherwise be done in the language. I really don't know what the fuss is about. It seems to me that "__chip" is a good solution for a unique Amiga feature... after all, the MS-DOS world has its "near", "far" and "cdecl" keywords. I can't recall a passage in the ANSI standard that specifically forbids implementation-specific language extensions. Personally I think a #pragma would be quite ugly and confusing. As for portability... well, as other people have pointed out, it's unlikely that an Amiga program that uses the "__chip" keyword will be portable anyhow.... I'd rather we discussed other matters, like Intuition under 1.4.... I hope it will have higher level support functions.... Eric Giguere 268 Phillip St #CL-46 C'est un nom francais, bien sur Waterloo, Ontario N2L 6G9 Bitnet : GIGUERE at WATCSG (519) 746-6565 Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!"
mwm@raven.pa.dec.com (Mike (Under Construction) Meyer) (01/12/90)
Section 4.1.2 of (my draft of) the ANSI standard states that "All external identifiers that begin with an underscore and iether an upper-case letter or another underscore are reserved." However, this simply means that these identifiers may be defined in standard header files, so the user should not use these names. The standard does NOT say that the implementor may use these identifiers to change the syntax of the C language, as you are doing when you introduce things like "__chip". You're right - they don't say you can use them to "change the syntax of the language", or even as type qualifiers (which is what Lattice is actually doing). On the other hand, the standard does give implementors a lot of leeway on extensions. Enough so that, even if it accepts __chip, a compiler can be a conforming implementation. And a program that uses __chip can be a conforming program. See section 1.7, especially the footnote that says that "conforming programs may depend upon non-portable features." Also, one of the key arguments against noalias was that there was no prior art, and thing like it should be done as extensions to a standard without it, so that there will be prior art for the next standard. Or, simply put, __chip is not a violation of the standard - it's an extension that the standards committee allowed for. [Homework question: why is the Lattice chip keyword (instead of __chip) a violation of the standard?] I'm sorry, but I can't find this in the standard. Can you direct me to the appropriate paragraph? Or perhaps this is something from the "Rationale"? Once again, you're right - there is no specific statement in the standard that says that you can't change the semantics of the program with #pragma. Of course (as with __chip), you have to look at the entire standard before you can rule that out. There are people who sat on the standards committee who claim that #pragma can't change the semantics of the program. There are also acknowledged authorities who says that it can. It'd be nice if this were cleared up in the final version, but it's not really important (see below). Again, I think that you guys are missing the point. It seems to me that the ANSI committee provided #pragma exactly for handling non-standard things, such as "__chip", which can't otherwise be done in the language. I think you're missing the point - it doesn't really matter. The only machine which is likely to have the need for __chip is an Amiga. Programs which use it almost certainly won't run on other hardware. Programs which are strictly conforming will compile whether or not __chip is supported. What does matter is whether any other compilers that provide support for declaring data structures to be in chip memory follows the lead already set by Lattice. Failure to do so calls for castigation of the implementors, just as lattice should be castigated for using <proto/all.h> instead of <functions.h>. You'd be using your time a lot better trying to convince people about to create an incompatable compiler to not do so rather than trying to change the minds of people who have working code that uses an existing feature. <mike -- The Sword of Damocles is hanging over my head Mike Meyer And I've got a feeling someone's gonna be cuttin' the thread mwm@berkeley.edu Oh -- woe is me, My life is a misery ucbvax!mwm And all I can see is I'm on the start of a pretty big downer mwm@ucbjade.BITNET
peter@sugar.hackercorp.com (Peter da Silva) (01/12/90)
[ to comp.std.c folks: the discussion is the use of __id for nonportable qualifiers in declarations, like Microsoft does with __far. ] > >Names beginning with two underscores or one underscore and an uppercase > >letter are reserved to the implementation and may be used for any purpose > >the implementer desires. Names beginning with one underscore and anything > >but an uppercase letter may be used with file scope, but as externals are > >reserved to the implementation. > Section 4.1.2 of (my draft of) the ANSI standard states that "All external > identifiers that begin with an underscore and iether an upper-case letter > or another underscore are reserved." However, this simply means that these > identifiers may be defined in standard header files, so the user should not > use these names. What it means is that a portable C program will not use those names for any purpose. So it's safe to use them for a non-portable extension to the language, because you will not break any portable programs. > The standard does NOT say that the implementor may use these > identifiers to change the syntax of the C language, as you are doing when you > introduce things like "__chip". And it doesn't say the implementor can't do this either. In practice it means it's guaranteed to be safe to use them for this purpose. > >On the other hand #pragma is not allowed to change the semantics of a > >program. > I'm sorry, but I can't find this in the standard. Can you direct me to > the appropriate paragraph? Anyone in comp.std.c want to take a crack at it? It certainly gets brought up often enough over there... Certainly #pragma is a lot less elegant: static __chip ushort icon[4+ISIZE]; Or: #pragma chip(icon) static ushort icon[4+ISIZE]; -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
henry@utzoo.uucp (Henry Spencer) (01/14/90)
In article <4919@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> >On the other hand #pragma is not allowed to change the semantics of a >> >program. > >> I'm sorry, but I can't find this in the standard... > >Anyone in comp.std.c want to take a crack at it? ... This is an issue which simply cannot be decided from the text of the standard. The usual "not allowed" argument is that the #pragma section must be read together with the rest of the standard, not in isolation, and therefore #pragma's "implementation-defined" effect is limited by the rest of the standard. The counterargument is that the rest of the standard must be read together with the #pragma section, i.e. with the possibility that #pragma may have implementation-defined effects on the rest of the standard. Both interpretations are self-consistent, and there is nothing in the standard that decides between them. In practice, people *will* implement #pragmas that have semantic effects. -- 1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology 1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu