> > 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. > 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. 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. Dave > Per > >
