www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - pl0stuff an optimizing pl0 > c transcompiler

reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Dec 27 2015
parent reply Nick B <nick.barbalich gmail.com> writes:
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 ?



 Dec 28 2015



  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


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 :)



 Dec 28 2015



 next sibling parent reply Nick B <nick.barbalich gmail.com>  writes:


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 ?



 Dec 28 2015



  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


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...



 Dec 28 2015



  parent reply Nick B <nick.barbalich gmail.com>  writes:


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 ?



 Dec 28 2015



  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


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.



 Dec 29 2015



  parent reply Nick B <nick.barbalich gmail.com>  writes:


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 ?



 Dec 29 2015



  parent  Stefan Koch <uplink.coder googlemail.com>  writes:


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.



 Dec 30 2015



prev sibling  parent reply Stefan Koch <uplink.coder googlemail.com>  writes:


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



 May 20 2016



 next sibling parent  Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:


 Therefore you can transcompile code at compileTime at call PL/0 
 functions as there were naively implemented in D.


If you do want to call functions from D.
You cannot use the optimizer.
As it does _very_ aggressive inlineing and will fold all used 
functions into main.



 May 20 2016



prev sibling  parent reply Johan Engelen <j j.nl>  writes:


On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:

 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.


This is pretty cool :D

Now I understand why you want to improve CTFE. You actually want 
better C++ interop. And to do that, you are going to CTFE compile 
the C++ code to D code, which is then mixed in, and all is good. 
Excellent idea! ;-)

cheers,
   Johan



 May 20 2016



  parent  Stefan Koch <uplink.coder googlemail.com>  writes:


On Friday, 20 May 2016 at 19:20:34 UTC, Johan Engelen wrote:

 On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:

 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.


 This is pretty cool :D

 Now I understand why you want to improve CTFE. You actually 
 want better C++ interop. And to do that, you are going to CTFE 
 compile the C++ code to D code, which is then mixed in, and all 
 is good. Excellent idea! ;-)

 cheers,
   Johan


Actually I think compiling c++ is a bit out of my league at the 
moment.
It would only work for self-contained subset of c++. Not for the 
whole c++ language.
Especially preprocessor tricks make this approach unfeasible.



 May 21 2016