Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!claris!apple!bcase
From: bcase@Apple.COM (Brian Case)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC.
Message-ID: <7520@apple.Apple.Com>
Date: 1 Mar 88 19:31:09 GMT
References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP> <2574@im4u.UUCP> <2116@saturn.ucsc.edu> <449@imagine.PAWL.RPI.EDU>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Ungermann-Bass Enterprises
Lines: 23

In article <449@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes:
>In article <2116@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
>>I'm glad somebody brought this up, and while we're also at it let's debate
>>the value of including 16 bit data types in RISC machines.
>	One reason should be enough: compatibility.  If you want another:
>Ram space.  Ram, especially for RISC computers, is less than cheap.  Priced
>any 20-ns SRAMs lately?  Also note that DRAM prices are goin UP lately, in
>contradiction to all established precedent.
>
>	And no, being able to load and store halfwords doesn't really
>slow a machine down.  All internal operations can be done in natural word
>size.

Not all RISC machines require 20ns SRAMs in order to have good performance.
One thing is for sure though, code size is almost always much less important
that data size.
DRAM prices are going up instead of down because of increased demand (and
it is starting to get a little tight everywhere, so I hear).  Have you
tried to get megabit DRAMs lately?  Yikes!
"Being able to load and store halfwords doesn't really slow a machine down"
is a statement that does not take in to consideration certain reasonable
implementations.  The necessary alignment network can indeed slow a
machine's cycle.  Doing internal operations in natural word size does not
solve the whole (main?) problem.