[Oberon] Negative integer literals in Oberon

[Joerg]

You can enrich the current Oberon system with new HW, but compatibility and flexibility is a little bit missing in the current form.

A modular driver architecture is missing. I’m looking into this, how this could be done. By introducing this new driver architecture responsible for one piece of HW, the idea of SysDef.Mod is taken one step further to split it in smaller modular parts.

Having all constants at one place like SysDef.Mod is good and bad. Good is that you see all relevant HW related constant definition at one place. But if you want to change one part of  it, you have to recompile the whole system, even modules not influenced by the change at all.

br
Jörg

> Am 27.04.2020 um 18:11 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Joerg:
> 
>> In my point of view Oberon report should slightly redefine SETs 
>> by defining its internal presentation:  define its bit numbering 
>> (= define its endianness) allow hex notation only for SETs 
>> (as alternative notation to { } ), drop hex notation 
>> for INTEGERs as I don't see a real use case for 
>> hex notation on INTEGERs yet.
> 
> How about all these MOD and DIV used for bit manipulations in 
> Oberon System? They are everywhere. Are you saying that someone
> (==NW?) should redefine both the SETs and the INTEGERs and then 
> modify most of the low level Oberon modules to eradicate 
> bit manipulations with MOD and DIV? 
> 
> This kind of redesign may be worth it, but who is going to do it? 
> You? NW? Paul? Somebody else? How about the adoption by the community?
> The story of SysDef.Mod is telling me that the entrenched coding practice
> is not going to change any easily. And now you are implying changing 
> lots of low level bit manipulation code across the entire System. Is it 
> a realistic proposition?
> 
> Wojtek
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon