Q: Why not (2^n)-bit?
dls2
16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
and I don't understand why this trend might exist.
Is this trend due to economic factors?
Is this trend due to technical factors?
A combination of both? Or neither?
I know that in the past, DEC's PDP systems were not
based on powers of 2, but on multiples of 2, with the
exception of the PDP-11, a 16-bit computer.
Any ideas as to why DEC decided to only produce a
single (2^n)-bit based PDP model, and stuck to using
multiples of 2 for all its' other PDP models?
****
PDP-01 1960-vintage 18-bit
PDP-02 19??-vintage 24-bit
PDP-03 19??-vintage 36-bit
PDP-04 1962-vintage 18-bit
PDP-05 1963-vintage 12-bit
PDP-06 1964-vintage 36-bit
PDP-07 1965-vintage 18-bit
PDP-08 1965-vintage 12-bit
PDP-09 1966-vintage 18-bit
PDP-10 1967-vintage 36-bit
PDP-11 1970-vintage 16-bit
PDP-12 1969-vintage 12-bit
PDP-13 19??-vintage ??-bit
PDP-14 19??-vintage ??-bit
PDP-15 1970-vintage 18-bit
PDP-16 1972-vintage ??-bit
****
Are there advantages/disadvantages to running (2^n)-bit?
Are there advantages/disadvantages to NOT running (2^n)-bit?
What about for systems based only on multiples of 2, instead?
appreciatively,
-- Derrick Shearer
Nick Maclaren
dls2 <dlsh...@home.com> wrote:
>Systems nowadays all seem to be running at an 8-bit,
>16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
>and I don't understand why this trend might exist.
>
>Is this trend due to economic factors?
>Is this trend due to technical factors?
>A combination of both? Or neither?
I would say more marketing and semi-political issues.
>Are there advantages/disadvantages to running (2^n)-bit?
>Are there advantages/disadvantages to NOT running (2^n)-bit?
>What about for systems based only on multiples of 2, instead?
I believe that there are some minor hardware ones, but the main
reason is that the nastier software tends to assume it, and
so some customers prefer it, and so the marketing departments
insist on it ....
The rot started with the dominance of the System/360 - before
then, few semi-portable programs built that assumption into their
codes, but a fair number of ones written for that system did.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
James Van Buskirk
dls2 wrote in message ...
>Systems nowadays all seem to be running at an 8-bit,
>16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
>and I don't understand why this trend might exist.
>Is this trend due to economic factors?
>Is this trend due to technical factors?
>A combination of both? Or neither?
One thing I have noticed about x86 and Alpha that explicitly
makes use of their (2**n)-bit register size is the shift
operations. Both ISAs mask out the low 5 (on x86) or 6 (mmx
and Alpha) bits to create the shift count. This procedure
seems more sensible on machines with (2**n)-bit register
sizes than on those with other sizes and I might guess that
such other machines would likely handle out of range shifts
differently. Also BT and its buddies seem easier to implement
on x86 with (2**n)-bit wide memory access. Of course the way
RCR works on x86 has always seemed just a little bit
counterintuitive to me for just this reason.
Ketil Z Malde
>> Are there advantages/disadvantages to running (2^n)-bit?
>> Are there advantages/disadvantages to NOT running (2^n)-bit?
>> What about for systems based only on multiples of 2, instead?
> I believe that there are some minor hardware ones, but the main
> reason is that the nastier software tends to assume it
The cost is probably negligible (e.g. just because you have 64bit
addressing doesn't mean you have to have 64bit physical, and 32bit
registers doesn't imply 32bit data paths (e.g. early 68Ks, IIRC)).
Generally, 2^n are nice numbers to work with, for instance with
systems that like aligned data.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Wilhelm B. Kloke
>PDP-02 19??-vintage 24-bit
>PDP-03 19??-vintage 36-bit
>PDP-04 1962-vintage 18-bit
>PDP-05 1963-vintage 12-bit
>PDP-06 1964-vintage 36-bit
>PDP-07 1965-vintage 18-bit
>PDP-08 1965-vintage 12-bit
>PDP-09 1966-vintage 18-bit
>PDP-10 1967-vintage 36-bit
>PDP-11 1970-vintage 16-bit
>PDP-12 1969-vintage 12-bit
>PDP-13 19??-vintage ??-bit
>PDP-14 19??-vintage ??-bit
>PDP-15 1970-vintage 18-bit
>PDP-16 1972-vintage ??-bit
Perhaps you did notice that all bit widths are either 2^n or 6*2^n.
In the old days 6 bits were needed to hold 1 character (no
upper/lower distinction possible). The CDC hat 60bit word length.
The 1st widely used computer with 8bit bytes was the IBM /360,
about 1965. And, in these old days, memory was extremely expensive.
Therefore addresses were not longer than actually needed for most
programs. So the PDP-8 could be successful.
Now we have ASCII code, which is based on the 8bit/byte assumption.
Therefore no computer whose word length is not a multiple of
8 can be successful. This makes 24 the smallest word length which is not
2^n, and is compatible with ASCII.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
David Gesswein
>16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
>and I don't understand why this trend might exist.
>
>Is this trend due to economic factors?
>Is this trend due to technical factors?
>A combination of both? Or neither?
>
>based on powers of 2, but on multiples of 2, with the
>exception of the PDP-11, a 16-bit computer.
>
on the pdp-8 you have to use marker characters to indicate upper/lower case
and extracting them is difficult (If I remember the byte swap instruction
is a later addition to the instruction set (upper and lower 6 bits of AC)
If you use 12 bits you waste bits. The industry was also standardizing
on 8 bits so you would have difficulty using the cheaper standard peripherals.
The PDP-8 shows this with only using 3/4 of the space on the RX01/2 floppy
when run in 12 bit mode.
Early on when you didn't care about mixed case and memory was very expensive
the value of the strange word sizes was probably more.
I would have to think more of the impact of using multiples of 8 verses
2^n.
David Gesswein
http://www.pdp8.net/ -- Old computers with blinkenlights
Mel Wilson
>I know that in the past, DEC's PDP systems were not
>based on powers of 2, but on multiples of 2, with the
>exception of the PDP-11, a 16-bit computer.
>PDP-01 1960-vintage 18-bit
>PDP-02 19??-vintage 24-bit
>PDP-03 19??-vintage 36-bit
>PDP-04 1962-vintage 18-bit
>PDP-05 1963-vintage 12-bit
>Are there advantages/disadvantages to NOT running (2^n)-bit?
In the days of punched cards and BCD there was an advantage. It was
customary then to want NUMBERS from your computer, and only enough text
on the printout to remind people what the numbers were. Upper-case only
was dandy. So you needed codes for
0 to 9
.
- and +
and then you wanted
$ and , for accounting, who might also want (, ) and @
A to Z
and that made 41 character codes. The least power of 2 that contains 41
is 64, 2^6. Note that all the old machines listed have word lengths
that are a multiple of 6 bits. The GE-425, the first computer I got to
really know, had a 24-bit word. The character set assigned codes 00 to
11 octal to the digits "0" to "9", by right of privilege, and scattered
the rest around depending on their Hollerith card representation.
(Actually that helds for "0".."9", too. Shows how the Hollerith code
made sure of taking care of the numbers first.)
>Are there advantages/disadvantages to running (2^n)-bit?
If you really, really care about NUMBERS, you start to ask: why
throw away two bits out of 6 on other stuff when numbers only need 4?
Maybe 4-bit bytes were deemed silly; the world went to 8-bit bytes
and packed decimal arithmetic. Eventually people also wanted lower
case, and BCD character sets wouldn't cut it any more.
(2^n) bit words can address data homogeneously down to the bit,
if the hardware designers care to let you. Honeywell engineers added
bit addressing to the 6000 series, which used a 36-bit word. Index
registers could contain bit offsets, and these offsets could span 36-bit
words and 9-bit bytes. Consider the impact that the leap year has on
date calculations, then imagine a leap-bit thrown into the addressed
data at intervals. As I recall this was handled by hardware, not
programs, thank goodness.
Regards. Mel.
Ben Hutchings
<snip>
> Now we have ASCII code, which is based on the 8bit/byte assumption.
The original ASCII code was 6-bit, and the later version is only
7-bit. If I'm not mistaken, 36-bit machines such as the PDP-10 would
let you pack 5 7-bit characters into a word without too much trouble.
But you can never have enough bits for all the characters you want to
include, and some people would put 4 9-bit characters in instead.
> Therefore no computer whose word length is not a multiple of
> 8 can be successful.
That seems to be true *now*. The question is surely, how did this
come to be true - and ASCII is not an adequate explanation.
> This makes 24 the smallest word length which is not 2^n, and is
> compatible with ASCII.
No.
--
Any opinions expressed are my own and not necessarily those of Roundpoint.
Magnus Olsson
Wilhelm B. Kloke <w...@yorikke.arb-phys.uni-dortmund.de> wrote:
>In article <rpNl5.131549$lU5.8...@news1.rdc1.nj.home.com>,
>dls2 <dlsh...@home.com> wrote:
>>
>>PDP-01 1960-vintage 18-bit
>>PDP-02 19??-vintage 24-bit
>>PDP-03 19??-vintage 36-bit
>>PDP-04 1962-vintage 18-bit
>Perhaps you did notice that all bit widths are either 2^n or 6*2^n.
Ahem. 18 = 6 * 3, 36 = 6 * 3 * 2...
By the way, I think that 40 bits was a rather common word length
for early computers, presumably before 6-bit character codes became
standard.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
dls2
> Wilhelm B. Kloke wrote:
<snip>
> > Now we have ASCII code, which is based on the 8bit/byte
> > assumption.
>
> The original ASCII code was 6-bit, and the later version is only
> 7-bit. If I'm not mistaken, 36-bit machines such as the PDP-10
> would let you pack 5 7-bit characters into a word without too
> much trouble. But you can never have enough bits for all the
> characters you want to include, and some people would put 4
> 9-bit characters in instead.
"IBM PC Extended ASCII Display Characters
Strictly speaking, the ASCII character set only includes values
up to 127 decimal (7F hex). However, when the IBM PC was
developed, the video card contained one byte for each character
in the 80x25 character display. Gee...what to do with that extra bit
per character? Why not invent 128 new characters, for line-drawing
and special symbols? The result, of course, was the extended
ASCII character set for the IBM PC. The chart below shows (most of)
the characters that can be generated by the display in the original
IBM PC." http://www.jimprice.com/jim-asc.htm
If this is true, then why did the video card contain one (8-bit) byte
for each character?
> > Therefore no computer whose word length is not a multiple of
> > 8 can be successful.
>
> That seems to be true *now*. The question is surely, how did
> this come to be true - and ASCII is not an adequate explanation.
IBM PC Extended ASCII Display Characters, then?
> > This makes 24 the smallest word length which is not 2^n, and is
> > compatible with ASCII.
>
> No.
No? Why not? Assuming "n" to be an integer.
2^3 = 08 1*8 = 08
2^4 = 16 2*8 = 16
3*8 = 24 log_2(24) = ~4.585
2^5 = 32 4*8 = 32
Were 24-bit machines doomed to fall by the wayside for lacking
simultaneous (2^n)-bit capability? Or for other reasons?
-- Derrick Shearer
Magnus Olsson
dls2 <dlsh...@home.com> wrote:
>"Ben Hutchings" wrote:
>> Wilhelm B. Kloke wrote:
><snip>
>> > Now we have ASCII code, which is based on the 8bit/byte
>> > assumption.
>>
>> The original ASCII code was 6-bit, and the later version is only
>> 7-bit. If I'm not mistaken, 36-bit machines such as the PDP-10
>> would let you pack 5 7-bit characters into a word without too
>> much trouble. But you can never have enough bits for all the
>> characters you want to include, and some people would put 4
>> 9-bit characters in instead.
>
>"IBM PC Extended ASCII Display Characters
> Strictly speaking, the ASCII character set only includes values
>up to 127 decimal (7F hex). However, when the IBM PC was
>developed, the video card contained one byte for each character
>in the 80x25 character display. Gee...what to do with that extra bit
>per character? Why not invent 128 new characters, for line-drawing
>and special symbols? The result, of course, was the extended
>ASCII character set for the IBM PC. The chart below shows (most of)
>the characters that can be generated by the display in the original
>IBM PC." http://www.jimprice.com/jim-asc.htm
>
>If this is true, then why did the video card contain one (8-bit) byte
>for each character?
It would have been afwfully inefficient, performance-wise, to pack
8 7-bit characters into 7 8-bit bytes.
>> > Therefore no computer whose word length is not a multiple of
>> > 8 can be successful.
>>
>> That seems to be true *now*. The question is surely, how did
>> this come to be true - and ASCII is not an adequate explanation.
>
>IBM PC Extended ASCII Display Characters, then?
8-bit bytes (and word lengths an integral multiple of this) were
a standard long before the IBM PC (though there were still 36-bit machines
being made after the introduction of the IBM PC).
Ben Franchuk
> "IBM PC Extended ASCII Display Characters
> Strictly speaking, the ASCII character set only includes values
> up to 127 decimal (7F hex). However, when the IBM PC was
> developed, the video card contained one byte for each character
> in the 80x25 character display. Gee...what to do with that extra bit
> per character? Why not invent 128 new characters, for line-drawing
> and special symbols? The result, of course, was the extended
> ASCII character set for the IBM PC. The chart below shows (most of)
> the characters that can be generated by the display in the original
> IBM PC." http://www.jimprice.com/jim-asc.htm
The characters are OK , but the color mapping on the PC video cards
really sucks, of all the combinations of foreground and background
only about 8 look good. I would of liked them to have the control
byte control color (via a look up table) and have over strike flags
but that is life.
> If this is true, then why did the video card contain one (8-bit) byte
> for each character?
>
> > > Therefore no computer whose word length is not a multiple of
> > > 8 can be successful.
> >
> > That seems to be true *now*. The question is surely, how did
> > this come to be true - and ASCII is not an adequate explanation.
>
No but I/O devices are. Since 90% of all data processing that
is not number crunching is text orientated it makes sense
to have I/O at least 7 bits width. A 8 bit byte has the least
waste for I/O and remember back then floppy and hard discs came only
in small sizes. I am sure one would love to load Windows 2000 from
paper tape.:)
> > No.
>
> No? Why not? Assuming "n" to be an integer.
>
> 2^3 = 08 1*8 = 08
> 2^4 = 16 2*8 = 16
> 3*8 = 24 log_2(24) = ~4.585
> 2^5 = 32 4*8 = 32
>
> Were 24-bit machines doomed to fall by the wayside for lacking
> simultaneous (2^n)-bit capability? Or for other reasons?
How about the fact that the CPU chip was developed for
8 bit use. The only other chip was the 6100 series that
did the PDP-8, and we all know now 32k is way too small
of a memory space.
Ben.
PS. I still think 24 bits is the Right Size for a small
computer, providing it is updated for modern computer
ideas like stacks.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
http://www.jetnet.ab.ca/users/bfranchuk/index.html
Christian Bau
> Were 24-bit machines doomed to fall by the wayside for lacking
> simultaneous (2^n)-bit capability? Or for other reasons?
For some reason, all the early microprocessors were 8 bit processors.
Maybe someone knows why the designers of the 8080 and the 6800 chose 8
bits, and not 7 or 9; the 8085, Z80, and 6502 were eight bit because each
of them tried to be similar to either 8080 or 6800. So all the early
microprocessor based computers were 8 bit.
For some reason, all the microprocessors building on the early ones tried
to support existing data, plus double width data, so they added 16 bit
capability, then 32 bit capability. So in the eighties, everything
microprocessor based was 8/16/32 bit. I think the main assumption of all
the software written for microprocessors was that one byte = 8 bit, with
bytes being directly addressable, and that is where the 24 bit machines
failed.
There is no real technical advantage of 8/16/32 bit. If I had to write
software that has to run on an 8/16/32 bit system, a 9/18/36 bit system,
and a 12/24/48 bit system, that would be no problem at all - but existing
software makes assumptions about byte size, and that is what makes
different byte and word sizes commercially unviable.
(12/24/48 bit would actually be quite attractive. 12 bit allows for
relatively large character sets, including everything european, arabic,
hebrew, cyrillic, greek. 24 bit is quite nice for video. 48 bit is a nice
size for pointers, allowing access to 256,000 GB of memory; that should be
ok for a dozen years. 48/96 bit for floating point isn't bad either).
Nick Maclaren
In article <8n8vms$sph$1...@news.lth.se>, m...@pobox.com (Magnus Olsson) writes:
|>
|> It would have been afwfully inefficient, performance-wise, to pack
|> 8 7-bit characters into 7 8-bit bytes.
Not really. Packing and unpacking isn't hard, if done right.
We used to do it all the time :-)
Peter da Silva
Ben Hutchings <ben.hu...@roundpoint.com> wrote:
>That seems to be true *now*. The question is surely, how did this
>come to be true - and ASCII is not an adequate explanation.
As someone else noted, you can pack decimal digits together better if a
word is 4N bits long.
You can do offset arithmetic easier if you can do it with shifts. On the
PDP-11/45/55, for example, adds and shifts had an effective time of 0.3 uS.
MUL had an effective time of over 3 uS. DIV had an effective time of 7 to
9 uS. (with bipolar memory, core added about .6 uS to everything), so
you ended up building little shift trees to index packed arrays, or you
had to build hardware that did the same thing.
As memory got cheaper and it was no longer so critical to store characters
so tightly. Also you needed more than 6 bits to handle upper and lower case
for the rapidly growing field of computer typesetting, and the next easy cell
size after 6 bits was 8 bits.
Character-addressible machines made text processing easier, too, and the
PDP-11 memory organization just worked out better there.
The other big advantage 36 bits had over 32 was better floating point, but
64 and 128 bits gives you even more precision, and again memory was getting
cheaper so the extra word size was less a cost than an advantage.
Lots of reasons. None of them critical, but they add up.
--
Rev. Peter da Silva, ULC.
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans)
Patrick A. O'Donnell
> 2^n, and is compatible with ASCII.
Actually, ASCII is a 7-bit code. Five ASCII characters fit
comfortably in a 36-bit word. Many computer vendors, and ISO, have
defined 8-bit extensions to ASCII, but to say that there is "a
standard" is to be hopelessly optimistic.
- Pat
Russell Wallace
>
> Systems nowadays all seem to be running at an 8-bit,
> 16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
> and I don't understand why this trend might exist.
>
> Is this trend due to economic factors?
> Is this trend due to technical factors?
> A combination of both? Or neither?
Aesthetics. It's a lot cleaner and more hassle-free that way.
Considering there's no good reason to _not_ do it that way, people
tended to; therefore software tended to get written on that assumption,
which meant portability issues forced the holdouts into line.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace
gla...@glass2.lexington.ibm.com
>In article <%0Tl5.132491$lU5.9...@news1.rdc1.nj.home.com>, "dls2"
><dlsh...@home.com> wrote:
>
>> Were 24-bit machines doomed to fall by the wayside for lacking
>> simultaneous (2^n)-bit capability? Or for other reasons?
>
>For some reason, all the early microprocessors were 8 bit processors.
>Maybe someone knows why the designers of the 8080 and the 6800 chose 8
>bits, and not 7 or 9; the 8085, Z80, and 6502 were eight bit because each
>of them tried to be similar to either 8080 or 6800. So all the early
>microprocessor based computers were 8 bit.
>
No, not all of the early microprocessors were 8 bit. The earliest (practical)
microprocessor was the Intel 4004, which, if I remember correctly, was
originally designed for use in a calculator. The Intel 4004 was 4 bits wide,
which was just wide enough to process one digit of BCD information. The
follow-on product, the Intel 8008, was exactly double the width at 8 bits.
>For some reason, all the microprocessors building on the early ones tried
>to support existing data, plus double width data, so they added 16 bit
>capability, then 32 bit capability. So in the eighties, everything
>microprocessor based was 8/16/32 bit. I think the main assumption of all
>the software written for microprocessors was that one byte = 8 bit, with
>bytes being directly addressable, and that is where the 24 bit machines
>failed.
>
You can still do 8 bit bytes with a 24 bit machine. However, the addressing
is a little more confusing when stepping through storage in 24 bit increments.
>There is no real technical advantage of 8/16/32 bit. If I had to write
>software that has to run on an 8/16/32 bit system, a 9/18/36 bit system,
>and a 12/24/48 bit system, that would be no problem at all - but existing
>software makes assumptions about byte size, and that is what makes
>different byte and word sizes commercially unviable.
>
Actually, there is a technical advantage of a 4/8/16/32 bit machine.
Try doing arithmetic on packed BCD digits with a 9 bit machine.
It's possible, but you end up wasting a bit.
Note that a lot of early systems (and a lot of current systems, too)
use BCD arithmetic, especially those doing financial calculations,
and that was one of the applications that originally drove computer
evolution.
>(12/24/48 bit would actually be quite attractive. 12 bit allows for
>relatively large character sets, including everything european, arabic,
>hebrew, cyrillic, greek. 24 bit is quite nice for video. 48 bit is a nice
>size for pointers, allowing access to 256,000 GB of memory; that should be
>ok for a dozen years. 48/96 bit for floating point isn't bad either).
But, 12 bits isn't enough to handle all of the possible character sets.
Take a look at the Unicode specifications to see what's happening in the
world of character set development (32 bit characters?).
Dave
P.S. Standard Disclaimer: I work for them, but I don't speak for them.
dls2
> dls2 wrote:
<snip>
> > > > Therefore no computer whose word length is not a multiple of
> > > > 8 can be successful.
> > >
> > > this come to be true - and ASCII is not an adequate explanation.
> >
> is not number crunching is text orientated it makes sense
> to have I/O at least 7 bits width. A 8 bit byte has the least
> waste for I/O and remember back then floppy and hard discs came
> only in small sizes. I am sure one would love to load Windows 2000
> from paper tape.:)
Least waste? Or allows for error detection?
"When an eighth bit is used as a "parity bit," that is a value used for
checking whether or not data have been transmitted properly, then
ASCII becomes an 8-bit, or one-byte (8 bits = 1 byte), character code."
http://tronweb.super-nova.co.jp/characcodehist.html
<snip>
> Ben.
> PS. I still think 24 bits is the Right Size for a small
> computer, providing it is updated for modern computer
> ideas like stacks.
Why do you feel 24-bits is best? For Forth? Or in general?
24-bits addressing? 24-bits data? 24-bits split? Or other?
dls2
> dls2 <dlsh...@home.com> wrote:
<snip>
> >Are there advantages/disadvantages to running (2^n)-bit?
>
> I believe that there are some minor hardware ones, but the main
> so some customers prefer it, and so the marketing departments
> insist on it ....
Well what did the nicer software tend to do?
Provide for every architectural contingency?
Not make use of any architectural features?
Or something else?
> The rot started with the dominance of the System/360 - before
> then, few semi-portable programs built that assumption into their
> codes, but a fair number of ones written for that system did.
Could you elaborate on this?
-- Derrick Shearer
Nick Maclaren
In article <jjUl5.132504$lU5.9...@news1.rdc1.nj.home.com>, "dls2" <dlsh...@home.com> writes:
|> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote:
|> > dls2 <dlsh...@home.com> wrote:
|> <snip>
|> > >Are there advantages/disadvantages to running (2^n)-bit?
|> > >Are there advantages/disadvantages to NOT running (2^n)-bit?
|> > >What about for systems based only on multiples of 2, instead?
|> >
|> > I believe that there are some minor hardware ones, but the main
|> > reason is that the nastier software tends to assume it, and
|> > so some customers prefer it, and so the marketing departments
|> > insist on it ....
|>
|> Well what did the nicer software tend to do?
|>
|> Provide for every architectural contingency?
|> Not make use of any architectural features?
|> Or something else?
Not write system-dependencies into the code unless they were
necessary for its function or important for some other reason
and, even then, to localise them in a few, clean functions.
With assumptions like this, you will often find that they are
completely unnecessary in 90%+ of the programs that make them,
in the sense that code that does not make the assumptions is
as concise, as clear and as efficient.
|> > The rot started with the dominance of the System/360 - before
|> > then, few semi-portable programs built that assumption into their
|> > codes, but a fair number of ones written for that system did.
|>
|> Could you elaborate on this?
Certainly, but in which respect?
paramucho
The PDP-11 represented a new beginning: a machine with an architecture
designed to last a decade or so. Thus, the planners needed to make
some guesses about where market was going.
The principle publication on the PDP-11 says this, under the title
"Design Constraints":
WORD LENGTH
Then most critical constraint, word length (defined by IBM), was
chosen to be a multiple of 8 bits. The memory word length for the
Model 20 [PDP-11/20] is 16 bits... The interna, and preferred
external character set, was chosen to be 8-bit ASCII.
A New Architecture for Minicomputers -- The DEC PDP-11
COMPUTER ENGINEERING, Bell et al, p242
I think that confirms the view that DEC were simply guessing where the
market would go over a period of ten years. And they guessed right.
If you look at the implementation of the instruction set that 16 bit
word is divided into five 3-bit fields plus a 1-bit field. Old habits
die hard. It took the VAX to make the full transition to power-of-two
view of the world.
Ian
Charles Richmond
>
> In article <%0Tl5.132491$lU5.9...@news1.rdc1.nj.home.com>, "dls2"
> <dlsh...@home.com> wrote:
>
> > Were 24-bit machines doomed to fall by the wayside for lacking
> > simultaneous (2^n)-bit capability? Or for other reasons?
>
> For some reason, all the early microprocessors were 8 bit processors.
> Maybe someone knows why the designers of the 8080 and the 6800 chose 8
> bits, and not 7 or 9; the 8085, Z80, and 6502 were eight bit because each
> of them tried to be similar to either 8080 or 6800. So all the early
> microprocessor based computers were 8 bit.
>
twelve bits.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> Perhaps you did notice that all bit widths are either 2^n or 6*2^n.
> upper/lower distinction possible). The CDC hat 60bit word length.
> The 1st widely used computer with 8bit bytes was the IBM /360,
> about 1965. And, in these old days, memory was extremely expensive.
> Therefore addresses were not longer than actually needed for most
> programs. So the PDP-8 could be successful.
>
> 2^n, and is compatible with ASCII.
>
(nee the Datacraft 500). The 800 was a bit-slice processor with an
operating system that was good for real-time simulations, and a heck
of a good FORTRAN77 compiler...it did a great job of optomizing. Boeing,
MacDonald-Douglas, General Dynamics, and most aerospace companies had
these machines for use in simulations.
I used this machine for C programming...it had a byte pointer style of
addressing that would let you get to the bytes. But strings might begin
in the middle of a 24-bit word. To get a string guarenteed to be at
the start of a word, you could define an array of 24-bit integers, and
then cast the pointer to char *.
int inray[20];
char *str = (char *) inray;
Now str[0] was guarenteed to be at the beginning of a word...
Ketil Z Malde
> (12/24/48 bit would actually be quite attractive. 12 bit allows for
> relatively large character sets, including everything european, arabic,
> hebrew, cyrillic, greek. 24 bit is quite nice for video.
And audio!
> 48 bit is a nice size for pointers, allowing access to 256,000 GB of
> memory; that should be ok for a dozen years. 48/96 bit for floating
> point isn't bad either).
-kzm
dls2
Yet oddly enough, the PDP-11 turned out to be DEC's *ONLY*
16-bit PDP model. It seems that, for some reason, DEC didn't
commit itself to the constraints, and reasoning, guiding PDP-11
design.
Though didn't the PDP lineage falter after PDP-11?
Didn't the 32-bit VAX architecture axe, and follow, PDP?
-- Derrick Shearer
James Cownie
> Yet oddly enough, the PDP-11 turned out to be DEC's *ONLY*
> 16-bit PDP model. It seems that, for some reason, DEC didn't
> commit itself to the constraints, and reasoning, guiding PDP-11
> design.
>
> Though didn't the PDP lineage falter after PDP-11?
> Didn't the 32-bit VAX architecture axe, and follow, PDP?
>
By the time that the VAX appeared the PDP 11 was suffering from the
one fatal architectural problem : not enough addressability.
Kluges like separate I and D space couldn't overcome that fundamental issue.
Individual processes needed to address more than the 16bit address space.
The PDP 11 architecture was designed when memory was _expensive_, and it
was sensible for that time and its target market. When memory became cheap
it suffered.
IIRC the paper on 20 years of 360/370 architecture reckoned that address space
requirements went up by one and a half bits every two years...
-- Jim
James Cownie <jco...@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
dls2
> "dls2" <dlsh...@home.com> writes:
> |> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote:
> |> Well what did the nicer software tend to do?
> |>
> |> Provide for every architectural contingency?
> |> Not make use of any architectural features?
> |> Or something else?
>
> Not write system-dependencies into the code unless they were
> necessary for its function or important for some other reason
> and, even then, to localise them in a few, clean functions.
OK.
> With assumptions like this, you will often find that they are
> completely unnecessary in 90%+ of the programs that make them,
> in the sense that code that does not make the assumptions is
> as concise, as clear and as efficient.
OK.
> |> > The rot started with the dominance of the System/360 - before
> |> > then, few semi-portable programs built that assumption into their
> |> > codes, but a fair number of ones written for that system did.
> |>
> |> Could you elaborate on this?
>
> Certainly, but in which respect?
Why was there a change in expectations about a system's capabilities,
advented by IBM's System/360?
-- Derrick Shearer
Sander Vesik
> christ...@isltd.insignia.com (Christian Bau) writes:
>> (12/24/48 bit would actually be quite attractive. 12 bit allows for
>> relatively large character sets, including everything european, arabic,
>> hebrew, cyrillic, greek. 24 bit is quite nice for video.
> And audio!
And 12 bit is also nice for graphics. A lot nicer than 8 bits.
[snip]
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants
--
Sander
FLW: "I can banish that demon"
dls2
What I feel is significant is not the fact that there was an increase
in addressability, but rather what the increase in addressability
was to. Instead of an increase to 18-, 24-, or even 36-bits, a choice
was made to go with 32-bit addressing for the VAX architecture.
If longevity were a real concern, going to 36-bits would not have
been a problem, and would have kept with previous corporate
decisions. The PDP-3, PDP-6, and PDP-10 were all 36-bit.
Why then, were VAXen chosen to be 32-bit, and not 36-bit?
Had DEC come to the conclusion that (2^n)-bit addressing was
fundamentally better, for whatever reasons? It would seem so,
as exemplified by DEC's PDP-11 design constraints mentioned
by paramucho, and later, by DEC's continued reliance on (2^n)-bit
architectures.
-- Derrick Shearer
Nick Maclaren
In article <lyVl5.132517$lU5.9...@news1.rdc1.nj.home.com>,
"dls2" <dlsh...@home.com> writes:
|>
|> > |> > The rot started with the dominance of the System/360 - before
|> > |> > then, few semi-portable programs built that assumption into their
|> > |> > codes, but a fair number of ones written for that system did.
|> > |>
|> > |> Could you elaborate on this?
|> >
|> > Certainly, but in which respect?
|>
|> Why was there a change in expectations about a system's capabilities,
|> advented by IBM's System/360?
Ah! Well, a very large part of the reason was that no one design
had dominated before, and therefore most programs were either
system-specific or portable enough to allow for such variations.
But, with the System/360, it became common for a programmer and
90% of the colleagues with whom he shared data to use a single
architecture.
This was essentially a USA phenomenon, of course, as that did
NOT occur in Europe to the same extent, which is why the skills
in writing portable code were (and, to some extent, still are)
so much more widespread in Europe. In the USA in the 1970s,
they were almost limited to the non-IBM customers!
Maynard Handley
Maclaren) wrote:
>In article <jjUl5.132504$lU5.9...@news1.rdc1.nj.home.com>, "dls2"
<dlsh...@home.com> writes:
>|> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote:
>|> > dls2 <dlsh...@home.com> wrote:
>|> <snip>
>|> > >Are there advantages/disadvantages to running (2^n)-bit?
>|> > >Are there advantages/disadvantages to NOT running (2^n)-bit?
>|> > >What about for systems based only on multiples of 2, instead?
>|> >
>|> > I believe that there are some minor hardware ones, but the main
>|> > reason is that the nastier software tends to assume it, and
>|> > so some customers prefer it, and so the marketing departments
>|> > insist on it ....
>|>
>|> Well what did the nicer software tend to do?
>|>
>|> Provide for every architectural contingency?
>|> Not make use of any architectural features?
>|> Or something else?
>
>Not write system-dependencies into the code unless they were
>necessary for its function or important for some other reason
>and, even then, to localise them in a few, clean functions.
>
>With assumptions like this, you will often find that they are
>completely unnecessary in 90%+ of the programs that make them,
>in the sense that code that does not make the assumptions is
>as concise, as clear and as efficient.
Exactly.
Like all those electrical appliances targetted at 220/110 volts when we
all know that THEORETICALLY we could be delivering power at any voltage.
Like all those engines targetted as gasoline rather than being able to use
any random organic liquid one comes across.
It just makes me so mad that engineers take the easy way out rather which
they then disguise as making a cost-benefit analysis.
Goddammit. In the grand scheme of things that suck about computers and
which should be fixed, 8-bit bytes ranks pretty #$%^ing low.
Maynard
Peter da Silva
paramucho <i...@beathoven.com> wrote:
> If you look at the implementation of the instruction set that 16 bit
> word is divided into five 3-bit fields plus a 1-bit field. Old habits
> die hard. It took the VAX to make the full transition to power-of-two
> view of the world.
Unless you've got some reason to build a packed array of these bit fields
it doesn't much matter how wide they are.
--
`-_-' In hoc signo hack, Peter da Silva.
'U` "Milloin halasit viimeksi suttasi?"
Disclaimer: Matthew 10:16.
Peter da Silva
dls2 <dlsh...@home.com> wrote:
> Though didn't the PDP lineage falter after PDP-11?
> Didn't the 32-bit VAX architecture axe, and follow, PDP?
At one point the VAX had a PDP designation (PDP-11/780 ?).
Ben Franchuk
> Goddammit. In the grand scheme of things that suck about computers and
> which should be fixed, 8-bit bytes ranks pretty #$%^ing low.
>
I like 8-bit bytes for character data. Its the cpu's that have
8 bit opcodes like the 8086,8286,8386,...8786. If intel was smart
they would have made the 8086 a dual processor - 8085 opcodes or
a new 16 bit opcode instruction set rather than all this backwards
compatibility. Ben.
Ps. Good I can sell you my 24 bit processor... No 8 bit bytes.
You can be my only customer.:)
Kevin Handy
dls2 wrote:
>
> "James Cownie" <jco...@etnus.com> wrote:
> > dls2 wrote:
> > > Yet oddly enough, the PDP-11 turned out to be DEC's *ONLY*
> > > 16-bit PDP model. It seems that, for some reason, DEC didn't
> > > commit itself to the constraints, and reasoning, guiding PDP-11
> > > design.
> > >
> > > Though didn't the PDP lineage falter after PDP-11?
> > > Didn't the 32-bit VAX architecture axe, and follow, PDP?
> >
> > By the time that the VAX appeared the PDP 11 was suffering from
> > the one fatal architectural problem : not enough addressability.
> >
> > Kluges like separate I and D space couldn't overcome that
> > fundamental issue. Individual processes needed to address more
> > than the 16bit address space.
> >
> > The PDP 11 architecture was designed when memory was
> > _expensive_, and it was sensible for that time and its target
> > market. When memory became cheap it suffered.
> >
> > IIRC the paper on 20 years of 360/370 architecture reckoned that
> > address space requirements went up by one and a half bits every
> > two years...
>
> What I feel is significant is not the fact that there was an increase
> in addressability, but rather what the increase in addressability
> was to. Instead of an increase to 18-, 24-, or even 36-bits, a choice
> was made to go with 32-bit addressing for the VAX architecture.
>
> If longevity were a real concern, going to 36-bits would not have
> been a problem, and would have kept with previous corporate
> decisions. The PDP-3, PDP-6, and PDP-10 were all 36-bit.
>
> Why then, were VAXen chosen to be 32-bit, and not 36-bit.
I wonder if the available memory technology had something to do
with it. Most of the memory chips were developed with the idea
of interfacing to the 80x86, which is a 2^n based system.
Also, the VAX was being developed as a "Super" PDP-11, and had
a PDP-11 emulation mode built in. Trying to emulate a 16 bit
processor on a 36 bit machine would cause a lot of problems,
and probibly cause a lot of porting problems (like converting
from PDP-11 32/64 bit floats to 36/72 bit floats).
Nick Maclaren
Maynard Handley <hand...@ricochet.net> wrote:
>>
>>Not write system-dependencies into the code unless they were
>>necessary for its function or important for some other reason
>>and, even then, to localise them in a few, clean functions.
>>
>>With assumptions like this, you will often find that they are
>>completely unnecessary in 90%+ of the programs that make them,
>>in the sense that code that does not make the assumptions is
>>as concise, as clear and as efficient.
>
>Exactly.
>Like all those electrical appliances targetted at 220/110 volts when we
>all know that THEORETICALLY we could be delivering power at any voltage.
>Like all those engines targetted as gasoline rather than being able to use
>any random organic liquid one comes across.
Grin :-) You really have chosen a lovely pair of examples!
Back in the days when electronics meant valves (vacuum tubes),
many companies did market dual 110/220 volt systems. Then they
tried to market into the UK, and discovered that the national
average was 240 volts, with some areas going up to 260. A
short life and a merry one :-) So they produced a special UK
model. Then they tried to sell in the Far East, to discover
that many places used the Japanese 200 volt standard, but often
were 20% under. So they produced a special Far East model.
Then they lost sales because their products weren't portable,
so they reengineered. By which time they had lost the market.
I once got an earful from someone who thought that multigrade
engines were obsolete on cars, because you could get 100
octane (four star) anywhere. He then took a day trip to
Eastern Europe, only to find that he had to stay within close
range of the only city that sold it - which wasn't his plan
at all. He was VERY lucky not to get stranded and, in those
days, you couldn't leave the country without a car if you
entered with one (even temporarily, to get fuel) and you
were charged a high daily tax!
Back to computing, in the early 1970s. I was told by people
like you that writing portable code was pointless, because
the System/370 and MVT was so dominating that all future
systems would be compatible with it. And then was told
precisely the same thing by the VAX brigade. Whereas the
quite unnecessarily portable code written in the early 1970s
is still in use :-)
You may be able to predict the future. I can't.
David C. DiNucci
> > ... This makes 24 the smallest word length which is not
> > 2^n, and is compatible with ASCII.
> >
> Which is the word length of the word-addressable Harris 800 or 1200
> (nee the Datacraft 500).
I worked as a summer intern in their OS group in Ft. Lauderdale at one
point, and I remember lots of consideration regarding porting that
"other" OS called Unix to the thing, as opposed to the VULCAN (VirtUaL
Core mANager, or something like that) that ran there at the time.
> I used this machine for C programming...it had a byte pointer style of
> addressing that would let you get to the bytes.
And it was a pain. I did lots of Fortran and assembly work on these
machines. If you wanted to increment such a pointer correctly, you
needed to use a special increment byte pointer instruction (to skip past
the 4th, unused bit combination in the byte offset field), or add code
to do it manually. It really made one appreciate how easy it is to
shift and/or mask on other machines to do the same job.
I also worked on the Honeywell 6400(?), with a 36-bit word which stored
either 4 9-bit ASCII characters or 6 6-bit BCD characters. Again,
dividing by 6 to get to a character--why bother? On a slightly related
note, there was also some encoding used on early PDP-11s (called "mod40"
or something like that) which allowed you to pack 3 characters from a
reduced instruction set (i.e. with 26 letters, 10 digits, and 4 special
characters) into 16 bits using the obvious multiply-by-40-and-add
approach. (In fact, I always figured it was this practice that led to
conventions like 6-letter file names with 3-letter extensions, like
those in early OSs.)
I think the real answer to "why a power of two" is right there in the
subject line. Why not? If it might even POSSIBLY make some things
easier, why not do it unless there are costs that offset it. (And,
these days, costs relating to memory sizes just aren't that great.)
-Dave
Sander Vesik
>> Goddammit. In the grand scheme of things that suck about computers and
>> which should be fixed, 8-bit bytes ranks pretty #$%^ing low.
>>
> I like 8-bit bytes for character data. Its the cpu's that have
> 8 bit opcodes like the 8086,8286,8386,...8786. If intel was smart
> they would have made the 8086 a dual processor - 8085 opcodes or
> a new 16 bit opcode instruction set rather than all this backwards
> compatibility. Ben.
Oh my god! No, no, no, not that!
As if there were not enough modes as it is with AMD to add a couple
of new ones soon for 64 bit support!
> Ps. Good I can sell you my 24 bit processor... No 8 bit bytes.
> You can be my only customer.:)
> --
> "We do not inherit our time on this planet from our parents...
> We borrow it from our children."
> "Octal Computers:Where a step backward is two steps forward!"
> http://www.jetnet.ab.ca/users/bfranchuk/index.html
--
Bob Schor
CDC 160-A Early 1960's 12-bit
CDC 160-G Middle 1960's 13-bit (yes, 13!)
I believe that a lot of this came via IBM from encoding schemes,
and wanting to stick with powers-of-two (i.e. "binary") for obvious
reasons. If you want to represent the letters of the alphabet (one case
only) plus numbers, you need 36 symbols, so 6 bits will work for you
(you will have some left-over space for symbols, like period, question
mark, slash, asterisk, plus, minus, space, etc.). Also, the Hollerith
punch card had 12 rows, so you could (in principle) encode a 12-bit
binary number in a single column (the CDC-160 series used this trick to
read in the bootstrap loaders).
Then, with the System 360 series (I believe), IBM said "Let There
Be EBCDIC", thereby adding two more bits to the unit character size, and
coining a new storage unit, the "byte". And the rest is history ...
Bob Schor
dls2 wrote:
> Systems nowadays all seem to be running at an 8-bit,
> 16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
> and I don't understand why this trend might exist.
>
> Is this trend due to economic factors?
> Is this trend due to technical factors?
> A combination of both? Or neither?
>
> I know that in the past, DEC's PDP systems were not
> based on powers of 2, but on multiples of 2, with the
> exception of the PDP-11, a 16-bit computer.
>
> Any ideas as to why DEC decided to only produce a
> single (2^n)-bit based PDP model, and stuck to using
> multiples of 2 for all its' other PDP models?
>
> ****
>
> PDP-01 1960-vintage 18-bit
> PDP-02 19??-vintage 24-bit
> PDP-03 19??-vintage 36-bit
> PDP-04 1962-vintage 18-bit
> PDP-05 1963-vintage 12-bit
> PDP-06 1964-vintage 36-bit
> PDP-07 1965-vintage 18-bit
> PDP-08 1965-vintage 12-bit
> PDP-09 1966-vintage 18-bit
> PDP-10 1967-vintage 36-bit
> PDP-11 1970-vintage 16-bit
> PDP-12 1969-vintage 12-bit
> PDP-13 19??-vintage ??-bit
> PDP-14 19??-vintage ??-bit
> PDP-15 1970-vintage 18-bit
> PDP-16 1972-vintage ??-bit
>
> ****
>
> Are there advantages/disadvantages to running (2^n)-bit?
> Are there advantages/disadvantages to NOT running (2^n)-bit?
> What about for systems based only on multiples of 2, instead?
>
> appreciatively,
>
> -- Derrick Shearer
John Wilson
>> Why then, were VAXen chosen to be 32-bit, and not 36-bit.
>
>I wonder if the available memory technology had something to do
>with it. Most of the memory chips were developed with the idea
>of interfacing to the 80x86, which is a 2^n based system.
Probably not it, because
(a) The VAX and 8086 both came out in 1978, the VAX had a strong start but
the 8086 didn't really catch on until the IBM PC in 1981. So the VAX
certainly wouldn't have been following the 8086's lead or anything.
(b) DRAM chips at that time usually/always were just one bit wide, so you
could cook up any width you wanted just as easily. Good thing, because
it made ECC memory arrays cheaper than they would have been if you had
to waste bits up to the next multiple of 8 (or 32 or whatever). Well
of course, TGHA could find a use for those buts, but anyway...
I imagine that the success of many 8-bit-byte-addressable machines, including
DEC's own PDP-11s, made 32 bits the obvious choice for the VAX (since 16
address bits clearly wasn't enough, and IBM was already outgrowing 24).
The VAX is *very* byte-y, really you'd think it was a giant 8-bit machine
if not for those wide registers.
John Wilson
D Bit
John Wilson
David C. DiNucci <da...@elepar.com> wrote:
>On a slightly related
>note, there was also some encoding used on early PDP-11s (called "mod40"
>or something like that) which allowed you to pack 3 characters from a
Radix-50 (the 50 is octal of course, so it's 40.). In use to this day...
The 10s used similar stuff, you could fit an entire symbol name in a
register.
>(In fact, I always figured it was this practice that led to
>conventions like 6-letter file names with 3-letter extensions, like
>those in early OSs.)
Exactly. It also prevented the stupid punctuation in filenames that we
have to put up with now.
John Wilson
D Bit
John R. Mashey
Article: 38023 of comp.arch
From: ma...@mash.engr.sgi.com (John R. Mashey)
Subject: Re: Why the powers of 2 ?
Date: Wed, 16 Feb 94 11:05:59 PDT
Lines: 80
In article <CL9q6...@cnsnews.Colorado.EDU>, cro...@rintintin.Colorado.EDU (Matthew Crosby) writes:
|> While there are technical advantages to be had, especially on a byte-addressed
|> another decided that the Vax was the way to go, so they killed the PDP-10.
|> Partly because they believed that powers of 2 were the way to go. IBM
|> stuck to powers of 2 quite early, and with the dominance of the 360 and ebcdic
|> (which is 8 bit, unlike ascii which is 7) they had to stay there. Most of
|> the other non-byte contenters (CDC, for instance) have faded for various
|> reasons.
This is getting close, although somewhat out of order, but really, I believe
that there are just two simple reasons:
1) TECHNICAL NECESSITY IN BYTE/WORD-ADDRESSED MACHINES
Machines designed to support Roman-alphabet character sets
argue for 7,8, or maybe 9-bit characters [some other languages'
character sets need bigger bytes].
Useful integers are bigger, at least 16-32 bits, and generally big
enough to hold interesting pointers.
Floating-point numbers, in general-purpose machines, have reasons
to be at least 32 bits (and one can argue for 36), but 60-64 is often
a necessity.
In any machine whose smallest addressable unit is a byte, and whose
datapaths need to access small multiples of bytes as single units,
i.e., want to access words, at least, using the same kind of addresses,
those multiples generally NEED to be powers of 2 for reasonable designs:
start with a byte address and data-size type
physical memory is normally accessed in larger chunks than a byte
Of N bits of address, use the high-order N1 bits to access the
physical memory, getting 2**(N-N1) bytes back. [usually, 2, 4 or 8]
Use the data-size and low order N-N1 bits to extract the required
data.
All this can be done easily and quickly, just by selecting bits.
IF word = power-of-2 bytes, this has efficient hardware.
IF a "word" is NOT a power-of-2 in terms of bytes, then either you
a) Use word-addressing, and sometimes have special byte pointers
(as in PDP-10 and others) and special operations to sequence
through bytes. Note: you *sequence* through bytes, which can be
done with a fast, narrow adder, not a divider.
OR
b) You need to DIVIDE the byte address by the size of the physical
storage unit to figure out which one to access. This is an
expensive multi-cycle operation right in the middle of the
(critical) addressing path ... maybe somebody has actually built
such a machine for comemrcial use, but I can't think of one.
For example, here's a machine with 3 bytes/word, stored in words:
word byte addr
0, 1, 2 = offset within word
0 0, 1, 2 word addr = byte/3, offset = byte % 3
1 3, 4, 5
2 6, 7, 8
As for a), this kind of solution was used, in various guises, with technical
architectures that needed to do more character processing, and it
works OK, EXCEPT: the C language doesn't fit it very well, in practice.
C is easiest to use when there is exactly one real kind of address pointer.
It is certainly possible to do C on such machines, and was done early,
but there is enough code that takes work to port that C hasn't helped the
lives of other machines. [In fact, this is exactly the reason that I
begged Hennessy & co out of using Stanford MIPS' word-addressing in
the commercial MIPS R2000. I knew what friends had gone through doing
C on XDS Sigma and Univac 100 systems, and didn't want to do it again.]
However, there is no reason that one could not have 7-bit or 9-bit
bytes. Of course, in some instruction sets, there is a minor inefficiency
in the encoding of shifts, extracts, etc, if you end up with a word-size
that isn't a pwoer of 2 in number of total bits (not just bytes), but I think
this is relatively minor. So, The other MAJOR reason is:
2) For whatever reasons, IBM chose 8-bit bytes for the S/360, in the early
1960s, long before there were any Intel chips or any microprocessors.
[Contrary to popular belief, computing did not start with micros :-)].
Once IBM did that, we were going to have 8-bit bytes throughout the
industry, because almost everyone was going to have to deal with
streams of 8-byte bytes, which was either excruciating if your hardware
supported 7-bit bytes, and wasteful of space if you used 9-bits.
(recall that this happened in the core memory era, where a 512KB machine
was quite large.) Had they chosen 9-bit bytes, and 36-bit words,
that's what we'd have, (and the 7090 crowd would have been happier).
SUMMARY
1) IF you have combined byte/word (haflword, doubleword) addressing,
with a uniform addressing scheme, you WILL have words that are powers-of-2
in number of bytes, and a power-of-two byte size might have a minor advantage,
but is not critical.
2) Once IBM chose byte/word addressing and 8-bit bytes around 1960,
we were going to have 8-bit bytes ...
Put another way, the industry choice of byte-addressing & 8-bit bytes
happened around 1960. Nothing later has much to do with it, although
the success of C, and its preference for uniform byte/word/etc addressing,
certainly didn't help word addressed architectures in the 1970s and 1980s.
--
-John Mashey EMAIL: ma...@sgi.com DDD: 650-933-3090 FAX: 650-933-2663
USPS: SGI 1600 Amphitheatre Pkwy., ms. 562, Mountain View, CA 94043-1351
SGI employee 25% time, local consulting elsewise.
Terje Mathisen
> But, 12 bits isn't enough to handle all of the possible character sets.
> Take a look at the Unicode specifications to see what's happening in the
> world of character set development (32 bit characters?).
UTF8 defines encodings for up to 31-bit chars, so presumably the last 2G
of encodings aren't used.
"What, only 2e9 different characters to choose from? That's less than
one per human being!"
Terje
--
- <Terje.M...@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Terje Mathisen
>
> In comp.arch Ketil Z Malde <ke...@ii.uib.no> wrote:
> > christ...@isltd.insignia.com (Christian Bau) writes:
>
> >> (12/24/48 bit would actually be quite attractive. 12 bit allows for
> >> relatively large character sets, including everything european, arabic,
> >> hebrew, cyrillic, greek. 24 bit is quite nice for video.
>
> > And audio!
>
> And 12 bit is also nice for graphics. A lot nicer than 8 bits.
Maybe not nice enough?
John Carmack wrote a long (.plan?) message this spring, calling for
64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
another 16 bits for Alpha.
Eric Fischer
> "IBM PC Extended ASCII Display Characters
> Strictly speaking, the ASCII character set only includes values
> up to 127 decimal (7F hex). However, when the IBM PC was
> developed, the video card contained one byte for each character
> in the 80x25 character display. ...
>
> If this is true, then why did the video card contain one (8-bit) byte
> for each character?
Because all the other memory was 8 bits wide (actually, 8 bits
plus a parity bit), so it would have been more trouble than it
was worth to have a range of 7-bit wide memory just for the
display.
But note that not all computer designers made the same decision:
The original TRS-80 Model I, for instance, had only 7-bit-wide
video memory, and used half of the range for the uppercase-only
subset of ASCII and the other half for block graphics.
eric
Mark Crispin
> I like 8-bit bytes for character data.
Ah, yes, that old "one byte, one character" assumption.
Are you ready for Unicode? If you use the Internet standard UTF-8
encoding, then one Unicode character can be one, two, three, or four
bytes.
So you say you'll use 2 bytes. But Unicode isn't just the 16-bit BMP You
have to consider surrogates. A character is either 2 bytes or 4 bytes,
and you have to look at the value to determine which.
Unicode has 16 planes in addition to the BMP; that is, 0x000000 to
0x20ffff. Yes, really. 0x20ffff. Not 0xfffff. A "20 and 1/2 bit
address space." I haven't seen any 20.5-bit CPUs, have you?
Ah, but even if you say "I'll use UCS-4, and have the full potential of
ISO 10646", you won't win. That's because Unicode has combining
characters. So a character may be multiple Unicode characters, hence 64
bits, 96 bits, 128 bits,...
You can't assume that characters have any relationship to the byte or word
size of your machine any more. You can't assume that characters have a
fixed size in bits any more. Get over those assumptions.
A 36-bit PDP-10 can handle Unicode as competantly as any 8-bit byte
oriented machine. That wasn't the reason why 8-bit byte architecture won.
Nor are the occasional fancy algorithms that only could work on an 8-bit
byte oriented machine. There were just as many (perhaps more) fancy
algorithms that only could work on a 36-bit machine. For many years,
the PDP-10 was a preferred machine for scientific calculations because it
had much better floating point than a 32-bit machine.
The reason is simple: the market. From the market's perspective,
deviation from a perceived standard has a cost. The deviation may be
technically quite desirable; but that doesn't compensate for a small
market presence.
That's why the x86 killed the 68K. Why VHS killed Beta. Why the PC
killed the Mac. You can be better, but "not better enough".
-- Mark --
* RCW 19.190 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.
Tim Shoppa
> Though didn't the PDP lineage falter after PDP-11?
You mean the PDP-11/780? The name was changed before the official
release, but you find references to the PDP-11/780 in much of the
early VAX 11/780 documentation.
> Didn't the 32-bit VAX architecture axe, and follow, PDP?
That's particularly funny, because new PDP-11's are still coming
off the production line, while VAXen are produced no more.
Tim.
Tim Shoppa
> Goddammit. In the grand scheme of things that suck about computers and
> which should be fixed, 8-bit bytes ranks pretty #$%^ing low.
If I see it assumed in C source code, I know that the author made
no provision for portability. This, unfortunately, is true for
about 98% of the non-toy C source that I see.
There are other things that bother me just as much. Things like
assumptions that sizeof(int) == sizeof(pointer).
Tim.
Nick Maclaren
Terje Mathisen <Terje.M...@hda.hydro.com> wrote:
>Sander Vesik wrote:
>>
>> And 12 bit is also nice for graphics. A lot nicer than 8 bits.
>
>Maybe not nice enough?
>
>John Carmack wrote a long (.plan?) message this spring, calling for
>64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
>another 16 bits for Alpha.
Hmm. What species does he belong to? Mere humans cannot distinguish
more than about 2^20 colour/intensity combinations ....
those who know me have no need of my name
>It just makes me so mad that engineers take the easy way out rather which
>they then disguise as making a cost-benefit analysis.
more like marketing requiring a product faster than an elegant solution
could be finished, if indeed it were even possible.
or maybe not. people are generally pretty lazy.
--
okay, have a sig then
Tim Shoppa
>
> In article <%0Tl5.132491$lU5.9...@news1.rdc1.nj.home.com>, "dls2"
> <dlsh...@home.com> wrote:
>
> > Were 24-bit machines doomed to fall by the wayside for lacking
> > simultaneous (2^n)-bit capability? Or for other reasons?
>
> For some reason, all the early microprocessors were 8 bit processors.
> Maybe someone knows why the designers of the 8080 and the 6800 chose 8
> bits, and not 7 or 9; the 8085, Z80, and 6502 were eight bit because each
> of them tried to be similar to either 8080 or 6800. So all the early
> microprocessor based computers were 8 bit.
Yeah, well, they "all" were 8-bit if you interpret "all" to mean
"only the ones that were 8-bit". The Intersil 6100/Harris 6120
was 12 bits wide, and appeared widely in DECmate boxes in offices
around the world. And General Instruments had a hugely succesful
(billions of them sold) Harvard architecture microcontroller line
where the instruction word was 9 to 14 bits wide; the descendants
of these machines are very popular today as PIC controllers from
Microchip.
Tim.
Mark Crispin
> UTF8 defines encodings for up to 31-bit chars, so presumably the last 2G
> of encodings aren't used.
Like UTF-16, UTF-8 defines encodings for 20 1/2-bit characters. Unicode
only defines the 16-bit Basic Multilingual Plane (BMP) plus 16 additional
planes. Yes, there are 17 planes!
You're thinking about UCS-4, which defines the full range of 31-bit
characters in ISO 10646. However, ISO JTC1/SC2/WG2 has stipulated that
planes 1 - 14 (0xe) are to be used for future character assignments, and
this is being done in tandem with Unicode. Plane 14 (0xe) has been
further co-opted for tag character purposes. Planes 15 (0xf) and 16
(0x10) are reserved for private use.
Of the other ISO 10646 planes of UCS-4, groups 0x60 to 0x7f and planes
0xe0 to 0xff in group 0x00 are reserved for private use, but are strongly
discouraged because these codepoint values can't interoperate with
Unicode.
Graphically, the UCS-4 assignments look like:
00 00 00 00 - 00 00 00 7f ASCII
00 00 00 00 - 00 10 ff ff Unicode
00 00 00 00 - 7f ff ff ff ISO 10646 (UCS-4)
00 00 00 00 - 00 00 ff ff ISO 10646/Unicode BMP and surrogates
00 00 01 00 - 00 0e ff ff ISO 10646/Unicode future characters
00 0f 00 00 - 00 10 ff ff ISO 10646/Unicode private use
00 11 00 00 - 00 df ff ff ISO 10646 unassigned(?)
00 e0 00 00 - 00 ff ff ff ISO 10646 private use
01 00 00 00 - 5f ff ff ff ISO 10646 unassigned(?)
60 00 00 00 - 7f ff ff ff ISO 10646 private use
Surrogates use the S (Special) zone of the BMP, between 0xd800 and 0xdfff,
in a pair. The low order 10 bits of each pair member combine to form a 20
bit value, and then 0x10000 is added to this (so a surrogate can never
represent a BMP value). So now you know why there are 17 planes.
The PDP-10 byte instructions would have been quite useful for UTF-8!
Jim Stewart
All valid points. I think that more than anything, cheap 8-bit wide
eproms and cheap 4-bit and 8-bit wide srams were the reason the 8-bit
data bus prevailed.
Jim
hg/jb
of a system included the datapath, the bus, and alllllllllll the
hardware
bits to put it together.
Generally, a 12 bit machine was cheaper to manufacture in 1970
than a 16bit machine in 1970.
We are talking CORE memory, TTL logic, fairly low density pc boards,
minimal integration (ssi was what it was called).
Cost was a serious driver.
bob
Ketil Z Malde wrote:
>
> nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
> >> Are there advantages/disadvantages to running (2^n)-bit?
> >> Are there advantages/disadvantages to NOT running (2^n)-bit?
> >> What about for systems based only on multiples of 2, instead?
>
> > I believe that there are some minor hardware ones, but the main
> > reason is that the nastier software tends to assume it
>
> The cost is probably negligible (e.g. just because you have 64bit
> addressing doesn't mean you have to have 64bit physical, and 32bit
> registers doesn't imply 32bit data paths (e.g. early 68Ks, IIRC)).
> Generally, 2^n are nice numbers to work with, for instance with
> systems that like aligned data.
>
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants
hg/jb
VAX= Virtual Address eXtended.
Bytes were 8 bits (versus a half a word) in 78. Before that there were
bytes of
various sizes - pdp8 had 6 bit bytes, a byte was a half a word.
bob
>
> John Wilson
> D Bit
hg/jb
>
> "paramucho" <i...@beathoven.com> wrote:
> >
> > The PDP-11 represented a new beginning: a machine with an
> > architecture designed to last a decade or so. Thus, the planners
> > needed to make some guesses about where market was going.
> >
> > The principle publication on the PDP-11 says this, under the title
> > "Design Constraints":
> >
> > WORD LENGTH
> > Then most critical constraint, word length (defined by IBM), was
> > chosen to be a multiple of 8 bits. The memory word length for the
> > Model 20 [PDP-11/20] is 16 bits... The interna, and preferred
> > external character set, was chosen to be 8-bit ASCII.
> > A New Architecture for Minicomputers -- The DEC PDP-11
> > COMPUTER ENGINEERING, Bell et al, p242
> >
Look closely at pdp11, ibm360, etc.
You might just see these are 8bit machines with various data path
widths.
Look at the first 8 bits of the instruction, the rest of the
instruction, in byte size chunks, is the operand field.
bob
> > I think that confirms the view that DEC were simply guessing
> > where the market would go over a period of ten years. And they
> > guessed right.
> >
> > If you look at the implementation of the instruction set that 16 bit
> > word is divided into five 3-bit fields plus a 1-bit field. Old habits
> > die hard. It took the VAX to make the full transition to power-of-two
> > view of the world.
>
> Yet oddly enough, the PDP-11 turned out to be DEC's *ONLY*
> 16-bit PDP model. It seems that, for some reason, DEC didn't
> commit itself to the constraints, and reasoning, guiding PDP-11
> design.
>
> Though didn't the PDP lineage falter after PDP-11?
> Didn't the 32-bit VAX architecture axe, and follow, PDP?
>
> -- Derrick Shearer
Ben Franchuk
>
> The question posed, references snapshots in the past where cost
> of a system included the datapath, the bus, and alllllllllll the
> hardware
> bits to put it together.
>
> Generally, a 12 bit machine was cheaper to manufacture in 1970
> than a 16bit machine in 1970.
>
> We are talking CORE memory, TTL logic, fairly low density pc boards,
> minimal integration (ssi was what it was called).
>
> Cost was a serious driver.
> bob
Don't forget 16 bit systems also have a more complex
alu and control unit than the 12 bit-er.
Tim Shoppa
> However, with EBCDIC and extended ASCII (and some other earlier character
> sets) that was less reasonable and also individual logic chips tended to be
> designed to support 1, 2, 4 or 8 bits per chip for various functions
But there are (were) lots of chips that handled, say, 6-bit
wide, 9-bit wide, and 10-bit wide buses, too. And many of these
chips are pretty recent (meaning "new" in the mid-to-late 80's).
There's the 74HCT679 and 74HCT680 12-Bit Address Comparators,
the 74HCT821 10-Bit Bus Interface, the 74HCT923 8-Bit Bus
Interface, and the 74HCT365 Hex Tri-State Bus Driver, for
example.
In the early 70's it was extremely rare to find a DTL or
TTL package that was an 8-bit wide unit. The common 16-bit
packages simply didn't have enough pins for 8 lines in, 8 lines out,
power, ground, and control signals, so most everything
was built out of 4-bit and 6-bit wide units.
Tim.
Ben Franchuk
The TTL market is shrinking fast and it is hard to find any kind
of TTL nowadays in the "Build your own Computer" design field.
Most of the new TTL is bus transfer logic. Two 10 bit chips
address 1 Meg of memory and 9 bit for 8 bits data with parity.
Arg!!! shades of 8088/8086 clones. TTL lost out to low cost
microprocessors and low lost micros lost out to high priced
well marketed and over rated cpu's. Bring back TTL!.
Ben.
Ben Franchuk
>
> In article <8n9p9l$6no$1...@pegasus.csx.cam.ac.uk>,
> Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> >In article <39985C...@hda.hydro.com>,
> >Terje Mathisen <Terje.M...@hda.hydro.com> wrote:
> >>John Carmack wrote a long (.plan?) message this spring, calling for
> >>64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
> >>another 16 bits for Alpha.
>
> >Hmm. What species does he belong to? Mere humans cannot distinguish
> >more than about 2^20 colour/intensity combinations ....
>
> be enough to cover those 2^20 values, since the response of the eye doesn't
> have any direct mapping to electron gun intensity levels and phosphor
> brightness.
Why not just make the RGB floating point, with a common exponent
for magnitude, like Radiance does. Anyhow they have a new model
of how the eyes/brain sees colors and that may be a better way
to render colors. Ben.
> --
> Rev. Peter da Silva, ULC.
>
> "Be conservative in what you generate, and liberal in what you accept"
> -- Matthew 10:16 (l.trans)
Andrew Reilly
>Ps. Good I can sell you my 24 bit processor... No 8 bit bytes.
>You can be my only customer.:)
There are lots and lots of 24 bit processors in everyday use and
development: all of Motorola's DSP56000 family, for example.
_Most_ of the time it makes no difference whatsoever. The
address and data range available in 24 bits is quite nice for
modelling some fairly complicated physical systems.
The only time where it bites is if, say, you have a byte-wide
EPROM in part of the address space, and you need to look
some 24-bit data up in it. That almost certainly involves
multiplication by three or (sometimes) division by three, and
both of those are much nastier operations than the few-bit
shifts required to calculate address offsets in power-of-two
systems.
--
Andrew
Andrew Reilly
>Why do you feel 24-bits is best? For Forth? Or in general?
>24-bits addressing? 24-bits data? 24-bits split? Or other?
Not my original comment, but I'll just add that 24 bits is nice
for quite a few things. There aren't too many measurable physical
phenommena that have a working range larger than 144dB (the dynamic
range of a 24-bit system). 24 bits give you 16M (words) addressability,
which is still close to "enough" for many problem sets, particularly
ones that you want to be able to carry the solution around with
you.
Sure, there are lots of examples that don't need 24 bits. That's
why zillions of 8-bit microcontrollers and 16-bit DSPs are still
sold. There are plenty of abstract problems that require greater
dynamic range or greater addressability, and we have floating point
and 32 or 64-bit systems for those too.
I guess that the interesting question is whether there would have
been useful functionality at the 40 or 48-bit design points, instead
of leaping straight from 32 to 64 bits. I suspect that packing
and sub-word addressability issues ruled the day.
--
Andrew
Michael Lee Finney
dlsh...@home.com says...
> Are there advantages/disadvantages to NOT running (2^n)-bit?
> What about for systems based only on multiples of 2, instead?
Way back...most character applications used a 64-bit character code (not
even the weird 7-bit ANSI which was designed to optimize serial data
transmission). For example, CCITT # 2 and BCDIC. This also meshed very well
with punched cards which have 12 holes per row. Print trains usually had 64
(or less) characters. So, many machines were designed with characters as
multiples of 6 bits, thus 12, 18, 36 and 60 were common and provided a good
deal of compatibility for their time. That meant that you could get 6
characters in a 36-bit word and two characters in a 12-bit word or binary
card deck. By the time ASCII was defined, 36-bit words were more common and
you could still get five characters in a 36-bit word with only a single
wasted bit.
However, with EBCDIC and extended ASCII (and some other earlier character
sets) that was less reasonable and also individual logic chips tended to be
designed to support 1, 2, 4 or 8 bits per chip for various functions --
probably because adding a single line doubled the number of bits per chip.
Besides that, the prevalence of IBM's 360 tended to encourage other vendors
to also adopt 8-bit words. So, while 12, 18, 36 and 60 are multiples of 4
(and 6), that wasn't true for 8-bit chips as the integration level
increased. Since that meshed very well with 8-bit character sets (and
everybody pretty much uses 7-bit ASCII as if it were an 8-bit character
set) the power of two trend was apparent.
Ignoring trivial embedded chips, the last sibilant holdouts for power of 2
words were supercomputers (such as the CRAY). But, even those have fallen
by the wayside.
At this point, I would disqualify a machine for a new application if it did
not have a power of two word. I do make that assumption in all of my
programs (when it makes a difference) and I have yet to have the assumption
violated. At the same time, I have abandoned any assumption about the
number of bits in the character set because we now have 8-bit (extended
ASCII, EBCDIC), 16-bit (Unicode) and 31-bit (ISO 10646). It's true that
Unicode defines symbols in the 10000..100ffff range, but is done via a pair
of characters rather than directly using the complete address range.
Really, that character range is part of ISO 10646 and not Unicode, even
though Unicode provides a mechanism to represent characters in that range.
What is very disappointing is that post version 3.0, 914 new mathematical
symbols have been added in that range even though the lower 16-bit range
hasn't been exhausted. Which means that, in turn, that all signficant
programs will probably need to use ISO 10646 making Unicode itself
obsolete. It also raises, yet again, the problem of displaying extended
character sets for those operating systems which have adapted to Unicode,
but not ISO 10646.
Ketil Z Malde
> Generally, a 12 bit machine was cheaper to manufacture in 1970
> than a 16bit machine in 1970.
> We are talking CORE memory, TTL logic, fairly low density pc boards,
> minimal integration (ssi was what it was called).
> Cost was a serious driver.
But no longer, it would appear.
Actually, since it's becoming fashionable to embed CPUs in FPGAs for
embedded systems, it might make sense again to reduce the bitness? I
know for sure that our stuff won't make use of 4Gb of address
space...(using PPC, not FPGA at the moment though)
Ketil Z Malde
>> John Carmack wrote a long (.plan?) message this spring, calling for
>> 64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
>> another 16 bits for Alpha.
> Hmm. What species does he belong to? Mere humans cannot distinguish
> more than about 2^20 colour/intensity combinations ....
And I'd be surprised if any monitors are that exact, anyway. Why
would he want FP, BTW? To use SSE for fast math, or to get a
logarithmic intensity scale?
Terje Mathisen
>
> On Mon, 14 Aug 2000, Terje Mathisen wrote:
> > UTF8 defines encodings for up to 31-bit chars, so presumably the last 2G
> > of encodings aren't used.
>
> Like UTF-16, UTF-8 defines encodings for 20 1/2-bit characters. Unicode
> only defines the 16-bit Basic Multilingual Plane (BMP) plus 16 additional
> planes. Yes, there are 17 planes!
>
> You're thinking about UCS-4, which defines the full range of 31-bit
> characters in ISO 10646.
Actually, I wasn't:
I stated that UTF-8 defines 31-bit encodings simply because that's what
the encoding scheme does.
As you noted, this does not mean that all possible encodings must (or
can?) be legal.
Having a way for UTF-8 byte stream to encode UCS-4 seems like an
eminently useful feature, particularly since this happens without any
extra magic in the encodings.
Here's my (simplified) perl UTF-8 decoder, it does not check for any
illegal longer-than-needed encodings:
sub utf8_decode
{
my ($t) = @_;
# Any UTF-8 char must start with a byte in 0xC0-0xFD range, followed
# by one or more chars in the 0x80-0xBF range:
# Fast return if no UTF-8 chars found!
return $t unless ($t =~ /[\xC0-\xFD][\x80-\xBF]+/);
my ($out, $start, $match);
$out = "";
do {
# Add any preceeding chars to the output, save the matching pattern
# and any tail end:
$out .= $`; $match = $&; $t = $';
$start = substr($match,0,1); $match = substr($match,1);
# Extract the relevant bits from the lead-in (should be a single
line!)
$start =~
tr/[\xC0-\xDF][\xE0-\xEF][\xF0-\xF7][\xF8-\xFB][\xFC-\xFD]/[\0-\x1F][\0-\xF][\0-\7][\0-\3][\0-\1]/;
$start = ord($start);
# Loop while adding 6 more bits per byte:
do {
$start = ($start << 6) + (ord($match) & 63);
$match = substr($match,1);
} while ($match ne "");
$out .= chr($start);
} while ($t =~ /[\xC0-\xFD][\x80-\xBF]+/);
$out .= $t;
return $out;
Terje Mathisen
>
> nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
> >> John Carmack wrote a long (.plan?) message this spring, calling for
> >> 64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
> >> another 16 bits for Alpha.
>
> > Hmm. What species does he belong to? Mere humans cannot distinguish
> > more than about 2^20 colour/intensity combinations ....
>
> And I'd be surprised if any monitors are that exact, anyway. Why
> would he want FP, BTW? To use SSE for fast math, or to get a
> logarithmic intensity scale?
Both of these comes from the same reason:
He wants to be able to do _many_ layers of texture
processing/lighting/bump mapping etc., while still allowing a smoothly
varying intensity of a single color.
According to his article, at around 8-10 processing steps, and
particularly with low light intensity, having just 8 or 12 bits per
primary color to work with is not enough to avoid banding.
As you noted, a log intensity scale (i.e. fp) gets rid of the varying
intensity resolution problems.
paramucho
>In article <39a013e5...@news.remarq.com>,
>paramucho <i...@beathoven.com> wrote:
>> If you look at the implementation of the instruction set that 16 bit
>> word is divided into five 3-bit fields plus a 1-bit field. Old habits
>> die hard. It took the VAX to make the full transition to power-of-two
>> view of the world.
>
>Unless you've got some reason to build a packed array of these bit fields
>it doesn't much matter how wide they are.
I'm aware of that, but it is curious, and I got some follow-up today.
I was talking an 11-hacker in the city and he recalled a rumour that
an 18-bit design had been considered for the PDP-11 at one point. It
is possible that the 16-bit decision came late in the piece.
Ian
Brian Inglis
wrote:
>Systems nowadays all seem to be running at an 8-bit,
>16-bit, 32-bit, 64-bit, or some other (2^n)-bit capacity,
>and I don't understand why this trend might exist.
>
>Is this trend due to economic factors?
>Is this trend due to technical factors?
>A combination of both? Or neither?
>
>I know that in the past, DEC's PDP systems were not
>based on powers of 2, but on multiples of 2, with the
>exception of the PDP-11, a 16-bit computer.
Multiples of 6 for 6 bit character codes (0-63) and 3 bit octal
number codes.
In DEC's case, may have been related to the amount of discrete
circuitry they could fit on a "Flip Chip" (R) - a small circuit
card.
Later, 3/4 gates per 16 pin SSI TTL may have been a factor.
>Any ideas as to why DEC decided to only produce a
>single (2^n)-bit based PDP model, and stuck to using
>multiples of 2 for all its' other PDP models?
Character codes became 7 bit which involved packing 5 characters
into one 36 bit word or two 18 bit words.
Allowing for parity as telecomms became more popular made 8 bits
a better size for characters, and 16/32 bit addresses were big
enough for most mini/mainframe purposes envisaged.
>****
>
>PDP-01 1960-vintage 18-bit
>PDP-02 19??-vintage 24-bit
>PDP-03 19??-vintage 36-bit
>PDP-04 1962-vintage 18-bit
>PDP-05 1963-vintage 12-bit
>PDP-06 1964-vintage 36-bit
>PDP-07 1965-vintage 18-bit
>PDP-08 1965-vintage 12-bit
>PDP-09 1966-vintage 18-bit
>PDP-10 1967-vintage 36-bit
>PDP-11 1970-vintage 16-bit
>PDP-12 1969-vintage 12-bit
>PDP-13 19??-vintage ??-bit
>PDP-14 19??-vintage ??-bit
>PDP-15 1970-vintage 18-bit
>PDP-16 1972-vintage ??-bit
IIRC, PDP-11s were initially built using AMD 2900 4 bit slice
parts.
DEC stuck with octal, even on the PDP-11s, until the VAX came
along, and then they switched to hex.
>****
>
>Are there advantages/disadvantages to running (2^n)-bit?
>Are there advantages/disadvantages to NOT running (2^n)-bit?
>What about for systems based only on multiples of 2, instead?
>
>
>appreciatively,
>
> -- Derrick Shearer
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian_...@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
use address above to reply
Brian Inglis
wrote:
>dls2 wrote:
>>
>> "paramucho" <i...@beathoven.com> wrote:
>> >
>> > The PDP-11 represented a new beginning: a machine with an
>> > architecture designed to last a decade or so. Thus, the planners
>> > needed to make some guesses about where market was going.
>> >
>> > The principle publication on the PDP-11 says this, under the title
>> > "Design Constraints":
>> >
>> > WORD LENGTH
>> > Then most critical constraint, word length (defined by IBM), was
>> > chosen to be a multiple of 8 bits. The memory word length for the
>> > Model 20 [PDP-11/20] is 16 bits... The interna, and preferred
>> > external character set, was chosen to be 8-bit ASCII.
>> > A New Architecture for Minicomputers -- The DEC PDP-11
>> > COMPUTER ENGINEERING, Bell et al, p242
>> >
>Look closely at pdp11, ibm360, etc.
>You might just see these are 8bit machines with various data path
>widths.
>Look at the first 8 bits of the instruction, the rest of the
>instruction, in byte size chunks, is the operand field.
>bob
s360 had 16 bit multiple instructions and 32 bit data (24 bit
addresses) except for 360/20.
Sander Vesik
>> > christ...@isltd.insignia.com (Christian Bau) writes:
>>
>> >> (12/24/48 bit would actually be quite attractive. 12 bit allows for
>> >> relatively large character sets, including everything european, arabic,
>> >> hebrew, cyrillic, greek. 24 bit is quite nice for video.
>>
>> > And audio!
>>
>> And 12 bit is also nice for graphics. A lot nicer than 8 bits.
> Maybe not nice enough?
It basicly depends upon if you want to use the same data format (12bits)
for intermediate calculations or if you use a wider format for that. In
a hypothetical 12/24/48 it would be "natural" to use 'one-higher' data
type for the temporary values - 24 for graphics and 48 for audio
(you would occasionaly use long long type 96 bit quantities - see for example
the 56 bit accumulators in DSPs).
> John Carmack wrote a long (.plan?) message this spring, calling for
> 64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
> another 16 bits for Alpha.
Weren't there SGI OpenGL boards that supported this? IIRC, of course.
> Terje
> --
> - <Terje.M...@hda.hydro.com>
> Using self-discipline, see http://www.eiffel.com/discipline
> "almost all programming can be viewed as an exercise in caching"
--
Sander
FLW: "I can banish that demon"
paramucho
>
>Had DEC come to the conclusion that (2^n)-bit addressing was
>fundamentally better, for whatever reasons? It would seem so,
>as exemplified by DEC's PDP-11 design constraints mentioned
>by paramucho, and later, by DEC's continued reliance on (2^n)-bit
>architectures.
By the time the VAX came around I don't think anyone would have
seriously considered going to a 6-bit model. It would have been like
going back to punch cards or paper tape. Who else produced a 6-bit
based machine at that time?
Ian
paramucho
Another point along the same line occurred to me.
The native machine language base of the PDP-11 was the 3-bit Octal
code, which is perversely unnatural in an 8-bit system. A hangover
from the 6-bit architectures.
Again, it took the Vax to go the further step and move to Hex, a 4-bit
encoding. The move was well judged: octal has become an anachronism
(sadly :-)
Ian
jepler epler
>>64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
>>another 16 bits for Alpha.
>
<nm...@cus.cam.ac.uk> wrote:
>Hmm. What species does he belong to? Mere humans cannot distinguish
>more than about 2^20 colour/intensity combinations ....
Carmack suggested that the reason for 16-bit-float framebuffer components
is to support multipass rendering with intermediate intensities outside a
[0,1) range, presumably even if the final output is truncated to somewhere
in the 15-30 bit range.
Jeff
paramucho
wrote:
>dls2 wrote:
>
>> Yet oddly enough, the PDP-11 turned out to be DEC's *ONLY*
>> 16-bit PDP model. It seems that, for some reason, DEC didn't
>> commit itself to the constraints, and reasoning, guiding PDP-11
>> design.
>>
>> Though didn't the PDP lineage falter after PDP-11?
>> Didn't the 32-bit VAX architecture axe, and follow, PDP?
>>
>
>By the time that the VAX appeared the PDP 11 was suffering from the
>one fatal architectural problem : not enough addressability.
Actually, by the time that the *PDP-11* appeared the PDP-11 was
already suffering from the memory problem:
In the original 1970 PDP-11 paper, a set of design goals and
constraints were given, beginning with a discussion of the
weaknesses frequently found in minicomputers...
...The first weakness of minicomputers was their limited
addressing capability. The biggest (and most common) mistake
that can be made in a computer design is that not providing
enough address bits for memory addressing and management.
The PDP-11 followed this hallowed tradition of skimping on
address bits but it was saved by the principle that a good
design can evolve through at least one major change.
[IH: I think the original formulation of the last point was
something like: "you can afford at least one major screw-up
in an architecture"].
For the PDP-11, the limited address problem was solved for
the short run [IH: by stealing a couple of unused bus lines]
but not with enough finess [IH: read: "the memory management
design *also* skimped with its 32-word page size] to support
a large family of minicomputers [IH: which was the primary
goal of the PDP-11]
It is extremely embarassing that the PDP-11 had to be
redesigned with memory management only two years after writing
the paper that outlined the goal of providing increased address
space....
In retrospect, it is clear that another adress bit is
required every two or three years, since memory prices decline
about 30 percent yearly, and users tend to buy constant price
successor systems.
The Evolution Of The PDP-11
COMPUTER ENGINEERING, Bell et al, p383
I haven't read that passage in many years, but it's pretty easy, in
retrospect, to read the handwriting of Gordon Bell. The key ideas of a
major screwup, and constant price successor systems stand out and the
use of an economic equation to determine growth are typical.
He must have worked hard on the passage since this was where he had to
explain a really basic error. I always found his honesty refreshing.
What about the "bit every two or three years" dictum. It's 30 years
since 1970, so we should be around about at 16+10=26 to 16+15=31 mark.
I'd say that describes pretty much the low to high end of the client
market, with an expection of 64-bit systems for the broad market in
the next couple of years.
BTW: I seem to recall that the unibus lines used for memory management
were a couple of unused lines reserved for memory parity???
Ian
Peter da Silva
Mark Crispin <m...@CAC.Washington.EDU> wrote:
>A 36-bit PDP-10 can handle Unicode as competantly as any 8-bit byte
>oriented machine. That wasn't the reason why 8-bit byte architecture won.
I think there's a problem with timing in that.
Peter da Silva
paramucho <i...@beathoven.com> wrote:
>The native machine language base of the PDP-11 was the 3-bit Octal
>code, which is perversely unnatural in an 8-bit system. A hangover
>from the 6-bit architectures.
I think it was more of a matter of them trying to pack as many registers and
modes into 16 bits as they could, while keeping the instruction set regular.
It would arguably have been better to require one of the operands to be
a register (it would certainly have made it easier to build fast PDP-11s
later on), letting them have 16 registers in the same 12 bits of operand (7
bits for memory operand, 4 bits for register, 1 bit for load/store), but
they were deliberately trying to avoid a load/store architecture. Once you
had made that decision, the 3.3.3.3 encoding is more or less inevitable.
paramucho
>In article <39a62eea...@news.remarq.com>,
>paramucho <i...@beathoven.com> wrote:
>>The native machine language base of the PDP-11 was the 3-bit Octal
>>code, which is perversely unnatural in an 8-bit system. A hangover
>>from the 6-bit architectures.
>
>I think it was more of a matter of them trying to pack as many registers and
>modes into 16 bits as they could, while keeping the instruction set regular.
>
>It would arguably have been better to require one of the operands to be
>a register (it would certainly have made it easier to build fast PDP-11s
>later on), letting them have 16 registers in the same 12 bits of operand (7
>bits for memory operand, 4 bits for register, 1 bit for load/store), but
>they were deliberately trying to avoid a load/store architecture. Once you
>had made that decision, the 3.3.3.3 encoding is more or less inevitable.
Yes, but it occurs much more readily to a bunch of designers who are
used to working with 3-bit and 6-bit fields. In fact, a byte-oriented
PDP-11 along the lines of the VAX could have been more memory
effective.
My point is probably not much more than an aside: old habits change
slowly.
Ian
Jay Maynard
wrote:
>Are you ready for Unicode? If you use the Internet standard UTF-8
>encoding, then one Unicode character can be one, two, three, or four
>bytes.
>
>So you say you'll use 2 bytes. But Unicode isn't just the 16-bit BMP You
>have to consider surrogates. A character is either 2 bytes or 4 bytes,
>and you have to look at the value to determine which.
>
>Unicode has 16 planes in addition to the BMP; that is, 0x000000 to
>0x20ffff. Yes, really. 0x20ffff. Not 0xfffff. A "20 and 1/2 bit
>address space." I haven't seen any 20.5-bit CPUs, have you?
Gods below, what a kludge.
Dan Pop
>IIRC, PDP-11s were initially built using AMD 2900 4 bit slice
>parts.
You don't remember correctly. There was no such thing as AMD 2900 in
the late sixties, when the PDP-11 was initially designed.
Later PDP-11 models and the low cost VAX-11/730 were built using AMD 2900
parts.
>DEC stuck with octal, even on the PDP-11s, until the VAX came
>along, and then they switched to hex.
With 8 registers and 8 addressing modes, octal is the *natural* choice
for the PDP-11. Likewise, with 16 registers and (sort of) 16 addressing
modes, hex is the natural choice for the VAX.
The 8080 opcodes were originally documented in octal, too, because this
is the natural choice for an architecture with 7 registers and one
register pair (HL) used for indirect memory addressing.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Johnny Billquist
>
> "paramucho" <i...@beathoven.com> wrote:
> >
> > If you look at the implementation of the instruction set that 16 bit
> > word is divided into five 3-bit fields plus a 1-bit field. Old habits
> > die hard. It took the VAX to make the full transition to power-of-two
> > view of the world.
>
> 16-bit PDP model. It seems that, for some reason, DEC didn't
> commit itself to the constraints, and reasoning, guiding PDP-11
> design.
Actually, the PDP-16 claims to be a 16-bit machine...
But yes, DEC didn't design a new 16-bitter. The PDP-11 was hugely
successful, and DEC developed inside that architecture.
> Though didn't the PDP lineage falter after PDP-11?
> Didn't the 32-bit VAX architecture axe, and follow, PDP?
No. The "last" PDP model came out about 1972, and the PDP-12 as well
as the PDP-15 was pretty successful.
DEC, for whatever reason, decided to stop crank out several new
architectures each year, and instead started to refine whatever
they had, that was selling good.
This meant the PDP-8, PDP-10, PDP-11 and PDP-15.
All of these did see improved models coming out.
The PDP-8 and PDP-15 soon reached the end though, as other
machines came out that could replace them.
The VAX didn't come until 1976, so you have a four year gap
here. Thus it's rather pretentious to claim that the
VAX had much to do with the stop on new PDP models.
Although perhaps it might be said that effort poured into
the VAX instead of other new architectures. But I doubt
that much effort was underway in 1972.
Johnny
--
Johnny Billquist | johnny.b...@netinsight.net
Net Insight AB | phone: +46 8 685 04 88
Västberga Allé 9 | fax: +46 8 685 04 20
Box 42093 |
SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net
donald tees
paramucho wrote in message <39a62eea...@news.remarq.com>...>>On 14 Aug 2000 17:27:28 GMT, pe...@nmti.com (Peter da Silva) wrote:
>>
>>>In article <39a013e5...@news.remarq.com>,
>>>paramucho <i...@beathoven.com> wrote:
>>>> If you look at the implementation of the instruction set that 16 bit
>>>> word is divided into five 3-bit fields plus a 1-bit field. Old habits
>>>> die hard. It took the VAX to make the full transition to power-of-two
>>>> view of the world.
>>>
>>>it doesn't much matter how wide they are.
>>
>>I'm aware of that, but it is curious, and I got some follow-up today.
>>I was talking an 11-hacker in the city and he recalled a rumour that
>>an 18-bit design had been considered for the PDP-11 at one point. It
>>is possible that the 16-bit decision came late in the piece.
>
>
>Another point along the same line occurred to me.
>
>code, which is perversely unnatural in an 8-bit system. A hangover
>from the 6-bit architectures.
>
You really believe that? I don't. I think they probably used three bits
because they had eight opcodes. I doubt very much that they decided to have
eight opcodes based on a sense of what was "natural" and what was
"unnatural". I can just picture an engineer saying "lets just throw one bit
away, and not use it. Octal is becoming unfashionable".
Johnny Billquist
> > > 16-bit PDP model. It seems that, for some reason, DEC didn't
> > > commit itself to the constraints, and reasoning, guiding PDP-11
> > > design.
> > >
> > > Didn't the 32-bit VAX architecture axe, and follow, PDP?
> >
> > the one fatal architectural problem : not enough addressability.
> >
> > fundamental issue. Individual processes needed to address more
> > than the 16bit address space.
> >
> > The PDP 11 architecture was designed when memory was
> > _expensive_, and it was sensible for that time and its target
> > market. When memory became cheap it suffered.
> >
> What I feel is significant is not the fact that there was an increase
> in addressability, but rather what the increase in addressability
> was to. Instead of an increase to 18-, 24-, or even 36-bits, a choice
> was made to go with 32-bit addressing for the VAX architecture.
You miss the obvious point. It wasn't the PDP-10 that was having
addressing problems, it was the PDP-11.
Thus, they set out to solve that problem. The VAX-11/780 was initially
named PDP-11/780 before the VAX name was coined.
Since it was a development of the PDP-11, word size obviously would
have to be a multiple of the PDP-11 word size. Anything *but* 32 would have
been a big mystery. (Well, perhaps 48 or 64 would have been acceptable
too. :-)
> If longevity were a real concern, going to 36-bits would not have
> been a problem, and would have kept with previous corporate
> decisions. The PDP-3, PDP-6, and PDP-10 were all 36-bit.
??? There is no sense at all in trying to convert the PDP-11 to
a 36-bit machine. It would not have been backwards compatible,
which means the whole development would have been useless. It
was the PDP-11 which had an addressing problem, but at the same
time it was selling like hell. Those customers wanted that machine
but they were asking for larger addressing for it.
What would you do?
Develop another, incompatible machine with 36-bit addresses and
try to sell that? That sure as hell don't make sense. You already
have a 36-bit machine...
> Why then, were VAXen chosen to be 32-bit, and not 36-bit?
You seem to be totally unaware of why the VAX was developed,
or what DEC was selling at that time. At the same time the VAX
came out, the -2020 was released as well. It obviously didn't
penetrate to the same customers that the PDP-11 was selling to.
Is there any other conclusion that can be drawn, except that
they wanted those darned 16-bitters?
And if they wanted those 16-bitters, but didn't go for the 18-bitters,
nor 36-bitters, we might as well try to make a 32-bitter, which
looks, tastes and somewhat smells like the PDP-11, and see
if we can't sell them that.
> Had DEC come to the conclusion that (2^n)-bit addressing was
> fundamentally better, for whatever reasons? It would seem so,
> as exemplified by DEC's PDP-11 design constraints mentioned
> by paramucho, and later, by DEC's continued reliance on (2^n)-bit
> architectures.
No. When DEC came out with the VAX, they was by no way comitted to
2^n bits. They were selling 12, 16, 18 and 36 bits at the time.
But the selling numbers for the PDP-11 outperformed that of
the PDP-8/12, which was the previous high volume machine.
18 and 36 bits were rather low volume. When VAX turned out
to be really high volume as well, that's when they decided
to throw the rest out. Not a wise decision if you ask me,
but the numbers atleast can't be argued.
I'd say the customers at large drove DEC to 2^n.
"Better" has very little to do with business decisions.
Johnny Billquist
>
> dls2 wrote:
> >
> > Why then, were VAXen chosen to be 32-bit, and not 36-bit.
>
> I wonder if the available memory technology had something to do
> with it. Most of the memory chips were developed with the idea
> of interfacing to the 80x86, which is a 2^n based system.
No. The 80x86 came out around or after the VAX, and besides the
PDP-11 was already there.
> Also, the VAX was being developed as a "Super" PDP-11, and had
> a PDP-11 emulation mode built in. Trying to emulate a 16 bit
> processor on a 36 bit machine would cause a lot of problems,
> and probibly cause a lot of porting problems (like converting
> from PDP-11 32/64 bit floats to 36/72 bit floats).
This is important. Note that VAX and PDP-11 have compatible
FP formats.
And the PDP-11 compatible mode in early VAXen was rather important.
Without that, they would not have been able to sell that good,
and the effort to develop VMS would have been substatially larger,
and taken a lot more time.
Early VMS had quite a lot of RSX stuff in there.
Johnny Billquist
>
> In article <39984CFD...@srv.net>, Kevin Handy <k...@srv.net> wrote:
> >> Why then, were VAXen chosen to be 32-bit, and not 36-bit.
> >
> >I wonder if the available memory technology had something to do
> >with it. Most of the memory chips were developed with the idea
> >of interfacing to the 80x86, which is a 2^n based system.
>
>
> (a) The VAX and 8086 both came out in 1978, the VAX had a strong start but
> the 8086 didn't really catch on until the IBM PC in 1981. So the VAX
> certainly wouldn't have been following the 8086's lead or anything.
Eh? I remember VAXen coming out 1977, or possibly even 1976.
Thinking of it I suspect it was 1977 however...
> (b) DRAM chips at that time usually/always were just one bit wide, so you
> could cook up any width you wanted just as easily. Good thing, because
> it made ECC memory arrays cheaper than they would have been if you had
> to waste bits up to the next multiple of 8 (or 32 or whatever). Well
> of course, TGHA could find a use for those buts, but anyway...
>
> I imagine that the success of many 8-bit-byte-addressable machines, including
> DEC's own PDP-11s, made 32 bits the obvious choice for the VAX (since 16
> address bits clearly wasn't enough, and IBM was already outgrowing 24).
> The VAX is *very* byte-y, really you'd think it was a giant 8-bit machine
> if not for those wide registers.
Well, also, the VAX was considered a plain expansion of the PDP-11.
Thus PDP-11/780.
But the architecture definitely was byte-y, in contrast with the PDP-11
which still was rather word-y. :-)
Johnny Billquist
>
> VAX= Virtual Address eXtended.
Yes.
> Bytes were 8 bits (versus a half a word) in 78. Before that there were
> bytes of
> various sizes - pdp8 had 6 bit bytes, a byte was a half a word.
Huh??? Bytes were 8 bits on the VAX, correct. A halfword don't exist
on the PDP-11 or VAX. On a PDP-10 a halfword is 18 bits.
Bytes were definitely of various sizes before that. A PDP8, however,
didn't have 6-bit bytes. It had no concept like that. Your software
did. And SIXBIT was used to store text sometimes. But you also
stored text in 8-bit bytes, three to two words.
Remember, a byte is a convenient number of bits for whatever use you
need. A PDP-10 can have anything from 1 to 36 bits in a byte.
Dan Pop
>Another point along the same line occurred to me.
>
>The native machine language base of the PDP-11 was the 3-bit Octal
>code, which is perversely unnatural in an 8-bit system.
When the system has 8 registers and 8 addressing modes, the 3-bit octal
code becomes perversely *natural* in a 16-bit system :-) The PDP-11
instructions contained up to 4 3-bit fields.
I've done quite a lot of hand coding for the PDP-11 and this octal coding
scheme worked like a charm (although I came from a hex background). The
only tricky bit was hand coding the branch instructions, because the
offset was stored in the lower 8 bits of the instruction.
>A hangover from the 6-bit architectures.
Not at all. The 8080 opcodes were originally documented in octal too,
for exactly the same reason (they contained one or two 3-bit fields)
and Intel had no hangover from the 6-bit architectures.
Nick Maclaren
How very boring! I hoped that we had achieved SETI at home :-)
While I agree with him that a scaled-down floating point is an
appropriate notation, I don't think that I regard as 16-bits
as worth bothering with. In particular, it isn't good enough
for such intermediate calculations if they use any non-trivial
image processing techniques (e.g. FFT-based ones).
And, for mere display, 8 bits per colour plus 8 bits Alpha is
quite enough.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Johnny Billquist
>
> Look closely at pdp11, ibm360, etc.
> You might just see these are 8bit machines with various data path
> widths.
> Look at the first 8 bits of the instruction, the rest of the
> instruction, in byte size chunks, is the operand field.
If you believe that, then I suggest you start learning about the PDP-11.
You are about as wrong here as you can possibly be.
Johnny Billquist
>
> IIRC, PDP-11s were initially built using AMD 2900 4 bit slice
> parts.
Hmmm. Interesting. Could anyone confirm/deny this?
I know that the 11/20 was the only PDP-11 that wasn't
microprogrammed, but instead used discrete logic. I've
always assumed this meant standard 74xx TTL chips, in
the same way the 8/E did, but I've never seen one
in real life.
> DEC stuck with octal, even on the PDP-11s, until the VAX came
> along, and then they switched to hex.
Yep. But octal on the PDP-11 was a mixed blessing. It was good
for viewing the opcodes, but a pain for 8-bit bytes.
amoli...@visi-dot-com.com
>
>The native machine language base of the PDP-11 was the 3-bit Octal
>from the 6-bit architectures.
>
Octal is Just The Thing for writing 16 bit numbers in, because
you get 5 digits plus a sign digit. I forget WHY, but the top bit was
important on the PDP-11s, so octal made reading machine code a little
easier. I know you can get the sign bit in hex too, but it sure was
nice to just have a 1/0 digit you could look at.
Andrew
>Ian
Dan Thompson
>
> Brian Inglis wrote:
> >
> > IIRC, PDP-11s were initially built using AMD 2900 4 bit slice
> > parts.
>
> Hmmm. Interesting. Could anyone confirm/deny this?
> I know that the 11/20 was the only PDP-11 that wasn't
> microprogrammed, but instead used discrete logic. I've
> always assumed this meant standard 74xx TTL chips, in
> the same way the 8/E did, but I've never seen one
> in real life.
>
The PDP-11/20 came out in 1969-1970. It was built with TTL on 1 and 2
unit flip-chip type cards and required 2 1/2 4-slot backplace units for
the processor itself. Most of the available ICs were SSI(small scale
integration). I first started working on a PDP-11/20 in spring of 1970.
The 11/05 & 11/10 were also mostly TTL I believe. I have looked at (even
studied ) the engineering drawings of these machines in the years I was
working with them. Even the 11/40 (we got one in Summer 1974) still used
a lot of TTL.
I did not hear about the AMD2900 4-bit slice ICs until a few years
later. I would have to look up stuff at home to pin-point the time for
this.
Gene Wirchenko
>In article <rpNl5.131549$lU5.8...@news1.rdc1.nj.home.com>,
>dls2 <dlsh...@home.com> wrote:
>>
>>PDP-01 1960-vintage 18-bit
>>PDP-02 19??-vintage 24-bit
>>PDP-03 19??-vintage 36-bit
>>PDP-04 1962-vintage 18-bit
>>PDP-05 1963-vintage 12-bit
>>PDP-06 1964-vintage 36-bit
>>PDP-07 1965-vintage 18-bit
>>PDP-08 1965-vintage 12-bit
>>PDP-09 1966-vintage 18-bit
>>PDP-10 1967-vintage 36-bit
>>PDP-11 1970-vintage 16-bit
>>PDP-12 1969-vintage 12-bit
>>PDP-13 19??-vintage ??-bit
>>PDP-14 19??-vintage ??-bit
>>PDP-15 1970-vintage 18-bit
>>PDP-16 1972-vintage ??-bit
>
>Perhaps you did notice that all bit widths are either 2^n or 6*2^n.
On the latter, not if n is an integer. Did you mean 6*n? That
would cover *all* of them except that one 16-bitter.
>In the old days 6 bits were needed to hold 1 character (no
>upper/lower distinction possible). The CDC hat 60bit word length.
>The 1st widely used computer with 8bit bytes was the IBM /360,
>about 1965. And, in these old days, memory was extremely expensive.
>Therefore addresses were not longer than actually needed for most
>programs. So the PDP-8 could be successful.
>
>Now we have ASCII code, which is based on the 8bit/byte assumption.
ASCII is a seven-bit code ESPECIALLY in afc.
>Therefore no computer whose word length is not a multiple of
>8 can be successful. This makes 24 the smallest word length which is not
Jumping a little far on that conclusion, aren't you?
>2^n, and is compatible with ASCII.
What's wrong with 7 or 14 or 21?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Gene Wirchenko
>gla...@glass2.lexington.ibm.com wrote:
>> But, 12 bits isn't enough to handle all of the possible character sets.
>> Take a look at the Unicode specifications to see what's happening in the
>> world of character set development (32 bit characters?).
>
>UTF8 defines encodings for up to 31-bit chars, so presumably the last 2G
>of encodings aren't used.
>
>"What, only 2e9 different characters to choose from? That's less than
>one per human being!"
May I please have ^G?
John F Carr
Brian Inglis <Brian.do...@SystematicSw.ab.ca> wrote:
>IIRC, PDP-11s were initially built using AMD 2900 4 bit slice
>parts.
I thought the VAX 11/750 was the bit slice CPU.
--
John Carr (j...@mit.edu)
Dan Pop
> Octal is Just The Thing for writing 16 bit numbers in, because
>you get 5 digits plus a sign digit. I forget WHY, but the top bit was
>important on the PDP-11s,
It made the distinction between the byte and the word version of the
same instruction (0 for word, 1 for byte).
>so octal made reading machine code a little easier.
Octal made reading (and writing) machine code a *lot* easier, for other
reasons mentioned in this thread.
Maynard Handley
Maclaren) wrote:
>In article <handleym-140...@handma2.apple.com>,
>Maynard Handley <hand...@ricochet.net> wrote:
>>>
>>>Not write system-dependencies into the code unless they were
>>>necessary for its function or important for some other reason
>>>and, even then, to localise them in a few, clean functions.
>>>
>>>With assumptions like this, you will often find that they are
>>>completely unnecessary in 90%+ of the programs that make them,
>>>in the sense that code that does not make the assumptions is
>>>as concise, as clear and as efficient.
>>
>>Exactly.
>>Like all those electrical appliances targetted at 220/110 volts when we
>>all know that THEORETICALLY we could be delivering power at any voltage.
>>Like all those engines targetted as gasoline rather than being able to use
>>any random organic liquid one comes across.
>
>Grin :-) You really have chosen a lovely pair of examples!
>
>Back in the days when electronics meant valves (vacuum tubes),
>many companies did market dual 110/220 volt systems. Then they
>tried to market into the UK, and discovered that the national
>average was 240 volts, with some areas going up to 260. A
>short life and a merry one :-) So they produced a special UK
>model. Then they tried to sell in the Far East, to discover
>that many places used the Japanese 200 volt standard, but often
>were 20% under. So they produced a special Far East model.
>Then they lost sales because their products weren't portable,
>so they reengineered. By which time they had lost the market.
"Back in the days"? I am talking about designing TODAY.
Sure, yes if we were designing a radio in 1910 we might make a different
set of assumption.
>I once got an earful from someone who thought that multigrade
>engines were obsolete on cars, because you could get 100
>octane (four star) anywhere. He then took a day trip to
>Eastern Europe, only to find that he had to stay within close
>range of the only city that sold it - which wasn't his plan
>at all. He was VERY lucky not to get stranded and, in those
>days, you couldn't leave the country without a car if you
>entered with one (even temporarily, to get fuel) and you
>were charged a high daily tax!
Yes---so the entire OECD should suffer more expensive, heavier cars to
help out some tiny fraction of the population who want to drive their car
elsewhere?
Maynard
Thatcher Ulrich
>
> In article <slrn8pgvn3.m...@potty.housenet>, jeple...@lnk.ispi.net (jepler epler) writes:
> |> In article <39985C...@hda.hydro.com>,
> |> Terje Mathisen <Terje.M...@hda.hydro.com> wrote:
> |> >>John Carmack wrote a long (.plan?) message this spring, calling for
> |> >>64-bit graphics, using 16 bits (in fp format) for each of R, G & B, plus
> |> >>another 16 bits for Alpha.
> |> >
> |> On 14 Aug 2000 21:45:25 GMT, Nick Maclaren
> |> <nm...@cus.cam.ac.uk> wrote:
> |> >Hmm. What species does he belong to? Mere humans cannot distinguish
> |> >more than about 2^20 colour/intensity combinations ....
> |>
> |> Carmack suggested that the reason for 16-bit-float framebuffer components
> |> is to support multipass rendering with intermediate intensities outside a
> |> [0,1) range, presumably even if the final output is truncated to somewhere
> |> in the 15-30 bit range.
>
> How very boring! I hoped that we had achieved SETI at home :-)
>
> While I agree with him that a scaled-down floating point is an
> appropriate notation, I don't think that I regard as 16-bits
> as worth bothering with. In particular, it isn't good enough
> for such intermediate calculations if they use any non-trivial
> image processing techniques (e.g. FFT-based ones).
Many of the new and future cutting-edge effects in real-time game graphics
involve multiple passes and pixel math in the frame buffer.
Here's what Carmack wrote:
http://finger.planetquake.com/plan.asp?userid=johnc&id=14274
> And, for mere display, 8 bits per colour plus 8 bits Alpha is
> quite enough.
Carmack disagrees with you here, too, claiming that restricted-range
images show banding w/ 8 bit components. If you've ever played Quake,
you'll know what he means by "restricted-range images" :) Although he's
not yet calling for 64-bit front buffers on pragmatic grounds. Anyway,
don't listen to me; read the article.
--
Thatcher Ulrich
http://tulrich.com
Joe Smith
>Are there advantages/disadvantages to NOT running (2^n)-bit?
32 bits is not really enough for floating point numbers. When designing
a machine that uses word addressing, the number of bits per word can be
adjusted to match the application. If it was determined that the
primary application needed 59 bits to store a number, then it made sense
to build a 59-bit machine. That's what they did back in the '40s and
'50s. Back when single-purpose computers were built to match the
problem. This also meant building a custom disk controller to read and
write 59-bit words, but that's how things were done.
Interoperability these days means that doing I/O to off-the-shelf
8-bit-wide peripherals is highly desirable.
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.