Dan Sugalski <[EMAIL PROTECTED]> 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".

>>  > 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

Reply via email to