From: stripes@eng.umd.edu (Josh Osborne)
Newsgroups: alt.games.lynx
Subject: Re: Whaddabout the so-called Jaguar? (was Re
Date: 16 Dec 92 05:28:30 GMT
Organization: Project GLUE, Merriversity of Uniland, College Purgatory

In article <De7RVB2w165w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes:
>wastrel@jotunheim.EBay.Sun.COM (William Osser) writes:
>> Have you ever programmed in RISC?  It really is (IMHO :) easier than CISC.  
>
>Depends how R your IS in your C is.
>
>For instance, some RISC chips have heavy pipelining, so that when they hit a
>jump they've already decoded the next couple of instructions.  Rather than
>waste all that effort, they execute 'em anyway before jumping.

Which isn't that confusing after the 2nd day of writing RISC code.  (and
I havn't seen a RISC that will execute more then 1 insn after a taken
branch).  Also the number of instructions after the branch that are executed
is predictable (not haphazard, as some readers might assume from your wording).

And, yes, that's so the branch/jump/call only takes one cycle, taken or not.
Of corse if you can't find something usefull to put after the branch it
will take 2 cycles (like it does on fast CISCs).

Some of the newest RISCs have decided _not_ to do this but rely on branch
prediction instead (either static, or dyanmic).

>Some RISC chips don't have stacks; you have to use registers to pass all your
>arguments.  Because this could lead you to run out of registers quite
>rapidly, some RISCs have 128 or more of the little buggers.  Sometimes
>they're arranged in banks, so that a single instruction is equivalent to
>swapping out all the registers and another instruction swaps them back in
>again.

Yes, and no.  The SPARC (banks of registers), and the AMD29k's (192 user
visiable GP 32 bit registers), and others are like this, mostly.  All RISCs
can do stacks.  And they normall all do.  When you change register windows
on the SPARC and overflow/underflow there is a trap, and the trap handler
will take care of spilling/filling the window for you, same deal with the
29k as long as you use the "standard" 2 insn sequence formaking a stack frame.
Even if you don't have a real OS (like in a game machine) your ROM monitor 
will have a spill/fill trap handaler (or you can put it in your code - the 
source is in the CPU manual).

It is as easy as LINK/UNLINK on a 68000.  And tons faster.

>Some RISC chips have unlikely addressing modes.  Since you've got
>instructions of fixed width, something simple like "move 1 into register D1"
>leaves lots of bits unneeded.  So they implement operations like "take
>registers A1 and A2, add together, add the specified offset, indirect through
>that location, get the value stored there, exclusive-or with the value in the
>memory location pointed to by A3, and increment A3".

No they don't.  This is the one thing that RISC CPU's do not do.  This is
the domain of the CISC processers only.  Just about every RISC in existance
will only do loads of the basic form
LOAD R1, R2  ; Load R1 with value at Mem[R2]

Some RISCs add LOADM (load multiple, you normall need to set the reg count/mask
in a seporate insn), LOADL (load locked), a few have instructions to help
speed up unaligned access.  None have anything even remotly resembling the
complex addressing modes the 68020 has.

This does tend to make the code less dense, but so far the speed improvement
has been worth it.

>Even CISC chips have odd little tricks.  For instance, on the 68000 the
>quickest way to multiply a register by 4 is to add the value to itself twice,
>because there's no hardware barrel shifter.  RISC chips have similar "tricks"
>because of the stuff that's left out in order to ensure that all instructions
>take 1 cycle.

(a) not all instructions take one cycle, for example FMUL on the i860
takes 3 cycles to multiply 2 FP numbers.  However it takes only one
cycle (or half a cycle in superscaler mode) to start, as long as you
don't use any of the registers specifyed to FMUL during the next 2 cycles
you would never know that it wasn't a 1 cycle insn.
(b) For most RISCs (and all low cost RISCs) all you need to do is move
the computation of a value as far ahead of the use of the value; and on many
RISC boxes, the assembler will be glad to do that for you.
(c) CISCs are starting to have this problem, see the 486 guide, Appendix G
(d) the real pain in the ass is dealing with superscaler boxes that can execute
more then one instruction per cycle as long as you have no more then N adds,
M multiplys, O bitops, P load/stores, Q branches, and so on.  I havn't delt
much with these yet, so it may not be as bad as I think it will be.

>These sorts of features mean that it can be very hard to write good RISC
>assembler by hand.  In fact, today's compilers can produce faster, more
>compact RISC code than all but the finest assembler programmers.

Bull.  I am a good assembler programmer, but not one of the finest.  I can
beat AMD's C compiler, Gcc on the AMD29k, Sun's stock cc on the SPARC, IBM
and metaware on the ROMP, the older (never used the newer) Intel i860 compiler
(which beat out IBM's ROMP compiler in the "who can slow down their own box
the most" awords...).  I don't know enough MIPS to see if I can win on a Rx000,
and I can't yet read ARM code, let alone write it.  I also havn't read a
Alpha reference, or an HPPA one (yet).  Anyone with some time, and some (not
alot) can beat a C compiler, even on a RISC.  I'll admit it is harder, but I
think it has more to do with the quality of the compilers then the chip.

>None of this has anything whatsoever to do with the Lynx, so could the thread
>be taken elsewhere please?

As soon as a few mis-conceptions are cleared up.
-- 
           stripes@eng.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
            "NFS only behaves properly..."                  - jik@athena
                "...when the computer is not drawing power." - rbj@uunet
Newsgroups: alt.games.lynx