August 2013 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] WITH removal in Oberon-07
by Paul Reed 13 Mar '14

13 Mar '14

> Date: Thu, 21 Feb 2013 22:52:05 +0100 > From: "Frans-Pieter Vonck" <fp(a)vonck.nl> > Subject: Re: [Oberon] WITH removal in Oberon-07 Hi Frans-Pieter, > i watched your presentation at MEDIA OberonDay2011. > Am I right that you made an ARM emulator first. No. The virtual machine is RISC, as in Prof. Wirth's Compiler Construction book (published in English in 1996 and updated on his home page http://www.inf.ethz.ch/personal/wirth/) > And did you use this emulator to ran Oberon System07 on top of it? It's not called System07, but it's basically the original system in the Project Oberon book, modified to compile under Oberon-07, run inside a RISC virtual machine executing on a bare-metal PC. > You showed a Spartan FPGA. I scanned through the Verilog ARM code. But > that seems a to big leap to me. I don't know what Verilog code you are referring to here. The Spartan-3 board only has 500K gates and 1MB of external static RAM, so it's much smaller and simpler than a typical ARM system. But ideal for Oberon. > Do you think it is possible to run [The Oberon System, compiled in Oberon-07] on an of the shelf > board with a Cortex M3 processor? I don't see why not, but most small ARM boards don't have a video framebuffer. The Raspberry Pi does, but it's a complicated board, as I've said before. The Oberon inner core (Kernel, FileDir, Files, Modules) and even the text system do not actually require a framebuffer display, so you could build a hybrid system. Using a simple FPGA board allows us to avoid the vast and irrelevant complexity inherent with most ARM System-on-Chip (SoC) systems; but since field-programmable gate arrays are so flexible, they will never be as cheap or as fast as a dedicated ARM. That's life. :) HTH Paul

4 5

Can ETHO be ported to ARM?
by eas lab 13 Jan '14

13 Jan '14

No, not the <language>, but the unique interface of S3/V4. What matters is the human-interface. That's what determines your productivety [maximum gain for minimum pain]. Not needing to switch between awkward F-keys and the screen, and having easy access to multiple text-files together, and each text-view having <what the bottle does, written on the bottle, instead of in the filing cabinet>. Porting ETHO to linux [both S3 & V4] was a killer app:. you get the Inet capability of *nix together with the superior human-interface of ETHO, plus you can view *pdf, LaTex..etc. on the same screen. For tricky problems, needing simultaneous views of: email/s, USEnet/s, your test-logs EHO is unbeaten, especially with the text colouring facilities, which help extract the meaning of difficult explanations. Because opeing/closing a new ETHO-for-linux takes a second, it's viable to have several copies running in the various dirs, which are handling current problems. Real life doesn't allow fixing one problem at a time. Can those of us who want to escape the WinTel monopoly, hope to use ARM based CPUs with an ETHO-like interface, by a porting of the existing/proven code? == Chris Glur. PS. LNO's inability to easily navigate the dir-tree, limits its utility.

3 7

Partitions.Show detail ~, Partitions.ShowAosFSLimits ~ and block size.
by peasthope＠shaw.ca 21 Aug '13

21 Aug '13

I'm interested in these questions about block size, primarily for relevance to flash storage. Partitions.Show detail ~ ... Disk: IDE1, 497MB = 1018080 * 512, removable, CHS: 1010*16*63, SAMSUNG CF/ATA, mntcnt=1 ... suggests a block size of 512 bytes. Partitions.ShowAosFSLimits ~ Aos file system limits with 4096 byte sectors ... suggests a block size of 4096 bytes, or might simply mean "If the block size is 4096 bytes, then these are the file system limits." Partitions.Mod has BS = 512; ... N2KSS = 2048; A block size of 512 seems fairly definite. What is N2KSS? Any ideas why ShowAosFSLimits mentions 4096 bytes? ProjectOberon.pdf doesn't mention N2KSS. Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Re: [Oberon] Re (2): ProjectOberon.pdf
by Claudio Nieder 08 Aug '13

08 Aug '13

Hi, > a monolith. One interesting aspect. If a module is unloaded > the linkages will be broken. Reloading must fix them again. If Module A depends on Module B then you would want Module A unloaded before you unload Module B exactly because of this reason. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch

1 0

Re: [Oberon] Project Oberon loader external reference methods
by peasthope＠shaw.ca 08 Aug '13

08 Aug '13

From: Paul Reed <paulreed(a)paddedcell.com> Date: Thu, 8 Aug 2013 12:32:43 +0100 > On the other hand, if the code merely refers to an entry in a table > maintained by the loader, the code itself doesn't need to be patched. > > The NS32032 had some fancy instructions and registers to support this > latter method. Such details I would hope might find their way into a Wiki document. > HTH Definitely; thanks! ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Re (2): ProjectOberon.pdf
by peasthope＠shaw.ca 08 Aug '13

08 Aug '13

From: Claudio Nieder <private(a)claudio.ch> Date: Thu, 8 Aug 2013 13:05:20 +0200 > Then once the linker has the proper address of B.P it will consult the fixup table ... So to my naive thinking, the fixup process appears as a "completion of compilation". After fixup the executable is a monolith. One interesting aspect. If a module is unloaded the linkages will be broken. Reloading must fix them again. > ... the linking table is a structure which needs to be kept > in RAM after loading ... In this case, unloading a module and reloading would be easier. Go through the table and update the entries pertaining to the module. Thanks! ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Project Oberon loader external reference methods
by Paul Reed 08 Aug '13

