Re[2]: P64 Math

[Mike Losh <mlosh01@xxxxxxxxxxxxxxxxx>]

>When you hit 32 bits I think it's worthwhile to use some sort of carry
>propagate acceleration. Something like a carry skip adder doesn't cost too
>much silicon, and will be *much* faster than a ripple adder for wide words.

>I've been looking at 64 bit arithmetic recently, and (for the silicon we use)
>the tradeoffs do seem to change between 32 & 64 bit operations. For a fast 64
>bit processor, where addition may be a bottleneck, a good optimised adder would
>be essential - either a carry skip adder for medium speeds, a hybrid carry
>select adder (such as the one the Alpha uses) for fast speeds. If the word 
>width grew beyond 64 bits, or *very* fast addition was the aim then bizarre 
>adder architectures (Prefix adders, such as Brent-Kunge or Kogge-Stone (sp?)) 
>start looking like a good idea. They're pretty expensive on silicon, 
>unfortunately.

Thanks for the comment - I was hoping someone familiar with different 
implementations could tell us about them, and you did.  A little more info on 
the prefix adders would be interesting.

What about multiplication?  The +* instruction looked slick for a really minimal
CPU, but also looks very limiting for any future P32 or P64.  Imagine stringing 
32 sequences of  +* 2/ nop nop ... together on a P64 to multiply two 32 bit 
numbers.  Can a multiply operation be broken up into larger chunks?  I'm 
imagining using a little ROM-type table of 4 bit by 4 bit multiplications, then 
stringing these together with larger (4 bit) shifts and 32 or 64 bit adds.  This
would be a little closer to doing multiplication with digits, as most of us do 
when working with decimal digits on paper.  This approach is a little different 
than the array of full-adder units operating on individual bits that was 
described in the recent past.  Would there be a speed improvement by using table
lookups as part of the multiplication process?  Would it be simpler or more 
complicated to design?  More or fewer transistors?
--
Michael A. Losh                       Standard disclaimers apply.