Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Message-ID: <41188@mips.mips.COM> Date: 29 Aug 90 20:36:55 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@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: Your Organization Goes Here Lines: 91 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 ... >|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?)). This area clearly needs discussion, not just from this comment, but from another email that came to me, but that I accidentally lost and couldn't reply to. (The email told me that wanting bit-addressing hardware to have a language expression that should be portable meant that if everyone had my attitude, calculus and most other important mathematics never would have been invented. (??) (As I was a physicist & mathematician by original background, and have studied science/technology history a lot, I don't quite understand this, but maybe whoever wrote me the mail will send me more info to educate me.)) Anyway, consider computer architecture, languauge design, standards, and practice (as opposed to purist theory): IF you are designing computers for any market in which noticable amounts of code already exist THEN anything you do that makes it harder to port such software must be justified by something that people want; the more difficulty, the more absolutely compelling that something must be. This fact is what causes computer companies to maintain upward compatibility, up to the point where there is too much competitive disadvantage in doing so. These days, the domain of possibilities includes: a) It's upward-compatible from anything that has a large installed base, and then it's faster, cheaper, or smaller. b) It's faster, cheaper, or smaller, and although it's different, its architecture+software make it easy to recompile lots of existing code with zero hassle. c) It's faster, cheaper, or smaller, and although it's different, its architecture+software make it easy to recompile lots of existing code with minimum hassle. For example, minor portability flaws will need to get fixed. EX: most of the RISCs pass some arguments in registers, and they like you to take varags.h seriously. d) It's (better).... and with modest work, it's a lot faster. Ex: recoding to get to vector libraries, or slight rework of algorithms, or a few extra declarations to help. (Note: Perfect Club has nice methodology in this area.) Ex: profile-driven compiling, which requires hacking of makefiles. e) It's (better), but only when you redesign the code substantially. f) It's (better), but it doesn't even work until you redesign it, or recode it in a special language available nowhere else. g) It's not any better, just different, and hard to port to. Now: a) is anybody with serious installed base. c) is anybody with hot new general-purpose technology, like RISCs. It's fairly hard to get b). Doing c) well requires good judgement about 1) How people really use languages, and 2) The realistic progress of portability standards and 3) if necesary, the realistic practicality of requiring standards a little earlier than people would actually get there naturally. d) includes many scientific machines, like vector machines e) often includes fine-grain parallel processors f) might include the state of Transputers when they first came out and Occam was really the preferred languauge) g) is what happened to vendors who tried to move UNIX to some superminis or mainframes that C didn't really fit very well, i.e., I believe relatively few machines were sold this way. NOTE: THERE IS NOTHING WRONG WITH e) or f), IF you can find people for whom the value of the improvement is worth the hassle, and there are plenty of such applications that demand highest performance or lowest cost. Progress sometimes happens this way, and this is good. Also, compelling reasons cause people to clean up their act. For instance, recall that once upon a time, UNIX was pretty much Little-Endian, with a lot of 16-bit stuff that wasn't very portable. Things improved when there was a good reason to do it. However, it is still clear that bit-addressing would break more programs than byte-addressing, so all I wanted was for someone to work through a complete example to show why it would be A Good Thing on balance. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086