Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Not-so RISCy
Summary: It would definitely slow down many things
Keywords: risc
Message-ID: <1126@l.cc.purdue.edu>
Date: 10 Feb 89 12:44:38 GMT
References: <732@wpi.WPI.EDU>
Organization: Purdue University Statistics Department
Lines: 25

In article <732@wpi.WPI.EDU>, jhallen@wpi.wpi.edu (Joseph H Allen) writes:

			............................

>                               Would it be a terrible hardship to only have two
> data sizes (perhaps character and word) and not allow words to cross word
> boundaries?  Certainly it would require that people don't use "bad"
> programming techniques similer to what has to be done on 68000 or IBM 360. 
> But would not the improvement in speed (by freeing up chip space to allow for
> more registers or to simply reduce data path delay time) be worth it?

It would be a real nuisance.  For numerical problems, it would be a good idea
to have _at least_ 32, 64, and 128, for both fixed point and floating point.
There are very good reasons for editing, etc., to have 8 and 16 also.  I can
also think of good uses for individual bits.  As for crossing word boundaries,
this can be very convenient, but not as important.  BTW, what is a word?  Is
it 16, 32, or 64 bits?  And if a word is 32 bits, does a 64-bit quantity have
to start on an address divisible by 64?

We can get more registers by using more chips.  Data path delay is not likely
to be reduced by having fewer types.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)