On Thu, Apr 18, 2002 at 03:24:58PM +1000, Andrew J Bromage wrote:
> G'day all.
>
> This patch introduces a new op parameter type "inconst", which is like
> "in" except that it only produces const versions of the op (i.e. it
> will not take values from registers).
Should it be all one keyword, or should 'const' be an orthogonal
modifier? ("inconst INT" vs "in const INT"/"const in INT") Though that
conflicts with the c/c++ meaning of "const".
> This is mostly for the benefit of branch targets. The "feature" of
> using register values as branch targets can safely be eliminated
> because:
>
> - Nobody uses it.
Allow me to introduce myself. I'm nobody. :-)
I used it for a regex backtracking stack. I kept a stack of addresses,
independent from the regular return address stack, and popped things
off into registers and then branched to them.
I don't do this anymore, but it doesn't seem like a ridiculous idea.
(And I remember having to go through and make goto ADDRESS work
everywhere, because the only other op that used it was enternative and
nobody notices when it's broken...)
> - Nobody is likely to use it any time soon.
I will be implementing jump tables in the regex compiler soonish.
Register destinations may (or may not) make that easier.
> - In the rare event that you may want to use it, you could
> always branch to a jump_i op.
Doesn't sound awful to me.
I like the shrinkage in the _ops.c files.
> - None of the JIT ports implement it. This will save work.
As long as my JITed jumptables are fast.
> - It is in general impossible for an optimizer to determine
> where the branch targets are if you allow registers as
> branch targets. Even when it's possible, it's too hard.
This reminds me of when this is necessary. How will we be calling
methods? We'll be looking up some kind of code address by index or
name and putting it into a register. (jump_i sounds plausible for
this.)
The optimizer argument only matters when register addresses are
actually used. If you're right and nobody ever uses it, then the
optimizer doesn't care. When it is used, it's just as hard for the
optimizer to deal with
unless P0, $REG_BRANCH_1
...
$REG_BRANCH_1:
jump I0
as it would be to deal with 'unless P0, I0', no?
> - Eliminating it speeds up life.pasm by about 5-10% according
> to my highly unscientific benchmark.
Something's fishy with that. If deleting unused code gives that much
of a speedup, then the speedup will probably disappear when we add a
few more ops, and reappear when we randomly reorder instructions or
run on a Wednesday.
