Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.arch
Subject: Re: Why make word size a power of two? (was: > 32 bits needed where?)
Message-ID: <3049@bloom-beacon.MIT.EDU>
Date: 19 Feb 88 15:13:36 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4611@ames.arpa> <1354@vaxb.calgary.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 28

In article <1354@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes:
>In article <4611@ames.arpa>, lamaster@ames.arpa (Hugh LaMaster) writes:
>
>> Word size (or the size of any addressable data) should ALWAYS be a 
>> power of two.
>
>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.

I spent some time at BBN writing code for for the C70, which has a 20
bit word made up of two 10-bit bytes. The major problem in porting C
code to it was the 10-bit byte, rather than the 20-bit word. I think
that any large C program must have 'for (i = 0; i < 8; i++) bash bit;'
in it just to screw up those poor machines. Unfortunately, the name of
the include file that defines constants for such sizes seems to be
different on every system, thus leading to a different portability
problem... 

If you restrict your word size to a multiple of 8 bits, such problems
should go away. (Most 'portable' code seems to realize that word size
can differ, as well as ended-ness, and handles this in a correct
fashion.) 

				Peter Desnoyers