[Oberon] [EXT] Oberon V4 Windows startup oberon.exe

[Skulski, Wojciech]

Andreas:

would it be possible to bring your compiler closer to the previous Oberon-2 implemented under V4 in order to make porting a bit easier? 

You mentioned "original language Oberon, as defined in 1988". I thought that parts of V4 are implemented in Oberon-2. I just walked a tour among different source files and I have not seen Oberon-2 syntax anywhere yet. So you are probably right that V4 was written in Oberon-a rather than Oberon-2, except Dialogs and my B2, which were both written in Oberon-2. 

Manifest departures from Oberon-07 are RETURN statements in the code. I used them number of times. I can also see them in some V4 sources. This should be easy to fix, though of course tedious. I am not asking for relaxing this improvement, if we call it this way. (From the application programmer standpoint all such improvements are destructive because they tend to break the code and impact the already completed applications.)

Ideally, we would have V4 sources which would be identical under RISC5 and Windows. Applications can be then made portable by simply copying the files. I wonder if it is possible?

Wojtek

PS: Curiously, Dialogs are not present in my V4 implementation. I have the original booklet Report which I received from Markus a while back, so I know he used Oberon-2. I always thought that panels which I am seeing under V4 are Dialogs panels, but apparently they are not. This is interesting. I wonder what these panels are, if not Dialogs.
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Andreas Pirklbauer [andreas_pirklbauer at yahoo.com]
Sent: Saturday, November 28, 2020 10:47 AM
To: Oberon List
Subject: [Oberon]  [EXT] Oberon V4 Windows startup oberon.exe

   > "Oberon-2" parser frontend with a "RISC5" code generator backend. This does not exist so far.

There is actually an Oberon-2 compiler for NW’s FPGA RISC5, but it cannot be used to compile LinzOberon on FPGA as is, because the FPGA Oberon-2 compiler implements a superset of the Oberon-07 language (i.e. it uses CASE T OF instead of WITH T DO for the type case statement, it has no LOOP statement, etc) rather than the original language Oberon, as defined in 1988.