Truffle and mlvm

[Jochen Theodorou]

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 <mroos at roos.com
> <mailto:mroos at 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 at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at 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