[Oberon] Module aliases - what is the correct way to handle them

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Mon Feb 17 13:46:47 CET 2020


    > In addition, this fix (in ORB12 and ORB13) will make symbol files even
    > more minimal than oberonc, because it will *only* write module descriptors
    > for those modules out to the symbol file, for which the "regular export”
    > in ORB.Export has not already re-exported at least one type.

Actually, this is not necessarily the case. In modules with many re-imported
types, oberonc ends up better in fact, because - as Luca has pointed out
earlier - the global module table used in oberonc ensures that the module
name (and key) is only ever written once, regardless of how many types
we are re-exporting from that module.

In any case, here are some stats:

Variant    Lines  sloc  Difference in sloc relative to FPGA Oberon (projectoberon.com)

 
ORB00.Mod  432    398   +0  (=FPGA Oberon, not a correct nor a full solution)

ORB07.Mod  435    401   +3  (=Extended Oberon, correct, but more restrictive)

ORB12.Mod  475    439   +41 (=two-pass solution, full solution)

ORB13.Mod  485    451   +53 (=one-pass solution, full solution)

oberonc:  >100 ?  (guessing from the diff file, but hard to compare due to other differences)




More information about the Oberon mailing list