Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of davanum@gmail.com designates
 64.233.170.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JeGBrEiBLsbKqX5FOCUpHXo9Bx3FXwwzYGW7keTKi1WRhWqOiuVasFco55ovgPA41GtzHMym8zBZHIDl4bjt/8f8NszjIWcy2gGyebsc6W/GkEwa1GShzBvB51J43cIgk8iYeVN7Wreyl3EoCuTRPEPizqcoVMM5YABaHhQ0DY0=
Message-ID: <19e0530f050606092745a25912@mail.gmail.com>
Date: Mon, 6 Jun 2005 12:27:30 -0400
From: Davanum Srinivas <davanum@gmail.com>
Reply-To: dims@apache.org
To: harmony-dev@incubator.apache.org
Subject: Re: Other interesting papers and research
In-Reply-To: <20050606.223052.304097499.shudo@aist.go.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
 <OFCC30D7B4.A7532A88-ON85257018.00432E1E-85257018.0044548E@us.ibm.com>
	 <20050606.213444.607090211.shudo@aist.go.jp>
	 <d58509a805060606584b2dbe84@mail.gmail.com>
	 <20050606.223052.304097499.shudo@aist.go.jp>

Found a paper from David too...
http://www.research.ibm.com/people/d/dgrove/papers/cgo05.html

On 6/6/05, shudo@computer.org <shudo@computer.org> wrote:
> Hi Rob,
>=20
> > From: Robert Lougher <rob.lougher@gmail.com>
> > Date: Mon, 6 Jun 2005 14:58:45 +0100
>=20
> > > > One thing to
> > > > note is that a threaded interpreter would see something like a 2-4x
> > > > expansion over "normal" bytecodes when it converts from bytecodes t=
o its
> > > > internal form (arrays of function pointers).
> > >
> > > Direct threading interpreters like JDK's one work on plain Java
> > > bytecode and they do not need to expand normal bytecode instructions.
> > > Such expansion may have been required if Java bytecode is not linear
> > > and rather a tree or other complicated form.
> >
> > According to my understanding, an indirect threaded interpreter uses
> > the original bytecode stream.  It's indirect because the handler
> > address must be looked up via the bytecode.
>=20
> Ah, thanks for the indication.
> My wording 'direct threading' was not correct.
>=20
> Threading (interpreting) techniques I referred as implemented in JDKs
> should be called 'token threading', neither direct nor indirect threading
> because they work directly on bytecode instructions withought any expansi=
on.
> Note that the interpreter provides NEXT routines to for all native
> code fragments corresponding to VM instructions.
> For JVM, this wording like something threading is not very informative
> because direct interpretation of portable bytecode is naturally
> 'token threading'.
>=20
> Dave's last posting was based on direct threading technique and his sayin=
g
> was correct about direct threading but my posting was incorrect in advanc=
e.
>=20
>   Kazuyuki Shudo        shudo@computer.org      http://www.shudo.net/
>=20


--=20
Davanum Srinivas - http://webservices.apache.org/~dims/