[Linux-aus] RISC-V

[Les Kitchen]

On Thu, Mar 30, 2023, at 05:21, jon.maddog.hall--- via linux-aus wrote:
...
> The architecture also allows for different extensions to the CPU.   
> Here is where floating point accelerators can be implemented as well as 
> GPUs, and other extensions that today we tend to think of as part of 
> the system.   I will note that I programed the DEC PDP-8 "back in the 
> day" and it had only eight basic instructions where the system could 
> not even subtract (much less multiply and divide, much less do floating 
> point)....all it could do was add.   By finding the compliment of the 
> number you wish to subtract, adding it to the minuend and discarding 
> the high order bit you could get the result.

Your observation about the PDP-8's small instruction set
reminded me that one of the early computers (sorry, I can't
remember which one off the top of my head) had only a subtract
instruction for arithmetic.  You could negate by subtracting
from zero, and add by working with negatives, then negating at
the end:

   x + y = 0 - (0 - x - y)

So, subtract is all you need.

I did a fair bit of PDP-8 programming back in the mid-1970s — it
was about half of my Honours project in computer vision.

Yes, you did subtraction on the PDP-8 by forming the
twos-complement negation and then adding.  But I don't think you
needed to explicitly discard any bits.  You got the right answer
by the magic of twos-complement arithmetic (though some stuff
might have ended up in the carry and overflow bits).

The PDP-8 did have an assembler (and an interpreted BASIC-like
language called FOCAL).  But using the assembler was such
trouble (all done on paper tape) that I found it more efficient
to code directly in machine code.  Having only eight opcodes to
remember (and only 4k words of memory to fill) made that
feasible.

> Later on I used a PDP-11/70 time-sharing machine that had no floating 
> point hardware.   Every time you encountered a floating point op-code 
> it caused a hardware exception and did the floating point arithmetic 
> with software, then returned from the exception.  If you had a floating 
> point accelerator the same exception happened, but the hardware 
> accelerator did the work a lot faster, so the return was much faster.

I did most of my Ph.D. work (also in computer vision) on a
PDP-11/45.  Yes, it worked like that: if you didn't have a
floating-point unit you got an illegal-instruction trap on
floating-point instructions, and the handler looked at the
instruction that caused the trap and emulated it in software.
But my recollection is different about the case when you *did*
have a floating-point unit: then the floating-point operations
I think were just executed as instructions — no traps or
exceptions.

It was roughly similar with the early 80386 CPUs, depending on
whether or not you had an 80387 floating-point coprocessor.

> All of this is off the top of my head, and I am tired, so please take 
> this as a generality to demonstrate how a hardware extension does not 
> have to be part of the basic ISA.

Yeah, it's the take-away generalities that matter — about
hardware extension, and about being inventive with getting the
job done within the limits of currently available hardware.

I also remember that one of the early computers didn't even have
a program-counter register — all for the sake of minimizing
hardware.  I think it was one of the PDPs, but I can't track it
down.  It used (core) memory location zero as the program
counter, which the execution cycle could address simply by
clearing the memory-address register.  I leave to you to think
through how this worked.

...
> A nice project.  My project to create the little computer down in 
> Brazil (caninosloucos.org) is closely following and working on RiSC-V 
> chips.

Should that be "over in Brazil"?  Same hemisphere.

Yeah, a nice project.  Good work!  Those Labrador boards look
really interesting.  It looks like you have to go through the
contact form to enquire about buying one.  I couldn't find any
listing of the prices.


— Smiles, Les.