Honestly, I have no idea how to test this… maybe someone should attempt to golf
it, but given that the commit description is “JIT compile native calls”, I
guess it'd be a bit complicated.
… I'm fine with just delegating it to the DBIish test suite…
On 2017-10-20 08:12:41, alex.jakime...@gmail.com
Offending commit reverted in
https://github.com/MoarVM/MoarVM/commit/1a9be0ad487bc6e2d21df54c6a12892e3f9c8259
I tested it with moar HEAD and indeed the issue is no longer there. So it
should work fine after moar and nqp bumps.
｢testneeded｣ ?
On 2017-10-20 07:53:23, alex.jakime...@gmail.com wrote
Moar bisected to
https://github.com/MoarVM/MoarVM/commit/4eadf94599cc021ec7a9e0e49e198f5861468dc1
On 2017-10-20 07:23:04, alex.jakime...@gmail.com wrote:
> DBIish tests started to fail (with segv) after this rakudo commit:
>
https://github.com/rakudo/rakudo/commit/ff063e7b53ab41b79279ffc38e1740d3d
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #132328]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132328 >
DBIish tests started to fail (with segv) after this rakudo commit:
ht
At 4:28 PM -0500 1/30/02, Josh Wilmes wrote:
>This patch allows parrot to mostly-build with tcc. It allows one to skip
>compiling the JIT stuff (by specifying --define jitcapable=0), and it
>introduces a test program which gives a friendlier error in this case for
>compilers which are as picky as
This patch allows parrot to mostly-build with tcc. It allows one to skip
compiling the JIT stuff (by specifying --define jitcapable=0), and it
introduces a test program which gives a friendlier error in this case for
compilers which are as picky as tcc is about function pointer conversion.
If
On 11/17/01 Dan Sugalski wrote:
> >BTW: we just got our compiler running on linux and compiling a simple
> >program, hopefully by next week it can be used for some more real code
> >generation.
>
> Yahoo! Congrats. Are we still slower than you are? :)
It's a couple of months I'm in features-and-
> There is an effort to compile ruby to the CLR, I don't know more,
> because I can't read japanese :-) And there is someone working on python
> support in the mono compiler, too.
> BTW: we just got our compiler running on linux and compiling a simple
> program, hopefully by next week it can be us
At 03:32 PM 11/16/2001 +0100, Paolo Molaro wrote:
>On 11/08/01 Benoit Cerrina wrote:
> > I heard that, I was thinking that it would be great to run ruby on mono but
> > ruby is very dynamic (like perl but since its so much easier to use and
> > program
> > it is also easier to redefine the methods
On 11/16/01 Simon Cozens wrote:
> On Fri, Nov 16, 2001 at 03:32:06PM +0100, Paolo Molaro wrote:
> > And there is someone working on python
> > support in the mono compiler, too.
>
> I know, I've just seen. Wouldn't it be really wonderful, Paolo, if
> someone wrote some Perl bindings for it as wel
On Fri, Nov 16, 2001 at 03:32:06PM +0100, Paolo Molaro wrote:
> And there is someone working on python
> support in the mono compiler, too.
I know, I've just seen. Wouldn't it be really wonderful, Paolo, if
someone wrote some Perl bindings for it as well? :)
--
I did write and prove correct a 2
On 11/08/01 Benoit Cerrina wrote:
> I heard that, I was thinking that it would be great to run ruby on mono but
> ruby is very dynamic (like perl but since its so much easier to use and
> program
> it is also easier to redefine the methods and done more often)
There is an effort to compile ruby t
On Sat, 10 Nov 2001, Dan Sugalski wrote:
> There's a minimum charge you're going to have to pay for the privilege of
> dynamicity, or running a language not built by an organization with 20
> full-time engineers dedicated to it.
Umm, this isn't really the place for it, so just a quick question:
At 07:13 PM 11/8/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > [native code regexps] There's a hugely good case for JITting.
>
>Yes, for JITing the regexp engine. That looks like a much easier
>problem to solve than JITing all of Parrot.
The problem there's no different than for the rest of
Dan Sugalski wrote:
> [native code regexps] There's a hugely good case for JITting.
Yes, for JITing the regexp engine. That looks like a much easier
problem to solve than JITing all of Parrot.
> If you think about it, the interpreter loop is essentially:
>
>while (code) {
> code = (fun
people have relying upon the side effects of perl5
>lexical scoping. The same results could be had, but in a different fashion.
Everyone's code can benefit from JIT compilation. It doesn't suffer from
the issues that come up with optimizations. In fact, the only issue there
real
> On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
> >
> > JITs help when the VM is focused on lots of small instructions
> > with well-known, static semantics. Perl's use of Parrot is going
> > to be focused almost completely on PMC vtable ops. A JIT has
> > no advantage over a threaded
> IMHO, a less dynamic perl is perl no more, though some consideration
> should be made to make it easier to implement the language on virtual
> machines such as the JVM and CLR.
> That said, I'm open to sneak into mono opcode handling that may make it
> easier to run parrot code there, if it is
On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
>
> JITs help when the VM is focused on lots of small instructions
> with well-known, static semantics. Perl's use of Parrot is going
> to be focused almost completely on PMC vtable ops. A JIT has
> no advantage over a threaded interpreter.
On 11/08/01 Norbert Bollow wrote:
> BURG means "Bottom-Up Rewrite Grammar"... a way to generate
> optimized code quickly *if* you have plenty of memory available.
Maybe, if < 32 KB for a large method is plenty (about 600 bytes of IL code):
basically all the methods in out corlib are below that si
On 11/07/01 Ken Fox wrote:
> Simon Cozens wrote:
> > ... Mono's work on JIT compilation ... they've got some pretty
> > interesting x86 code generation stuff going on.
>
> Mono is doing some very cool stuff, but it's kind of hard
> to understand at this t
Ken Fox <[EMAIL PROTECTED]> wrote:
> Simon Cozens wrote:
> > ... Mono's work on JIT compilation ... they've got some pretty
> > interesting x86 code generation stuff going on.
>
> Mono is doing some very cool stuff, but it's kind of hard
> to und
> There's a more fundamental issue though. After spending time
> looking at the benefits of a JIT and thinking about the "yet
> another switch/goto implementation" conversation, I'm starting
> to think that a JIT will be almost useless for Parrot.
>
> JITs help when the VM is focused on lots of s
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> JITs help when the VM is focused on lots of small instructions
KF> with well-known, static semantics. Perl's use of Parrot is going
KF> to be focused almost completely on PMC vtable ops. A JIT has
KF> no advantage over a threaded inter
Simon Cozens wrote:
> ... Mono's work on JIT compilation ... they've got some pretty
> interesting x86 code generation stuff going on.
Mono is doing some very cool stuff, but it's kind of hard
to understand at this time. The x86 code generation macros are
easy to use
I've just been having a look at Mono's work on JIT compilation,
and it looks like they've got some pretty interesting x86 code
generation stuff going on. Anyone want to have a look at that
and report back on its potential for Parrot?
--
And it should be the law: If you use the
26 matches
Mail list logo
