vishapoberon/compiler
1
0
Fork 0
mirror of https://github.com/vishapoberon/compiler.git synced 2026-04-05 23:22:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix hex parsing, readme typos.

Browse source
This commit is contained in:
David Brown 2016-07-08 12:53:30 +01:00
parent d50e08ac3f
commit 56256a49f2
5 changed files with 29 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

2
ReadMe.md
View file

@ -195,7 +195,7 @@ of Einstein and Antoine de Saint-Exupéry:
###### Oberon 2
- [Differences between Oberon and Oberon-2](http://members.home.nl/jmr272/Oberon/Oberon2.Differences.pdf)
- [The Programming Language Oberon-2](http://www.ssw.uni-linz.ac.at/Research/Papers/Oberon2.pdf)
- [Programming in Oberon. Steps beyond Pascal and Modula](www.ethoberon.ethz.ch/WirthPubl/ProgInOberonWR.pdf)
- [Programming in Oberon. Steps beyond Pascal and Modula](http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberonWR.pdf)
- [The Oakwood Guidelines for Oberon-2 Compiler Developers](http://www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf)
###### Oberon 07

2
doc/Installation.md
View file

@ -32,7 +32,7 @@ The following type sizes follow the built compiler size:
| Types | 32 bit builds | 64 bit builds |
| ----- | ------------- | ------------- |
| INTEGER | 16 bit | 32 bit |
| LONGINT, SET | 32 bit | 16 bit |
| LONGINT, SET | 32 bit | 64 bit |
Note that many library modules have been written with the assumption that INTEGER
is 16 bit and LONGINT 32 bit, therefore they will only work in 32 bit builds.

23
doc/Roadmap.md
View file

@ -66,6 +66,29 @@ means client code does not need changing.
This fixes the current 16 bit hole in the range of INTEGER types on 64 bit systems.
#### Oakwood Guidelines on type sizes
The Oakwood guidelines are interesting.
- 5.2 requires that e.g. LONGINT is 32 bits *or more*,
but
- Appendix A 1.2.5.4 requires that MODULE Files *always* reads and writes
LONGINT as 4 bytes.
The restriction for the Files module makes sense as it is intended to produce
and consume files in a compatible way between platforms. Thus if a system uses
64 bit LONGINT, it is an error (detected or not) to write
to MODULE Files any LONGINT values outside the 32 bit range.
To put it shockingly, it is an error to write the vast majority of possible
LONGINT values - specifically over 99.998% of LONGINT values are invalid for
MODULE Files.
I see this as another argument in favour of locking LONGINT down as 32 bits.
#### A feature I'd really like to see

1
src/compiler/OPM.cmdln.Mod
View file

@ -31,7 +31,6 @@ MODULE OPM; (* RC 6.3.89 / 28.6.89, J.Templ 10.7.89 / 22.7.96 *)
MaxRExp* = 38;
MaxLExp* = 308;
MaxHDig* = 8;
MinHaltNr* = 0;
MaxHaltNr* = 255;

7
src/compiler/OPS.Mod
View file

@ -90,7 +90,7 @@ MODULE OPS; (* NW, RC 6.3.89 / 18.10.92 *) (* object model 3.6.92 *)
END Identifier;
PROCEDURE Number;
VAR i, m, n, d, e: INTEGER; dig: ARRAY 24 OF CHAR; f: LONGREAL; expCh: CHAR; neg: BOOLEAN;
VAR i, m, n, d, e, maxHdig: INTEGER; dig: ARRAY 24 OF CHAR; f: LONGREAL; expCh: CHAR; neg: BOOLEAN;
PROCEDURE Ten(e: INTEGER): LONGREAL;
VAR x, p: LONGREAL;
@ -136,8 +136,9 @@ MODULE OPS; (* NW, RC 6.3.89 / 18.10.92 *) (* object model 3.6.92 *)
ELSE err(203)
END
ELSIF ch = "H" THEN (* hexadecimal *) OPM.Get(ch); numtyp := integer;
IF n <= OPM.MaxHDig THEN
IF (n = OPM.MaxHDig) & (dig[0] > "7") THEN (* prevent overflow *) intval := -1 END;
IF MAX(LONGINT) > 2147483647 THEN maxHdig := 16 ELSE maxHdig := 8 END;
IF n <= maxHdig THEN
IF (n = maxHdig) & (dig[0] > "7") THEN (* prevent overflow *) intval := -1 END;
WHILE i < n DO intval := intval*10H + Ord(dig[i], TRUE); INC(i) END
ELSE err(203)
END