Don't forget the so-called miniparrot, which must be built with ANSI C
only- no POSIX functions that aren't guaranteed in C89.
--Josh
At 22:48 on 06/11/2003 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > I've got a p6i backlog, so I don't kno
And I fully expect to get a few monster commit messages when this is
all done. Anyway, I've moved the registers out of the context struct,
and to the front of the interpreter struct, which is where they were
anyway, just indirectly. The non-JIT version compiles and builds just
fine (including I
I give warning since it's likely to break a lot of stuff. I'll try
and keep them in the same position in the interpreter structure, but
this'll probably break the JIT. (I expect a rather large CVS diff by
the time I'm done, though it may take a while...)
This'll probably get checked in tonight,
For reference:
*) We need to get Leo's concerns about string reusability dealt with.
(Which, strictly speaking, wasn't discussed but it's been hanging too
long) We're generating too many new strings. Fooey.
Dan in "Change to the calling convention, and other fallout from last
week's perl 6 meeting
My last attempt WRT this got warnocked, so I'll repeat and summarize
again the issue.
The PARROT_ARGDIR_{IN,OUT,INOUT} defines the directions of information
flow in and out of Parrot opcodes, for some definition of information.
You could also think of these as LHS-usage (OUT) and RHS-usage (IN)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:59 PM +0200 6/13/03, Leopold Toetsch wrote:
>> IMCC is a much bigger problem here.
> I'm not sure it does, or at least that it should. (Though if people
> play interesting games with register set swapping it could, I suppose)
Apart from such trick
