Dave Walker writes:
> > 2) Internal coercion within the package, eg
> > result$ = HP_ADD(fp64$, fp80$) or even
> > result$ = HP_ADD(int64$, qdosfp)
>
> This would probably be the way to go. Less likely to get user error that
> way. As the strings would be "opaque" data from the programmers
perspective
> it would be easy to add a few "type" bytes at the start that would not
> actually be passed on to the routines that did all the work.
Precisely. Qdos fp and word integer types could also be included for
completeness' sake, in addition to the ability to read their types directly
from the name table, ie
result$ = HP_ADD(fp64$, qdosfp$) and
result$ = HP_ADD(fp64$, qdosfp)
would both do the same thing.
Determining which type the result should be could be either 1) the same as
that of the first (or only) parameter, 2) the "smallest" of the parameter
types that the result will fit into, though this could be problematic for
various reasons, or 3) as for (1) or (2) by default, but with an optional
additional parameter that would force the type, eg:
result$ = HP_SIN(number$; result_type%)
ie, if result_type% was different from number$'s type, then convert number$
to result_type% type, take the sine and return.
Type codes could be as simple as Qdos types, 2 = fp, 3 = int, and then
whatever you choose for the additional ones. In the event of some kind of
error set the top bit of the type code (you might want to dump the FPU's
status register in the remainder of the byte, or whatever), followed by a
long word Qdos error code. All the routines should recognise this situation
and throw a "hard" error if fed such a code as a parameter, to aid
debugging.
<>
> > Another nice touch might be to use the FPU if present, though perhaps
this
> > may not speed things up due to the various overheads.
>
> The routines already have this option. Experience said that the overhead
of
> testing for the presence of hardware FP was negligible if going down the
> software only path and the gain was significant if it was present. In
> particular for operations like multiply/divide.
If you dont mind the code being non-ROMable this could be done once and for
all at initialisation. Alternatively, do two separate toolkits and leave it
up to the user to load the correct one at boot time.
These are just some ideas. You will obviously have, or develop, your own.
Sorry for sicking all this over you, but it was once a pet project of mine
;)
If the DBAS author is still active it shouldnt be too difficult to retrofit
the IEEE types into the package, though just using strings should also be
fine.
Per
