Jakob Praher <j...@hapra.at> wrote on 05/07/2009 07:09:08 PM:
> Hi Vijay,
>
> thank you for the information. What I would be interested in is are you
> thinking about beeing able to convert/call Java clases/methods from X10?
> Given that there are plenty of libraries it would make sense to be able
> to reuse existing java libraries from within X10, right?
Hi, Jakob,
We do not yet have a robust mechanism to interface with the target
language (a la JNI). The @Native mechanism used in the X10 library
implementation is very fragile and not yet ready for public consumption.
That said, the generated C++ code will not interface with Java (nor the
generated Java code with C/C++). If you want to invoke Java code from
C++, you could use JNI from the hand-written C++ code (similarly for the
Java backend).
> Vijay Saraswat schrieb:
> > Jakob Praher wrote:
> >> I was stumbling over X10 recently. I have some questions:
> >>
> >> * What are your plans with the c++ backend? Do you aim at a two level
> >> integration also w/ legacy code? What was the rationale for directly
> >> generating C++ code?
> >>
> > (Dave is away on vacation this week, so let me step in and respond.)
> >
> > The C/C++ back-end is the main back-end for the statically compiled,
> > high-performance implemenation of X10. (We currently generate C++, but
> > may generate C in the future.)
>
> Do you plan on dynamic code generation with the C++ backend?
No. X10 does not have dynamic class loading, so there is really no
reason to do this. We do have plans to do code generation in the X10
debugger, e.g., for conditional breakpoints, but this will happen
inside the debugger itself, and not in the X10 runtime.
> > Integration with legacy code is already possible. X10 can call C++
> > through @Native and @NativeRep annotations. For C++ to call X10, the
> > programmer has to know the kind of code generated. We are working to
> > stabilize that and fix the interface so that this will be possible.
>
> Wow this is amazing. Is it able to really call use C++ directly or does
> one have to export the C++ through C. Sorry for my ignorance, it is
> stated somewhere for sure.
It calls C++ directly, but the C++ code has to be in the form that the
generated code expects. That's why this mechanism is really fragile.
We are planning to develop a more robust mechanism in the future, but
there is no timeframe for those plans yet.
Since the mechanism is for internal consumption, it's not really described
anywhere in detail. The best bet for experimenting with it is to copy
bits the X10 library code and adapt them to your uses.
> > Compiling to C/C++ is a fairly common strategy for high-level
languages.
> > The upside is that it gives you working implementations with decent
> > performance quickly on a variety of architectures. The downside is
that
> > you have to rely on a longer tool chain (a native C/C++ compiler, like
> > gcc and xlc) which does not know anything about X10 semantics. So you
> > have to be careful to compile to a subset of C/C++ which you can
> > reasonably expect the native compilers to treat the same way.
> >
> > We are continuing with code development for (enhanced) JVMs. I feel
that
> > VMs are ripe for a significant round of revision to better handle
> > concurrency, distribution and heterogeneity. Stay tuned for more
> > announcements around this in the coming months.
>
> Could you elaborate on enhanced - what JVM is the minimum requirement
> for being able to handle the enhancments? Are you working with the
> JikesRVM to support X10? Does enhanced here state the fact that X10 will
> have its own binary format / bytecodes?
All of the above. Enhanced JVMs means JVMs modified to handle features
needed by X10 (e.g., headerless objects). There will also be an X10
binary
format. We are looking into the Jikes RVM as our initial test platform
for
these experiments.
> > Our goal continues to be to develop a simple, clean modern OO language
> > for concurrency, distribution and heterogeneity. To this end we are
> > innovating in areas that we feel we absolutely must in order to
support
> > our basic goal, while remaining fairly conservative in areas that we
> > feel are now established and non-controversial. In particular we have
> > chosen to stay with the single inheritance/multiple implementation OO
> > structure of Java -- though many changes are coming in 2.0 to support
> > structs. Similarly, we have chosen to stay with the static members of
> > Java.
>
> This sounds interesting. Yet to reissue my question: This was just to
> retain some similarity with Java? Or was there a problem that the Scala
> static free syntax did not allow you to do. IMHO static methods are a
> feature of constant debate in the OO communities...
I'll let others elaborate on the reasons for this.
Igor
--
Igor Peshansky (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
X10: Parallel Productivity and Performance (http://x10.sf.net/)
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users
