On 6/1/13 9:49 PM, Walter Bright wrote:
> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote:
>> On 01-06-2013 09:59, bearophile wrote:
>>> "Recently" the Python C interpreter was modified and speed up thanks to
>>> this non-standard feature. CPython source code has two versions, one
>>> with computed gotos and one without, to compile it even if your C
>>> compiler doesn't support them or their GNU-C syntax.
>>
>> I don't think there's any question as to the usefulness (and essentialness) of
>> this feature. I'm very close to just writing most of the interpreter in C over a
>> triviality like this.
>
> To be pedantic, C and C++ don't have that feature. Some compilers add it as an extension.
>
> Also, such a construct could not be made @safe. The trouble is you could pass those addresses
> anywhere, and goto them from anywhere.

While you're technically correct, every major compiler in the unix world support it with the same syntax.  It's entered into defacto standard status.

Am 02.06.2013 09:25, schrieb Brad Roberts:
> On 6/1/13 9:49 PM, Walter Bright wrote:
>> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote:
>>> On 01-06-2013 09:59, bearophile wrote:
>>>> "Recently" the Python C interpreter was modified and speed up thanks to
>>>> this non-standard feature. CPython source code has two versions, one
>>>> with computed gotos and one without, to compile it even if your C
>>>> compiler doesn't support them or their GNU-C syntax.
>>>
>>> I don't think there's any question as to the usefulness (and
>>> essentialness) of
>>> this feature. I'm very close to just writing most of the interpreter
>>> in C over a
>>> triviality like this.
>>
>> To be pedantic, C and C++ don't have that feature. Some compilers add
>> it as an extension.
>>
>> Also, such a construct could not be made @safe. The trouble is you
>> could pass those addresses
>> anywhere, and goto them from anywhere.
>
> While you're technically correct, every major compiler in the unix world
> support it with the same syntax.  It's entered into defacto standard
> status.

If your world is only UNIX then yeah, there are still lots of non UNIX os out there if you look outside the desktop computers.

Of course, one could always question if they matter at all.

On 6/2/13 12:33 AM, Paulo Pinto wrote:
> Am 02.06.2013 09:25, schrieb Brad Roberts:
>> On 6/1/13 9:49 PM, Walter Bright wrote:
>>> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote:
>>>> On 01-06-2013 09:59, bearophile wrote:
>>>>> "Recently" the Python C interpreter was modified and speed up thanks to
>>>>> this non-standard feature. CPython source code has two versions, one
>>>>> with computed gotos and one without, to compile it even if your C
>>>>> compiler doesn't support them or their GNU-C syntax.
>>>>
>>>> I don't think there's any question as to the usefulness (and
>>>> essentialness) of
>>>> this feature. I'm very close to just writing most of the interpreter
>>>> in C over a
>>>> triviality like this.
>>>
>>> To be pedantic, C and C++ don't have that feature. Some compilers add
>>> it as an extension.
>>>
>>> Also, such a construct could not be made @safe. The trouble is you
>>> could pass those addresses
>>> anywhere, and goto them from anywhere.
>>
>> While you're technically correct, every major compiler in the unix world
>> support it with the same syntax.  It's entered into defacto standard
>> status.
>
> If your world is only UNIX then yeah, there are still lots of non UNIX os out there if you look
> outside the desktop computers.
>
> Of course, one could always question if they matter at all.

I agree.  I said unix primarily to mean most except for msvc.

Many if not most of those non-unix platforms use gcc, which is included in the set of compilers that does support it.  The point is, which you didn't change, is that's it's a defacto standard even if not technically in the c or c++ language specs.

01-Jun-2013 20:13, Timon Gehr пишет:
> On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote:
>> Hi,
>>
>> I'm sure this has been brought up before, but I feel I need to bring it
>> up again (because I'm going to be writing a threaded-code interpreter):
>> http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>>
>> This is an incredibly important extension. The final switch statement is
>> not a replacement because it doesn't allow the programmer to store a
>> label address directly into a code stream, which is what's essential to
>> write a threaded-code interpreter.
>>
>
> I'd also like to see this.
>

Same here.

Though I believe a way to force tail-call can support the same use case also helping functional programming.

Say:

goto Call-Expression; //forced tail call

instead of:

return Call-Expression;

-- 
Dmitry Olshansky

On Saturday, 1 June 2013 at 05:29:28 UTC, Alex Rønne Petersen wrote:
> Hi,
>
> I'm sure this has been brought up before, but I feel I need to bring it up again (because I'm going to be writing a threaded-code interpreter): http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>
> This is an incredibly important extension. The final switch statement is not a replacement because it doesn't allow the programmer to store a label address directly into a code stream, which is what's essential to write a threaded-code interpreter.
>
> The Erlang folks went through hell just to use this feature; see the 5th Q at: http://www.erlang.org/doc/installation_guide/INSTALL-WIN32.html#Frequently-Asked-Questions
>

It would also solve the problem with IASM and being unable to address the labels in iasm

I noticed the problem when I tried to address the db'ed bytes.
http://dpaste.dzfl.pl/36bbd7d3

Commented out //mov dword ptr RAX, meh; ??? illustrates the problem.

Jumping to labels in IASM blocks seems to work ( http://dpaste.dzfl.pl/d9e47f70 ).

I guess we could have two chickens backed on the same fire ;)

