<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
span.E-MailFormatvorlage19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:72708844;
mso-list-template-ids:1370656534;}
@list l0:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:547377161;
mso-list-template-ids:1453610858;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1330714632;
mso-list-template-ids:457237700;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:1702125110;
mso-list-template-ids:90609660;}
@list l3:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style></head><body lang=DE-CH link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Hi<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>There are different ways to implement the limits Hans wanted to know.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>The quick and dirty solution is to add a module “def.FP.Mod” like this:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> MODULE FP;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> CONST<br> MAXFLT* = 16777216;<br> MAXFLOOR* = 16777216.0<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> END FP.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Only the floating point HW defines those limits (in Project Oberon it’s in FPAdder.v). Whenever a HW developer decides to enhance the floating point routine, the HW developer must not forget to adjust the limits here and compile this Oberon module.<br>You have to find out what other module import FP.Mod and have to recompile them as well and so on.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>A more dynamic approach is the following:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> MODULE FP;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> VAR<br> MAXFLT*: INTEGER; <br> MAXFLOOR*: REAL;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> BEGIN<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> MAXFLT* := 16777216; MAXFLOOR* := 16777216.0<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> END FP.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>With such an approach the HW developer enters his new limits only in the implementation part of the module and does not change the definition part, and hence stays on the same module key. No recompilation of other modules needed.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Even another approach would be to do it with “dynamic HW”. Like so:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> MODULE FP; (* this is the device driver for the FPU *)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> IMPORT S := SYSTEM;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> VAR<br> MAXFLT*: INTEGER;<br> MAXFLOOR*: REAL;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> PROCEDURE Init*;<br> BEGIN<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> MAXFLT := S.GET(-4); MAXFLOOR := S.GET(-4)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> END Init;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> END FP.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Here, the HW developer does not have to change the Oberon part at all, as he “only” has to adapt his limits in the HW part (RISC5Top.v)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>br<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Jörg<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div id=mail-editor-reference-message-container><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='color:black'>Von: </span></b><span style='color:black'>Oberon <oberon-bounces@lists.inf.ethz.ch> im Auftrag von Jörg Straube <joerg.straube@iaeth.ch><br><b>Datum: </b>Mittwoch, 17. Juli 2024 um 16:08<br><b>An: </b>Skulski, Wojciech <skulski@pas.rochester.edu>, ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br><b>Cc: </b>pdewacht@gmail.com <pdewacht@gmail.com><br><b>Betreff: </b>Re: [Oberon] [EXT] Re: Fighting a dragon ...<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Wojtek</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>The idea is good but the way you propose is not.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Let’s look at the SW side first:</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Please understand that Oberon is a programming language allowing separate compilation.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Your SysDef module is NOT just an include file like in C or assembler. The complier allocates an own module key to it.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Let’s assume we do as you propose. And let’s assume the FPGA gets more memory.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>You have to change your constant MEMLIM and hence have to recompile SysDef.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>All modules importing SysDef have to be recompiled, although not necessarily needed.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Eg FSOffset (FS for Filesystem) or REG12 have nothing to do with the memory.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Two alternative approaches:</span><o:p></o:p></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo3'><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Split up this one monolithic SysDef.Mod in separate, logically independent modules:<br>Eg all register constants (REG15, REG14 …) in a file def.RISC5.Mod or def.CPU.Mod.<br>The logical register names (MT, SB SP..) in a File def.Compiler.Mod, as the complier (basically ORG.Mod) defines how RISC registers are used in Oberon.</span><o:p></o:p></li></ol><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>The constant FSoffset (FS = file system, has nothing to do with STACKORG) is currently used by BootLoader and Kernel<br>and in the future perhaps by some disk inspection tool that does not want to use Kernel.</span><o:p></o:p></p><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>This could be in an own def.Boot.Mod or def.SDCard.Mod. But it is debatable if you need an own module for one constant.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoListParagraph style='margin-left:0cm;mso-list:l3 level1 lfo6'><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Complimentary to the above: Each module exports variables where it exposes its implementation choices.<br>Eg Kernel defines where the heap is and allocates memory from the heap. So, it appears logical that Kernel exports its implementation choices, how Oberon organizes its heap.</span><o:p></o:p></li></ol><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Actually, it does it already: your constant STACKSIZE is basically Kernel.stackSize, your constant HEAPORG is basically Kernel.heapOrg.</span><o:p></o:p></p><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>If you have more memory, Kernel.Mod decides if and how it wants to use it, you change the IMPLEMENTATION of Kernel (NOT exported constants impacting the module key) and the rest of the system is untouched and benefits of more memory without recompiling everything as with your approach.</span><o:p></o:p></p><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>The module Modules.Mod handles the loading of modules, so decides on ModAllocAdr, MTOrg and so forth.</span><o:p></o:p></p><p class=MsoListParagraph><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>A lot of your “constants” are actually not needed as you can find them via<br>MEMLIM := SYSTEM.GET(MemLimAdr); or MEMLIM := Kernel.MemLim<br>MTOrg := SYSTEM.GET(ModRootAdr); or MTOrg := Modules.MTOrg</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>I understand that the concept of abstraction and separate compilation brings the drawback of several files and not ONE file as you might like.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Kernel.Mod decides on heap allocation, Modules.Mod on module allocation, FileDir.Mod on file allocation, Display on display memory etc. Every implementation decides independently on how it organizes its HW resources and exports its decisions to the rest of the system either via constants or more flexibly as variables or procedures.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Now to the HW point of view:</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:110pt;mso-fareast-language:EN-US'>I agree that some of the issues you address are not solved: How does the Bootloader know, that he can set the stack pointer to 80000H?</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>It apparently assumes that it has at least 512kB (=80000H) of memory. These bootstrapping issues should not be solved with SysDef nor with my approaches explained above.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>These issues should be solved with “dynamic HW”: I mean the SW should be able to ask HW capabilities. E.g “How much memory do we have installed”?</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>“What’s the address and size of the video frame buffer?” These “constants” burnt in HW may well be at one place if you like. In the Project Oberon environment, RISC5Top.v is most probably the best place for this.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>One idea how the SW can “talk” to the HW is to use the last possible IO port (-4) for this. Something like this</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><br>System.PUT (-4, 0); (* 0 = get info on all devices *)<br>len := System.GET(-4); IF len = 0 THEN (* HW does not support device enumeration *)</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>ELSE</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:110pt;mso-fareast-language:EN-US'> FOR i := 1 TO len DO dev[i] := System.GET(-4) END; (* this lists all devices in the system: memory, IO Ports, graphics… *)<br>END;</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>System.PUT (-4, dev[3]); (* Example: get info on device with number dev[3] *)<br>ch := System.GET(-4); IF ch = 0X THEN (* HW does not support device info *)</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>ELSE</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> i := 0; REPEAT driver[i] := ch; INC(i) ch := SYSTEM.GET(-4) UNTIL ch = 0X; (* max 32 chars *) </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> Modules.Load(driver, D); P := Modules.ThisCommand(D, “Init”); P; (* initializes the driver and reads the rest of the HW info of this device *)<br>END;</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>The HW first returns the name of the device driver of the specific device.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Then, the device driver is loaded and gets the remaining device info.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>Such a scheme is not implemented yet.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>br</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;mso-fareast-language:EN-US'>Jörg</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Am 17.07.24, 12:17 schrieb "Skulski, Wojciech" <skulski@pas.rochester.edu>:<o:p></o:p></p><div><p class=MsoNormal><span lang=EN-US>>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.</span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US>Hans,</span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US>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.</span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US>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. </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US>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. </span><o:p></o:p></p></div><div><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p></div><div><p class=MsoNormal>Wojtek<o:p></o:p></p></div></div></div></div></body></html>