|
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 |
