On Fri 05 Jun 2009 15:21, l...@gnu.org (Ludovic Courtès) writes:
Hello!
Andy Wingo wi...@pobox.com writes:
@deffn Instruction object-ref n
-Push @var{n}th value from the current program's object vector.
+...@deffnx Instruction long-object-ref n
+Push @var{n}th value from the current program's object vector. The
+``long'' variant has a 16-bit index instead of an 8-bit index.
@end deffn
Good that you fixed it! However, I'm wondering whether it's really a
good idea to keep both the long and short instruction variants, instead
of having a single 16-bit variant. What do you think?
The 8-bit cases are more common, leading to less code size, and
hopefully more cache hits. But see below...
+VM_DEFINE_INSTRUCTION (52, long_object_ref, long-object-ref, 2, 0, 1)
+{
+ unsigned int objnum = FETCH ();
+ objnum = 8;
+ objnum += FETCH ();
Perhaps a FETCH32() macro would actually be handy, and possibly more
efficient on platforms with 32-bit GP registers.
Actually, it would be even better if OBJNUM was encoded as part of the
instruction, since it would reside on the same cache line as the
instruction that's just been read. It'd look like:
#v+
objnum = ((* (ip - 1)) ~SCM_VM_INSTRUCTION_MASK)
SCM_VM_INSTRUCTION_MASK_LOG2;
#v-
Well, if you were to do this, you would want aligned, word-sized
instructions. This might be the right thing but I am not convinced, as
it would double or quadruple the size of the code, thus increasing cache
pressure. Java's bytecode is one byte in width, Lua's is too, Self's was
one byte wide, ... I don't know I guess is my perspective. I'd be
interested in checking this out, but it would take a few days, and I'm
trying to focus on broad correctness, then we could analyze such a
change with regards to benchmarks.
Also, I've forgotten about the details, but I was expecting one of the
fields in `scm_objcode' to become 16-bit after this change. Probably
I'm just confused? :-)
Yes you are confused :) The object table is stored in a Scheme vector.
Cheers,
Andy
--
http://wingolog.org/
