Oberon compiler 
Author Message
 Oberon compiler

Quote:
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.

    \     /   /
   /#. # #-  #  /
  ## ## ## ##  ##
 # #   ## ##  ##
" "  #    ## ##
"."  ".   "./
TTTTTTTTTTT  UU       UU    Delft University of Technology
TTTTTTTTTTT  UU       UU
    TTT      UU       UU    Eric Maryniak, scientific programmer
    TTT      UU       UU

    TTT      UU       UU      uucp address: mcvax!dutrun!dutrex!wiors12
    TTT      UU       UU      real address: Julianalaan 132    TWI/SSOR
    TTT       UUUUUUUUU                     2628 BL Delft, The Netherlands

Standard disclaimer: not specified yet.
N.B.: if 'mcvax' does not work, try 'hp4nl'.



Fri, 19 Jun 1992 09:08:00 GMT  
 Oberon compiler

Quote:

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


% Surface: Tomas Felner, Quellenstrasse 30, 8005 Zuerich, Switzerland %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



Mon, 20 Jul 1992 16:04:00 GMT  
 Oberon compiler

Quote:

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

FTL Modula-2 supports structured opaque types by patching the symbol file.
You don't have to do it that way, but unless you want a monster linker
that's the way you do it. The Oberon language modification you mention
sort of takes away the whole beauty of public projection. The point of
public projection (and opaque types in Modula-2) is to _hide_ the
(parts of the) data stuructures you don't want the module's clients
to be able to touch and give the author of the implementation module
a choice of implementing data structures as well as procedures.
Declaring the size of the type T in the implementation part I
consider a crude solution, be it Oberon or Modula-2.

Still, I'm happy that someone's doing a portable Oberom compiler. As
Oberon is played with around the globe, I'm sure N.W. will get lots
of feedback. A couple of days ago, I heard someone say that type
extension could be the Modulean's answer to not having inheritence
in his language. Oberon is an experimental language of course, and
it lacks features many Moduleans wouldn't live without (like subrange
and enumeration types).

Has anyone looked into applying an Oberon-like manner of type extension
to Modula-2?  After doing some large-scale projects in Modula-2, I've
found a need for type extensions and/or parameterized types/modules.

                                - Frode

--
| Frode L. Odegard         |"The world is coming to an end! Repent and|
| Modula-2 CASE Systems    |rm /bin/cc"                               |
| NORWAY (EUROPE)          |                                          |



Mon, 20 Jul 1992 11:18:00 GMT  
 Oberon compiler

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

Why couldn't this be handled by the linker instead of the compiler?

--

Disclaimer: I do not speak for ATT-Paradyne.  They do not speak for me.
___________ This Month's Slogan: Reach out and BUY someone (tm). ___________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.



Mon, 20 Jul 1992 15:38:00 GMT  
 Oberon compiler

Quote:

}  [ stuff deleted ]
} 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.

This looks like a real portability feast. Assuming this "hint" indicates the
number of bytes to reserve for the record, this number is highly hardware (and
probably compiler) dependent. Assuming the private part consists of two
INTEGERs, the size of the number depends on the size (in bytes) of an INTEGER
item. Is this _really_ preferrable to an visible "private part" (e.g. as done
in Ada) where at least your code is portable?

--
Gernot Heiser                   Phone:       +41 1/256 23 48


CH-8092 Zuerich, Switzerland    UUCP (old):  {uunet,mcvax,...}!iis!heiser



Mon, 20 Jul 1992 20:42:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Very portable Oberon compiler (Oberon and ANDF)

2. Oberon compiler, anyone ?

3. Portable Oberon compiler

4. Looking for Oberon compiler

5. Oberon compiler for VMS?

6. c to oberon compiler

7. Oberon Compiler for DOS

8. Oberon Compiler Source Code?

9. ANNOUCE Experimental Oberon Compiler C++

10. ANNOUCE: Oberon Compiler C/C++

11. CD-Oberon Compilers

12. New Oberon compiler goes public

 

 
Powered by phpBB® Forum Software