🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.modula2
Article #4630

Portable Oberon compiler

#4630
From: Rico und Jan
Date: Sun, 05 Feb 1989 16:04
94 lines
5333 bytes
In article <INFO-M2%89012710550179@DB0TUI11> Modula2 List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes:
>Vincent Manis writes:
>
>>I'm looking for the source code for an Oberon compiler, for any
>>machine. Can anyone help me ?
>
>Somewhere june 1988, I wrote a letter to Mr. Wirth, asking him about the
>(future) availability of an Oberon compiler.
>I received a letter some weeks later, in which Mr. Wirth said that there was
>no compiler available (at that time) in source form. It was likely, however,
>that the coming winter semester (of 1988) a (portable) compiler would be
>developed. But he could not make any promises.
>I haven't heard anything since, but it seems we might expect an ETH compiler,
>because the first (~portable) Pascal and Modula-2 compilers also came from
>the ETH.
>Any ETH-hackers on the net ?
>
>Bye, Eric.

Yup ! I'm one of those ETH-hackers :-).

Last wednesday (Feb 1) there was a half-hour presentation about that 
portable Oberon compiler project. There are two students working on it
and they hope to have it sort of finished by the end of this month.
Actually, it's their diploma project and they have to deliver their
report on February 28. 

What they did is basically this: They wrote an Oberon compiler in
Modula-2 which produces an intermediate code. This intermediate code
works stack-oriented, i.e. no registers. The I-code (looks like another
weird assembler :-}) is Oberon specific. It has, for example, an
intruction 'IST' which is the 'IS' type test of Oberon. To run the
I-code there are two approaches: an interpreter or another compiler
which produces target specific machine code out of the I-code. They
decided for the interpreter in order to get it running (they don't have
the time to write another compiler). So far they have a version for the
PC and another one for the Sun. But they are still working on both of
them. 

This solution might not be the fastest, but it will work, and at least
people can play around with Oberon. If there's more interest the second
compiler might be added in another project. I don't know if the sources
are going to be released to the public. I'll get their report as soon as
they have finished it, and I will check with them and Wirth if the
sources may and can be posted to the net.

But PLEASE: I don't have the sources yet !! And I don't know more than
what I told you above !! As soon as a have any news, I'll post them to
the net ! After all, I'm just a student who has no privileges and who
has to run after all this. I'll do my best, but I can't promise anything !


But here I have a little story about Oberon. It's about a problem that
not everybody might have realized. 

I'm working on another semester-project where I am using Oberon on the
Ceres. When I was compiling certain modules, the compiler gave a message
saying "new symbol file". I had no idea what it meant. However, my code
was working OK, so there was no reason for me to find out what this
meant. Last wednesday, on that presentation, the mystery was revealed
to me. In Oberon you can have so-called 'public projections'. This means
you can have a partial definition of a record type in the definition
part and the full definition of it in the implementation part (for
details see the last paragraphs of the section "Type extension" from the
paper "From Modula to Oberon"). This feature might be quite nice, but it
introduces serious problems for the compiler. If the public projection
(i.e. the declaration in the definition part) has a size smaller than
the actual declaration in the implementation part, the compiler looks at
the symbol file, and __patches__ it in order to have the size of the
record fixed ! To avoid this, the portable Oberon compiler will have a
slight modification to the language: you have to add a compiler hint in
the definition part. It will then look like this (referring to the
example in the paper): 

TYPE	Viewer = RECORD
		   width, height : INTEGER;
		   [8]
		 END;

The number indicates the size of the record as it will be in the
implementation part. It's not quite clear to me if it is possible to
give any size, even if it is bigger then the actual size in the
implementation part. I hope It will be clear in their report.

- Tomas

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% I'm a student at the Swiss Federal Institute of Technology (ETH) in %
% Zuerich, Switzerland, studying Computer Science.                    %
%                                                                     %
% ean:  felner@inf.ethz.ch                                            %
% uucp: ...!uunet!mcvax!ethz!jungfrau!marvin (marvin@jungfrau.UUCP)   %
% Surface: Tomas Felner, Quellenstrasse 30, 8005 Zuerich, Switzerland %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Technical Details
Message-ID: <772@jungfrau.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcvax!cernvax!ethz!jungfrau!marvin
References: <INFO-M2%89012710550179@DB0TUI11>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!mcvax!cernvax!ethz!jungfrau!marvin
From: marvin@jungfrau.UUCP (Rico und Jan)
Newsgroups: comp.lang.modula2
Subject: Portable Oberon compiler
Keywords: Oberon portable compiler ETH Wirth
Message-ID: <772@jungfrau.UUCP>
Date: 5 Feb 89 16:04:44 GMT
References: <INFO-M2%89012710550179@DB0TUI11>
Reply-To: marvin@jungfrau.UUCP
Organization: Mathematics Department, ETH Zuerich
Lines: 94