Dan Sugalski wrote:
At 1:30 PM +0100 1/6/03, Leopold Toetsch wrote:
1) for linear access half sized PMCs give double mark speed. This is
in good relation to stress.pasm
... A region of the PMC pool that's entirely mark area would
up the cache density by a factor of three or four.
s/three
Dear fellow hackers,
the "C" disassembler is crashing :
mdupont@introspector:~/development/parrot/parrot$ ./disassemble
t/pmc/sub_1.pbc
disassemble: debug.c:1055: PDB_disassemble_op: Assertion `size + 20 <
space' failed.
Aborted
And the perl dissambler works !
I have been looking into and it
At 1:30 PM +0100 1/6/03, Leopold Toetsch wrote:
Attached test program shows some additional effects of PMC size and
timing. A PMC is 32 byte, a SPMC is 16 byte, matching current and
minimal PMC sizes for i386 (or a typical 32 bit system).
1) for linear access half sized PMCs give double mark spe
At 11:00 AM +0530 1/6/03, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
>> Why would we want to avoid this? It looks exactly like what ought to
>> happen.
If you can provide that in-vm , it would be a lot faster ...(hmm, that's
one argument that should convince you ;)
Stru
first of all :
to run this, it needs a -I.
second of all, the test has errors
the Perl6grammar.pm did not return a true value at (eval 58) line 3.
can be ignored, because via some magic, it is regenerated.
I get the following error
>>WHOA! Somehow you got a different number of results than test
Attached test program shows some additional effects of PMC size and
timing. A PMC is 32 byte, a SPMC is 16 byte, matching current and
minimal PMC sizes for i386 (or a typical 32 bit system).
1) for linear access half sized PMCs give double mark speed. This is
in good relation to stress.pasm
2) A
