[Oberon] OP2 Vs Wirth's compiler.

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Mon Jul 31 18:26:36 CEST 2017


The latest RISC5 compiler handles this similar to the original Oberon compiler on Ceres: one single key per module. Thus, when the interface of a module is changed, *all* clients are invalidated. In the specific implementation, the key is simply the sum of all bytes in the symbol file, i.e. really is a checksum.
See procedure ORS.Export at http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/ORB.Mod.txt .
AP

--------------
Josef Templ josef.templ at gmail.com 
Mon Jul 31 15:52:13 CEST 2017

   
   - Previous message: [Oberon] OP2 Vs Wirth's compiler.
   - Next message: [Oberon] Re (2): Italicization of comments and emboldening of keywords.
   - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Besides the abstract syntax tree construction, one difference between OP2
and the original NW Oberon
compiler is the compatibility checking across module boundaries.
In OP2 there is a separate key (fingerprint) per exported object while in
the original compiler there is a single key
per module. Thus, whenever anything in a module is changed all clients are
invalidated. In OP2 only clients that
are using the changed object are invalidated. I don't know how this is
handled in the latest RISC5 compiler.

- JT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170731/bc094882/attachment.html>


More information about the Oberon mailing list