[Oberon] System V5 - SYSTEM.Mod creation

[eas lab]

Jorg OneLineWrote:---
The compiler is always tied to the CPU. The compiler's modules Scanner
(ORS) and Parser (ORP) are tied to the Oberon language. The module
Generator (ORG) is tied to the CPU. So very roughly: when you have a
new CPU, only ORG has to be replaced, but in reality unfortunately
it's a little bit more complex...
======
Well it was nice to get the same LookAndFeel of ETHO on the rPi-ARM.
So apparently the original design was modular enough for Peter Matthias
to adapt it.

==Chris Glur.



On 4/16/16, Jörg Straube <joerg.straube at iaeth.ch> wrote:
> The compiler is always tied to the CPU. The compiler's modules Scanner (ORS)
> and Parser (ORP) are tied to the Oberon language. The module Generator (ORG)
> is tied to the CPU. So very roughly: when you have a new CPU, only ORG has
> to be replaced, but in reality unfortunately it's a little bit more
> complex...
>
> Jörg
>
> Am 17.04.2016 um 06:05 schrieb eas lab <lab.eas at gmail.com>:
>
>>> Module SYSTEM uses the same syntax as "normal" modules, but the
>>> implementation is provided directly by the compiler.
>>
>>> Eg when you write SYSTEM.GET it's more like an embedded assembler
>>> statement
>>> as the compiler will generate a Load instruction to get a word or a byte
>>> from memory.
>>
>> Wow ! Isn't that being too cleva ?
>> Don't you lose modularity?
>> The compiler is tied to the CPU architecture?
>> Or you could have separate <plugin> modules for each architecture?
>>
>> I can't afford to read the <book> to get an answer.
>> Each extra *.pdf fetched contaminates the system.
>>
>> == Chris Glur.
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>