[Oberon] Compiler Modules Empty?

[eas lab]

Here's my log of <trace a call to SYSTEM.PUT in V5's sources to find
the actual machine-code-implementation>.
It's good to do it with V5, rather than being 'married to any specific
proprietry hardware', and especially since V5 hardware is simplified.

Let's  trace:
$PWD/PO2013/PO2013d => MODULE Display; =>
 PROCEDURE Dot*(col, x, y, mode: INTEGER);  => SYSTEM.PUT(a, u + s)

? Where did they say <SYSTEMfile> was? :--Jan Verhoeven:
It is mentioned in ORB.Mod. The SYSTEM functions are entered as keywords
in the linked list, but the functions by themselves are never defined.
---Douglas G. Danforth:
BlackBox/Component Pascal files...file CPB you will find code...
=!=> of these 3 CASEbranches, 3 are errorExcuses why NOT to GenCode
]| valfn: (*SYSTEM.VAL*)
]                 IF x.class # Ntype THEN err(110)
]                 ELSIF (f IN {Undef, String8, String16, NoTyp, NilTyp})
]                 (* OR (x.typ.comp = DynArr) *) THEN err(111)
]                 ELSE CheckOldType(x)
]                 END
  still doesn't map an arg to a value. <-- failed search branch.
---cfbsoftware:
]SYSTEM is a so-called 'pseudo module'...generate in-line instructions.

OK, that's interesting. Speed is needed for eg. dispaly-drivers.

]They are 'compiler magic' specified in the compiler itself. If you want to
]see how they are implemented in FPGA RISC Oberon, study the following
]compiler procedures:
]
]ORB (module initialisation).
=> "...This module contains the list of standard identifiers, with which
    the symbol table (universe), and that of the pseudo-module SYSTEM are initia
lized. *)
...
IF modid1 = "SYSTEM" THEN ...
system := NIL;  (* initialize "unsafe" pseudo-module SYSTEM*) <- ?!
...
  enter("PUT", SProc, noType, 112);
  enter("GET", SProc, noType, 102);
END ORB.

]ORP.StandFunc
PROCEDURE StandFunc(VAR x: ORG.Item; fct: LONGINT; restyp: ORB.Type);
BEGIN Check(ORS.lparen, "no (");  ..... a nightmare of CHECKing!

]ORP.StandProc
  PROCEDURE StandProc(pno: LONGINT);

==============> ORB, ORP are monsterous Modules.
Lets find the byteCodes for SYSTEM.PUT(... ,from the hardware spec?
=> from: PO.System.pdf <- Ends at 9.5
16. Implementation of the RISC processor
16.1. Introduction
16.2. The Arithmetic and Logic Unit (ALU)
...
  16.3.3. Floating-point division
...
A2. The processor architecture RISC
 1. The RISC-philosophy
 2. The arithmetic-logic unit (ALU)
 3. The control unit
 4. The instruction set

=> PO.Aplications.pdf ends at pg 86.
15.3. A generator of graphic macros
...
Ie. the vital info listed in the Table Of Contents is missing.

There's a lot of this type of fraud on the internet these days.

== Chris Glur.

PS. Nobody ever mentioned the ETHO x86 <dis-assembler>,
whose output is quite fascinating. It may be broken, or only do 386;
but could possibly be modified for other architectures.

IMO writing machineCode in Oberon is as wrong as writing music
scores in natural-language. You should only write the machineCode
handling-TOOLS in Oberon.
Oberon is good for making Domain-Specific-Languages.