Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdahl!ames!lamaster From: lamaster@ames.arpa (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: Why make word size a power of two? (was: > 32 bits needed where?) Message-ID: <4915@ames.arpa> Date: 19 Feb 88 02:27:05 GMT References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4611@ames.arpa> <1354@vaxb.calgary.UUCP> Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 56 In article <1354@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes: > >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. Example: Write code on CDC 7600 to create a graphics output file which, when moved to a PDP-11, is an integral number of 512 byte blocks. Simple. You just use 1024 60 bit words on the 7600. You get 1024x60 bits= 61440 bits. 61440/8=7680 bytes = 15 512 byte blocks. Now, write your code on the 7600 so that you pack the 16 bit PDP words into the 60 bit CDC words. It is trivial to do. Also, very time consuming, and you have to do it for each such application. Which means programming costs. Convert the code to a 64 bit machine and rewrite the bit crunching stuff again. Now, try to maintain separate versions of the code for each machine. Then ask yourself how much easier life would be if you didn't have wierd word sizes. >little-endian incompatibility, I would think that a general data typing Well, I am a confirmed "standard-endian" (there should be a standard mapping of words onto bytes in a specific order) myself, because, it does make things easier. But, having congruent word sizes is the first step. >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. Actually, no. The code to handle arbitrary bit alignments is much more complex than if the wordsizes involved are multiples of a power of two. And much slower than code which knows what the wordsizes are, because you have to do arithmetic in addition to boolean operations. > >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. Well, actually, you are right that if all machine data types were a power of two factor of some base, that is good enough. The base could be 9 bit bytes. It just so happens that with so many 8 bit byte addressable machines out there, that is the defacto standard. The ability to do boolean operations only (no arithmetic) is almost always a big performance win. The original argument was that IF you need to move BINARY data between machines, THEN, all the machines involved should have wordsizes that are a power of two. Now, do you ever NEED to move BINARY data between machines? Well, Yes. Because, using character coded data for graphics and floating point applications is orders of magnitude slower. For that reason, I am looking forward to the day when all machines use IEEE 32 and 64 bit floating point formats (whether they implement full IEEE arithmetic or not) in a standard byte order (consistent Big-Endian, of course :-) ).