G'day all.
On Fri, Apr 19, 2002 at 01:08:46PM -0700, Steve Fink wrote:
> Should it be all one keyword, or should 'const' be an orthogonal
> modifier?
IMO, one modifier, because "const" doesn't make sense on any direction
but "in".
> > - 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.
I think a dedicated dense switch op (and a corresponding sparse switch
op) might be a better solution. Otherwise, jump tables need arrays,
and PMC arrays seem like overkill.
The problem with switch ops is that either you need a variable number
of arguments, or you need to put the switch arms somewhere else.
Probably the const table is the sanest place, but then you need to come
up with an assembler syntax and an automatic way to generate it from
the ops file.
> 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.)
Or jsr_i even.
The JVM solution is to have a dedicated method call op, which is a great
idea in principle, but may not work with everyone's object model.
> 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?
The problem is that when you use a register branch target anywhere, it
means the entire _module_ can't have simple optimization done, because
a branch could potentially go anywhere.
I think the problem could be fixed with some semantic constraints. For
example:
- No jumps between subs except through the sub's entry point
are allowed.
- jump_i and jsr_i (plus maybe some others not yet written) are
the only instructions which can branch to register targets.
They take absolute addresses, not relative ones.
- There are only a limited number of ways to generate an
absolute address, such as:
- Returned from a call.
- Vtable method lookup.
- A special op which turns a relative address (which
must be const) into an absolute address.
Any attempt to call an absolute address which was not
generated in one of these documented ways (e.g. by performing
some computation) results in undefined behaviour.
Cheers,
Andrew Bromage
