February 2018 - Oberon - mailman3.inf.ethz.ch

FPGA - Screen.Mod
by Tomas Kral 26 Oct '18

26 Oct '18

Hi, EDIT (1) I am looking for `Screen.Mod' module (mainly its `Screen.Grub' command) hinted in PO2013 pictures. I have completed early version of `Bitmaps.Mod' supporting basic set of raster operations. I wish to share pictures and code. As we may not post attachments to the forum, I could expose to GitHub, there is also `WikiBook' run by Lyall E. Please advise. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 15

FPGA Oberon - Definition Module Tool
by thomas.kral＠email.cz 08 Oct '18

08 Oct '18

Hi, I am thinking of a simple tool that could extract definition info from *.Mod and produce respective *.Def file. Definition files can be quickly looked at, to remind a programmer of the interface *.Mod modules export. While on Linux one could use grep $ grep PROCEDURE\ * *.Mod.txt to obtain info at least about procedures, but how about exported types and variables? I am looking for a recommended way how to simply code such a tool, is it a good idea to use `ORP' parser somehow for the task? I prefer to code it simple, does not have to be perfect, but should carry the idea. Tomas

5 11

WIP: Project Oberon / ARM Linux
by Peter Matthias 23 Mar '18

23 Mar '18

Hi all, an untested public version of PO/L is available at http://oberon.wikidot.com Regards, Peter

2 2

New complaint from Fox.
by peter＠easthope.ca 02 Mar '18

02 Mar '18

Fox in LinuxA2 Generic, rev.7600, gives this error when attempting to compile https://en.wikibooks.org/Oberon/Oberon.Sort.Mod . Oberon.Sort.Mod@5809 error: undeclared identifier (selector). Oberon.Sort.Mod error: Oberon-Sort could not be compiled (checker errors). (This Sort isn't exactly as in the A2 release. It is meant to sort Text in a Document viewer as well as in a Text viewer.) When compilation is invoked in PET, the complaint refers to D(Documents.Document).name. The first component of a Document is its name. So why the error? Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

Forward declarations of procedures in Oberon-07 on PO2013
by Andreas Pirklbauer 27 Feb '18

27 Feb '18

A PO2013 implementation of forward declarations of procedures (which have been removed from the language in the Oberon-07 revision) is at: http://github.com/andreaspirklbauer/Oberon-forward-declarations-of-procedur… This should make it possible to directly compare (the run-time performance) of nested procedures vs. procedure variables, e.g. in the compiler itself. I have more or less followed the overall approach of the Ceres implementation, but have made a number of different implementation decisions, in order to make calls to such procedures optimally efficient (only a single BL instruction is issued vs an external procedure call on Ceres) -ap

1 0

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 27 Feb '18

27 Feb '18

> 3) Procedure variables. In the compiler, this comes for free. ADDENDUM: Actually, on RISC (used in PO2013), the run-time overhead of calling a procedure VARIABLE p versus a procedure P is as follows: Calling a procedure P directly (assume P declared local to module M): BL -8 ; BL (i.e. branch using a 24bit offset as dest addr, modifier u = 0) Calling a procedure variable p: LDR SB R0 8 ; get static base (will be fixed up to 'LDR SB MT mno' by module loader) LDR R0 SB 0 ; R0 := M[SB] = value stored in procedure variable p BLEQ MT ; generate TRAP if it is zero BL R0 ; BLR (i.e. branch using a REGISTER as dest addr, modifier u = 1) For procedures whose body is large, this extra overhead may be viewed as negligible, but for short procedures it may be significant relative to the execution time of the (rest of the) procedure body. This would suggest that KEEPING procedure forward references in the language may have been worth considering (as their procedure calls are of course compiled into the same single BL instruction as for P). But they are inherently nasty to deal with in a compiler (which must check equality of headers, etc) which is why they have been eliminated. Andreas Test program: ============= MODULE M; VAR p: PROCEDURE; PROCEDURE P; BEGIN END P; BEGIN P; p END M. ORP.Compile M.Mod ~ ORTool.DecObj M.rsc ~ # code for procedure P (generated by ORP.ProcedureDecl) 0 4EE90004 SUB SP SP 4 1 AFE00000 STR LNK SP 0 2 8FE00000 LDR LNK SP 0 3 4EE80004 ADD SP SP 4 4 C700000F B LNK # module entry code (generated by ORG.Header) 5 4EE90004 SUB SP SP 4 6 AFE00000 STR LNK SP 0 # code for calling procedure P directly (offset -8, i.e. the BL branches to 0) 7 F7FFFFF8 BL -8 ; BL (i.e. branch using a 24bit offset as dest addr, modifier u = 0) # code for calling procedure *variable* p 8 8D000008 LDR SB R0 8 ; get static base (will be fixed up to 'LDR SB MT mno' by module loader) 9 80D00000 LDR R0 SB 0 ; R0 := M[SB] = value stored in procedure variable p 10 D1004C5C BLEQ MT ; generate TRAP if it is zero 11 D7000000 BL R0 ; BLR (i.e. branch using a REGISTER as dest addr, modifier u = 1) # module exit code (generated by ORG.Close) 12 8FE00000 LDR LNK SP 0 13 4EE80004 ADD SP SP 4 14 C700000F B LNK

