From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: What was the intended advantage of using 36bits CPU?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 16 Oct 1992 19:09:45 GMT

In article <26957@castle.ed.ac.uk> ercm20@festival.ed.ac.uk (Sam Wilson) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> In article <26915@castle.ed.ac.uk> Sam.Wilson@ed.ac.uk writes:
>> >lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> >> But what happens when it turns out you need 17 bits?  Again, the -10 is
>> >> up to that, since it can pack two chars of 18 or less bits per word in
>> >> byte addressing mode wasting 2 bits if 17 bits/char.  All of these machines
>> >> that are 32 bits are going to have to round up to 32 bit/char, or are you
>> >> still insisting on finding a need for 2^32 unique combinations?
>> >
>> >A 8-bit-byte oriented machine could just use 24 bits.  It could also fit
>> >19-bit characters into 24 bits, wasting 5 bits.  It or a 32-bit-word
>> >oriented machine could fit 19-bit characters into 32 bits and waste 13
>> >bits.  A -10 would have to waste 17, surely.  :-)
>> >
>> >Why is it that any discussion with cjl starts off sensible enough and
>> >ends up extremely silly?
>> 
>> For a very simple reason: you aren't looking at my perspective of the
>> discussion, and your position is silly, not mine :-).  My point about the
>> evils of bytes of fixed size is the driving force behind the thread, is
>> that silly?  You don't have to agree with me, but it's pretty ridiculous
>> to not understand what's being discussed.
>
>If that is your point: silly yourself! You picked an arbitrary size of
>object for which the -10's architecture happens to be more efficient in
>storage.  Bully for you.  I simply picked a counter example where an
>8-bit or even a 32-bit architecture could be better. 

Or it might be worse.  My objection is that the examples are implying that
the arbitrary 8-bit multiples have some innately useful property for this
class of problem.  I know of few where they really help significantly if
at all, but certainly not in the case of N-bit character codes.  It further
looks like character set designers are "contaminated" with the notion of
accomodating designs stuck with 8-bittedness influencing them instead of
what best serves the character design considerations.  This only serves the
status quo, and is contrary to why standards committees are even formed.

I never suggested that the PDP-10 is a panacea, but it goes a long way towards
solving most of these problems, without compromising the general instruction
set with 8-bit byte addresses, offsets, etc.  The concept could be extended
in any design to any arbitrary maximum width if needed.  Lot's better than
slavishness to multiples of 8 arbitrarily.

>
>For storing objects of arbitrary size then finer granularity with
>objects spanning storage unit boundaries is generally better because you
>waste less at the boundaries.  I'm not saying variable width data
>objects are not a good idea - for instance if you wanted to store 37 bit
>objects on a -10 then you could presumably pack the extra bits from 36
>of them into 36 one-bit bytes in the 37th word rather than waste 35 bits
>out of 72 - but that wasn't your point.
>

Correct, and presumably a new design would be for some max size like 64
or 128 or 256 bits.  I can even see a point to *this* parameter being
a multiple of a power of 2, but on the -10 it made more sense to stop at
36 for obvious reasons.  However, 2^36 distinct codes is an awful lot of
characters!

>Now if you had said that your point was the comparison between character
>sets that operate with a small set of codes and a variety of shift
>sequences to select different translations, and those that represent a
>large variety of different characters directly I'd have agreed at once!
>But then we've been through that one recently too...  :-)

That's an argument for more compact code sets.  Some others will argue it's
easier to be able to do a lookup on an open form of the set, which is a
classic speed or space tradeoff, and is another topic, etc.

>
>> [[[ discussion about 8-bit bytes, IBM, EBCDIC, 7- and 8-bit ASCII,
>>     variable width bytes and PDP-10s mostly deleted ]]]
>
>8-, 16- and 32-bit quantities have the advantage that they are nice
>round binary numbers and opcode selectors into them can be fitted nicely
>into fixed width opcode fields (I presume - I'm not a h/w designer) - it
>lookslike it would be lishglty mnore economical to design -10-type
>variable bytes on a 32-bit word machine than a 36-bit one. 

A little garbled, but in any case, I don't agree.  Nice is irrelevant, round
is irrelevant, all numbers are binary for this disussion, and opcodes is a
meaningless topic since it's merely an arbitrary notion for overall
hardware design.  The whole notion of variable versus fixed-length instruction
size is a whole 'nother topic.  The -10 concept is generic about variable-size
bytes.  The only restriction is that you can't efficiently do it for a size
larger than the internal bus width because then there are special cases of
splits between data fetched from memory in different (adjacent) areas.  So,
if a machine inherently gets data 64 bits at a time, bytes up to 64 bits wide
are practical.

>
>> Any other silly remarks?  (On the topic?)
>
>I'm just waiting for them (except I'm off on holiday for a week so I
>won't see them!)  :-)
>
>Sam

Perhaps your gain and our loss :-).

cjl

Newsgroups: alt.folklore.computers