> All --
>
> > I've created a varargs-ish example by making a new op, print_s_v.
> > This is pretty rough, and I haven't updated the assembler, but it
> > seems to work.
>
> Um.. I *have* updated the assembler. Its the *dis*assembler I haven't
> updated. This is what happens:
>
> * *_v ops list their number of args as 1 + the number of fixed
> args. They list the types of the fixed args, plus a last arg of 'v'.
>
> * The assembler sees all this and splices in an arg count for the
> 'v' arg place, and then hangs however many args remained on the
> line after the count.
>
> * The op decides how many args it is expecting. For print_s_v,
> that is via the format string (but really should take care to
> not read more than the "arg count" arg says are present.
>
> * Since the op is in control of returning the next address to
> execute, it is trivial for the op to arrange for excecution to
> continue after the last vararg (thanks, Dan!)
>
> * Since the assembler splices in the arg count, though, the
> disassembler won't have to think very hard to find the beginning
> of the next op when doing its job.
>
> * Of course, all this assumes that all args have sizeof() ==
> sizeof(IV), which won't be true until NV constants are moved to
> the constants area. SO DON'T USE THEM. :)
>
> Anyway, whether or not folks really like the idea of having ops with
> variable numbers of args, this proves its not too hard to do with a
> small amount of cooperation between the assembler and the op func.
With var-args, we could produce highly efficient SIMD instructions.
printf obviously, multi-push/pop, createArrays/ Hashes.
I toyed with the idea of a stack-based ALU to handle algebra such as:
( ( a + b*c ) / d + e ) / ( f + g + h )
// compute dest, "fmt", register-names
compute Rd, "++^*+/+", f, g, h, a, b, c, d, e
Unfortunately I couldn't find a way of garunteeing that it's efficient.
The best I've come up with so far is to use a mini-switch statement. The
only reason it might be faster than an optimized switch-statement over all
op-codes is that the switch has fewer terms.
The above case also gets complex if we don't use multiple registers for
intermediate calculations.
None the less the possibilities are cool.
-Michael
