[Oberon] Intermediate scopes in Oberon-07

Srinivas Nayak sinu.nayak2001 at gmail.com
Tue Feb 27 18:18:54 CET 2018


Since nobody is talking about this,
shall I assume, this is completely irrational?
Not as simple as possible?


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 02/25/2018 10:34 PM, Srinivas Nayak wrote:
> Dear All,
>
> How shall it be, if a nested procedure
> can only access its own parameters and local stuff?
> No access to outer scopes, no access to globals!
>
> Will it not be good and simple?
>
>
> With thanks and best regards,
>
> Yours sincerely,
> Srinivas Nayak
>
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
>
> On 02/25/2018 05:57 PM, Andreas Pirklbauer wrote:
>>   > 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
>>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>


More information about the Oberon mailing list