[Oberon] [EXT] Re: Portability of Project Oberon

[Skulski, Wojciech]

Joerg:

>I generally agree that NW‘s low level sources are full of double declarations (e.g stack-size literals at two different places etc) and literals instead of named constants. I cleaned them up a little, eg. my Modules imports Kernel.

Are your sources available?

>Your effort of collecting all low level values and document them in one file is appreciated. 

I would appreciate not the appreciation, but using my work to advance the system. Who is going to use what I have done? The collection was released 10 months ago.

> But ONE big SysDef.Mod is NOT a good idea. 

I agree. Remembering your advice I wrote "file or files". My proposition is that cleanup is much needed. The details are less important. I am not standing behind a single file, or a name SysDef.

> Oberon modules are unlike .h files in C not just „includes“; Oberon modules have version keys. So when you mix graphic-related constants, register-related constants and memory-related constants in one place, the whole Oberon idea of separate compilation is void. When you change e.g the stack size in your SysDef, SysDef gets a new key. Hence you would have to recompile the graphic driver without any need to do so.

I agree on all counts.

> The way out would be to spilt up your SysDef in several modules, eg MemoryDef, RegisterDef and so on.

Sure enough. Who is going to do it? I can. Who is going to adopt this work, then?

> Further on, we should carefully decide whether to export a CONST or a VAR (or even a PROCEDURE). NW often uses VARs (iso CONST) as then the upper modules don‘t have to be recompiled if the value changes.

Of course? Why not? It does not matter how we export the memory size. CONST MEMLIM*; VAR MEMLIM*; PROCEDURE GetMemLimit(); are all equally good. The critical point is that it should be declared *once*. 

Am I discovering the wheel here? I thought I read such recommendations in the NW papers.  Why are we not following the teaching?

I am attaching the compilation of NW teachings from his papers. Why are we disregarding these?

>Those considerations are always a trade off of portability and code efficiency.

Code efficiency is not impacted by declaring the constants *once* and then importing the definition. If it does then the compiler is broken, but I do not believe it is the case.

> I know you rate portability high. The higher you go in the abstraction, the more I like portability as well. 

Portability is not a technical necessity. It is a logistical necessity to have the work done.

>The lower HW-based you go, code efficiency is key and decides whether your code is fast enough to detect a signal edge or not. On lower layers portability is anyhow questionable as HW might differ.

There is only one way to interface with HW, and this is via registers. The present OS is doing just that. This is OK. 

My contribution is to clean the code, not to change it. I have not changed *anything*. All the addresses stay the same. My only contribution is documenting what is going on. The target of my work is not hardware. The target is *people*, which means myself, or other Oberon programmers for whom the present OS is incomprehensible. 

I am trying to improve the comprehension. There are no technical changes in what I have done.

If this is too much to ask for, then we have answered the question why is Oberon failing to gain acceptance.

Wojtek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Wirth_Programming_Recommendations.pdf
Type: application/pdf
Size: 22219 bytes
Desc: Wirth_Programming_Recommendations.pdf
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201208/ea0b2e16/attachment.pdf>