Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
2nd attempt at datatype-agnostic bytecode (via MethodHandles)
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Miguel Garcia  
View profile  
 More options May 5 2012, 4:28 pm
From: Miguel Garcia <miguel.gar...@tuhh.de>
Date: Sat, 5 May 2012 13:28:10 -0700 (PDT)
Local: Sat, May 5 2012 4:28 pm
Subject: 2nd attempt at datatype-agnostic bytecode (via MethodHandles)

After exploring the JSR-292 API, looks like dataflow-style keeps the code
free from hardcoded signatures that expose datatypes (int, float, etc). It
would be great to hear from  projects testing this approach. For example,
adding three operands (either ints or floats) in a datatype-agnostic manner
becomes:

@ForceInlining public final
MethodHandle add3(MethodHandle rand1,
                  MethodHandle rand2,
                  MethodHandle rand3) {
  return add2(add2(rand1, rand2),
              rand3);

}

@ForceInlining public final
MethodHandle add2(MethodHandle a,
                  MethodHandle b) {
  // assert: both operands have the same datatype (int or float)
  if(a.type().returnType() == INT) {
    int result = (   (int) a.invokeExact() // this triggers all
side-effects of evaluating the first operand
                   + (int) b.invokeExact()
                  )
    return constantMH(result);
  } else {
    ... // ditto for float

}

The compilation scheme above does without reifying everything into MHs,
e.g. loops, try-catch-finally, and all of switch, ternary operation,
if-then stmt; can appear in their plain formulation. On the other hand,
accesses to datatype-dependent fields and local vars has to be mediated via
MHs.

I really hope the above can be made to run at native speed (after inlining
and tracing).

P.S.: It would be great to have an API for the above besides the current
one ;)

Miguel
http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Miguel Garcia  
View profile  
 More options May 14 2012, 5:26 am
From: Miguel Garcia <miguel.gar...@tuhh.de>
Date: Mon, 14 May 2012 02:26:27 -0700 (PDT)
Local: Mon, May 14 2012 5:26 am
Subject: Re: 2nd attempt at datatype-agnostic bytecode (via MethodHandles)

I've concretized the ideas around using MethodHandles for "runtime
specialization" (to avoid autoboxing, an aspect very close to our hears
when compiling Scala code). It's all still experimental but the approach is
definitely multi-language, comments are welcome:

Write-up:
http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2012Q2/Runt...

Prototype: https://github.com/magarciaEPFL/MethodHandleUtils

Miguel
http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »