Hello again.

I'd like to announce a simple pl0 trans-compiler.

https://github.com/UplinkCoder/pl0stuff

with my parser generator it took me about 3 hours to get the compiler running.

The implemented optimizations are
* function-call-inclining
* nested-block-simplification,
* constant-promotion
* unused-variable-elimination
* dead-code-removal

please feel free to comment or ask questions here.

On Sunday, 27 December 2015 at 21:13:07 UTC, Stefan Koch wrote:
> Hello again.
>

>

> please feel free to comment or ask questions here.

Hi.

what languages do you plan to support for input and output ?

On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote:
> what languages do you plan to support for input and output ?

I just planned on PL/0 as input and C as output.
It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation.

There is no middle-end.

And very little verification. Everything that parses will produce an c-output.
Which does may or may not compile.

Since PL/0 just one type.
Int

you can get away with anything :)

On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote:
> On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote:
>> what languages do you plan to support for input and output ?
>
> I just planned on PL/0 as input and C as output.
> It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation.
>
> There is no middle-end.
>
> And very little verification. Everything that parses will produce an c-output.
> Which does may or may not compile.
>
> Since PL/0 just one type.
> Int
>
> you can get away with anything :)

so could it be used to produce D output instead of C ?

Could it be used to parse PHP as input ?

On Monday, 28 December 2015 at 23:40:31 UTC, Nick B wrote:
> On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote:
>> On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote:
>>> what languages do you plan to support for input and output ?
>>
>> I just planned on PL/0 as input and C as output.
>> It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation.
>>
>> There is no middle-end.
>>
>> And very little verification. Everything that parses will produce an c-output.
>> Which does may or may not compile.
>>
>> Since PL/0 just one type.
>> Int
>>
>> you can get away with anything :)
>
> so could it be used to produce D output instead of C ?
>
> Could it be used to parse PHP as input ?

That would probably require implementing a vm.
fancyPars can certainly be used to create a php parser but a straightforward translation will not give you good performance...

On Tuesday, 29 December 2015 at 00:50:49 UTC, Stefan Koch wrote:

>>
>> so could it be used to produce D output instead of C ?
>>
>> Could it be used to parse PHP as input ?
>
> That would probably require implementing a vm.
> fancyPars can certainly be used to create a php parser but a straightforward translation will not give you good performance...

Would you know what is required to get good performance ?

On Tuesday, 29 December 2015 at 04:37:44 UTC, Nick B wrote:
> Would you know what is required to get good performance ?

I can guess. However without actually implementing it my guess is as good as any.
I would probably look at HHVM, and see what is easy to reimplement in D.

On Tuesday, 29 December 2015 at 17:59:15 UTC, Stefan Koch wrote:
> On Tuesday, 29 December 2015 at 04:37:44 UTC, Nick B wrote:
>> Would you know what is required to get good performance ?
>
> I can guess. However without actually implementing it my guess is as good as any.
> I would probably look at HHVM, and see what is easy to reimplement in D.

So the best approach, if I understand you correctly, would be to perform micro-benchmarks on new code that is either D code (with a variety of algorithms and/or vibe.d framework code) or HHVM 64 bit code, and compare (and publish) the results ?

On Tuesday, 29 December 2015 at 22:13:44 UTC, Nick B wrote:
>
> So the best approach, if I understand you correctly, would be to perform micro-benchmarks on new code that is either D code (with a variety of algorithms and/or vibe.d framework code) or HHVM 64 bit code, and compare (and publish) the results ?

I am not sure if this is the right thing to do.
The main reason to look at HHVM is to get an idea of implementation strategies.
benchmarking would require to already have a solution to work on.

On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote:
> On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote:
>> what languages do you plan to support for input and output ?
>
> I just planned on PL/0 as input and C as output.
> It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation.

Update I have implemented D codegen.
The CodeGenerator as well as the optimizer work at CTFE.
Therefore you can transcompile code at compileTime at call PL/0 functions as there were naively implemented in D.

While this does not make sense for underpowered languages like PL/0.
You can apply the same concept to something more powerful.

I will write up a detailed blogpost about the mechanisem at codesoldier.blogspot.de