🚀 go-pugleaf

From article <43278@ames.arc.nasa.gov>, by lamaster@ames.arc.nasa.gov (Hugh LaMaster):
> 
> As an example, consider the following complaint:  "Current machines don't
> do well on arbitrary precision arithmetic".  Question:  Are there simple,
> cheap, architectural extensions which could do a much better job of 
> implementing variable precision arithmetic, and, which would also be useful
> in the context of current problem domains?  To be more specific, are there
> forms of integer multiply step, for example, which would make it much easier
> to implement fast 128 bit, or 192 bit, arithmetic?  
> 
> What small set of reasonable instructions would provide significant performance
> improvements?
> 
From my relation to the people of the Kulisch-group at Univ. of Karlsruhe
( you {should} know, those with the optimal arithmetic, rounding control
and verified results ) I know that this is quite simple:

You need all those things, that hardware does on floatingpoint numbers,
to be able to be done on strings of words. The main point is:

DON'T LOOSE ANY BITS !!!!

this means:
You must have 32 * 32 = 64 bit multiply, reverse vor divide wouldn't be bad.
You must have carry or something comparable for long additions
You need support for multi-word shifts ( remember someone the RLD, RRD
   instructions in the Z80 )

Now the problem with those c-ish RISC is: in C these things are not needed,
C-program statistics do not show them ( in fact, no high level language

Another bunch of difficulties comes from these long numbers being so long.
This means: the tend to grow during calculations, and they tend not to
fit into the registers, even if there are 32 of them. So the program
has to deal with two kinds of looongs, the short ones which fit, and the
loooooooooooooooong ones which do not. For these CISCs with shifts and adds
in memory are very nice.
support such things !! ) and so nearly nobody has all what is needed.

  
> on problems of this type, and, what instructions do they have that make
> a difference (Can HP-PA do better on such problems?) 
> 
This is hard to say since it can only be said after writing such things
on the machine ( in assembler, of course, since these are the inner-inner-
inner loops, and even C does not support multiword-operations )
and testing it. Of course one can write a long arithmetic in C, the
Kulisch-people have one, but it is not the fastest at all -:)

Simply looking at the instruction set can only give hints if it will be
more or less difficult, and often tiny little details can give big trouble.

So everybody may check his prefered architecture for the criteria listed
above.

I did not yet look at the HP-PA, but this posting might be a reason to do it-:)

R. Kirchner
Univ. of Kaiserslautern Germany
kirchner@uklirb.uni-kl.informatik.de    ( see also head of posting )
kinf89@dkluni01.bitnet                   ( prefered )