<p dir="ltr">Hello.</p>
<p dir="ltr">In the nutshell you are explaining that NQP can't be implemented in NQP. Sorry, but "bootstrap problem" was already solved. Checking in of generated C code is equivalent of checking in PIR.</p>

<p dir="ltr">Bacek.</p>
<div class="gmail_quote">On 23 Feb 2013 15:07, "Christoph Otto" <<a href="mailto:christoph@mksig.org">christoph@mksig.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>




<div><div>The ops2c-necromancy branch reminds me why we felt the way we did about ops2c.  Nobody could accuse it of being an elegant or smart tool.  A proper compiler based on NQP or Rakudo would generally be preferable but there are a few factors that make it less attractive.<br>
</div>
<div> </div>
<div>The big one is that modern NQP has a non-trivial setting.  Code can't just be compiled down to PIR or pbc and treated as a standalone fakecutable that links against libparrot.so .  If NQP has to be installed and working before Parrot, NQP or Rakudo's ops can be bootstrapped, everyone's toolchain becomes much more brittle.  NQP's ops have been changed in 16 commits so far this month and pm has stated that we should not assume that NQP/Rakudo's ops will remain relatively static.  The ops compiler needs to be a tool that works no matter what state the user's system is in.  P5 is a better foundation for that purpose because we can safely assume that it's installed and working, whether the system it's on has an ancient installed Parrot, a broken NQP or no Parrot at all.<br>
</div>
<div> </div>
<div>The goals are to reduce dependence on a dead-end tool (NQP-rx) and to provide a robust ops preprocessor.  <br></div>
<div> </div>
<div>Yes, we could decide on a stable-ish NQP version, check in NQP.pir, all of NQP's stage 2 PIR and its post-processed dynops (and hope that they're for the right Parrot version), then integrate them with our build, then make sure that they worked correctly both from Parrot's build and install directories, then make sure that they didn't conflict with upstream NQP or ancient NQP-rx when installed ("/usr/local/bin/parrot-nqp-but-not-the-old-one-that-we-already-install-called-parrot-nqp"?), then make sure that they were regularly updated, then the deal with upstream NQP changes that break parrot-nqp-not-rx, then subscribe to the advil of the month club.  I'd rather not go down that path and it's not immediately clear that it'd be in Parrot's interest to even accept such a patch, given that we're in a do or die regarding performance.  I'm not entirely adverse to leaving opsc as part of the build since ripping it out won't lead to an immediate performance gain, but moving to NQP proper isn't a good option.<br>
</div>
<div> </div>
<div>Working on opsc was great but it was a misstep to depend on NQP-rx at the time.  It's unfortunate, but progress at this point does mean moving in the opposite direction.<br></div>
<div> </div>
<div>Christoph<br></div>
<div> </div>
<div> </div>
<div>On Fri, Feb 22, 2013, at 4:16, Vasily Chekalkin wrote:<br></div>
<blockquote type="cite"><div dir="ltr">Hello.<div> </div>
<div>Moving opsc back to perl5 is the biggest mistake you can make. Upgrade opsc to modern nqp is the way.<br></div>
<div> </div>
<div>Keywords: JIT, compile-time optimisations, PBC emitting, kill PIR with fire.<br></div>
<div> </div>
<div>-- <br></div>
<div>Bacek<br></div>
</div>
<div class="gmail_extra"><div> </div>
<div> </div>
<div class="gmail_quote"><div>On Fri, Feb 22, 2013 at 3:11 PM, Christoph Otto <span dir="ltr"><<a href="mailto:christoph@mksig.org" target="_blank">christoph@mksig.org</a>></span> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Feb 21, 2013, at 20:02, Brian Gernhardt wrote:<br></div>
<div>
><br></div>
<div>
> On Feb 21, 2013, at 10:04 PM, Jimmy Zhuo <<a href="mailto:jimmy.zhuo@gmail.com" target="_blank">jimmy.zhuo@gmail.com</a>> wrote:<br></div>
<div>
><br></div>
<div>
> > Well, the original front is not written by PIR, it's by C.<br></div>
<div>
><br></div>
<div>
> And whiteknight rewrote it in Winxed because it was clearer and faster.<br></div>
<div>
><br></div>
<div>
> <a href="http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html" target="_blank">http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html</a><br></div>
<div>
> <a href="http://whiteknight.github.com/2011/08/08/frontend_parrot2.html" target="_blank">http://whiteknight.github.com/2011/08/08/frontend_parrot2.html</a><br></div>
<div>
> <a href="http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881" target="_blank">http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881</a><br></div>
<div>
><br></div>
<div>
><br></div>
<div>
> I don't think the frontend is _the_ reason to keep Winxed around.  The<br></div>
<div>
> reason to keep it in core is so that I never have to write a single line<br></div>
<div>
> of PIR again.<br></div>
<div>
><br></div>
<div>
> ~~ benabik<br></div>
<div>That's the biggest thing winxed has going for it and the reason why<br></div>
<div>
there's no reason for it to go away.  Its runtime requirements are much<br></div>
<div>
less complicated than full nqp and it can compile code down to (mostly)<br></div>
<div>
standalone PIR.  If you've ever written straight PIR, you'll know why<br></div>
<div>
that's a good thing.  I'm not saying that its use should be expanded,<br></div>
<div>
largely because the path to a Parrot that continues to exist 24 months<br></div>
<div>
from now involves cutting things out rather than adding them, but winxed<br></div>
<div>
isn't hurting anything and could potentially help us later if we're able<br></div>
<div>
to boost Parrot's performance sufficiently.<br></div>
<div> </div>
<div>
I'm looking at much of the current work as a warm-up before the main<br></div>
<div>
event.  Ripping out opsc will reduce Parrot's dependence on nqp-rx but<br></div>
<div>
the real speed gain is profiling and optimizing, especially in improving<br></div>
<div>
pcc (as has been mentioned).  Other things are easier to do and<br></div>
<div>
relatively harmless, but only profiling and optimizing for nqp are what<br></div>
<div>
will get Parrot into an attractive state.<br></div>
<div> </div>
<div>
Christoph<br></div>
<div>
_______________________________________________<br></div>
<div><a href="http://lists.parrot.org/mailman/listinfo/parrot-dev" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-dev</a><br></div>
</blockquote></div>
</div>
</blockquote></div>

<br>_______________________________________________<br>
<a href="http://lists.parrot.org/mailman/listinfo/parrot-dev" target="_blank">http://lists.parrot.org/mailman/listinfo/parrot-dev</a><br>
<br></blockquote></div>