Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!HDETUD1.BITNET!WIORS12 From: WIORS12@HDETUD1.BITNET (Eric Maryniak 015-782547) Newsgroups: comp.lang.modula2 Subject: Portable Oberon compiler Message-ID: Date: 23 Feb 89 10:03:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 66 Tomas (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