Dave Walker writes:
> If there really is a need for these extra precision routines to be
available
> from SB, then maybe it would be worth writing SB wrappers for the maths
> support routines used by c68? These include support for IEEE 32,64 and
80
> bit, and also for 64 bit integers with add/subtract/multiply/divide
> supported as arithmetic operators. They are highly optimised assembler,
so
> should not be that difficult to wrap? In fact if there is a real need, I
> could do it (on the basis that I already support these routines).
Need? I did have a need for such once, when I wrote my accounts program. I
started writing an fp package then, but got another job before inflation and
the operation outgrew the limits of long word integers (£21,474,836.47 ;) so
it was never completed. It could be very useful. And where there already is
a solution, the need may soon follow ;)
> The hardest part will be to get agreement on the SB interface needed to
> support what is wanted.
Introducing a new type into SB, though it undoubtedly would be the most
pleasing solution, would be a major operation that could take years to get
right. The simplest method, imho, would be to do it as an add-on toolkit,
which would also benefit the non-smsq scene.
Heres my penny's worth on how to implement it. Store the numbers in their
internal formats or as coded strings (ie not straight ascii, see below) and
have suitable conversion routines to input and display the numbers. From
this starting point there are different ways of proceeding:
1) Separate routines for each of the new types, eg
result$ = ADD64(n1$, n2$),
result$ = ADD80(n1$, n2$),
result$ = ADDI64(n1$, n2$), etc, or
2) Internal coercion within the package, eg
result$ = HP_ADD(fp64$, fp80$) or even
result$ = HP_ADD(int64$, qdosfp)
The latter method (my preference) would make use of coded strings, ie the
type of the number would be included in the string together with the number
in its internal format. I seem to recall that there are some spare bits in
the IEEE formats which could be used, otherwise simply tag a byte to the
front of the number. The tag could also be usefully employed to indicate
whether the operation or conversion was successful, which would be
translated into standard Qdos errors using something like
ERT HP_ERR(result$)
Another nice touch might be to use the FPU if present, though perhaps this
may not speed things up due to the various overheads.
Per
