Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!cbosgd!cblpf!cbstr1!Karl.Kleinpaste
From: Karl.Kleinpaste@cbstr1.att.com
Newsgroups: comp.unix.wizards
Subject: Re: compiler predefines
Message-ID: <304@cbstr1.att.com>
Date: Wed, 22-Jul-87 12:16:22 EDT
Article-I.D.: cbstr1.304
Posted: Wed Jul 22 12:16:22 1987
Date-Received: Sun, 9-Aug-87 08:45:58 EDT
References: <521@quacky.UUCP> <526@quacky.UUCP> <23741@sun.uucp> <8888@tekecs.TEK.COM>
Sender: karl@cbstr1.att.com
Lines: 43

seifert@doghouse.gwd.tek.com writes:
> guy%gorodish@Sun.COM writes:
> > I don't know if
> > there *is* one for the WE32K series - AT&T seems to use stuff like
> >	#if u3b20 || u3b2 || u3b5 || u3b15 || ...
> > but enumerating all the 3Bs seems like a silly way of defining the
> > set of machines using the WE32K
> Last time I looked, the 3b20 didn't use the WE32K chip(s).  It predated
> them, if I remember correctly.  Various boards had various micros (8085,
> 8086, 2911, etc).  Obviously they should define "3b" or similar.
> (and probably we32k as well)

You are correct, the 3B20 is architecurally distinct from the
3B{2,5,15}.  The latter 3 can be considered identical for most any
application purpose.  The former is an older processor.

Also, the symbol defined on the -20 is just "u3b" (not "u3b20") which
it claims for historical reasons (i.e., it was there first), before
there was a useful distinction of one 3B from another.

For the most part the complicated "u3b2 || u3b5 || u3b15" is
significant only for certain pieces of the kernel, where such issues
actually matter.  Applications aren't supposed to care.  But a
distinction between the -20 and the rest is somewhat necessary at
other times.  As it happens, even large things like GNU Emacs can
avoid the issue entirely; the m-att3b.h file for GNU Emacs says, in
part:
	#define ATT3B
and then all the tests which are relevant to 3B's of any flavor just
work off of ATT3B.  A point of difference is in the data space
organization of the -20 versus 2/5/15, where the 2/5/15 have data
space starting with the high-order bit on, which plays hell with lisp
garbage collectors.  There is one 2||5||15 test in m-att3b.h which
defines special macros for accessing the necessary bit fields; other
than that, there's just one other 2||5||15 test to turn off the
optimizer because it happens to be just plain broken; the -20's
optimizer is fine.

(Chicken-and-egg problem: Compile -O, notice bug in resulting program
operation; recompile without -O in order to find apparent bug in your
program, bug goes away.  Mumble...I *hate* optimizer bugs...)

Karl