On Wed, 2005-05-04 at 01:51, Leopold Toetsch wrote: > Aaron Sherman wrote: > > On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote:
> > Here is some example P5 source from pp_pow in pp.c: > > I presume that Ponie eventually will run Parrot opcodes. pp_pow() is > like all these functions part of the perl runloop. Therefore it'll be > > infix .MMD_POW, P1, P2, P3 Sorry, I wasn't being clear with my example and the fact that it was just that. Yes, I understand that the opcode "pow" will become Parrot... well, at least I think I understand that, but I'm not 100% sure. There's some very hairy magic in pp.c and pp_hot.c that Perl code relies on, and in some places (e.g. pp_add), its behavior is not compatible with Parrot in some very fundamental ways (e.g. all addition is done as unsigned integers if/when possible to gain the overflow semantics of C8X uint, check the novella-length comments in pp.c for details). ALL THAT ASIDE, however, I did understand that the goal was not explicitly to leave pp_pow as it is. I was using it as an example of the kind of code that uses the Perl 5 core. XS, the Perl 5 runtime (e.g. the regexp engine), parser, etc. all rely on the same sort of constructs that I used pp_pow to outline. > > If you're writing a compiler from scratch, I can see that being mostly > > true. However, in trying to port Perl 5 guts over to Parrot, there's a > > lot of code that relies on knowing what's going on (e.g. if a value has > > ever been a number, etc.) > > Most of the guts are called from the runloop. But there is of course XS > code that messes with SV internals. Ignore code that "messes with SV internals". Code in many parts of the runtime that almost certainly won't be re-written use the SV interface provided by sv.h correctly, doing tons of flag tests all the time. Literally every operation requires several flag tests! -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
