marvin@jungfrau.UUCP (Rico und Jan) (02/06/89)
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 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
frode@m2cs.uu.no (Frode Odegard) (02/07/89)
In article <772@jungfrau.UUCP>, marvin@jungfrau.UUCP (Rico und Jan) writes: > In article <INFO-M2%89012710550179@DB0TUI11> Modula2 List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: > 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) | | | Email: frode@m2cs.uu.no | |
alan@pdn.nm.paradyne.com (Alan Lovejoy) (02/07/89)
In article <772@jungfrau.UUCP< marvin@jungfrau.UUCP writes:
<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?
--
Alan Lovejoy; alan@pdn; 813-530-2211; ATT-Paradyne: 8550 Ulmerton, Largo, FL.
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.heiser@iis.UUCP (Gernot Heiser) (02/08/89)
In article <772@jungfrau.UUCP> marvin@jungfrau.UUCP writes: } [ 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 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser
WIORS12@HDETUD1.BITNET (Eric Maryniak 015-782547) (02/23/89)
Tomas <mcvax!cernvax!ethz!jungfrau!marvin@UUNET.UU.NET> (5 feb) writes: >... > 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 > This is indeed a problem; Wirth already mentioned it in article [1] together with the solution of a compiler hint denoting the size of an object, in the definition part. The problem is that a client module, that is being compiled, must know the size of an object (storage for variables, parameter passing) in order to produce correct object code. I don't think the solution with a compiler hint is an efficient one, however. When you define the record too large, this would e.g. result in too many pops and pushes in modules that pass the object as a value parameter. And what happens if the size is too small (e.g. when you're extending the record more than you expected when you wrote the definition) ? The implementation shouldn't compile then, and what do you do ? Increase the [size] in the definition part (I call this a patch !!), recompile it and compile the implementation again ... a lot of trouble ! I think that the patch, together with an update of the version number (to be sure that all modules import the type with the correct size !), in the symbol file (compiled definition part) is the best solution. You can do a perfectly portable patch by simply copying the symbol file to a new symbol file. And even if this patching is not portable, let that be the Oberon implementor's problem (he is spared enough already). This kind of thing should not be part of the syntax of Oberon. This [size] is non-portable too: should it denote bytes, words ? Furthermore, the size of an integer or real etc. in whatever storage unit is very hardware/operating-system dependant as Gernot Heiser also pointed out recently. Bye, Eric. Literature ---------- 1. Wirth, N. 1988. Type Extensions. ACM Transactions on Programming Languages and Systems 10(2): 204-214. bitnet address: wiors12@hdetud1 uucp address: mcvax!dutrun!dutrex!wiors12 real address: Julianalaan 132 TWI/SSOR 2628 BL Delft, The Netherlands