On 01/13/2017 05:18 AM, Steve Mynott wrote:
The most important difference is that the JIT version is 64 bit and
the "no JIT" is 32 bit.
So if you are running a modern Windows you almost certainly want the
64 bit (JIT) version
Also the JIT version is a more recent version.
S
I missed that
The most important difference is that the JIT version is 64 bit and the "no
JIT" is 32 bit.
So if you are running a modern Windows you almost certainly want the 64 bit
(JIT) version
Also the JIT version is a more recent version.
S
On 01/11/2017 06:43 PM, yary wrote:
You don't need JIT! It's an
implementation detail that doesn't affect functionality. In
theory it improves speed at which Perl6 code runs. In
practice, it won't make a bit of difference with FTP
You don't need JIT! It's an implementation detail that doesn't affect
functionality. In theory it improves speed at which Perl6 code runs. In
practice, it won't make a bit of difference with FTP client/server programs.
Leopold Toetsch [EMAIL PROTECTED] wrote:
arm, mips, and sun4 JIT platforms need definitely some work to even keep
up with the current state of the JIT interface.
That's actually wrong - sorry. Sun4 JIT is fairly complete and is up to
date and should't have been in above sentence.
I've messed
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 23, 2004, at 4:20 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
See attached the patch, plus the new asm.s file.
Doesn't run, segfaults on even mops.pasm - please check.
I can't reproduce that here; parrot -j works for me
Jeff Clites [EMAIL PROTECTED] wrote:
On Oct 23, 2004, at 3:42 AM, Leopold Toetsch wrote:
We were allocating the volatile float registers first (or, only)--so
Cset_s_sc was blowing away an N-register, even with only one in use.
That's why I was surprised there weren't more failures.
Yes. As
On Oct 22, 2004, at 3:57 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related,
and pointing out things
Jeff Clites [EMAIL PROTECTED] wrote:
See attached the patch, plus the new asm.s file.
Doesn't run, segfaults on even mops.pasm - please check.
JEff
leo
Jeff Clites [EMAIL PROTECTED] wrote:
Yep, that was the core of the issue. There's no free lunch--if we use
the nonvolatile registers, we need to preserve/restore them in
begin/end, but if we use the volatile registers, we need to preserve
them across function calls (incl. normal op calls).
On Oct 23, 2004, at 4:20 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
See attached the patch, plus the new asm.s file.
Doesn't run, segfaults on even mops.pasm - please check.
I can't reproduce that here; parrot -j works for me with
examples/{benchmarks,assembly}/mops.pasm, and
On Oct 23, 2004, at 3:42 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Yep, that was the core of the issue. There's no free lunch--if we use
the nonvolatile registers, we need to preserve/restore them in
begin/end, but if we use the volatile registers, we need to preserve
them
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related, and
pointing out things which needed fixing anyway (float register
preservation issues). I'll
Jeff Clites wrote:
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related, and
pointing out things which needed fixing anyway (float register
Joshua Gatcomb [EMAIL PROTECTED] wrote:
Parrot doesn't use GMP right?
Right.
... So the math library in
question is the /usr/include/math.h header?
No. That's the header do declare functions in the math library. The
library is e.g. F/usr/lib/libm.so.
WRT alignment there were some
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
... So the math library in
question is the /usr/include/math.h header?
No. That's the header do declare functions in the
math library. The
library is e.g. F/usr/lib/libm.so.
Well you see - that's what I thought but removing it
seemed to have
Joshua Gatcomb [EMAIL PROTECTED] wrote:
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
math library. The
library is e.g. F/usr/lib/libm.so.
For example
$ objdump -p parrot.exe
DLL Name: cygwin1.dll
vma: Hint/Ord Member-Name Bound-To
1b5588 14
Joshua Gatcomb [EMAIL PROTECTED] wrote:
Well, it only happens under JIT for the following
functions (identical code for atan works fine):
cosh, sinh, tanh, sech, exp, pow
It only happens if there are two set N# prior to the
function where # is two different numbers
N0 = 1
N1 = 1
I think
I thought I had already replied to this but I don't
seem to see it in the archive anywhere.
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
I think next step would need to review Cygwin math
lib sources and trace
into the library. Nasty.
Parrot doesn't use GMP right? So the math library in
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
I think next step would need to review Cygwin math
lib sources and trace
into the library. Nasty.
Parrot isn't using GMP right? I am not sure where to
go look for the math lib sources other than the math
header /usr/include/math.h ???
Is your
Joshua Gatcomb [EMAIL PROTECTED] wrote:
4 print N3
gdb p N3
$2 = 4.4942328371557898e+307
If both N1 and N2 are not set prior to cosh, then
everything works fine.
I've checked in a possible fix for this. Please try again after cvs
update.
Thanks for your analysis,
leo
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
Joshua Gatcomb [EMAIL PROTECTED] wrote:
4 print N3
gdb p N3
$2 = 4.4942328371557898e+307
If both N1 and N2 are not set prior to cosh, then
everything works fine.
I've checked in a possible fix for this. Please try
again after
Joshua Gatcomb [EMAIL PROTECTED] wrote:
Sorry - still a problem. I am attaching a more
descriptive debugging session where I show the floats
and registers at every step. Not sure if this will be
useful, but I figured it couldn't hurt.
It looks like that the Cygwin libs have some assumption
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
It looks like that the Cygwin libs have some
assumption how the floating
point stack is used. I'll try to insert a Cemms
instruction before
math lib functions are called.
leo
Well, it only happens under JIT for the following
functions
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #27200]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27200
Stephane Peiry wrote:
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold
Stephane Peiry wrote:
Looking at it makes it pretty clear why it loops forever (mainly
it jumps back to a load, loading always the same value).
Yep. That's a bit complicated. The jit code tries to avoid
loading/storing the same register from/to memory. This is achieved by
remembering the size
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote:
Yep. That's a bit complicated. The jit code tries to avoid
loading/storing the same register from/to memory.
Actually on this, while looking at what jit on i386 would give for this
particular loop, just noticed it does quite a lot
Stephane Peiry [EMAIL PROTECTED] wrote:
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote:
Yep. That's a bit complicated. The jit code tries to avoid
loading/storing the same register from/to memory.
Actually on this, while looking at what jit on i386 would give for this
On Mon, Feb 16, 2004 at 09:08:55AM +0100, Leopold Toetsch wrote:
I see. Your libc's sprintf seems to be missing the 0x prefix for the
%p format.
Ok you were right, that fixed it immediatly, and I'm now able to
see within jit :). Attached are the dumps for this loop, with
and without the print
Stephane Peiry [EMAIL PROTECTED] wrote:
mh ok, I do get the stabs file, and apparently the reason no objfile gets
created is that as complains with loads of warnings and some errors when
given the stab file.
I see. Your libc's sprintf seems to be missing the 0x prefix for the
%p format. Can
On Fri, Feb 13, 2004 at 10:48:09AM +0100, Leopold Toetsch wrote:
I don't know suns JIT code nor the assembler syntax, but it seems that
the two subcc lines are broken:
emitm_subcc_r(NATIVECODE, MAP[1], emitm_g(0), emitm_g(0));
If I understand that correctly it should read:
Stephane Peiry [EMAIL PROTECTED] wrote:
whats a good way to debug jit?
s. docs/jit.pod /Debugging
docs/debug.pod /jit
Thanks,
Stephane
leo
On Sat, Feb 14, 2004 at 02:35:02PM +0100, Leopold Toetsch wrote:
docs/debug.pod /jit
saw that one, but jit doesn't generate a .o file under sparc?
Stéphane
Stephane Peiry [EMAIL PROTECTED] wrote:
On Sat, Feb 14, 2004 at 02:35:02PM +0100, Leopold Toetsch wrote:
docs/debug.pod /jit
saw that one, but jit doesn't generate a .o file under sparc?
Calling Parrot_jit_debug() is enabled for __GNUC__ and __IBMC__. If your
system doesn't define one of
Stephane Peiry [EMAIL PROTECTED] wrote:
While playing with JIT on Suns, I've found out that the following pasm code:
set I1, 2
LOOP: sub I1, 1
ifI1, LOOP
print end\n
end
never finishes.. that is: parrot -j loop.pasm hangs forever (never
Jonathan Worthington [EMAIL PROTECTED] wrote:
Hi,
I was looking over the WinXP Service Pack 2 Changes to functionality
document, which you can get here:-
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechn
ol/winxppro/maintain/winxpsp2.asp (download available in
Leopold Toetsch wrote:
JIT code is run in malloc'ed memory (s. jit.c:1026) as well as JITted
NCI stubs. We already have some system specific stuff for JIT (some
architectures need a page flush before execution).
So best would be to use a set of spcialized function, e.g.:
-
Peter Gibbs [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
JIT code is run in malloc'ed memory (s. jit.c:1026) as well as JITted
NCI stubs. We already have some system specific stuff for JIT (some
architectures need a page flush before execution).
So best would be to use a set of
Ah, that's the reason for your bug report WRT JIT/NCI. The question is,
how can we detect the presence of the exec-shield patch. Your `uname -a`
doesn't indicate it.
What for? We just always do allocating memory from a JIT dedicated heap with
execute flas set on it, no matter the presence of
Leopold Toetsch wrote:
So we need:
1) a config test/option/whatever (e.g. mallocing some mem, fill in a
ret instruction and call that.
2) Some means to allocate executable memory.
Could you please have a look at fedora (kernel) docs?
There are two ways to flag memory as executable:
1) A
Vladimir Lipsky [EMAIL PROTECTED] wrote:
Ah, that's the reason for your bug report WRT JIT/NCI. The question is,
how can we detect the presence of the exec-shield patch. Your `uname -a`
doesn't indicate it.
What for? We just always do allocating memory from a JIT dedicated heap with
execute
Peter Gibbs [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
So we need:
1) a config test/option/whatever (e.g. mallocing some mem, fill in a
ret instruction and call that.
2) Some means to allocate executable memory.
Could you please have a look at fedora (kernel) docs?
There are two
From: Leopold Toetsch [EMAIL PROTECTED]
Vladimir Lipsky [EMAIL PROTECTED] wrote:
Ah, that's the reason for your bug report WRT JIT/NCI. The question is,
how can we detect the presence of the exec-shield patch. Your
`uname -a`
doesn't indicate it.
What for? We just always do allocating
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string to trigger
it). Here's a stacktrace:
---
On Sunday 03 August 2003 15:27, Simon Glover wrote:
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string to trigger
it). Here's a stacktrace:
I couldn't
On Sun, 3 Aug 2003, Daniel Grunblatt wrote:
On Sunday 03 August 2003 15:27, Simon Glover wrote:
On 3 Aug 2003, Luke Palmer wrote:
This fix has worked fine with JIT until now, so I suspect the problem
is elsewhere.
Bug confirmed here (although I need a slightly longer string to
At 9:54 AM +0200 6/14/02, Aldo Calpini wrote:
you would
not be able, for example, to inspect the call stack from inside a Parrot
program anymore.
That, unfortunately, makes it untenable, since we need to be able to
do this in the general case. Also, we'll fill up the thread stack
pretty
On Fri, 14 Jun 2002, Dan Sugalski wrote:
: At 9:54 AM +0200 6/14/02, Aldo Calpini wrote:
: you would
: not be able, for example, to inspect the call stack from inside a Parrot
: program anymore.
:
: That, unfortunately, makes it untenable, since we need to be able to
: do this in the general
On Fri, 14 Jun 2002, Nicholas Clark wrote:
: But surely an routine that calls another routine can potentially have its
: stack inspected by the caller?
Certainly.
: So it would only make sense for leaf nodes, and even then they might
: get inspected by overloaded values or methods on objects
At 1:49 PM -0700 6/14/02, Larry Wall wrote:
On Fri, 14 Jun 2002, Nicholas Clark wrote:
: Or would the property of I don't use caller or want still be useful on a
: subroutine, because the run-time could determine that it would be
: inline-able (or whatever) inside a loop at run time, based on
Daniel Grunblatt wrote:
Don't implement any print op yet, if I didn't understood wrong they are
going to be updated to use the IO system.
ok, I draw back them then.
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed
On Fri, 24 May 2002, Aldo Calpini wrote:
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed increase isn't at all
dramatic, but OTOH I have no idea how to do complicate stuff like allocating
memory natively in asm.
On Thu, 23 May 2002, Aldo Calpini wrote:
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode
On Fri, 10 May 2002, Aldo Calpini wrote:
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
Yes, the new JIT will work (actually, it works) on Windows, probably you
didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so,
as
Daniel Grunblatt wrote:
is anybody working on JIT-enabling the Win32 platform?
Yes, the new JIT will work (actually, it works) on Windows, probably you
didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so,
as soon as the the code is in you will be able to use the JIT on
On Fri, 10 May 2002, Aldo Calpini wrote:
it was really nice to work on it anyway. I have learned alot of things, and
would like to suggest an 'enhancement' to Configure.pl.
if the compiler is 'cl' (that is, Visual C++), and you invoke Configure.pl
with --debugging, it should add '-DDEBUG
At 12:29 PM -0300 5/10/02, Daniel Grunblatt wrote:
On Fri, 10 May 2002, Aldo Calpini wrote:
also, to inspect core_ops.c in the debugger (instead of the not-so-helpful
core.ops), I had to comment all the #line directives in core_ops.c.
I hate that too.
If you want to throw in a patch to
On Wed, 30 Jan 2002, Jason Gloudon wrote:
On Wed, Jan 30, 2002 at 03:27:18PM -0500, Andy Dougherty wrote:
objdump. Is anyone with a Solaris system familiar enough with jit
internals to have a go at adapting it to use dis instead of GNU objdump?
The difference was pretty minimal. It should
This should make solaris 'as' happy. There will be an assembler warning, but
it's harmless.
diff -r1.3 sun4Generic.pm
78c78
return Parrot::Jit-Assemble(ld [\%o0], \%o0\njmpl \%o0, \%g0\n);
---
return Parrot::Jit-Assemble(ld [\%o0], \%o0\njmpl \%o0, \%g0\nnop\n);
151c151
At 3:27 PM -0500 1/30/02, Andy Dougherty wrote:
On Solaris, it looks like JIT will now be enabled if the user has also
installed GNU objdump. However, there is (often) already a disassembler
in /usr/ccs/bin/dis. It's output is similar, but not identical to,
objdump. Is anyone with a Solaris
On Wed, Jan 30, 2002 at 03:27:18PM -0500, Andy Dougherty wrote:
On Solaris, it looks like JIT will now be enabled if the user has also
installed GNU objdump. However, there is (often) already a disassembler
in /usr/ccs/bin/dis. It's output is similar, but not identical to,
objdump. Is
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
To run a program with the JIT, pass test_parrot the -j flag and watch it
scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
On Mon, Dec 24, Gregor N. Purdy wrote:
Nicholas --
Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
On Mon, Dec 24, 2001 at 02:11:15PM -0500, Gregor N. Purdy wrote:
Or, do we really need to have the three-way in/out/inout tagset?
inline op set(out i, in i|ic) {
$1 = $2;
}
Making the distinction between the three cases enables a number of
optimizations of native code based on
Jason --
Making the distinction between the three cases enables a number of
optimizations of native code based on analysing data flow. 'in' would be good
as an implicit default, as many PMC opcodes will not overwrite any PMC
registers.
An optimizing native code generator (whether static
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
It looks like it is going to need some work before it can work for
other instruction sets though, at least for RISC systems where the
operands are typically encoded with the opcode as part of a single
word and the range of immediate
I think we should leave all that for an optimizer.
Daniel Grunblatt.
On Mon, 24 Dec 2001, Nicholas Clark wrote:
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
It looks like it is going to need some work before it can work for
other instruction sets though, at least for RISC
Oh, and by the BTW,
I already tried you fastest example last week and got 50x speed up, but
that's works only for mops, so ...
Daniel Grunblatt.
On Mon, 24 Dec 2001, Nicholas Clark wrote:
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
It looks like it is going to need some
On Mon, Dec 24, 2001 at 03:19:39PM -0300, Daniel Grunblatt wrote:
I think we should leave all that for an optimizer.
I agree with that
Sorry, my point wasn't clear:
I believe the current JIT description syntax precludes making a good optimiser.
By making all ops pass by reference, with no
Nicholas --
Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
Dan likes C-like syntax as much as possible in
Gregor N. Purdy:
# Parrot_set_i_i(in,out): \x8b \x0d IR2 \x89 \x0d IR1
#
# I'm tempted to push the specification of this information all the way
# back to the syntax of .ops files, since the code that lives there
# should behave the same wrt read/write on args.
#
# Dan likes C-like syntax as
Dan and Michael --
$ ./test_parrot -j examples/assembly/mops.pbc
Illegal instruction
That's not supposed to happen is it? Its Linux/PowerPC, so maybe it
is supposed to happen.
It's sort of supposed to happen. It shouldn't work, at least--we need
better error checking and such,
All --
$ ./test_parrot -j examples/assembly/mops.pbc
Illegal instruction
That's not supposed to happen is it? Its Linux/PowerPC, so maybe it
is supposed to happen.
It's sort of supposed to happen. It shouldn't work, at least--we need
better error checking and such, so
On Fri, 21 Dec 2001, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
To run a program with the JIT, pass test_parrot the -j flag and watch it
scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
mops.pbc of 35x) but it's
In message [EMAIL PROTECTED]
Daniel Grunblatt [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2001, Tom Hughes wrote:
I suspect it is also rather questionable to call system calls
directly rather than going via their C library veneers - that is
even more true when you come to things
Don't forget that (if I'm missing somthing) by the time that pbc2c.pl
work with all the ops it will be much slower than the jit.
Daniel Grunblatt.
On 21 Dec 2001, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Daniel Grunblatt [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2001, Tom
On Thu, Dec 20, 2001 at 07:37:42AM -0500, Gregor N. Purdy wrote:
I see Simon already changed 'cp ...' to 'perl -MFile::Copy...'. I just
changed that to '$(PERL) -MFile::Copy...'.
NT 4.0's cmd shell does not like single quotes.
diff -r1.82 Makefile.in
22c22
platform$(O) $(CLASS_O_FILES)
Brent --
First of all, 'cp' is NOT always available, yet you used it in the
Makefile. I edited the Makefile to change the 'cp' to 'copy' and turned
slashes to backslashes. Then, I get a ton of errors about stuff like
this:
include\parrot\jit_struct.h(7) : error C2059: syntax error
Brent --
Give it another try. I just messed with jit2h.pl to make it not
generate empty brace pairs.
Regards,
-- Gregor
/Inspiration Innovation Excellence (TM)\
Gregor N. Purdy
On Thu, Dec 20, 2001 at 02:20:45PM +, Simon Cozens wrote:
I'm sure this shouldn't be. Anyone got any clues?
Me! The following seems to be an off-by-one error:
diff -d -u -r1.1 jit.c
--- jit.c 20 Dec 2001 01:57:01 - 1.1
+++ jit.c 20 Dec 2001 14:24:32 -
@@ -70,7
Gregor N. Purdy:
# Give it another try. I just messed with jit2h.pl to make it not
# generate empty brace pairs.
Builds beautifully now. Thanks.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
Nothing important happened today.
--George III of England's diary entry for
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 are
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 to
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
At 02:46 AM 11/8/2001 -0600, Dave Goehrig wrote:
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
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.
98 matches
Mail list logo
