Nicholas Clark wrote:
I'd suggest committing it, rather than sending it to the list.
Ok, I'll do that after checking again on a second machine
... I think it would be better to write them into a design doc
I'll include docs/dev/jit_i386.dev with has most of the gory details.
Nicholas
On Thu, Feb 13, 2003 at 06:34:55PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Thu, Feb 13, 2003 at 04:43:37PM +0100, Leopold Toetsch wrote:
> >>Should I commit it or send to the list first?
> >>
> >
> >I don't know. Are you confident in it? Does it pass all Parrot's regression
Nicholas Clark wrote:
On Thu, Feb 13, 2003 at 04:43:37PM +0100, Leopold Toetsch wrote:
Nicholas Clark wrote:
JIT/i386 uses the stackframe of CGP for its own. When there is a
sequence of non-JITed functions, JIT code braanches directly into the
CGP core and executes the CGP ops. Going back
On Thu, Feb 13, 2003 at 04:43:37PM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> > The idea actually works at all?
>
>
> I have it running now.
Can you write an opcode that solves the halting problem? :-)
> JIT/i386 uses the stackframe of CGP for its own. When there is a
> sequence
Nicholas Clark wrote:
On Tue, Feb 11, 2003 at 10:49:14AM +0100, Leopold Toetsch wrote:
Leopold Toetsch wrote:
Or go the other way round: Run from JIT. If there is a sequence of non
JITable ops, convert these to a CGP section, which returns to JIT when
finished. This would save a lot of fu
Nicholas Clark wrote:
On Tue, Feb 11, 2003 at 10:49:14AM +0100, Leopold Toetsch wrote:
I failed to follow most of the specific details, and all of the x86 specific
stuff.
Basically, all non JITed opcodes, which are now called functions
(Parrot_jit_normal_op) would instead get jumped to in
On Tue, Feb 11, 2003 at 10:49:14AM +0100, Leopold Toetsch wrote:
> Leopold Toetsch wrote:
>
> >Nicholas Clark wrote:
>
> >>Inside a cgoto core have 1 extra op - enter JITted section.
>
> >Or go the other way round: Run from JIT. If there is a sequence of non
> >JITable ops, convert these to a C
Leopold Toetsch wrote:
Nicholas Clark wrote:
Inside a cgoto core have 1 extra op - enter JITted section.
Or go the other way round: Run from JIT. If there is a sequence of non
JITable ops, convert these to a CGP section, which returns to JIT when
finished. This would save a lot of functio
Simon Glover wrote:
Hi all.
The new CGP code causes compilation of interpreter.c to fail if
HAVE_COMPUTED_GOTO is undefined.
Ah, yes thanks. I have checked in a fix.
leo
Hi all.
The new CGP code causes compilation of interpreter.c to fail if
HAVE_COMPUTED_GOTO is undefined. This is because it references
Parrot_DynOp_core_cgp_0_0_9, which is defined in core_ops_cgp.h,
and the latter is only included when HAVE_COMPUTED_GOTO is defined. This
bug appears to be
Jerome Vouillon wrote:
On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote:
This is one thing I allways wanted to try ;-)
fast_core MOps: 11
Prederef: 17.5
CGoto MOps: 19.4
CGP MOps: 27.5
CGP -O3 MOps: 65 !!!1
Why not also predereference the operation address
If memory serves me right, Nicholas Clark wrote:
> I had a (possibly) impractical idea - computed goto / JIT
> (or even computed goto / prederef / jit) core
>
> I don't know whether this is possible:
>
> Inside a cgoto core have 1 extra op - enter JITted section.
>
> The bytecode is "compiled"
Nicholas Clark wrote:
I had a (possibly) impractical idea - computed goto / JIT
(or even computed goto / prederef / jit) core
I don't know whether this is possible:
Inside a cgoto core have 1 extra op - enter JITted section.
The bytecode is "compiled" by the JIT (at some point) - if there are
On Sat, Feb 08, 2003 at 03:10:58PM +, Nicholas Clark wrote:
> The bytecode is "compiled" by the JIT (at some point) - if there are a run
> of consecutive JIT-able ops, then issue a section (an isolated section) of
> machine code for those ops, and replace those ops in the bytecode with an op
>
On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote:
> This is one thing I allways wanted to try ;-)
>
> fast_core MOps: 11
> Prederef: 17.5
> CGoto MOps: 19.4
> CGP MOps: 27.5
> CGP -O3 MOps: 65 !!!1
>
> This runloop combines the faster dispatch of opcodes via compu
Melvin Smith wrote:
At 10:12 PM 2/6/2003 +0100, Leopold Toetsch wrote:
Improvements welcome - and I'm a really bad C programmer, I won't do it.
*cough*
If you are a "bad" C programmer, what is your "good" language? :)
I don't have one. But IMHO I have a fair survey over the whole (except
At 10:12 PM 2/6/2003 +0100, Leopold Toetsch wrote:
Improvements welcome - and I'm a really bad C programmer, I won't do it.
*cough*
If you are a "bad" C programmer, what is your "good" language? :)
-Melvin
Jerome Vouillon wrote:
CGP -O3 MOps: 65 !!!1
This generates some pretty good code (for instance, for sub_i_i_i) :
Yep. I'd have a look at it, really compact.
Why not also predereference the operation address? This would save a
memory read. The goto would become:
goto **(cur_op
On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote:
> This is one thing I allways wanted to try ;-)
>
> fast_core MOps: 11
> Prederef: 17.5
> CGoto MOps: 19.4
> CGP MOps: 27.5
> CGP -O3 MOps: 65 !!!1
>
> This runloop combines the faster dispatch of opcodes via compu
leo++
Leopold Toetsch <[EMAIL PROTECTED]>
02/06/2003 07:37 AM
To: P6I <[EMAIL PROTECTED]>
cc:
Subject: [CVS ci] CGP - CGoto Prederefed runloop
This is one thing I allways wanted to try ;-)
fast_core MOps: 11
Prederef: 17.5
CGoto MO
This is one thing I allways wanted to try ;-)
fast_core MOps: 11
Prederef: 17.5
CGoto MOps: 19.4
CGP MOps: 27.5
CGP -O3 MOps: 65 !!!1
This runloop combines the faster dispatch of opcodes via computed goto
and the clever register addressing due to predereferencing registers and
21 matches
Mail list logo
