Message from discussion
CGP - CGoto Prederefed runloop
Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <gopal...@softhome.net>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Delivered-To: perl6-intern...@perl.org
Date: Sun, 9 Feb 2003 20:12:59 +0530
To: Nicholas Clark <n...@unfortu.net>
Cc: Leopold Toetsch <l...@toetsch.at>, P6I <perl6-intern...@perl.org>
Subject: Re: [CVS ci] CGP - CGoto Prederefed runloop
Message-ID: <20030209201259.A1583@md3.vsnl.net.in>
Mail-Followup-To: Gopal V <gopal...@symonds.net>, Nicholas Clark <n...@unfortu.net>, Leopold Toetsch <l...@toetsch.at>, P6I <perl6-intern...@perl.org>
References: <3E425716.1000608@toetsch.at> <20030208151058.GE287@Bagpuss.unfortu.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030208151058.GE287@Bagpuss.unfortu.net>; from nick@unfortu.net on Sat, Feb 08, 2003 at 03:10:58PM +0000
X-Useless-Header: Look ma, no windows !
X-SMTPD: qpsmtpd/0.21-dev, http://develooper.com/code/qpsmtpd/
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=1.9 required=7.0 tests=CARRIAGE_RETURNS,DATE_IN_FUTURE_03_06,FROM_ENDS_IN_NUMS,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: gopal...@symonds.net (Gopal V)
Lines: 35
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" 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
> that calls that section. If there isn't a run of JIT-able ops, then just
> leave the ops as ops, and use the regular computed goto core dispatch.
Are you discussing some sort of unroller for native code for some
opcodes ? .. basic blocks ?. Anything too complicated to unroll is
replaced by a jump back into the interpreter core ?..
This strategy has been used in pnet's engine (which is still a souped up
interpreter) ... the motivation was ease of porting unrollers than full
JITs, ie opcode by opcode .
> I'd envisage it becoming a win if PBC often ends up with tight, isolated
> loops that use a lot of JITted ops, but most of the code is ops we've not
See the Unrolling section on Rhys's paper for a detailed discussion on
this idea <http://www.southern-storm.com.au/download/pnet-engine.pdf>
Speaking truthfully , all I know is that it lifts pnetmark score for
loops by about 10 times .
Hope it helps,
Gopal
--
The difference between insanity and genius is measured by success