At 10:23 PM 6/1/2002 -0700, Brent Dax wrote: >Melvin Smith: ># Native Extensions for Parrot: ># ># Rather than talk about it at length and not get any code ># done, I decided, concerning the native extension interface, ># to just take a simple hello world approach with some outside library. > >I would normally agree with this sentiment, except that XS is externally >visible. That means that it can only change very slowly, so it has to >be more or less right from the start.
It can change very fast when its brand new. Anyone writing extensions in the near future must be prepared to have the rug snatched... :) Consider we don't even have symbol tables and several other important constructs yet. > -We don't use the stack that way. Arguments are supposed to come in >as an array PMC. Fair enough, thats my C background coming out. You are lucky I didn't commit my native assembly routine that copied the Parrot stack to the C stack. :) Dan already said that was probably too unportable. > -Macros suck. :^) Bah. The macro is only defining a signature, not chaining to another call that you have to track down. But, ideally, I think we want a preprocessor anyway, that was just to make it look neat and readable. > -How are you going to load a .dll instead of a .so on Windows when the >.so is hardcoded in? I knew that when I put it in, but was too lazy to bother. Thats an easy thing to take care of. > -callnative is the wrong way to do it. What we need is a subroutine >PMC and a call vtable method. Hmm. I was sort of thinking the same thing, where the PMC is the "class". That way we can have different calling conventions, etc. I've got a few more ideas, such as saving a stack marker just in case the native method munges we can recover, as well as caching the subroutine references as they are called. I'll take these suggestions and twiddle with it some more. Thanks! -Melvin
