[Oberon] [EXT] Re: Fighting a dragon ...

[Skulski, Wojciech]

>But I really think we need some standard way how to find out these limits. My proposal would be to put them all in a module like Limits.Mod and give them standard names.

Hans,

this is a known dragon raising its ugly head again. Oberon System needs parametrizing. Your proposed Limits.Mod is only a part of it. I proposed SysDef.Mod defining the memory size, memory locations, stack, etc. These are all constants, but these are constants that must be changed when porting to a new board. For example, the 1 MB size of the memory was imposed by a particular board which was popular 10 years ago. The location and size of graphics RAM followed from this limitation. Then the peripheral addresses were defined one after another, which was sufficient only because their implementations were very simple. This again was due to hardware limitation. FPGA was 94% full and nothing else would fit. All these design decisions were hardwired all over the code without any central definition. It almost looks as if Oberon System programmers are fond of repeatedly typing hex numbers in every possible place. This makes their software genuinely non portable. The first step towards portability would be parametrizing all these numbers so they can be managed in one central location. Wirth himself made this point in his textbooks, and then nobody followed, including himself.

I am attaching my proposition from 4 years ago. It was shot down using arguments whose logic I could not follow. Like for example, it would take too long to recompile the OS if this file is modified. (Recompiling the whole OS takes ~3 seconds under Michael's emulator, and this was "too long".) Also, this file can be divided into a few smaller files (RegDef.Mod, MemDef.Mod, etc). This obvious idea was ignored by the key developers. 

So I am not optimistic that this community will ever adopt your Limits.Mod. Your idea is both great and obvious, and therefore it is very likely to be swept under the rug. 

Wojtek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SysDef_Feb_11_2020c.Mod.odc.pdf
Type: application/pdf
Size: 18731 bytes
Desc: SysDef_Feb_11_2020c.Mod.odc.pdf
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20240717/b81ad09f/attachment.pdf>