Portable Oberon compiler 
Author Message
 Portable 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.

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


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



Mon, 20 Jul 1992 10:03:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Very portable Oberon compiler (Oberon and ANDF)

2. A portable Oberon compiler

3. SMALL PORTABLE Oberon compiler?

4. Portable Free Oberon-2 standalone compilers?

5. Portable Free Oberon-2 standalone compilers?

6. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

7. Extacy portable Oberon-2 and Modula-2 compiler demo is available on ftp

8. Oberon/Modula portable compiler

9. Announce: Oberon 960, an Oberon-2 compiler generating 80960 code

10. Is Oberon data format portable ??

11. Oberon and Portables

12. Portable Modula-2 compilers

 

 
Powered by phpBB® Forum Software