Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!inuxc!ihnp4!alberta!calgary!radford From: radford@calgary.UUCP (Radford Neal) Newsgroups: comp.arch Subject: Re: Why make word size a power of two? (was: > 32 bits needed where?) Message-ID: <1368@vaxb.calgary.UUCP> Date: 20 Feb 88 22:25:11 GMT References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4915@ames.arpa> Organization: U. of Calgary, Calgary, Ab. Lines: 39 In article <4915@ames.arpa>, lamaster@ames.arpa (Hugh LaMaster) writes: > 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. Most of your problems seem to come from word sizes that are not a multiple of eight bits. Whether they are a power of two seems less of an issue. Any difference in word sizes at all will bring problems of incompatible versions, reporting errors when an integer is too big for the destination format, etc. > 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. I agree. Despite the purported advantages of 9-bit bytes, having to cope with standard tape drives (to pick an example) seems like a lot of hassle. > 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. Certainly true. Various "remote procedure call" and other network protocols have a standard interchange format that (ought to) be much faster than ASCII while still keeping applications independent of data conversion considerations. Radford Neal