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,
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
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:
>
# 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:
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.
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
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 used
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
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 and
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
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 well? :)
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 the
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 understand at this time. The x86 code generation macros
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 time. The x86 code generation macros are
easy
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 size.
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.
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
. More importantly, I think a lot
of the problems currently facing Parrot really doing its job well, is
the nasty habits 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
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 =
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, but the instruction selection
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 interpreter.
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 word `paradigm
24 matches
Mail list logo
