On Sep 21, 2005, at 11:11 AM, Tom Tromey wrote:
"Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
On the other hand, a fast code-generating JIT can call runtime
helpers and native methods without additional glue code whereas an
interpreter has to have special glue code to make it work in a JIT
environment.
Geir> I believe you, but I don't understand this. Can you explain
in more
Geir> detail?
It is about handling calling conventions.
[SNIP]
Thanks
Our experience is that a fast, zero optimizing JIT can yield low-
enough response time. So, I think at least Harmony has the option
of having a decent system without an interpreter. Thoughts?
Geir> Basic thought is yes, I always figured we'd have this
pluggable, with
Geir> an interpreter for ease of porting, and then platform-
specific JIT.
It seems to me that there's a design question here. For instance, if
you want to eventually take interpreted code and compile it (when it
is "hot"), for full pluggability your JIT(s) and your interpreter need
to agree on some set of bookkeeping details in order to make this
possible. OTOH, you could make other decisions that make this problem
go away, for instance having a single choice of execution engine up
front; so the "fast JIT" and the "optimizing JIT" are just part of the
same code base and only need to talk to each other, and can be built
in an ad hoc way.
Personally I'd be just as happy if we only had a JIT. There are
already plenty of interpreters out there.
But I would think that we'd want both, right? An interpreter that
builds on anything to ensure wide platform portability, with the the
ability to augment with a JIT for those platforms for which people
are interested in creating a JIT...
geir
Tom
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
