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