4 4

Re: [Oberon] Intermediate scopes in Oberon-07
by Артур Ефимов 26 Feb '18

26 Feb '18

Diego Sardina wrote: > In the past I never saw procedure variables as a solution for circular reference, but at this point I prefer forward reference. > Also they don't really come for free especially in runtime, it is another level of indirection and they prevent the compiler to inline them. T he compiler can't inline these procedures anyway, as they are involved in recursion (and thus have to be forward-referenced in some way). I'm using procedure variables in my Oberon compiler, like N. Wirth does in Project Oberon. Didn't think about nesting all of these procedures inside Expression. By the way, does anybody know why in NW's compiler procedures "expression0", " qualident ", "selector", "element", "set", "factor", "term" (but not "SimpleExpression" for example) start from a small letter?

3 2

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 26 Feb '18

26 Feb '18

> > How shall it be, if a nested procedure can only access its own > > parameters and local stuff? No access to outer scopes! > > > That is not correct. Nested procedures can still access global variables. I think he just meant to say “no outer scopes except the global one"

2 1

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 25 Feb '18

25 Feb '18

> How shall it be, if a nested procedure can only access > its own parameters and local stuff? No access to outer scopes! > ... > Yours sincerely, > Srinivas Nayak Yes, one can of course always TRY to use NESTING (with the above restrictions, i.e. with no access to intermediate objects) to eliminate forward references, instead of using PROCEDURE VARIABLES. However, nesting cannot be used in all cases. As outlined in http://people.inf.ethz.ch/wirth/Oberon/PortingOberon.pdf nesting can ONLY be used IF all nested procedures are ONLY called from within the OTHER nested procedures. For example, in module ORP of the compiler itself, this is just not the case. Try it, i.e. start rewriting ORP... PROCEDURE expression(VAR x: ORG.Item); PROCEDURE SimpleExpression(VAR x: ORG.Item); PROCEDURE term(VAR x: ORG.Item); PROCEDURE factor(VAR x: ORG.Item); (*call expression here*) but THEN you see that can’t simply also move procedure ‘selector’ (which is both called by ‘factor' and itself calls ‘expression’) inside the innermost scope (=scope of ‘factor’), simply because procedure ’selector' is ALSO used OUTSIDE the above nested construct, namely in procedure ‘ORP.StatSequence'. So in THIS particular case one cannot use NESTING to eliminate the forward references (at least not in a straightforward way), but one HAS to use installed procedures instead (as is in fact done in the current implementation of ORP). Of course, if forward declarations of procedures WERE still allowed in the Oberon language, one could use THEM (and wouldn’t need any nesting at all). This would also come with faster procedure activations, as shown in an earlier post. But forward declarations of procedures were removed in Oberon-07 in 2007, so this is not an option here. So we are down to 2 options for ORP: a) nesting (which however is not possible in this case) b) procedure variables (=the current implementation) Andreas

1 0

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 25 Feb '18

25 Feb '18

> > Can you point to an example in Project Oberon 2013 which > > clearly illustrates what you mean by 'it may make assumptions > > which only make sense in the context of the caller'. > > > Sorry, don't know the Project Oberon source by heart. ;) Well, since access to intermediate objects (constants, types, variables) is now no longer allowed since the most recent (2016) change to the Oberon language spec, there cannot really be ANY assumptions anymore which ONLY make sense in the context of the caller ... since the “context” itself can no longer be accessed ;-) The only remaining POSSIBLE assumption would therefore have to be something that specifically has to do with the way the CODE of the surrounding code is implemented. Of the 17 local procedures (of 850 total) in the Oberon system, I have not found one that meets that description.

4 7