<div class="gmail_quote">On 28 October 2011 22:16, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com">dmitry.olsh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 28.10.2011 20:30, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi people.<br>
<br>
I'd like to propose support for taking the address of code labels, and<br>
supporting variable goto statements.<br>
This is a feature I have found extremely useful, implemented as a GCC<br>
specific extension.<br>
<br>
I've used this to get great speedups and simplify code while writing<br>
emulators/vm's. Perhaps also useful in efficient state machine type code<br>
too...<br>
<br>
</blockquote>
<br></div>
Yes, mostly efficient VMs. Maybe for JIT, though it would depend on some hacks.<br>
But custom made state machines usually do fixed jumps anyway.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Simple example:<br>
<br><div class="im">
void *opcodes[] = { &OP_ADDA, &OP_SUBA, &OP_MOVA, &OP_JMPA, &OP_etc... };<br>
<br>
</div></blockquote>
<br>
I gather this should be somewhere inside exec, or it will be *extremely* unsafe.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
void exec()<br>
{<br>
</blockquote>
<br>
i.e. :<br>
     enum opcodes[] = { ... };<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   // begin execution<br>
   goto opcodes[ pProgram[regs.PC++] ];<br>
<br>
OP_ADDA:<br>
   regs.A += pProgram[regs.PC++];<br>
   goto opcodes[ pProgram[regs.PC++] ];<br>
<br>
OP_SUBA:<br>
   regs.A -= pProgram[regs.PC++];<br>
   goto opcodes[ pProgram[regs.PC++] ];<br>
<br>
OP_MOVA:<br>
   regs.A = pProgram[regs.PC++];<br>
   goto opcodes[ pProgram[regs.PC++] ];<br>
<br>
OP_JMPA:<br>
   regs.PC = regs.A;<br>
   goto opcodes[ pProgram[regs.PC++] ];<br>
<br>
OP_etc:<br>
   ...<br>
   goto opcodes[ pProgram[PC++] ];<br>
}<br>
<br>
Notice how this structure completely eliminates branch logic, control<br>
statements, etc.<br>
</blockquote>
<br></div>
Yes, but you'd still have to check correctness, maybe before executing the whole VM program.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Note, GCC code labels are void*, but in D, perhaps some special code<br>
label pointer type should be invented for type safety...<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One may also expect that function pointers may also be implicitly cast<br>
to this generalised code pointer type, which might be useful in some<br>
code where a naked function pointer is used to implement some custom<br>
calling convention.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>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...?</div>
<div>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?</div><div><br></div><div>Anyway, I don't know the details of implementation, but it seemed simple to me in theory :)</div>
<div>Just thought I'd throw it out there.. I'd find this useful, as I have in the past on numerous occasions.</div></div>