Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!hao!oddjob!gargoyle!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch
Subject: Why make word size a power of two? (was: > 32 bits needed where?)
Message-ID: <1354@vaxb.calgary.UUCP>
Date: 15 Feb 88 21:31:37 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4611@ames.arpa>
Organization: U. of Calgary, Calgary, Ab.
Lines: 31

In article <4611@ames.arpa>, lamaster@ames.arpa (Hugh LaMaster) writes:

> Actually, it is extremely important in a networked world for word sizes
> to be a power of two bits long.  As someone who has spent a considerable
> amount of time maintaining code to move data between machines of 
> various sizes (in my case, DEC and IBM 8 bit byte/32 bit word machines
> and CDC 60 bit word machines), and helping users convert data written
> on one such machine to another, etc. etc., I can say with complete
> conviction:
> 
> Word size (or the size of any addressable data) should ALWAYS be a 
> power of two.
> 
> In addition to making life much easier for those who have to move
> binary data between machines (and with NFS, there are a lot more
> such people out there), it also makes it much easier to move CODE
> between machines.  Yes, I have converted bit-level code from IBM's
> to Cyber 170's and back to 8 bit machines again.

Please explain what problems you found in converting data from systems
with wordsizes that aren't a power of two. Given the big-endian vs.
little-endian incompatibility, I would think that a general data typing
scheme would be needed in any case, so odd word sizes would be no
additional hassle. As for bit-bashing code, a #define for wordsize would
seem to solve the problem.

Off hand, the only advantage to a power of two word size that I see is
that you can do the calculations needed to simulate bit addressing 
using shifts and ands rather than quotient and remainder.

    Radford Neal