accessing self in methods
Leopold Toetsch
It used to be:
1)
self."bar"()
where "self" automagically expanded to P2.
The current offical way is this sequence
2)
.include "interpinfo.pasm"
$P0 = interpinfo .INTERPINFO_CURRENT_OBJECT
$P0."bar"()
This two-liner looks a bit bulky compared to the old syntax.
I can imagine several ways to achieve the simplicity of 1) again, but
this needs some effort in code generation inside imcc.
As an intermediate step, I'm thinking of something like:
3)
.GET_SELF($P0)
This macro expands to the above two-liner and is defined internally.
A final and optimal solution would expand "self" to either a (re)fetch
into volatiles or non-volatiles, or depending on register allocation
pressure and usage to a fetch once and reuse this register.
Better solutions welcome,
leo
Dan Sugalski
>We should create some syntax to access the object in methods.
Well, there are two issues here.
First is in pasm/bytecode. For that, fetching things explicitly with
interpinfo is just fine, so the code sequence:
interpinfo P16, .INTERPINFO_CURRENT_OBJECT
works.
At the PIR level, self is just a special-case .local, so I don't see
much reason to do anything special there either -- the method tag on
the .sub declaration should be enough to tell the pir compiler that
it ought to go fetch the object into a register for use later on.
If you wanted to use this as a time to tie named .local declarations
to lexical pad slots and global names so the spilling code can
refetch spilled things from the pad/namespace rather than from a
private backing array, that'd be fine too. self would just spill in
from the interpreter info rather than a pad or namespace.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk