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