Topspeed Modules in XDS Compiler - bugs?

[jd63]

This concerns the Linux version only (native compiler). Version 2.60 from github. The code uses the RANDOMIZE and RANDOM functions from the Lib module, and WrLn from IO. Compiled with "xc -topspeed+ =m randtest.mod".

MODULE randtest;
IMPORT IO,Lib;
VAR roll,i: CARDINAL;
BEGIN
Lib.RANDOMIZE;
FOR i:=1 TO 6 DO
roll:=Lib.RANDOM(6)+1;
IO.WrCard(roll,1);
IO.WrLn;
END;
END randtest.

Firstly, RANDOMIZE doesn't work because on each run the numbers are the same, and secondly, carriage return isn't working in WrLn because on successive new lines the numbers are cumulatively offset by 1 space.

The Win32 version of the compiler (using Wine) produces the expected correct output (no offsets and different numbers each time).

I haven't raised this issue yet on github because I first wanted to see if there are any other XDS users getting the same behaviour.

Thanks!

[Martin Brown]

Post by jd63
This concerns the Linux version only (native compiler). Version 2.60 from github. The code uses the RANDOMIZE and RANDOM functions from the Lib module, and WrLn from IO. Compiled with "xc -topspeed+ =m randtest.mod".
MODULE randtest;
IMPORT IO,Lib;
VAR roll,i: CARDINAL;
BEGIN
Lib.RANDOMIZE;
FOR i:=1 TO 6 DO
roll:=Lib.RANDOM(6)+1;
IO.WrCard(roll,1);
IO.WrLn;
END;
END randtest.
Firstly, RANDOMIZE doesn't work because on each run the numbers are the same, and secondly, carriage return isn't working in WrLn because on successive new lines the numbers are cumulatively offset by 1 space.
The Win32 version of the compiler (using Wine) produces the expected correct output (no offsets and different numbers each time).

I have never seen that problem with the Windows version. I'd hazard a
guess that it gets a fixed answer for system time under Linux for some
reason. Can you set an explicit starting seed successfully?

You may have to inspect the generated code in a debugger to find out
what is going on here. I suspect IO.WrLn is still DOSian <cr><lf>.

Post by jd63
I haven't raised this issue yet on github because I first wanted to see if there are any other XDS users getting the same behaviour.
Thanks!

I don't think there are many people still using it now.
(I could be wrong)

[jd63]

Post by Martin Brown

Post by jd63
This concerns the Linux version only (native compiler). Version 2.60 from github. The code uses the RANDOMIZE and RANDOM functions from the Lib module, and WrLn from IO. Compiled with "xc -topspeed+ =m randtest.mod".
MODULE randtest;
IMPORT IO,Lib;
VAR roll,i: CARDINAL;
BEGIN
Lib.RANDOMIZE;
FOR i:=1 TO 6 DO
roll:=Lib.RANDOM(6)+1;
IO.WrCard(roll,1);
IO.WrLn;
END;
END randtest.
Firstly, RANDOMIZE doesn't work because on each run the numbers are the same, and secondly, carriage return isn't working in WrLn because on successive new lines the numbers are cumulatively offset by 1 space.
The Win32 version of the compiler (using Wine) produces the expected correct output (no offsets and different numbers each time).

I have never seen that problem with the Windows version. I'd hazard a
guess that it gets a fixed answer for system time under Linux for some
reason. Can you set an explicit starting seed successfully?
You may have to inspect the generated code in a debugger to find out
what is going on here. I suspect IO.WrLn is still DOSian <cr><lf>.

Post by jd63
I haven't raised this issue yet on github because I first wanted to see if there are any other XDS users getting the same behaviour.
Thanks!

I don't think there are many people still using it now.
(I could be wrong)
--
Regards,
Martin Brown

Thanks for the reply. I suspect your educated guesses are correct. I've had no problems with the Windows compiler TS modules, and I've made another module for random numbers which works on Linux. Cheers.

[nemo]

Post by Martin Brown

Post by jd63
This concerns the Linux version only (native compiler). Version 2.60
from github. The code uses the RANDOMIZE and RANDOM functions from the
Lib module, and WrLn from IO. Compiled with "xc -topspeed+ =m
randtest.mod".
MODULE randtest;
IMPORT IO,Lib;
VAR roll,i: CARDINAL;
BEGIN
   Lib.RANDOMIZE;
   FOR i:=1 TO 6 DO
     roll:=Lib.RANDOM(6)+1;
     IO.WrCard(roll,1);
     IO.WrLn;
   END;
END randtest.
Firstly, RANDOMIZE doesn't work because on each run the numbers are
the same, and secondly, carriage return isn't working in WrLn because
on successive new lines the numbers are cumulatively offset by 1 space.
The Win32 version of the compiler (using Wine) produces the expected
correct output (no offsets and different numbers each time).

I have never seen that problem with the Windows version. I'd hazard a
guess that it gets a fixed answer for system time under Linux for some
reason. Can you set an explicit starting seed successfully?

I have never used the Windows version but I used the OS/2 and Linux
versions extensively. I never had problems with RANDOMIZE/RANDDOM().

Post by Martin Brown
You may have to inspect the generated code in a debugger to find out
what is going on here.

On top of Martin's good advice, I would look at the source of Lib.mod
(https://github.com/excelsior-oss/xds/blob/cfd20e209193c9cfcee94ad2ca30d8c32ead48c9/Sources/Lib/src/TSlibs/Lib.mod).
As Martin guessed, it seeds with the system clock and then does a bit
of shuffling.

Post by Martin Brown
I suspect IO.WrLn is still DOSian <cr><lf>.

I never found that using it under Linux. IO.mod
(https://github.com/excelsior-oss/xds/blob/master/Sources/Lib/src/TSlibs/IO.mod)
is implemented with the ISO libs.

Post by Martin Brown

Post by jd63
I haven't raised this issue yet on github because I first wanted to
see if there are any other XDS users getting the same behaviour.
Thanks!

I don't think there are many people still using it now.
(I could be wrong)

One never knows, Martin. #6-)

N.

[Brian Knoblauch]

Post by jd63
I haven't raised this issue yet on github because I first wanted to see if there are any other XDS users getting the same behaviour.

I'm an XDS user, but only Windows. I wouldn't mind spinning up a GNU/Linux VM and giving it a try, but am swamped with work at the moment so won't be able to do it anytime real soon.