The Perfect Computer - 36 bits?
|
From: Walter Bushell on 7 Mar 2007 22:25 In article <esnf84$1lsu$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: > >One could also claim that the standardisation of twos complement for > >integers and signed magnitude for floating-point was settled at the > >same time and for the same reasons. > > Twos complement, sure. Floating point, heck no. Other than the S/360 > clones, the only maker I can recall using the IBM floating point format > was Data General. > > Two's complement has nice numeric and implementation properties. But > IBM's S/360 floating point was botched, and the hurried retrofit of > guard digits only helped a little. Between the hex normalization and > the lack of rounding, they lost at least a full digit compared to > obvious alternatives. It wasn't until the IEEE format came along that > the floating point format issue was settled. > > R's, > John And with 32 bits, losing a digit was *bad*. NASSA made all converted programs use 64 bit floating point.
From: Charlie Gibbs on 8 Mar 2007 01:17 In article <1173311807.109742.140780(a)h3g2000cwc.googlegroups.com>, jsavard(a)ecn.ab.ca (Quadibloc) writes: > Rich Alderson wrote: > >> A *really large* PDP-10 has (note tense) 128MW (and you meant 4MW, >> not 4KW, above). That's an XKL Toad-1 with 4 32MW boards (minimal >> memory on system is 32MW). The PDP-10 did not die with DEC. > > You mean a PDP-10 - compatible computer. > > Maclean's toothpaste may have prevented tooth decay with sodium > monofluorophosphate too. > > But Colgate could still run those "Only Colgate has MFP" commercials > in Canada, because MFP was a trademark of theirs! > > If DEC didn't make it, it isn't a DECsystem 20. (The PDP-10 actually > died *before* DEC did. On the other hand, Hewlett-Packard is still > very much alive last time I looked.) Yes, but today's Hewlett-Packard is much less like the HP of old than a PDP-10-compatible computer is like an original DEC PDP-10. -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
From: Torben =?iso-8859-1?Q?=C6gidius?= Mogensen on 8 Mar 2007 04:26 "Quadibloc" <jsavard(a)ecn.ab.ca> writes: > Walter Bushell wrote: >> How about 9 bit characters? Or even 12. One could get a great extended >> ASCII that would cover most of the world's languages with 12 bits. > > Indeed. And wouldn't 18 bit characters be wide enough to cover most of > the existing Unicode extensions beyond the Basic Multilingual Plane? As others have pointed out, no. And when you work with character sets as large as that, you don't want to use a fixed-length representation. It is true that with variable-length characters you can't find the Nth character in constant time by using an array, but arrays are a bad representation of long strings anyway, as inserting a character in the middle of a string takes time proportional to the length of the string. Torben
From: Tom Gardner on 8 Mar 2007 05:22 "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote in news:1161.657T275T13373636(a)kltpzyxm.invalid: > Yes, but today's Hewlett-Packard is much less like the HP of old > than a PDP-10-compatible computer is like an original DEC PDP-10. The Hewlett-Packard of old is alive and well -- but it is now called Agilent.
From: jmfbahciv on 8 Mar 2007 08:28
In article <1173275328.158652.194780(a)c51g2000cwc.googlegroups.com>, "Quadibloc" <jsavard(a)ecn.ab.ca> wrote: >Morten Reistad wrote: >> In article <1173149299.699296.318780(a)t69g2000cwt.googlegroups.com>, >> Quadibloc <jsavard(a)ecn.ab.ca> wrote: >.. >> >In any case, one might only wish to do 36-bit arithmetic, but nothing >> >stops one from using 72-bit addresses. >.. >> Ah. >.. >> For a while you were very close to reinventing the PDP10. > >My intention was to create something rather different from the PDP 10. > >In two ways. > >Instead of 16 general registers, I will continue with 8 base registers >and 8 arithmetic/index registers. > >Instructions will be: > >10 bits opcode > >2 mode bits > >3 bits destination register (destination index) > >3 bits source register (source index) > >if the mode bit says the source or destination is in memory, we add an >18 bit address specifier, having the form > >3 bits base register specification > >15 bits displacement > >So instead of re-inventing the PDP-10, I am re-inventing the IBM 360 >as a 36-bit computer instead of a 32-bit computer. With a touch of the >orthogonality of the PDP-11. What a difference incrementing by one >makes! > >Another difference: the PDP-10 has byte instructions that fit any >number of bytes of any length in a 36-bit word. My architecture will >*only* handle those byte widths and number sizes that fit *exactly* >into a 144-bit memory fetch. Starting with 6-bit characters, the >smallest practical item. That's not very versatile. Why not leave the byte sizing to the programmer where it belongs? No hardware architecture can predict how people will want to use their bytes. > >6,8,9,12,16,18,24,36,48,72. And if some implementation things it needs a sign bit or a parity bit within its byte, the above severe restrictions limits agility. So all kinds of screwy code has to be written to get around fixated byte sizes. /BAH |