Path: utzoo!utgpu!watserv1!watmath!att!rutgers!apple!bbn.com!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <15404@drilex.UUCP>
Date: 1 Sep 90 15:49:38 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> <225@csinc.UUCP> <1372@svin02.info.win.tue.nl> <141569@sun.Eng.Sun.COM>
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 44

In article <141569@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
>In article <1372@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes:
>>rpeglar@csinc.UUCP (Rob Peglar) writes:

>>>(Stuff about how the ETA, as a bit addressed machine, did transformations
>>>converting ints to pointers & vice-versa.)

>>The person adding 1 to the int expecting to have the (char *) casted int point
>>to the next byte shouldn't call himself a programmer ('cos he isn't producing
>>a program but pure garbage (eh?)).
>
>Ahem.  Two points:
>
>(1)  Unix has reached the age where it has what can be called dusty deck code.
>     And this code frequently does stuff like
>
>	 char *bar = (char*)malloc(100);
>    
>    which doesn't work under Rob's machine.  Do we want to support this code?

An amazing point here was how many people didn't pick up the error here.
Sure, Rob did not mention that there was no proper declaration of malloc
in scope.  But the cast of (char *) on malloc should have been a hint--
a good compiler would give a complaint about a 'redundant cast' if you didn't
turn the warning off, but Unix people wouldn't buy it.

>(2) Even so, it doesn't turn out to be so bad.  I hacked over lint to catch
>    these sorts of problems and ported most of /usr/src/cmd to the ETA in a
>    week.  ``Work smarter, not harder.''

One real shame is how often  'Unix' has been worked over by many programmers
working for many companies, each fixing one-by-one many bugs.  Since fixed
bugs are a proprietary advantage, it goes on until one of the 'master'
programmers (who work on porting bases) happens on it.

(Sorry for the comp.arch digressions.  To put my two cent's worth in about
bit addressing, I don't think there is a language out there today which
would care, as long as bit *fields* were reasonably cheap.  Sure, PL/I
had bit strings, but I don't think they would be significantly sped up
by bit addressing.)
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}