Re: [OT] Re: pl0stuff an optimizing pl0 > c transcompiler
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.
[OT] Re: pl0stuff an optimizing pl0 > c transcompiler
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
Re: pl0stuff an optimizing pl0 > c transcompiler
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.
Re: pl0stuff an optimizing pl0 > c transcompiler
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
Re: pl0stuff an optimizing pl0 > c transcompiler
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.
Re: pl0stuff an optimizing pl0 > c transcompiler
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.
Re: pl0stuff an optimizing pl0 > c transcompiler
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 ?
Re: pl0stuff an optimizing pl0 > c transcompiler
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 ?
Re: pl0stuff an optimizing pl0 > c transcompiler
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 :)
Re: pl0stuff an optimizing pl0 > c transcompiler
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 ?
Re: pl0stuff an optimizing pl0 > c transcompiler
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 ?
Re: pl0stuff an optimizing pl0 > c transcompiler
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...
