On 28 October 2011 22:16, Dmitry Olshansky <dmitry.o...@gmail.com> wrote:
> On 28.10.2011 20:30, Manu wrote:
>
>> Hi people.
>>
>> I'd like to propose support for taking the address of code labels, and
>> supporting variable goto statements.
>> This is a feature I have found extremely useful, implemented as a GCC
>> specific extension.
>>
>> I've used this to get great speedups and simplify code while writing
>> emulators/vm's. Perhaps also useful in efficient state machine type code
>> too...
>>
>>
> Yes, mostly efficient VMs. Maybe for JIT, though it would depend on some
> hacks.
> But custom made state machines usually do fixed jumps anyway.
>
>
>> Simple example:
>>
>> void *opcodes[] = { &OP_ADDA, &OP_SUBA, &OP_MOVA, &OP_JMPA, &OP_etc... };
>>
>>
> I gather this should be somewhere inside exec, or it will be *extremely*
> unsafe.
>
> void exec()
>> {
>>
>
> i.e. :
> enum opcodes[] = { ... };
>
>
> // begin execution
>> goto opcodes[ pProgram[regs.PC++] ];
>>
>> OP_ADDA:
>> regs.A += pProgram[regs.PC++];
>> goto opcodes[ pProgram[regs.PC++] ];
>>
>> OP_SUBA:
>> regs.A -= pProgram[regs.PC++];
>> goto opcodes[ pProgram[regs.PC++] ];
>>
>> OP_MOVA:
>> regs.A = pProgram[regs.PC++];
>> goto opcodes[ pProgram[regs.PC++] ];
>>
>> OP_JMPA:
>> regs.PC = regs.A;
>> goto opcodes[ pProgram[regs.PC++] ];
>>
>> OP_etc:
>> ...
>> goto opcodes[ pProgram[PC++] ];
>> }
>>
>> Notice how this structure completely eliminates branch logic, control
>> statements, etc.
>>
>
> Yes, but you'd still have to check correctness, maybe before executing the
> whole VM program.
>
>
>
>> Note, GCC code labels are void*, but in D, perhaps some special code
>> label pointer type should be invented for type safety...
>>
>
> Or just call them void function(void), there are cases where jumping to
> function is OK. It's some pretty low-level stuff, that most people do in
> assembly though.
>
>
> One may also expect that function pointers may also be implicitly cast
>> to this generalised code pointer type, which might be useful in some
>> code where a naked function pointer is used to implement some custom
>> calling convention.
>>
>
> Overall, I'd personally welcome this kind of extension, but it's should be
> doable in inline asm even today, which somewhat diminishes it's impact. The
> advantage of computed gotos compared to asm is portability, the disadvantage
> is complicating backend for a special case.
Regarding your points about my example, I agree re the scope of my array, it
was just a 2 second example. I would expect a D implementation to be more
strict (probably with regard to scope/etc), and typesafe as I suggested.
And you nailed it, probably is do-able in asm (although I can't think of a
way to produce an array of code addresses?), but this syntax is portable.
How would it complicate the backend an awful lot? The ability to goto to a
variable? I would have though this would be quite trivial. It should surely
be just about as easy to take a variable rather than an immediate target...?
The ability to assign the address of a code label to a const variable can't
be any more difficult than assigning it as the constant target of a goto?
Anyway, I don't know the details of implementation, but it seemed simple to
me in theory :)
Just thought I'd throw it out there.. I'd find this useful, as I have in the
past on numerous occasions.
