PL/M-51 math51.lib rounding

Rich Green" wrote

PL/M-51 didn't support floating point. There were several after-market add-on floating point libraries.

Do you know who produced your math51.lib? If you dump the .lib file as hex/ASCII does a copyright/company drop out?

Try a post at

I don't know who produced math51.lib. I did dump it the other day - sadly no company name or (c) message in there, though all the procedure names are readable...

CALL_BINBCD, CALL_FIX, CALL_FLOAT, CALL_FPABS, CALL_FPADD, CALL_FPASC, CALL_FPCMP, CALL_FPDIV, CALL_FPEXP, CALL_FPLN... etc...

All operations are performed on a floating point accumulator. The functions are called like this... call fp_link(call_ldfac, .fp_ROM_4812_8); which loads the floating point accumulator with an IEEE float stored at address .FP_ROM_4812_8 Does this ring any bells?

Cheers,

wrote

Sounds like (and I'll bet it is) FPAC51 from US Software.

US Software was sold to Lantronix who sold the technology on to 'Micro Digital'.

The FPAC product line has been replaced by what appears to be a semi-interpreted somewhat device-independent system call Go-Fast.

Thanks Nicholas, I emailed them.

Sorted my problem the other day. So for anyone else who ever wants to know - facnrm appears to control how the math51.lib functions read a float from memory. When you have a IEEE754 constant in ROM like this...

declare fp_ROM_273_15 (4) byte constant (033h, 093h, 088h,

...then you need to set facnrm true before referencing it, like this...

facnrm = TRUE; call fp_link(call_fpsub, .fp_ROM_273_15); /* convert to celcius

But don't set facnrm before referencing an auxiliary.

wrote

Oh, yes. It all comes back now, and if FACNRM is false then it grabs the data from ram but at the rom address ... hence your divide by zero, I imagine.

The interface I used was similar to an H/P calculator. The constant part was in the name of the function call, a trailing 'C' indicating a constant.

CALL FP_PUSH (.DEG_K); CALL FP_SUBC (.K_273_15);

It didn't prevent

CALL FP_SUB (.K_273_15);

as PLM/51 didn't enforce strong typing on assignment to a pointer, only dereferencing was typed.