The Perfect Computer - 36 bits?
|
From: Morten Reistad on 6 Mar 2007 06:32 In article <1173149299.699296.318780(a)t69g2000cwt.googlegroups.com>, Quadibloc <jsavard(a)ecn.ab.ca> wrote: >Nick Maclaren wrote: >> Er, no. It may have been then, but 36 bits is too small for modern >> systems. The optimal word size has been increasing steadily over >> the years, a fact that should surprise nobody. > >Given that I'm using a data type that goes three to a 144-bit >quadword, I figure I'll have to require that base register addresses >be quadword addresses. > >That means that a 36-bit base register provides the equivalent of a 40- >bit virtual address, which nicely matches the number of address lines >brought out on some current architectures. > >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. Let's see: ; 9 bit instruction, 4+4 bits for ac and indexing via ac, and an indirect bit, 18 bit address. 36 bit ints 18 bit halfwords/shorts 36 bit string descriptors that can have any byte length from 1-18 36 bit floats 72 bit doubles 256k words in original memory space, later extended by segments The design only has two hurdles that limit deployment in modern silicon : * Effective address calculation through indirection that will lead to huge pipelining problems. * Too small memory space. -- mrr
From: Walter Bushell on 6 Mar 2007 10:18 In article <7zejo2fyar.fsf(a)app-0.diku.dk>, torbenm(a)app-0.diku.dk (Torben AEgidius Mogensen) wrote: > "Quadibloc" <jsavard(a)ecn.ab.ca> writes: > > > I have started a page exploring an imaginary 'perfect' computer > > architecture. > > > > Struggling with many opcode formats with which I was not completely > > satisfied in my imaginary architecture that built opcodes up from 16- > > bit elements, I note that an 18-bit basic element for an instruction > > solves the problems previously seen, by opening up large vistas of > > additional opcode space. > > > > Even more to the point, if one fetches four 36-bit words from memory > > in a single operation, not only do aligned 36-bit and 72-bit floats > > fit nicely in this, but so do 48-bit floating-point numbers. > > [...] > > I think such an architecture is too great a departure from current > > norms to be considered, but this seems to be a disappointment, as it > > seems that it has many merits - involving being neither too big nor > > too small, but "just right". > > Need for more opcode space is not a very good reason to increase the > word-size (as used for numbers etc.) -- Many processors have opcodes > that are of a different size than the wordsize. Also, the trend these > days seems to be decreasing opcode size -- several 32-bit RISC CPUs > have added 16-bit opcodes to reduce code size. If you can't fit what > you want into a single 32-bit word, you might consider splitting some > instructions in two -- you pay when you use these, but not when using > instructions that fit into 32 bits, unlike if you go to a uniform > 36-bit opcode, where all instructions pay for the size of the largest. > > And fixed-size opcodes seems to be on the way out also -- Thumb2 > freely mixes 16 and 32 bit instructions, and in x86 that has a very > variable opcode size, handling this takes up only a small fraction of > the die-space, and with caching of decoded instructions, the time > overhead is also very limited. > > As for using 36 bits to increase number precision over 32 bits, the > step is too small, and the effort of handling strings without waste is > a considerable complication (in particular in C-like languages, where > you expect to have pointers to individual characters in a string). > > A more logical intermediate step between 32 and 64 bits is 48 bits -- > you have a whole number of 8 or 16 bit characters in a word, so you > can still have byte addressability. But power-of-two words do have a > clear advantage in alignment and fast scaling of indexes to pointers. > > If you want 36-bit word, you should consider 6-bit characters, so you > have a whole number of characters per word -- that was done on some > older computers (like the UNIVAC 1100), which used fieldata > characters. > > Torben 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.
From: Torben =?iso-8859-1?Q?=C6gidius?= Mogensen on 6 Mar 2007 10:47 Walter Bushell <proto(a)oanix.com> writes: > In article <7zejo2fyar.fsf(a)app-0.diku.dk>, > torbenm(a)app-0.diku.dk (Torben AEgidius Mogensen) wrote: > >> A more logical intermediate step between 32 and 64 bits is 48 bits -- >> you have a whole number of 8 or 16 bit characters in a word, so you >> can still have byte addressability. But power-of-two words do have a >> clear advantage in alignment and fast scaling of indexes to pointers. >> >> If you want 36-bit word, you should consider 6-bit characters, so you >> have a whole number of characters per word -- that was done on some >> older computers (like the UNIVAC 1100), which used fieldata >> characters. >> > 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. UNIVAC 1100 also used a 9-bit ASCII. I don't recall what extra characters (if any) were added. In any case, there are fairly universally adopted 7-bit (ASCII), 8-bit (ISO 8859-X) and 16-bit (Unicode) character sets, so it wold be difficult to get universal acceptance of a new character set with a different size -- especially as 99% of all code that operates on characters have assumptions about the size of a character. Torben
From: Morten Reistad on 6 Mar 2007 11:59 In article <7zvehetlv5.fsf(a)app-0.diku.dk>, Torben �gidius Mogensen <torbenm(a)app-0.diku.dk> wrote: >Walter Bushell <proto(a)oanix.com> writes: > >> In article <7zejo2fyar.fsf(a)app-0.diku.dk>, >> torbenm(a)app-0.diku.dk (Torben AEgidius Mogensen) wrote: >> >>> A more logical intermediate step between 32 and 64 bits is 48 bits -- >>> you have a whole number of 8 or 16 bit characters in a word, so you >>> can still have byte addressability. But power-of-two words do have a >>> clear advantage in alignment and fast scaling of indexes to pointers. >>> >>> If you want 36-bit word, you should consider 6-bit characters, so you >>> have a whole number of characters per word -- that was done on some >>> older computers (like the UNIVAC 1100), which used fieldata >>> characters. >>> >> 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. > >UNIVAC 1100 also used a 9-bit ASCII. I don't recall what extra >characters (if any) were added. > >In any case, there are fairly universally adopted 7-bit (ASCII), 8-bit >(ISO 8859-X) and 16-bit (Unicode) character sets, so it wold be >difficult to get universal acceptance of a new character set with a >different size -- especially as 99% of all code that operates on >characters have assumptions about the size of a character. As some other posters on this NG can probably tell a lot more about, there does exist a standard for 9-bit encoding of unicode. 9 bits would e.g. fit two MS-style codepages at once, or ISO8859 plus half the code space available for something else. 9+9 also fits all kana+kanji chacacters easily. -- mrr
From: Ken Hagan on 6 Mar 2007 12:43
On Tue, 06 Mar 2007 15:47:26 -0000, Torben �gidius Mogensen <torbenm(a)app-0.diku.dk> wrote: > In any case, there are fairly universally adopted 7-bit (ASCII), 8-bit > (ISO 8859-X) and 16-bit (Unicode) character sets, so it wold be > difficult to get universal acceptance of a new character set with a > different size -- especially as 99% of all code that operates on > characters have assumptions about the size of a character. I think Unicode 3.0 needs 20 bits for a "clean" encoding, and if you are willing to pay the complexity cost of fewer bits, nothing is actually simpler than UTF-8. On the other hand, there are still plenty of people using 16-bit encodings because their language or OS was "frozen" when that was sufficient. Evidently the number of bits to use for a character is not driven by either ease of implementation or ease of handling. With that in mind, I don't see any significant benefits to a 6, 9 or 18 bit type. |