Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!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: <7676@apple.Apple.Com>
Date: 14 Mar 88 20:03:56 GMT
References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP> <2574@im4u.UUCP> <2116@saturn.ucsc.edu> <1697@winchester.mips.COM> <15580@onfcanim.UUCP>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 22

In article <15580@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes:
>Any machine that stores a C "short" in 4 bytes is going to make
>my image data files twice as big, and allow only half the length of
>display lists in memory.  I wouldn't buy it.

It's the compiler making the decision, but I definitely do understand
that the machine plus compiler make a pretty tightly coupled unit.  If
only one compiler is available, any compiler decisions look like architecture
decisions.

>Any machine that stores a "short" in 2 bytes but requires multiple
>instructions (shift/mask) to access the data is going to have a
>difficult time executing the inner loops of some algorithms fast
>enough to benchmark comparably to another machine of similar cost
>which does support 16-bit data types.

Unless the the second machine is slower *because* it supports 16-bit
data types directly (or slower for other reasons).  It should not be
assumed that accessing small data types (16-bit or 8-bit types) with
a sequence of instructions is always slower.  Sometimes it will be,
sometimes it won't.  I won't argue that it's faster (unless the basic
cycle is faster).