kirchner@uklirb.informatik.uni-kl.de (Reinhard Kirchner) (02/26/90)
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 )
kirchner@uklirb.informatik.uni-kl.de (Reinhard Kirchner) (02/27/90)
Sorry, vi made me put a line at the wrong place. > > 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 insert line here: > > 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. This line to be inserted above: support such things !! ) and so nearly nobody has all what is needed. R. Kirchner Univ. of Kaiserslautern Germany kirchner@uklirb.uni-kl.informatik.de ( see also head of posting ) kinf89@dkluni01.bitnet ( prefered )