I recently got my hands on money for an upgrade, and got an AMD64 and
motherboard and installed them. I'm still using 32-bit Windows, but
I've also installed a 64-bit Gentoo on some previously unpartitioned
space.
Initially, Parrot didn't build. Fortunately, the error message was
helpful[1]; I
On Oct 29, 2004, at 11:29 PM, Brent 'Dax' Royal-Gordon wrote:
I recently got my hands on money for an upgrade, and got an AMD64 and
motherboard and installed them. I'm still using 32-bit Windows, but
I've also installed a 64-bit Gentoo on some previously unpartitioned
space.
...
Failed Test
A first patch is in CVS. Imcc now understands the syntax:
set_p_pc P0, 0 # load PMC constant no. 0
The explicit arguments are necessary to disambiguate
set P0, 0 # assign integer 0 to P0
This isn't much useful per se, as a compiler/you doesn't know the
constant index of a PMC
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote:
classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most
of the actual code is in lib/Parrot/Pmc2c.pm.
The created C code could need some improvements:
Can I add a fourth
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
... We could probably do something very clever to abstract it,
like load all the constants into a reserved, dynamically-sized set of
registers starting at [INSP]32.
That doesn't work. Registers are accessed per interpreter/thread and now
per
Ok, next is committed. The existing constant syntax is extended:
.const pmc_enum var_or_ident = initstring
Currently only subroutine constants are supported, e.g.
.const .Sub $P0 = foo
.const .Sub func = foo
The actual opcode emitted is sub_p_pc with the index of the subroutine
constant
On Oct 30, 2004, at 12:58 AM, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote:
* The created C code could benefit from #line directives to track
where
C code came from the input .pmc file, so that compiler errors
On Fri, Oct 29, 2004 at 05:19:35PM +0200, Leopold Toetsch wrote:
The method_lookup doesn't have a vtable indirection. And having a direct
array lookup doesn't really scale. So the actual code is a bit more
complicated (and in no way optimized).
Something that just struck me reading this whole
