Terra Datentechnik Home Home · Modula-2

List of Known Problems in Logitech Modula-2 V4.03

reported after TERRA Support Release 3 of June 1995
(List created 09-Feb-1998, last updated 28-May-1998)

Contents

  • TB-951027.1 String Constant Parameter Copy In Protected Mode
  • TB-960311.1 "HugePointer.INCHugePtr" Computes OFFSET Incorrectly
  • TB-961217.1 V2.22-L Compiler does not accept Large (>32 Bit) Set Constants
  • TB-970123.1 V2.22-L Compiler generates wrong code for accessing elements of a structured constant in a WITH statement when compiling the module with /CODE:L or /CODE:S
  • TB-971222.1 Year 2000/2028 Problems in Logitech V4 Library
  • TB-980526.1 Graphics Pixel/Character Operations and DefaultPalette
  • TB-980527.1 Missing Case Label in Procedure "Decimals.AddSub"

Top of Page



27-Oct-1995
Ref. TB-951027.1 (D. Steiner, CERBERUS)
SB V2.22-L compiler (also original Logitech M-2 V4.00)

String Constant Parameter Copy In Protected Mode

Contrary to common believe, the compiler problem TB-940202.1 (same as
TB-950201.1/Bug1) is not really fixed in SB V2.22-L:

The compiler generates inline code for copying a string constant
parameter. In case of a string constant of even size (size without
terminating 0C), e.g. "1234", it will copy one byte too much (same
amount as it reserves on the stack, i.e. size including 0C and then
rounded up to even). However, with the small and large CONST memory
model this may cause problems when running in protected mode (access
outside of segment limit).

In fact, the problem has only been resolved for the case, where the
offending string constant (with an even number of characters --> odd
size including 0C added by compiler) at the end of the segment by
chance has an even address. In this case, SB V2.22-L rounds up the
size of the CODE or FAR_CONST segment to even, i.e. adds an additional
null byte. The example used so far corresponded to this case.

However, an additional null byte is also required when that offending
constant has an odd address, i.e. if the segment size is even! The
following example may be used to demonstrate this case (please verify
that the last string constant has an odd address):

MODULE Z;



(* MUST BE COMPILED WITH /CONST:L OR /CONST:S ! *)

(*/noopt/alias/align:2/check/nocheck:s/data:m*)

(*/code:l/inline:n/nolibrary/debug/nowarn*)



  PROCEDURE P(s: ARRAY OF CHAR);

  END P;



BEGIN

  P("012345");

  P("789ab");

  P("de");  (* <=== this call generates trap D, as the string is

                    allocated at the end of the segment *)

END Z.

Alternatives for problem resolution in compiler:

(1) Compiler must always increment by one (instead of rounding up
to even) the segment size of the CODE resp. FAR_CONST segment
when compiling with /CONST:S resp. /CONST:L, i.e. add an
additional null byte at the segment end in these cases.

(2) Code generated for copying an open ARRAY OF CHAR (and maybe also
an open ARRAY OF BYTE) const parameter could be changed about as
follows:

Current Code:

  ...

  MOV CX, HIGH (ARRAY)

  ADD CX, 0002 ; CX = size + 1

  AND CL, 00FE ; round down to even if odd

  SUB SP, CX ; compute new SP

  PUSH SS

  POP ES

  MOV DI, SP ; DI = SP = offset of copy (always even)

  ...

  REP MOVSB ; copy CX bytes, possibly one too much

  ...

New Code:

  MOV CX, HIGH (ARRAY)

  INC CX ; CX = size

  MOV DI, SP

  SUB DI, CX ; compute new SP

  AND DI, FFFE ; round down to even (use one more byte) if odd

  MOV SP, DI ; SP = DI = offset of copy (always even)

  PUSH SS

  POP ES

  ...

  REP MOVSB ; copy CX bytes, always exact size

  ...

Top of Page


11-Mar-1996
Ref. TB-960311.1 (J. Mich‚ly, Techn. Büro C. Hilgers)
Library: Module "HugePointer", Function "INCHugePtr"
4.03 (= 4.00 & TERRA Support Releases 1, 2 & 3)

"HugePointer.INCHugePtr" Computes OFFSET Incorrectly

The OFFSET of the address returned is always equal to the value
"increment MOD 65536" instead of "(oldOffset + increment) MOD 65536".

