Minix: m2 type limits

FP managed to force a runtime error by having a CARDINAL overflow... Time for some type checking of the m2 compiler. Below you will find a trial to determine the limits of the m2 data types and a trial to force an overflow trap.

With the source code below, I printed the sizes of the m2 datatypes. It's all very easy so it doesn't nee dany comments. The sources can be downloaded or you can cut and paste them.

      
MODULE limits;

IMPORT  InOut;

BEGIN
   InOut.WriteString ("Limits of type INTEGER  :");
   InOut.WriteInt (MIN (INTEGER), 16);
   InOut.WriteInt (MAX (INTEGER), 16);
   InOut.WriteLn;
   InOut.WriteString ("Limits of type CARDINAL :");
   InOut.WriteCard (MIN (CARDINAL), 16);
   InOut.WriteCard (MAX (CARDINAL), 16);
   InOut.WriteLn;
   InOut.WriteString ("Limits of type CHAR     :");
   InOut.WriteInt (INTEGER (MIN (CHAR)), 16);
   InOut.WriteInt (INTEGER (MAX (CHAR)), 16);
   InOut.WriteLn;
END limits.

Compile and run this with the following commands

   $ m2 limits.mod -s -o Limits
   $ ./Limits

And this is the result:

    Limits of type INTEGER  :     -2147483648      2147483647
    Limits of type CARDINAL :               0      4294967295
    Limits of type CHAR     :               0             255

which shows us that the CHAR is as usual: [0..255] but the CARDINAL and INTEGER are full 32 bit numbers. Which of course makes sense. Why waste time on 16 bit numbers? They take up half a register so all in all they demand more attention than full 32 bit numbers.

FP did it and I want to confrm his tests: force an overflow trap. I made the following very simple program:

MODULE overflow;

VAR	teller		: CARDINAL;

BEGIN
   teller := 0;
   LOOP
      INC (teller, 8)
   END
END overflow.

If you compile and run this with:

    $ m2 overflow.mod -s -o Ovf
    $ time ./Ovf

you get the following on the display:

    "overflow.mod", line 8: cardinal overflow
          19.11 real      19.11 user       0.00 sys
    $

So the system needs 19 seconds to go through 530 million INC cycles in the loop. Not bad, for a 450 MHz system. So each cycle of the LOOP-END construct takes 35 ns or 16 clock cycles. Not bad at all!

Of course I tried to repeat the experiment with the variable of type INTEGER. But that didn't work. After a few minutes the teller value must have wrapped several times, but no trap was generated. Apparently, the value just wraps from MAX (INTEGER) to MIN (INTEGER) without the system knowing it. So take care!

Page created on 21 February 2007 and

Page equipped with FroogleBuster technology