Thomas, for me the most easy target for truffle are interpreter based
languages.
What would be really nice is to have some kind of migration tutorial,
which shows the steps involving the transformation of a bytecode
producing runtime to truffle. Almost all language implementors using
Am 29.08.2014 21:19, schrieb Jochen Theodorou:
[...]
Maybe the situation would
already improve if I would make callID, safeNavigation, thisCall,
spreadCall into one int
addendum to this... I actually already have those as single int. I tried
moving all that information into the callsite
Jochen,
Yes, interpreter based languages are easier to migrate. It is possible to
simulate invokedynamic and the method handle chain with Truffle trees.
Unfortunately, I do not expect this to mitigate the issues of the invokedynamic
architecture that people have been discussing here. The best
Removing all context, so it's clear this is just my opinions and thoughts...
As most of you know, we've opened up our codebase and incorporated the
graciously-donated RubyTruffle directly into JRuby. It's available on
JRuby master and we are planning to ship Truffle support with JRuby
9000, our
Am 30.08.2014 14:20, schrieb Thomas Wuerthinger:
[...]
Regarding environments supported by Truffle: Truffle interpreters are
regular Java programs and therefore run on any JVM. For backwards
compatibility, it is possible to build a Truffle backend that
automatically generates bytecodes.
can
Thanks a lot, Charlie, for this very detailed feedback! In fact, this is
probably the most comprehensive feedback we’ve received for Truffle so far :).
There are some valid points, some points where I’d like to add a comment, and
some where Graal and Truffle may have been misunderstood. I’ll
Comment on Jochen's long stack traces.
The difference must be in how our languages expect the call site to
resolve.
In my case I compile all of the target methods to match the callsite stack
structure.
So the fast path adds no additional manipulations ( binds etc ) between
the callsite
and the
