Labels as values and threaded-code interpretation

Alex Rønne Petersen alex at lycus.org
Sat Jun 1 19:35:26 PDT 2013


On 01-06-2013 09:59, bearophile wrote:
> Alex Rønne Petersen:
>
>> 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.
>
> This was discussed more than once, and I think it's a valuable
> improvement for certain kinds of low level D programming.
>
> Walter says that he has not added this feature to D because it's useful
> only to write interpreters and the like. I have found it useful in GCC
> to also write very fast finite state machines to analyse genomic
> strings. But even if Walter is right, writing interpreters (and
> emulators) is an important purpose for a system language as D. You can't
> write them efficient in scripting languages, and even Haskell/F# are not
> good at all to write them. Languages like C/D/C++ (and few others, as
> later probably Rust) are the only few natural languages to write them.
>
> "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.

>
>
>> Implementing it should be trivial as both LLVM and GCC support taking
>> the address of a block. I'm sure the DMD back end could be extended to
>> support it too.
>
> Even if DMD back-end will never implement it, I think it's important to
> define it formally and officially in the D language and add the relative
> syntax to the front-end (plus a standard version identifier that allows
> to write programs that have both a routine that uses computed gotos and
> one that doesn't use them).
>
> This has the big advantage that all future compilers that will want to
> implement it will use the same nice standard syntax. If D doesn't define
> this syntax, then maybe GDC will add it, and maybe later LDC will add
> it, and later maybe other future compilers will add it, and we can't be
> sure they will share the same syntax.
>
> Another advantage of having this syntax in D, is that even if a compiler
> back-end doesn't support computed gotos, the program compiles without
> syntax errors when you use conditional compilation to disable the piece
> of code that uses computed gotos.

Yes, good points.

>
> Bye,
> bearophile


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


More information about the Digitalmars-d mailing list