We noticed the same thing, and implemented a "macro" bytecode such
as you describe. The one wrinkle was that the ordinary push, push,
send +, pop sequence followed the macro bytecode. If either the receiver
or argument of + wasn't a small integer, it just went on to do the
normal send of +. But if the small integer addition was successful, then
it skipped the rest of the sequence.

As I recall (this was two years ago), it did yield a measurable
speedup--but only for almost trivial loops. Larger benchmarks hardly
showed any change.

I don't think this is a bad idea, but I think one would have to
apply the technique to a fairly broad range of common bytecode
sequences to see significant speedups on real code. However,
two things kept us from going further: (a) we're running low of
unused bytecodes to use for such accelerator bytecodes and
(b) Ian's new Jitter II promises to make such optimizations much
easier (as Dan said). Also, one would need to be sure the decompiler
and debugger understood the new bytecodes to make this "real".

On the other hand, it's possible that your variation might be an
improvement on mine, so if you'd like to experiment, I won't
try too hard to talk you out of it. After all, part of science
is having independent teams trying reproduce each other's
experimental results...

	-- John


>I've just seen that it takes 4 bytecodes to increment a small integer
>by 1, namely:
>
>26 <11> pushTemp: 1
>27 <76> pushConstant: 1
>28 <B0> send: +
>29 <69> popIntoTemp: 1
>
>Wouldn't it be better to have another kind of bytecode, say
>
>26 <F0> incrementTemp: 1 by: 1 "F0 is my guess for an unused bytecode"
>
>It would take two parameters stored in say the next 5 bytes, the first
>one the temp number and the second the value of such increment. In
>case of failure (overflow into the LargeIntegers), it would execute
><11> <76> <B0> <69>. Note that this bytecode would take care of
>incrementing and decrementing SmallIntegers because the second
>parameter can be a signed integer. And yes...
>
><F1> incrementTemp: x byTemp: y "with two extra parameter bytes"
>
><F0> and <F1> would replace expressions of the kind
>
>x _ x + y
>
>with
>
>x ++ y.
>
><F2> and <F3> could be #>> and #<<, which in case of failure will rely
>on the #bitShift: bytecode. Perhaps the Fx bytecode subset would be
>useful.
>
>Is this CISCish or C++-ish??? Or bad? :).
>Andres.
>
>PS: The Fx bytecode subset sounds good too!