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
invokedynamic should fall in this category, unless they have an
interpreter ready as well. So the obvious target for that would be kind
of an invokedynamic replacement.
But I strongly assume, that the strengths of truffle can't be played out
like this. That's what it makes an implementation approach wall. And
then there is the problem that you may have to support environments
without truffle.
bye Jochen
Am 30.08.2014 06:15, schrieb Thomas Wuerthinger:
Mark,
It is possible to use Truffle for parts of the functionality of your
language while the language itself is implemented with a bytecode
generation approach (e.g., native extensions or regular expressions).
Overall, I still believe that sometimes a larger step is needed when
current techniques start to reach local maxima.
Regards, thomas
On 29 Aug 2014, at 22:59, Mark Roos <mr...@roos.com
<mailto:mr...@roos.com>> wrote:
Moving from the startup thread.
Thomas has been wondering why using Truffle as a solution is not
getting immediate
traction. I was initially, and continue to be, quite interested in
Truffle. So how could
Truffle help out us non Java on the JVM developers to the point where
we could be a
driving force behind it. First note that myself and I would guess all
language implementers
( as compared to researchers ) are like Marcus, very pragmatic. Small
changes are welcome
but wholesale ones are seen as a barrier. So to use Truffle I would
want to see it as an
addition to the jvm which addresses one of my specific issues.
The issue that I have where the solution is not evident is in the
creation of primitive
methods. A primitive method in Smalltalk takes the arguments and some
constants
and executes object code to deliver the result. Traditionally written
C or assembler
I now use Java and JNI. Since we have the equivalent to value types
(wrapped byte[])
primitives can be quite important for our vector math ops performance.
What would be very nice would be to attach a truffle.jar, pass it some
data structure
which defines a primitive and get back a method handle wrapping some
optimized object code.
Given that this MH comes from a known source perhaps the jni like
overhead could
be much reduced similar to an intrinsic.
This would be much simpler, I would guess, then the Panama effort to
wrap arbitrary code.
Plus I would not have to have a pre made object file per external
environment.
regards
mark_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net <mailto:mlvm-dev@openjdk.java.net>
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
