guido@mcvax.UUCP (Guido van Rossum) (10/16/84)
Now that's the second compilation of predefined CPP symbols coming around this month. These symbols almost all seem to indicate particular hardware or software a program might be running on (exception: __FILE__ c.s.). I can't believe there is any program which checks for more than three or four of them (counterexamples to /dev/null, please). I suspect most people use them in a fashion like #ifdef MY_MACHINE ... Do some local tricks ... #endif or #ifndef MACHINE_X ... This doesn't work on machine X ... #endif or #ifdef SYSTEM_X ... Way to do it on sys X ... #else ... Way to do it somewhere else ... #endif Of course, this breaks when a program is spread to more that a few machines. What we really need here is something quite different: a set of #defines telling us what *features* are available on the target machine. (Note that the machine where the compiler runs is immaterial, unless it is a very buggy compiler.) So: #ifdef ETHERNET ... Collect and display info about net nodes ... #endif and #ifdef SELECT_SYSCALL ... Find out whether there's input pending ... #else ... Assume there is (or isn't) ... #endif I feel that, in the end, this is much more portable than using system names, where it will always be possible that a new system Z is a mixture of system X and system Y, thus necessitating a new #define although all the features are really nothing new. (I believe this is in fact already the case for many of the systems on the circulated lists.) (Aside: I've always wondered what use there was for Decus' "nomacargs". Either you can do the job without macro arguments; then do so, and you won't have to bother; or you can't, and then you're pretty helpless anyway when faced with the Decus compiler. But I shouldn't complain too loud, as it follows my proposal: #ifdef nomacargs is better than #ifdef DECUS.) Random shots at related topics: - #defined symbols should usually be recognizable by a convention line all uppercase (exception: getchar and such that must look like functions); - *pre*defined symbols should stand out even more because they may be there without the user knowing about them; perhaps __LINE__ and __FILE__ might set a standard (or the ANSI committee? :-) - it's nice if the ANSI standard finds a way out which makes things like 'unix' be defined and still evaluate to 'unix' by explicitly ruling out recursion; but have they thought about mutual recursion (#define a b; #define b a)? - I feel that "unix is on my side": during some stage of the development of the unix kernel, tests like #ifdef pdp111 were replaced by #ifdef UNIBUS etc. -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP "What was your mandoline doing in my bed?"
guy@rlgvax.UUCP (Guy Harris) (10/17/84)
> Therefor I am collecting a list of what #defines are used so that I can > use the same ones as everyone else; > -- you all DO use the same ones -don't you ? > > Hardware > #define Machine > vax vax m/c > pdp11 pdp11's > mc68000 68000 CPUs I gather that some people use m68000, how > widespread is this ? Can we agree on one or > the other as a standard. Unfortunately, AT&T throws in a joker; there are now 3 competing names, "mc68000", "m68000", and "m68k". Arguably, either "m68000" (which we, and I think some other people, use) or "m68k" should be used for all machines based on 68000 family CPU chips (68000, 68010, 68020) and "mc68000" used specifically to imply that it's an MC68000 chip. Precedent exists for this sort of thing; "u3b" implies a 3B, "u3b5" implies a 3B5. > It has been suggested that some of the above have specific values (other > than 1). Thus on a pdp11/44, pdp11 would have a value of 44. Thus in the few > places where the actual cpu mattered (eg I/O, memory management), appropriate > compile tests could be made. This could get tricky, as not all "model numbers" are numeric, and CPP can only do "#if"s on numeric values. > Would it be useful (possible) to have defines for different memory management > architectures ? What specific architectures? Paged vs. non-paged, or specific hardware? The former is nice; precedent sort of exists for this in the VMUNIX define used in some Berkeley software, except there's some software out there that thinks "VMUNIX" means "Berkeley UNIX", which it shouldn't. The latter is probably not useful, as the only software that will depend on it are parts of the OS, and #ifdefing that probably doesn't add anything (if you have to rewrite 1000 lines of code for a particular MMU - or for any other configuration change - it's probably best done by linking in different modules for different configurations). > Software > I have got an implies section here. The idea is that one piece of software > looks sufficiently like another, so rather than going round adding the #define > when a new release come along, we only need change the places where there is > a difference. Thus SYS5 implies SYS3, as most of System 5 looks like System 3. > Maybe there should be a USG implying SYS3 (but not SYS5). > > #define: O/S Implies -ie also defined: > SYS8 System 8 SYS3 (SYS5 as well ?) - or is it SYS5R3? What is System 8? It looks like Bell has reset their numbering scheme yet again, with every UNIX until 2^31-1 seconds after January 1, 1970, 0 hours GMT, being called System V. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/17/84)
I too like predefined symbols to be defined as themselves with the appropriate safeguards against recursion looping. But I don't think #define a b #define b a needs to be worried about besides making it illegal.
addw@root44.UUCP (Alain Williams) (10/20/84)
The following was prepared & just about to go when I read John Rogers'
article. This list has is a compilation of what we have seen in use.
Oh no, not someone else trying to force their standards on me !!
Well no. Since I try to make my software run on all sorts of things & being
a lazy sod I don't like to have to go back over stuff that I have done.
Therefor I am collecting a list of what #defines are used so that I can
use the same ones as everyone else;
-- you all DO use the same ones -don't you ?
Anyway, if you don't like standards -don't waste time reading this,
-go & program for YOUR machine.
These symbols would, ideally, be defined by cpp, though if not a -D option
would take care of it.
Hardware
#define Machine
vax vax m/c
pdp11 pdp11's
mc68000 68000 CPUs I gather that some people use m68000, how
widespread is this ? Can we agree on one or
the other as a standard.
z8000 z8000s
u3b 3b2, 3b20 etc
u370 IBM 370
ns16032 Nat Semis M/C Or is it ns32016 this week?
i80286 Intel 80286
OK, I've missed out your favourite hardware; so mail me & tell me what it is,
& what #define you use.
It has been suggested that some of the above have specific values (other
than 1). Thus on a pdp11/44, pdp11 would have a value of 44. Thus in the few
places where the actual cpu mattered (eg I/O, memory management), appropriate
compile tests could be made.
Would it be useful (possible) to have defines for different memory management
architectures ?
Software
I have got an implies section here. The idea is that one piece of software
looks sufficiently like another, so rather than going round adding the #define
when a new release come along, we only need change the places where there is
a difference. Thus SYS5 implies SYS3, as most of System 5 looks like System 3.
Maybe there should be a USG implying SYS3 (but not SYS5).
#define: O/S Implies -ie also defined:
V7 Edition 7
V8 Edition 8
SYS3 System 3
SYS5 System 5 SYS3
SYS5R2 System 5.2 SYS3 SYS5
SYS8 System 8 SYS3 (SYS5 as well ?) - or is it SYS5R3?
BSD2_8 Berkeley 2.8
BSD2_9 Berkeley 2.9
BSD4_1 Berkeley 4.1
BSD4_2 Berkeley 4.2
SYS5onBSD4_2 SYS5 emulation SYS5 SYS3
under BSD4.2 as by DA Gwyn of BRL
ZEUS Zeus
UNIPLUS Uniplus
XENIX Xenix (Last and least)
unix I'm not sure what look-alikes this includes
Misc
xxONVAX Means that the result is intended for machine xx but
it is being compiled on a vax. Are a whole lot more like
this needed. (This sort of thing is only of interest in
compiling cross compilers)
IEEE IEEE floating point emulation.
Alain Williams, Nigel Horne,
Root Computers Ltd, London, England.
<UK-net>!{hirst1|qmc-sc|edai|west44|ukc|glasgow|ist}!root44!{addw|njh}
root44!{rootcl|rootis}!{addw|njh}kendall@wjh12.UUCP (Sam Kendall) (10/21/84)
> Precedent exists for this sort of thing [hierarchies of CPP symbols to > handle types and subtypes of computer]; > "u3b" implies a 3B, "u3b5" implies a 3B5. > Guy Harris I wish it worked this way; I can see why Guy assumed that is does. Unfortunately, "u3b" implies a 3B20 only; the symbol is not defined on a 3B5, or at least not on a 3B2 that I played with. There is no "u3b20" symbol on a 3B20, either. Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall