C library uses UFA

[larsbrinkhoff]

The C library uses the obsolete UFA instruction. This is a problem when running on a KS10 processor.

[larsbrinkhoff]

It's just used three times, in DROUND, DTRUNCATE, and FIXIFY. In all cases it's used like this: UFA A,[233000000000]. The octal number is 0.0.

[larsbrinkhoff]

It's used to convert a floating point number to an integer. If A is a float between 1 and 2²⁷, UFA A,[0.0] will add 0 and leave the unnormalized result in B. Next the exponent is masked off leaving just the integer.

[larsbrinkhoff]

I see some options:

• Use UFA on KA10, and something else - maybe FIX - on KS10. (KL10 microcode has both.)
• Use UFA, add it to KS10 microcode.
• Use UFA, emulate it in the UUO handler.
• Don't use UFA, replace it with something that works on both KA10 and KS10.

[larsbrinkhoff]

One more option:

• Select the code to use at run time.

[rcornwell]

It was not uncommon in the 10 world to have different binaries for different machines. There is some code in Tops-10 (later versions), called kaser.mac which adds in support for the KA10 floating point instructions. This could be added into ITS to handle these as UUO's

[larsbrinkhoff]

Yes, I was thinking that would be a quick and convenient fix. Since the files with UFA are assembly language, I could add a assembly-time switch and use /T to enable it.

But actually it wouldn't be hard to patch out the instruction at run time from the UUH handler. Just overwrite the UFA A,[0.0] with FIX B,A and nop out the following TRZ 777000,B.

[larsbrinkhoff]

Fixed in #1356.

It turns out runtime patching was not as easy as I hoped. The instruction is in a pure page, and there doesn't seem to be a convenient way to make it writable. CORBLK says nope. Apparently you need to make a new writable page, copy the contents of the old page there, and replace the old pure page with the new.

Instead, I added an assembly time switch to select KS10 which uses FIX instead of UFA.