Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <141569@sun.Eng.Sun.COM>
Date: 30 Aug 90 05:52:43 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>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 31

In article <1372@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes:
>rpeglar@csinc.UUCP (Rob Peglar) writes:
>
>|Speaking from experience on such a machine (true bit addresses), one has
>|to deeply consider the relationship between compiler and OS code where
>|byte addressing is taken for granted.  sure, the compiler generates
>|the address (bit) of byte n as 0x100 (say) and byte n+1 as 0x108 (for
>|example);  the real pain reveals itself in the numerous occasions where
>|either the OS code or an application assumes integer = pointer.  you
>|just can't add one to the above example (0x100+1 = 0x101) and assume
>|byte n+1 lives at that address (0x101).  this kind of subtlety caused
>|us the most pain in the development cycle.
>
>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?

(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.''
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com