[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