Most simple correction:
Exchange AX and BX on line 42 in HUGEPOIN.ASM such that the result
of the ADD is in BX instead of AX:
add bx,ax ; increment offset

The following test program may be used to verify this bug and its fix:

MODULE TstH;

  FROM CardinalIO IMPORT

    WriteCardinal, WriteHex;

  FROM HugePointer IMPORT

    INCHugePtr, DECHugePtr;

  FROM SYSTEM IMPORT

    ADDRESS;

  FROM Terminal IMPORT

    WriteString, Write, WriteLn;



  PROCEDURE WriteAddr (a : ADDRESS);

  BEGIN

    WriteCardinal (a.SEGMENT, 5);

    Write (":");

    WriteCardinal (a.OFFSET, 5);

(*

    WriteHex (a.SEGMENT, 5);

    Write (":");

    WriteHex (a.OFFSET, 5);

*)

  END WriteAddr;



  PROCEDURE P (a          : ADDRESS;

               l          : LONGINT;

               correctSum : ADDRESS);

  BEGIN

    WriteAddr (a);

    a1 := INCHugePtr (a, l);

    WriteString (" --> ");

    WriteAddr (a1);

    a2 := DECHugePtr (a1, l);

    WriteString (" --> ");

    WriteAddr (a2);

    IF (a1 = correctSum) AND (a2 = a) THEN

      WriteString (", ok");

    ELSE

      WriteString (" ***ERROR");

    END;

    WriteLn;

  END P;



  VAR

    a1, a2 : ADDRESS;



BEGIN

  P (2727:0,   65536, 2735:0);

  P (2727:0,   32768, 2727:32768);

  P (2727:18,    500, 2727:518);

  P (2727:18, 131072, 2743:18);

  P (2727:18,  65518, 2735:0);

END TstH.

Top of Page



17-Dec-1996
Ref. TB-961217.1 (M. Geiger, Alphasem)
SB V2.22-L compiler (NOT original Logitech M-2 V4.00!)
4.03 (= TERRA Support Release 3 only)

V2.22-L Compiler does not accept Large (>32 Bit) Set Constants

MODULE ChSet; (*TB-961217.1*)

(*

The Modula-2 Compilers V2.22-L from Stony Brook exhibits a problem not

present in the original MultiScope/Logitech V4.00 version.

Is there another work-around than using a variable?



When compiling the following code a problem occurs with constant 

'WhiteSpace', i.e. the compiler reports this error message:

  "<file_name.mod>(<line_number>)(45) : error: Unstructured Constant 

  Expression required"



Everything works fine, if the constant is changed to a variable which

is initialized explizitly. The problem does not seem to occur with

other kinds of structured constants; it only seems to occur with SETs.



(translated from original text by Alphasem AG, M. Geiger)



--> Without using a variable, only the following, relatively "dirty"

    work-around with type-coercion has been found. We do not think,

    that another work-around exists.

TERRA Datentechnik, A. Gorrengourt

*)

FROM ASCII IMPORT

  EOL, cr, lf, ht;



TYPE

  SS0      = SET OF [CHR (  0H) .. CHR ( 1FH)];

  SS1      = SET OF [CHR ( 20H) .. CHR ( 3FH)];

  SS2      = SET OF [CHR ( 40H) .. CHR ( 5FH)];

  SS3      = SET OF [CHR ( 60H) .. CHR ( 7FH)];

  SS4      = SET OF [CHR ( 80H) .. CHR ( 9FH)];

  SS5      = SET OF [CHR (0A0H) .. CHR (0BFH)];

  SS6      = SET OF [CHR (0C0H) .. CHR (0DFH)];

  SS7      = SET OF [CHR (0E0H) .. CHR (0FFH)];

  CHARSET1 = RECORD

               s0 : SS0;

               s1 : SS1;

               s2 : SS2;

               s3 : SS3;

               s4 : SS4;

               s5 : SS5;

               s6 : SS6;

               s7 : SS7;

             END;

  CHARSET  = SET OF CHAR;



CONST

  WhiteSpace1 : CHARSET1 = [SS0 {EOL , cr, lf, ht},

                            SS1 {" "},

                            SS2 {},

                            SS3 {},

                            SS4 {},

                            SS5 {},

                            SS6 {},

                            SS7 {}];

(*

  WhiteSpace  = CHARSET {EOL , cr, lf, ' ', ht};

*)



VAR

  cs : CHARSET;

  

BEGIN

  cs := WhiteSpace1:CHARSET;

