Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!uw-june!rik
From: rik@june.cs.washington.edu (Rik Littlefield)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC --(really Cyber 170)
Message-ID: <6475@june.cs.washington.edu>
Date: 20 Nov 88 21:09:45 GMT
References: <595030314.2944@minster.york.ac.uk> <1762@scolex>
Organization: U of Washington, Computer Science, Seattle
Lines: 40

In article <1762@scolex>, seanf@sco.COM (Sean Fagan) writes:
> In article <595030314.2944@minster.york.ac.uk> martin@minster.york.ac.uk writes:
> >In article <1622@scolex> seanf@sco.COM (Sean Fagan) writes:
> >>where n=[1,5].  To store a value from X<n>, you load the address into A<n>,
> >	 ^^^^^
> >actually it was n=[3,4,5] A1 and A2 were also general purpose.
> 
> Nope, sorry.  'SA1 X1' would load the first argument into X1 (assuming you
> were using FORTRAN calling conventions).  Let's hope, however, that you only
> had one argument 8-).  It would, btw, also load the address of the first
> argument into A1, so that, when you were done, you do:
> 	BX6	X1
> 	SA6	A1
> and the argument was stored.  Nice.  (also explains why a 5 can become a 3
> and totally screw people up 8-).)

Not quite.  Sean is quite correct about A1-A5 being used for fetches.  But
the sequence SA1 X1 / BX6 X1 / SA6 A1 is a no-op as far as memory is
concerned -- it simply fetches a value from the address originally stored in
X1, then stores that value back *into the same address*.  Perhaps Sean meant
to imply that some other things happened to X1 in between the SA1 and the
BX6.  That would be inefficient, since the result could have been left in X6
directly, but I've seen it done.  BTW, that's the "FTN" calling sequence.
The earlier "RUN" Fortran compiler was completely different and used mostly
the B-registers.

> Lastly, why wouldn't you want to program these machines?  They are
> *wonderful*.  Anybody who has to learn assembly language should learn these
> machines (they're about as regular as a PDP, but are much faster, and
> prepare people for RISC)!

I agree completely -- no complicated addressing modes, a simple regular
instruction set, and (for their day) they ran like scalded dogs.  Having
just 18-bit addresses did get in the way, though.  Especially since only 17
of them were actually usable, and most machines weren't even that big!
(Also, as an aside, it's a bit amusing to see the number of posters who
revel in the simplicity of the instruction set ... and then get their
examples wrong ;-)

--Rik