Hello.
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.
Bacek.
On 23 Feb 2013 15:07, "Christoph Otto" <christ...@mksig.org> wrote:
> **
> 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.
>
> 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.
>
> The goals are to reduce dependence on a dead-end tool (NQP-rx) and to
> provide a robust ops preprocessor.
>
> 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.
>
> 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.
>
> Christoph
>
>
> On Fri, Feb 22, 2013, at 4:16, Vasily Chekalkin wrote:
>
> Hello.
>
> Moving opsc back to perl5 is the biggest mistake you can make. Upgrade
> opsc to modern nqp is the way.
>
> Keywords: JIT, compile-time optimisations, PBC emitting, kill PIR with
> fire.
>
> --
> Bacek
>
>
> On Fri, Feb 22, 2013 at 3:11 PM, Christoph Otto <christ...@mksig.org>wrote:
>
>> On Thu, Feb 21, 2013, at 20:02, Brian Gernhardt wrote:
>> >
>> > On Feb 21, 2013, at 10:04 PM, Jimmy Zhuo <jimmy.z...@gmail.com> wrote:
>> >
>> > > Well, the original front is not written by PIR, it's by C.
>> >
>> > And whiteknight rewrote it in Winxed because it was clearer and faster.
>> >
>> >
>> http://whiteknight.github.com/2011/01/20/parrot_in_parrot_new_frontend.html
>> > http://whiteknight.github.com/2011/08/08/frontend_parrot2.html
>> > http://irclog.perlgeek.de/parrot/2011-08-19#i_4300881
>> >
>> >
>> > I don't think the frontend is _the_ reason to keep Winxed around. The
>> > reason to keep it in core is so that I never have to write a single
>> line
>> > of PIR again.
>> >
>> > ~~ benabik
>> That's the biggest thing winxed has going for it and the reason why
>> there's no reason for it to go away. Its runtime requirements are much
>> less complicated than full nqp and it can compile code down to (mostly)
>> standalone PIR. If you've ever written straight PIR, you'll know why
>> that's a good thing. I'm not saying that its use should be expanded,
>> largely because the path to a Parrot that continues to exist 24 months
>> from now involves cutting things out rather than adding them, but winxed
>> isn't hurting anything and could potentially help us later if we're able
>> to boost Parrot's performance sufficiently.
>>
>> I'm looking at much of the current work as a warm-up before the main
>> event. Ripping out opsc will reduce Parrot's dependence on nqp-rx but
>> the real speed gain is profiling and optimizing, especially in improving
>> pcc (as has been mentioned). Other things are easier to do and
>> relatively harmless, but only profiling and optimizing for nqp are what
>> will get Parrot into an attractive state.
>>
>> Christoph
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
