Dan Sugalski <[EMAIL PROTECTED]> wrote:
> "jsr " where is an immediate address rather than a register
> generates bad code.
C takes an absolute bytecode address, which IMHO never can be an
immediate integer. The op should be defined as jsr(invar INT).
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Runtime code generation works mostly, but for some reason the sequence
Another note: jsr/ret are not prepared to do inter-segment branches. A
compiled code segments is currently an entirely new packfile (it should
be only a new packfile directory finally
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> 'make all' failed at the target 'cola'. The reason was a 'cd ../imcc; make'.
Removed some more imcc trails.
> 'make test' failed at 'perl6.test'. For some reason 'perl/t/harness' returns an
> error 29, at least on my Linux notebook.
I don't have
Currently there is no simple way, to packout a Key that has number or
string key members. PackFile_Constant_pack() for PFC_KEY does a linear
lookup (find_in_const) to get at the index of the string or number in
the constant table. This is really ugly.
So I'd change that, so that key string/numb
I have generalized the hash a bit. There is now a variant that can C
strings as keys too.
But what I always wanted to know is: do we really need the HASH_ENTRY as
storage for hash items, or just PMCs as Array/PerlArray does? I think
that the entry adds some overhead (type + union = 3 or 4 words)
At 2:19 PM +0200 10/25/03, Leopold Toetsch wrote:
Currently there is no simple way, to packout a Key that has number
or string key members. PackFile_Constant_pack() for PFC_KEY does a
linear lookup (find_in_const) to get at the index of the string or
number in the constant table. This is really
At 10:10 AM +0200 10/25/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
"jsr " where is an immediate address rather than a register
generates bad code.
C takes an absolute bytecode address, which IMHO never can be an
immediate integer. The op should be defined as j
Okay, it's time to address this. It's damned useful to be able to
pass in initialization data to a PMC--much more sensible to do it all
in one go, rather than separate new/init methods. And, unfortunately
that's somewhat problematic at the moment, as there are all sorts of
reasonable ways to pa
On Monday, October 20, 2003, at 11:40 , Jeff Clites wrote:
My solution was to define a new vtable method--I've called it visit(),
though the name's not the important part--to which you pass a callback
(plus an optional context argument). It's job is to invoke that
callback on each of it's refer
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:10 AM +0200 10/25/03, Leopold Toetsch wrote:
> Oh, it certainly can be an absolute address, if you know what the
> address is when you're generating the code.
Did you ever try, what the assembler considers needing fixup: a
_non_local label. I don't
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The seconds assumes its
> parameters are in the registers, with standard calling conventions,
> and goes from there.
Seems to heavy to me. We already have init_pmc (taking one additional
initializer) and init_pmc_props, taking a NULL or real initializer PM
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 2:19 PM +0200 10/25/03, Leopold Toetsch wrote:
>>Currently there is no simple way, to packout a Key that has number
>>or string key members. PackFile_Constant_pack() for PFC_KEY does a
>>linear lookup (find_in_const) to get at the index of the string or
I am getting a seg fault when doing a very simple subroutine call with
IMCC:
.sub _main
newsub $P4, .Sub, _two_of
$P6 = new PerlHash
.pcc_begin prototyped
.arg $P6
.arg 14
.pcc_call $P4
after:
.pcc_end
13 matches
Mail list logo