On 2 June 2013 17:25, Brad Roberts <braddr@puremagic.com> wrote:

> On 6/1/13 9:49 PM, Walter Bright wrote:
>
>> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote:
>>
>>> On 01-06-2013 09:59, bearophile wrote:
>>>
>>>> "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. CPython source code has two versions, one with computed gotos and one without, to compile it even if your C compiler doesn't support them or their GNU-C syntax.
>>>>
>>>
>>> I don't think there's any question as to the usefulness (and
>>> essentialness) of
>>> this feature. I'm very close to just writing most of the interpreter in
>>> C over a
>>> triviality like this.
>>>
>>
>> To be pedantic, C and C++ don't have that feature. Some compilers add it as an extension.
>>
>> Also, such a construct could not be made @safe. The trouble is you could
>> pass those addresses
>> anywhere, and goto them from anywhere.
>>
>
> While you're technically correct, every major compiler in the unix world support it with the same syntax.  It's entered into defacto standard status.
>

MSVC doesn't support it, which is really annoying.

On 02-06-2013 10:52, Dmitry Olshansky wrote:
> 01-Jun-2013 20:13, Timon Gehr пишет:
>> On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> I'm sure this has been brought up before, but I feel I need to bring it
>>> up again (because I'm going to be writing a threaded-code interpreter):
>>> http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>>>
>>> This is an incredibly important extension. The final switch statement is
>>> not a replacement because it doesn't allow the programmer to store a
>>> label address directly into a code stream, which is what's essential to
>>> write a threaded-code interpreter.
>>>
>>
>> I'd also like to see this.
>>
>
> Same here.
>
> Though I believe a way to force tail-call can support the same use case
> also helping functional programming.
>
> Say:
>
> goto Call-Expression; //forced tail call
>
> instead of:
>
> return Call-Expression;
>

I'm not sure that can support threaded-code interpretation.

-- 
Alex Rønne Petersen
alex@alexrp.com / alex@lycus.org
http://alexrp.com / http://lycus.org

On 02-06-2013 08:44, Paulo Pinto wrote:
> Am 02.06.2013 06:49, schrieb Walter Bright:
>> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote:
>>> On 01-06-2013 09:59, bearophile wrote:
>>>> "Recently" the Python C interpreter was modified and speed up thanks to
>>>> this non-standard feature. CPython source code has two versions, one
>>>> with computed gotos and one without, to compile it even if your C
>>>> compiler doesn't support them or their GNU-C syntax.
>>>
>>> I don't think there's any question as to the usefulness (and
>>> essentialness) of
>>> this feature. I'm very close to just writing most of the interpreter
>>> in C over a
>>> triviality like this.
>>
>> To be pedantic, C and C++ don't have that feature. Some compilers add it
>> as an extension.
>
> I always have fun in public forums making people aware that what they
> think is C or C++ code is actually compiler defined behaviour.
>
> Not much people seem to care to read language standards. :)
>
> --
> Paulo
>

I am perfectly aware that it's a GNU C extension.

-- 
Alex Rønne Petersen
alex@alexrp.com / alex@lycus.org
http://alexrp.com / http://lycus.org

02-Jun-2013 20:48, Alex Rønne Petersen пишет:
> On 02-06-2013 10:52, Dmitry Olshansky wrote:
>> 01-Jun-2013 20:13, Timon Gehr пишет:
>>> On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote:
>>>> Hi,
>>>>
>>>> I'm sure this has been brought up before, but I feel I need to bring it
>>>> up again (because I'm going to be writing a threaded-code interpreter):
>>>> http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>>>>
>>>> This is an incredibly important extension. The final switch
>>>> statement is
>>>> not a replacement because it doesn't allow the programmer to store a
>>>> label address directly into a code stream, which is what's essential to
>>>> write a threaded-code interpreter.
>>>>
>>>
>>> I'd also like to see this.
>>>
>>
>> Same here.
>>
>> Though I believe a way to force tail-call can support the same use case
>> also helping functional programming.
>>
>> Say:
>>
>> goto Call-Expression; //forced tail call
>>
>> instead of:
>>
>> return Call-Expression;
>>
>
> I'm not sure that can support threaded-code interpretation.

Why not:

alias OpCode = function void();

OpCode[] opcodes = [ opcode_1, ... ];

int pc;
...

void opcode_1()
{
	... //pick operands do whatever
	pc = pc + num_operands; //skip over arguments
	OpCode next = cast(OpCode)bytecode[pc];
	goto next(); //this is baked-in threaded dispatch
}

void opcode_2(){ ... }

//say bytecode contains operands and addresses of fucntions
void execute(size_t[] bytecode, int pc)
{
	OpCode start  = cast(OpCode)bytecode[pc];
	pc++;
	goto start();
}

One can get away without casting if data is in a separate array.
Then this solution is perfectly safe in this limited form. Call would only point to a function hence no problem with jumping who knows where and less problems for optimizer.

-- 
Dmitry Olshansky

On 6/2/2013 12:49 AM, Brad Roberts wrote:
> Many if not most of those non-unix platforms use gcc, which is included in the
> set of compilers that does support it.  The point is, which you didn't change,
> is that's it's a defacto standard even if not technically in the c or c++
> language specs.

The curious question is why it never gets into the newer C and C++ Standards.