[Oberon] Fighting a dragon ...

[Michael Schierl]

Hello,

Am 16.07.2024 um 02:28 schrieb Hans Klaver:
> On 15 jul. 2024, at 23:29 Michael Schierl wrote:
>> Am 15.07.2024 um 22:40 schrieb Hans Klaver:

>> Regardless, running the same disk image in my emulator that uses
>> "Native" floating point (on x86_64 on Windows), all expressions work, so
>> I would blame neither the compiler nor Texts.Mod.
>
> This I cannot explain. Possibly the floating point output routine does not use Texts.Mod.

Rather, Texts.Mod is not completely broken.

I traced both emulators side by side (only the floating point ops), and
the only places where both return different results is for fp_add, when
the v flag is set (i.e. when running a FLOOR instruction).

New test case:

Out.Int(FLOOR(2.0E7), 11);

Returns 10000000 with Peter's emulator, and 20000000 with mine. I am not
sure what range the FLOOR function is supposed to work in. While
20000000 is well within the range of integer numbers, it is larger than
16777217, which is the smallest integer number that cannot be
represented exactly as a 32-bit float. Its floating point
representation's binary exponent is 151, and the algorithm only works up
to binary exponent 150.

I hacked up a small workaround that is easy in emulation but probably
hard in verilog (as it uses a loop). Obviously, if your floating point
number is larger than what fits into an integer, garbage is still returned.


Pushed to my fork:

<https://github.com/schierlm/oberon-risc-emu-enhanced/commit/02ca0a1d51f43bb08f64336d011f5970111ecac0>


Another option is to ask for fewer digits, so that the expected printed
number without the decimal point is smaller than 16777216, i.e. for 7
digit precision the number must be smaller than 1.6777216.

Or use a different implementation of Texts.Mod, as you did.



Regards,


Michael