core.ops / vtable: keyed_int
Leopold Toetsch
vtable methods are defined to take a KEY* value instead of a plain
INTVAL value?
This causes an (IMHO) unneeded test for a NULL key, a stack variable for
the key and prohibits JIT code to pass a processor register directly,
when the integer register is MAPed.
leo
Tom Hughes
Leopold Toetsch <l...@toetsch.at> wrote:
> Is there any compelling reason, why the {get,set}_<type>_keyed_int
> vtable methods are defined to take a KEY* value instead of a plain
> INTVAL value?
They aren't are they? As far as I can see they are INTVAL* values...
> This causes an (IMHO) unneeded test for a NULL key, a stack variable
> for the key and prohibits JIT code to pass a processor register
> directly, when the integer register is MAPed.
If you're asking why they are INTVAL* rather than INTVAL then I had
thought the answer was to allow support of multi-level keys, but that
doesn't actually seem to be the case. I can only assume that the
original reason was to support multi-level keys though.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu
Juergen Boemmels
> Is there any compelling reason, why the {get,set}_<type>_keyed_int
> vtable methods are defined to take a KEY* value instead of a plain
> INTVAL value?
IIRC, to support operations like
add P0[7], P1, P2[0]
without the need of 8 diffrent vtable entries, they are passed as
INTVAL *. In the functions with only one keyed element this is for
symetry reasons.
> This causes an (IMHO) unneeded test for a NULL key, a stack variable
> for the key and prohibits JIT code to pass a processor register
> directly, when the integer register is MAPed.
Remove the functions add_keyed_int and friends which have more than
one keyed item, and use only the simple keyed functions. They must
handle integers as well to support
add P0[7], P1, P2["foo"]
so the overhead in this would be the KEY* construction.
For functions with only one keyed integer argument use _keyed_int
function which takes an INTVAL argument.
The problem is the set_pmc_keyed_int where are 2 PMC elements and so 2
INTVAL *. This will leave 4 cases:
set P0, P1 # handled by get_pmc()
set P0, P1[I0] # handled by get_pmc_keyed_int(P1, I0)
set P0[I0], P1 # set_pmc_keyed_int (I0, P1, NULL)
set P0[I0], P1[I1] # set_pmc_keyed_int (I0, P1, I1)
So only the later two versions use set_pmc_keyed_int, and only the
last argument is not know for sure if its zero or non-zero. Of this
later two the first one is IMHO the more common one so use this with
set_pmc_keyed_int and use set_pmc_keyed for the last one.
bye
boe.
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Leopold Toetsch
> In message <3E4B76E8...@toetsch.at>
> Leopold Toetsch <l...@toetsch.at> wrote:
>
>
>>Is there any compelling reason, why the {get,set}_<type>_keyed_int
>>vtable methods are defined to take a KEY* value instead of a plain
>>INTVAL value?
>>
>
> They aren't are they? As far as I can see they are INTVAL* values...
Argh, typo, of course INTVAL*.
>>This causes an (IMHO) unneeded test for a NULL key, a stack variable
>>for the key and prohibits JIT code to pass a processor register
>>directly, when the integer register is MAPed.
> If you're asking why they are INTVAL* rather than INTVAL then I had
> thought the answer was to allow support of multi-level keys, but that
> doesn't actually seem to be the case. I can only assume that the
> original reason was to support multi-level keys though.
Probably. Multilevel keys are done with the _keyed variants which take a
(Key) *PMC.
The _keyed_int methods are INTVAL only.
> Tom
leo
Leopold Toetsch
> Leopold Toetsch <l...@toetsch.at> writes:
>
>
>>Is there any compelling reason, why the {get,set}_<type>_keyed_int
>>vtable methods are defined to take a KEY* value instead of a plain
>>INTVAL value?
>>
>
> IIRC, to support operations like
> add P0[7], P1, P2[0]
We can't do these multi_keyed ops in that way. They would need ~64 times
the opcodes we currently have. Please read my RFC WRT multi_keyed ops.
There is already a hook in imcc to do these multi_keyed ops in a
different way - but this is really not tested.
I still prefer a special B<key> opcode, which does keyed argument fetch
and store.
With a 64K op code count all code locality and cache coherency would be
history and performance would really suck.
> without the need of 8 diffrent vtable entries,
The vtable entries are really not the primary problem - or at least not
until now, where we only have statically allocated vtables. When objects
emerge, this might as well be a problem. But I dunno, if the vtable
slots may be changed or if a lookup is done.
>
> bye
> boe.
>