Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] wrote: 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
Re: Loading up bytecode segments
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, perhaps the init code would add all the subs in a package to its namespace? Specifically, Cimport. Luke
Re: Loading up bytecode segments
On Wed, 24 Sep 2003, Leopold Toetsch wrote: 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. 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
Re: Loading up bytecode segments
On Wed, 24 Sep 2003, Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] 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, Cimport. Import does AFAIK need some params to be useful, so it has to be called explicitely. Which is fine. Dan
Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] wrote: 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
Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] wrote: 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
Loading up bytecode segments
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. Any objections, or shall I just make this happen? Dan
Re: Loading up bytecode segments
Dan Sugalski [EMAIL PROTECTED] 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. 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
Re: Loading up bytecode segments
At 11:13 PM +0200 9/23/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