08 Aug '13

> Date: Wed, 7 Aug 2013 21:34:21 -0700 > From: peasthope(a)shaw.ca > Subject: [Oberon] ProjectOberon.pdf >> http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf > "1. External references are directly patched in the code. The object file > contains a list of the locations of > all external references. It is called the fixup list. > 2. A separate link table is provided with external references to be > converted. The actual references > within the program code directly refer to these table entries, and only > indirectly to the objects." > > I don't understand this. If each external reference is patched, why is > the > fixup list needed? Appears that the fixup list is equivalent to the link > table and the two cases are almost one. Hi Peter, If the code in the object file references other modules directly, it needs to be patched by the loader when the code is loaded into memory (e.g. a branch offset to a procedure in another module). On the other hand, if the code merely refers to an entry in a table maintained by the loader, the code itself doesn't need to be patched. The NS32032 had some fancy instructions and registers to support this latter method. HTH Paul

1 0

Re: [Oberon] ProjectOberon.pdf
by Claudio Nieder 08 Aug '13

08 Aug '13

Hi, > "1. External references are directly patched in the code. The object file contains a list of the locations of > all external references. It is called the fixup list. > 2. A separate link table is provided with external references to be converted. The actual references > within the program code directly refer to these table entries, and only indirectly to the objects." > > I don't understand this. If each external reference is patched, why is the > fixup list needed? Appears that the fixup list is equivalent to the link > table and the two cases are almost one. Not at all. Let's say in your code of Module A you need to call a procedure from another module B. CALL addressOfPinB Problem is, at compile time you do not know this addressOfPinB. In the link table approach (2) you would have a list of all external procedures, and in your code you would fetch the address from the link table and use an indirect call MOV linkTableEntryForBdotP,Register CALL (Register) so on linking only one entry in the link table would need to be fixed to point to B.P. On the other hand with the fixup list approach (1), you make direct calls, e.g. in the case of calling B.P twice in the Object file you would actually see this: CALL 00000000 ... more code ... CALL 00000000 Then once the linker has the proper address of B.P it will consult the fixup table which contain the address of all CALL statements and their targets to see where it needs to patch the code and convert in memory the above into CALL addressOfPinB ... more code ... CALL addressOfPinB So these are two fundamentally different approaches to performing the linking. For one the linking table is a structure which needs to be kept in RAM after loading and linking was performed while the fixup information can be discarded after the linking is done. Size wise e.g. if module A calls only one procedure of module B in ten different places then a linking table would need one entry only all 10 calls refer to the same entry, but a fixup table would require 10 entries because 10 CALL statements need to be fixed. BTW regarding my CALL 0000000 example. For fixup you need to know which CALL statements need to be fixed and with what procedure entry (e.g. B.P) it needs to be fixed. The latter information might be stored in the object file by abusing of the at that time not used address information and some Oberon (or was it Modula-2) compiler as far as I know would do that by writing CALL 00010007 to signify that the seventh procedure of the first referenced module is called. Thus the fixup table would only contain the address of the call statement while the target is encoded in the CALL statement itself. One more comment regarding the linking table approach(2). In Modula-2 compilers which used that approach you often had a two step indirection. A first table which represents the modules and a second table associated with each module that contains the address of the procedure. So calling a method would look like MOV modNo(BaseReg),Register ; BaseReg points to module table. Load procedure table for desired module into Register MOV procNo(Register),Register ; Fetch address of procedure into Register CALL (Register) claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch

1 0

ProjectOberon.pdf
by peasthope＠shaw.ca 08 Aug '13

08 Aug '13

>From chris at cfbsoftware.com Mon Apr 15 00:16:16 2013 > Read section 12.6 'Searching the symbol table, and symbol files' in Wirth's > 'Project Oberon' book for a thorough explanation. You will probably find the > answer to your other question there as well. > > http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf Thanks for the pointer. It's an excellent document and I've reached chapter 6. "1. External references are directly patched in the code. The object file contains a list of the locations of all external references. It is called the fixup list. 2. A separate link table is provided with external references to be converted. The actual references within the program code directly refer to these table entries, and only indirectly to the objects." I don't understand this. If each external reference is patched, why is the fixup list needed? Appears that the fixup list is equivalent to the link table and the two cases are almost one. However perfect a document is for knowledgeable readers there can be some details which are difficult for less expert readers. So I would hope that at some future time, ProjectOberon.pdf or parts of it at least, can be incorporated into the Oberon Wiki. This wouldn't detract from credit to the authors. With suitable acknowledgement it would certainly expand recognition of their work. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Edit acess to the Oberon wiki.
by Peter Easthope 02 Aug '13

02 Aug '13

Folk, A request for a passwrd to allow editing of the wiki produced this reply. ==== The following message to <ocp(a)inf.ethz.ch> was undeliverable. The reason for the problem: 5.1.0 - Unknown address error 550-'Callout verification failed:\n550 5.1.1 User unknown' ==== Ideas? Thanks, ... Peter E.

1 0