Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instructions for RISC.
Message-ID: <1398@vaxb.calgary.UUCP>
Date: 27 Feb 88 23:52:58 GMT
References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP> <2116@saturn.ucsc.edu>
Organization: U. of Calgary, Calgary, Ab.
Lines: 26

In article <2116@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU (99700000) writes:

> ... while we're also at it let's debate
> the value of including 16 bit data types in RISC machines.  A variety
> of data sizes slows a machine down almost as much as a variety of
> instruction sizes.  I was rather surprised to see that Sun included
> 16-bit data in SPARC in this day and age of cheap memory.  8-bit data
> has the obvious utility for character strings; but do we really need
> 16-bit integers anymore?

I don't understand this. Given that you support 8-bit bytes, and thus
need the extra two bit in addresses, plus the complications of more than
one data size on the bus, why does supporting 16-bit data cost a lot?
As far as instructions go, it looks like somewhere between two and
four extra instructions for a load/store architecture.

I agree that 16-bit data will be used less and less. It's not that
that there isn't a lot of data that would fit in 16 bits, and it's
not that this wouldn't sometimes be a significant savings, it's because
of the popularity of C. If Pascal (which of course had other faults)
had become dominant, lots of people would be declaring variables
like "var i:1..Max_widgets" and if Max_widgets were 1000 this would
be held as 16 bits. As it is, declaring a C variable to be "short" is
an invitation to future problems.

   Radford Neal