Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Unix optimized for SPARC?
Message-ID: <60276@sun.uucp>
Date: 18 Jul 88 18:06:43 GMT
References: <253@iconsys.UUCP> <495@cvaxa.sussex.ac.uk>
Sender: news@sun.uucp
Lines: 36

In a way, BSD *is* optimised for a Vax, since there is lots of code that
has hardwired in a dependency on the dereference of the address zero
returning zero, that pointers and ints are interchangaeable, etc. etc.
[NO FLAMES PLEASE...]

Actually, the "dereference of address zero returning zero" stuff was cleaned up
quite a bit when the 4.2 stuff was ported to Suns; I'd rate BSD as better than
S5 in this case, at present.  Of course, AT&T could fix this by making the "-z"
flag to the linker be the default; *that* would teach people not to **** with
null pointers.

> Likewise, when writing for the SPARC I would keep my procedure argument
> lists to <= 6 args, so they'll all fit into the register window, etc. etc.
> [I CAN HEAR YOU ALL GROANING ALREADY]

Of course, keeping procedure argument lists shorter than 6 arguments has plenty
of *other* advantages, like keeping the procedure from becoming too baroque.
I don't think I've often needed long procedure argument lists, other than in
calls to "printf"; I don't "write for the SPARC", though, so when long argument
lists were called for I just used them, despite the fact that my machine
happens to be SPARC-based.

> It takes a mammoth effort to write code which is truly portable,
> and I don't mean just the machine-specific bits.  If AT&T write code
> for the SPARC, expect to see SPARC-isms wired in.   THIS IS NOT GOOD.

AT&T's machines use the WE32K, the SPARC, and the '386; Sun's machines use the
68K, the SPARC, and the '386.  With any luck, this will result in fewer *-isms,
unless it results in more of them (6 arguments per procedure for the SPARC
*and* only N register variables for the '386 or whichever processor has fewer
registers left over).

At least most of those machines have signed characters, so there won't be tons
of "8-bit clean" code that assumes that characters are unsigned, as there was
in S5R3.1.  Since one of them doesn't, one would hoep that there would also be
no code that depends on characters being *signed*.