Loading up bytecode segments
Dan Sugalski
have is those segments automatically running, something I think we need to
have happen.
When a bytecode segment is loaded, control should pass to the first
executable instruction in it, and proceed until it hits an end. (I can see
making this a ret instead) This seems simpler than having some sort of
magic label, and will allow loaded bytecode segments to initialize
themselves if that's what they need.
Any objections, or shall I just make this happen?
Dan
Leopold Toetsch
But how to pass arguments then? Init code might need some.
> Any objections, or shall I just make this happen?
I think a more flexible way is a "magic label", or just "__init" which
can be called explictely or even automatic - if such a label exists.
> Dan
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> I see we've got dynamically loaded bytecode segments. Good. What we don't
>> have is those segments automatically running, something I think we need to
>> have happen.
>
>> When a bytecode segment is loaded, control should pass to the first
>> executable instruction in it, and proceed until it hits an end. (I can see
>> making this a ret instead) This seems simpler than having some sort of
>> magic label, and will allow loaded bytecode segments to initialize
>> themselves if that's what they need.
>
>But how to pass arguments then? Init code might need some.
What arguments, though? This is just a chance to give the segment an
initialization run, nothing more.
> > Any objections, or shall I just make this happen?
>
>I think a more flexible way is a "magic label", or just "__init" which
>can be called explictely or even automatic - if such a label exists.
Ick. No magic labels like that. I'd rather set it so we start
executing at the beginning with some set parameters or something, and
for segments with no initialization they can just ret back out or
something. (I'm not sure full-on calling conventions are required
here, but then I'm not sure they aren't either)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
[ autorun of loaded byte code ]
>>But how to pass arguments then? Init code might need some.
> What arguments, though? This is just a chance to give the segment an
> initialization run, nothing more.
I don't. I don't know, what the autorun should initialize. Do you have
examples, what is/will be accomplished in the init "sub".
>> > Any objections, or shall I just make this happen?
>>
>>I think a more flexible way is a "magic label", or just "__init" which
>>can be called explictely or even automatic - if such a label exists.
> Ick. No magic labels like that. I'd rather set it so we start
> executing at the beginning with some set parameters or something, and
> for segments with no initialization they can just ret back out or
> something. (I'm not sure full-on calling conventions are required
> here, but then I'm not sure they aren't either)
Why calling conventions if there are no parameter to pass in/out :-)
Ok, the init code must return, so either "ret" or "invoke P1". But if
there is nothing to be done for init, this is just wasting cycles and
resources.
I don't see, why we shouldn't use a scheme like done in dlopen(3):
,--[ dlopen(3) ]---------------------------------------------------
| If the library exports a routine named _init, then that
| code is executed before dlopen returns.
`------------------------------------------------------------------
We can reserve all uppercase labels for such tasks.
WRT magical symbols. It was already discussed (and I'm leaning to that),
that the main entry to start execution is labeled "_main". (The register
allocator should know, if a subroutine or main is called - at the very
beginning all registers are clear and initialized. This allowes to emit
unitialized warnings and better life analysis of registers.)
leo
Luke Palmer
> I don't. I don't know, what the autorun should initialize. Do you have
> examples, what is/will be accomplished in the init "sub".
Considering that subs have to be manually inserted into the symbol
table, perhaps the init code would add all the subs in a package to its
namespace? Specifically, C<import>.
Luke
Leopold Toetsch
> Leopold Toetsch writes:
>> I don't. I don't know, what the autorun should initialize. Do you have
>> examples, what is/will be accomplished in the init "sub".
> Considering that subs have to be manually inserted into the symbol
> table,
.pcc_sub symbols automatically get entered into the global stash. The
lexer should probably allow '::' as a valid symbol char though.
> ... perhaps the init code would add all the subs in a package to its
> namespace? Specifically, C<import>.
Import does AFAIK need some params to be useful, so it has to be called
explicitely.
> Luke
leo
Dan Sugalski
> Dan Sugalski <d...@sidhe.org> wrote:
>
> [ autorun of loaded byte code ]
>
> >>But how to pass arguments then? Init code might need some.
>
> > What arguments, though? This is just a chance to give the segment an
> > initialization run, nothing more.
>
> I don't. I don't know, what the autorun should initialize. Do you have
> examples, what is/will be accomplished in the init "sub".
The case that's triggering it for me is that I've got a library that I'm
loading up that does a lot of active initialization, but nothing else. (It
wraps the ncurses library) I want the thing to run when I load it so it
can install its symbols and then return back to the caller, having done
its thing.
> >> > Any objections, or shall I just make this happen?
> >>
> >>I think a more flexible way is a "magic label", or just "__init" which
> >>can be called explictely or even automatic - if such a label exists.
>
> > Ick. No magic labels like that. I'd rather set it so we start
> > executing at the beginning with some set parameters or something, and
> > for segments with no initialization they can just ret back out or
> > something. (I'm not sure full-on calling conventions are required
> > here, but then I'm not sure they aren't either)
>
> Why calling conventions if there are no parameter to pass in/out :-)
That's a good point -- okay, no parameters, you've convinced me! :-P
> Ok, the init code must return, so either "ret" or "invoke P1". But if
> there is nothing to be done for init, this is just wasting cycles and
> resources.
No, it isn't, not compared to the label check and dispatch. Either way
there's a cost, as we're either unconditionally dispatching then
returning, or we're scanning through the fixup sybol list for _init. (Or
we're burning cycles on each symbol as we resolve it at load time)
Given that we load each segment exactly once, I don't care that much about
the time any scheme takes, which means my dislike for magic labels takes
precedence. I'd be OK with a field in the segment header that marks the
offset of the init code, with a -1 meaning there is none. I think we can
live with the init code having to be in the first 2G of any code segment.
:)
> WRT magical symbols. It was already discussed (and I'm leaning to that),
> that the main entry to start execution is labeled "_main". (The register
> allocator should know, if a subroutine or main is called - at the very
> beginning all registers are clear and initialized. This allowes to emit
> unitialized warnings and better life analysis of registers.)
No, I don't think so. The languages we're targeting don't have a magic
function name that marks the start of execution--they just start at the
beginning and go.
Hrm. That does mean that we may want two entry points for a segment, the
init point and the run point. For perl, the two are the same, but for a
language like C they'd be different. I still dislike magic names, so I'd
prefer slots in the header. (Or, if we really, *really* must, attributes
on labels, but that seems like real overkill)
Dan
Dan Sugalski
> Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> > Leopold Toetsch writes:
> >> I don't. I don't know, what the autorun should initialize. Do you have
> >> examples, what is/will be accomplished in the init "sub".
>
> > Considering that subs have to be manually inserted into the symbol
> > table,
>
> .pcc_sub symbols automatically get entered into the global stash. The
> lexer should probably allow '::' as a valid symbol char though.
We need to get some of this moved down into the base assembler as well.
> > ... perhaps the init code would add all the subs in a package to its
> > namespace? Specifically, C<import>.
>
> Import does AFAIK need some params to be useful, so it has to be called
> explicitely.
Which is fine.
Dan
Leopold Toetsch
> On Wed, 24 Sep 2003, Leopold Toetsch wrote:
>> .pcc_sub symbols automatically get entered into the global stash. The
>> lexer should probably allow '::' as a valid symbol char though.
> We need to get some of this moved down into the base assembler as well.
The somewhere mentioned ".Sub _label" directive? Wouldn't be to
complicated to implement it for PASM mode.
> Dan
leo
Leopold Toetsch
> Hrm. That does mean that we may want two entry points for a segment, the
> init point and the run point. For perl, the two are the same, but for a
> language like C they'd be different. I still dislike magic names, so I'd
> prefer slots in the header. (Or, if we really, *really* must, attributes
> on labels, but that seems like real overkill)
Two magic labels or some meta information that do they same are both
fine for me.
> Dan
leo
Leopold Toetsch
> On Wed, 24 Sep 2003, Leopold Toetsch wrote:
>> .pcc_sub symbols automatically get entered into the global stash.
> We need to get some of this moved down into the base assembler as well.
Done.
$ perldoc /docs/pmc/sub.pod
> Dan
leo