[Oberon] IMPORT Modules: why does order matter?

[Michael Schierl]

Hello Andreas,


Am 03.03.2019 um 01:10 schrieb Andreas Pirklbauer:

> Now that the main Oberon-2 features are implemented, one could (relatively)
> easily create a version of the EO compiler that is *fully* backward compatible
> with the “official” Oberon-2 language spec, 

Maybe. Depending on the definition of "relatively easily".

> i.e. such that any legacy Oberon-2 program can be compiled without *any* change.

No.

That may be true for Oberon-2 programs written in the ivory tower of
academia, but I intentionally wrote to test it on a random real world
module which is part of Native Oberon System 3. And those modules may
compile on OP2, but still are far from being portable Oberon-2
specification-compliant programs.


First, there are added features in every Oberon compiler, being it the
$$ raw string literals or 0abcdR raw float literals in PO2013, or e.g.
inline assembly in Native Oberon. And while academia agrees that inline
assembly is evil and should not be used unless really required in
low-level code, I've seen too many examples where inline assembly is
used "just for performance reason", sometimes with a comment of the
"portable" Oberon version behind that.

Examples:
https://github.com/schierlm/NativeOberon-2.3.6-Extracted/blob/master/FullInstall_ASCII/Pictures.Mod#L59-L78

https://github.com/schierlm/NativeOberon-2.3.6-Extracted/blob/master/FullInstall_ASCII/Fonts.Mod#L74-L94


Next, there are restrictions imposed by CPU architecture and/or ABI
considerations. For example, passing arguments as registers (PO2013)
naturally limits the number of arguments passable by the number of
hardware registers, while passing arguments on the stack (Native Oberon)
does not. I did not try to count occurrences with methods that have more
than 16 (or 10?) arguments, but I am pretty sure they exist in Native
Oberon.


And last there are allowed ambiguities in the spec where systems behave
differently, which cannot (in my opinion) be fixed in a way without
breaking compatibility with "new" Oberon modules. For example, PO2013
uses 32-bit INTEGER which do not trap on overflow but wrap, and Native
Oberon used 16-bit INTEGER which also wrap. Therefore some low-level
code (e.g. in data compression/decompression) that takes into account
this wrapping will still compile in a fictitions "compatible" Oberon-2
compiler, but the runtime behaviour will be different enough that it
results in garbage.


Of course, they can be fixed manually by adding appropriate MOD
instructions (or by using a new HALFINT type added to the compiler), but
just not automatically.


I am sure there are many more such points, which do not exist in
academia but in the real world. We all know that the difference between
theory and practice is that, in theory, there is none.


Regards,


Michael