Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.arch,net.unix-wizards
Subject: Re: Re: pyramid architectural restraints
Message-ID: <2478@watcgl.UUCP>
Date: Thu, 26-Apr-84 10:25:20 EST
Article-I.D.: watcgl.2478
Posted: Thu Apr 26 10:25:20 1984
Date-Received: Fri, 27-Apr-84 03:05:20 EST
References: <1028@ritcv.UUCP>
Organization: U of Waterloo, Ontario
Lines: 19

	PS:  Allowing non-aligned data to be accessed with a
	performance penalty is only a little less short-sighted.  When
	designing a computer, anything that makes the job of writing
	software easier will be justified in the marketplace,
	especially the oem marketplace.  Given the current comparison
	of hardware costs to software (i.e. people) costs, a more
	expensive cpu that is easier to program will be vastly cheaper
	in the long run.

There are always going to be tradeoffs.  Allowing the largest data type
accessed by the machine to be accessed on any boundary with no performance
penalty requires that the data path from memory be twice as wide as the
largest operand fetch that will be done from it, and the presence of
a data aligner which is fast (probably combinational logic) and also
that wide.  On the VAX, for example, where the longest data type is 8
bytes (ignoring H-floating for the moment), you'd need a 128-bit wide data
path from memory.  That's four times its current width; frankly, I'd rather
see the extra money spent on features that would speed the machine up
all the time, not just when doing unaligned data references.