Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!brl-adm!umd5!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.unix.wizards
Subject: Re: Size of SysV "block" (really: byte != 8 bits)
Message-ID: <1813@umd5.umd.edu>
Date: Fri, 24-Jul-87 09:23:19 EDT
Article-I.D.: umd5.1813
Posted: Fri Jul 24 09:23:19 1987
Date-Received: Sat, 25-Jul-87 13:46:37 EDT
References: <857@bsu-cs.UUCP> <326@hubcap.UUCP> <2425@ihlpl.ATT.COM>
Sender: news@umd5.umd.edu
Reply-To: louie@sayshell.umd.edu (Louis A. Mamakos)
Organization: University of Maryland, College Park
Lines: 69

In article <2425@ihlpl.ATT.COM> jhh@ihlpl.ATT.COM (Haller) writes:
>In article <326@hubcap.UUCP>, beede@hubcap.UUCP (Mike Beede) writes:
>> Seriously--different machines serve different purposes, and so are designed
>> differently.  That is why it is foolish to freeze some design parameter
>> arbitrarily.  I don't see that there is, for instance, a clear argument
>> against 36 bit words and 9 bit bytes as opposed to 32 bit words and 8 bit
>> bytes, especially if your application works well with 9 bit quantities.
>
>The clear argument against 36 bit words and 9 bit bytes is data
>communications.  Like it or not, data communications have virtually
>standardized the 8 bit byte.  Just try to generate TCP/IP headers
>on a 9 bit machine, packing all of the data contiguously.  Oh,
>you want to use a communications processor to do that?  How
>many bits is its byte?

Well, gee whiz;  I've done just that. Having 9 bits/byte doesn't make this
task anymore difficult that having byteswapped (little-endian) hardware.  The
1100 communications hardware (serial communications lines, byte/block
multiplexor channels, etc) just use the lower 8 bits of each byte to put on
the wire.  When the packet arrives, it do the equivilent of ntohl() and ntohs()
on the appropriate header fields so that I can do arithmetic, etc on them.  On
a VAX, these operations byteswap,  on the 1100 they simply squeeze the 9th bit
out of each byte.  Of course, in actual implmentation its not called ntohl()
and its written in PLUS, not C.


Also, having an 1100 makes calculating the 1's complement checksum easy, as
its a ones-complement machine.  

Having 9 bits bytes comes in handy.  You can leave "cookies" in a character
string that are unique from any possible ASCII character value.

>Given that a byte is an important measure, byte addressability
>becomes important in hardware architectures.  Given that
>our machines operate with binary logic, word sizes are going
>to be powers of two bytes long, just so that byte addresses
>can be easily converted into word addresses, which is typically
>related by a power of two to the memory and bus architecture.
>Look at the Harris/6 if you want to see what kind of
>contortions were necessary to provide byte addressability
>with a 24 bit word size.
>
>In summary, I agree that while there was no good technical reason
>to have an eight bit byte originally, anyone designing a new
>computer that does not have an eight bit byte will be doomed
>to market failure.  If Univac's 1100 series had taken off better than
>IBM's machines, I would probably be saying that six bit bytes
>are the wave of the future.  That is not the case.
>

Actually, it would be nice to have 9 bit bytes.  Granted, there are many times
that I wish I have byte addressability, but the PLUS compiler compiler can 
generate some (rather clever) code to do it for me.  Actually, with PLUS I
can have arrays of arbitrarly long entities, as someone in a previous message
wanted.

Another thing to consider is that on a machine like the 1100 with 36 bit words,
you have more precision available both in the (single/double) integer and 
floating point formats.  This apparantly matters to some folks around here.


>John Haller

BTW, if anyone is interesting in obtaining the TCP/IP package that was written
for the 1100 at the University of Maryland, drop me some mail.


Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming