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