(*

  cs := WhiteSpace;

*)

END ChSet.

Top of Page


23-Jan-1997
Ref. TB-970123.1 (Ph. Wagnieres, MetaPhysics)
SB V2.22-L compiler (and probabely also original V4 compiler)
4.03 (and probabely also 4.00)

V2.22-L Compiler generates wrong code for accessing elements of a structured constant in a WITH statement when compiling the module with /CODE:L or /CODE:S

MODULE TstCL;

(*

 TB970123.1 : Problem with /CONST:L or /CONST:S and initialized constants.

 Program works ok if compiled with default DATA and CONST model.

 Wrong code is generated for accessing constant in WITH when compiling with

 /CONST:L or /CONST:S (and /DATA:M).

 Work-around: When compiling with /DATA:L/CONST:L or /DATA:L/CONST:S then

 code generated is ok again!

*)

  FROM CardinalIO IMPORT

    WriteCardinal;

  FROM Terminal IMPORT

    WriteString, WriteLn;



  TYPE

    TestType = RECORD

                 description : ARRAY [0 .. 127] OF CHAR;

                 wait        : CARDINAL;

                 scall       : ARRAY [0 .. 5] OF CHAR;

               END;



  CONST

    test : ARRAY OF TestType =

      [

(*0*)   ["zero-zero desrc", 77, "xyz"],

(*1*)   ["one-one desrc",   88, "yzx"],

(*2*)   ["two-two desrc",   99, "zxy"]

      ];



  PROCEDURE P (k : CARDINAL);

  BEGIN

    WITH test [k] DO

      WriteString ("value in WITH:");

      WriteCardinal (wait, 5);

    END;

    WriteString (", should be equal to value direct:");

    WriteCardinal (test [k].wait, 5);

    WriteLn;

  END P;



BEGIN

  P (0);

  P (1);

  P (2);

END TstCL.

Top of Page


22-Dec-1997
Ref. TB-971222.1
Library: Various Library Modules
4.03 (= 4.00 & TERRA Support Releases 1, 2 & 3)

Year 2000/2028 Problems in Logitech V4 Library

Some procedures of the Logitech library provide support for 2-digit year
numbers. When using these features, year 2000 problems may result for
the corresponding application programs.

Moreover, the basic date and time representation applied by the Logitech
library can only be used to denote dates and times up to December 31st,
2027. This limitation also influences or limits several other library
modules.

Please contact the TERRA Modula-2 Support if you are interested in a fix for the year 2000/2028 library problems and limitations of Logitech Modula-2 V4.

Top of Page


26-May-1998
Ref. TB-980526.1
Priority: 2
Library: Modules Graphics, GraphicAsm, GraphicText
4.03 (= 4.00 & TERRA Support Releases 1, 2 & 3)

Graphics Pixel/Character Operations and DefaultPalette

The code of the assembly modules "GraphicAsm" and "GraphicText"
contains some problems that may cause arbitrary behaviour when using
non-default pixel/character operations (AND, OR, XOR) on EGA/VGA. This
also applies when using the corresponding procedures of module "Graphics",
as well as the "(Set)DefaultPalette" procedures.

Due to the special efforts required to identify and fix these problems
(and an expected low interest for this fix), a corrected version of
these modules is available from TERRA against an additional fee only.

Please inquire with TERRA Datentechnik if you are interested in a fix
for these problems.

Top of Page


27-May-1998
Ref. TB-980527.1
Priority: 3
Library: Module
4.03 (= 4.00 & TERRA Support Releases 1, 2 & 3)

Missing Case Label in Procedure "Decimals.AddSub"

In the first nested CASE, the label value "Plus" should be added.
The corrected code will look like this:

    ...

    CASE StatDec0 OF

        NegOvfl: CASE StatDec1 OF

                    NegOvfl,Minus,Plus,Zero : SetState (NegOvfl,Resul)|

                    PosOvfl,Invalid : SetState (Invalid,Resul)

                 END|

        Minus  : CASE StatDec1 OF

        ...

Top of Page

 
Von Mensch zu Mensch
Home · Modula-2

 Copyright © TERRA Datentechnik 1996-2006
Alle Rechte vorbehalten.TERRA Datentechnik übernimmt keine Haftung für die Vollständigkeit, Richtigkeit und Aktualität der Angaben!
Rechtliche Hinweise  ·  Firmenprofil
 
Contact us   Last Updated: 12-November-2002 Webmaster