Hello. I'm new to the list. I work on an text-based game server
called TinyMUX (http://www.tinymux.com), and for grins, I've been
playing with the hercules emulator.

In trying MUX 2.1 on Linux/390, I've run into a bug that I need
to isolate: compiler bug, emulation bug, MUX 2.1 bug, etc.

I've also put in a request for zSeries space with IBM in an
attempt to isolate the bug.

Full story:

I found the emulator for S/360, S/370, S/390 at
http://www.conmicro.cx/hercules/ and proceeded to burn gobs of time
getting MVF, MVT, MVS 3.8J, and finally Linux/390 running on it. On a
Pentium Pro 200, the emulator achieves about 1.5-2.5 MIPS (Pentium II
400 achieves about 10 MIPS). Once Linux/390 was up with access to the
Internet, I compiled MUX 2.1 on it -- something which took about 12
hours.

Once up, MUX 2.1 is fairly zippy. Linux/390 is weird in that it has
fpu_control.h, but it provides very few #defines for using it, and the
comments have warnings about changing it without breaking I/O code
somewhere else. Basically, that part of the system appears to be a
work-in-progress. However, everything I tried in MUX 2.1 worked
except...

think add(1.6,.1) --> 0.2
think add(1.7,.1) --> 0.2
think add(1.8,2.0,100.0,.1) --> 0.2
think add(1.8,2.0,100.0,.2) --> 0.4

What appears to be happening is MUX sorts the floating-point numbers in
a smallest-first fashion (on purpose to reduce the error from addition),
and then either the compiler or one of the emulation layers is
performing the operation +(a,b) --> a+a instead of a+b.

It's not a hugely critical request as I don't expect anyone to host MUX
2.1 on an hercules-emulated Linux/390. Still, bugs are bugs.

Stephen Dennis (AKA Brazil)

Reply via email to