Intel's Open Runtime Platform Specs 26
prostoalex writes "The new issue of Intel Technology Journal has a lengthy article on a new platform, developed in Intel labs. The Open Runtime Platform: A Flexible High-Performance Managed Runtime Environment describes the platform that is capable of running both Java VM and Microsoft's CLI, on both Windows and Linux platforms. Full PDF version is also available."
Is this... (Score:5, Informative)
Apparently that already runs several languages, including Python and PHP...C++ and Java are definitely supposed to be supported.
I think.
From elsewhere [everything2.com]:
Since it is a virtual machine executing virtual assembler code, there are several different languages that compile to Parrot bytecode - it isn't limited to Perl! Here are some of the languages that have been so far done to varying degrees:
Jako, a C-like language developed for testing Parrot
Cola, likewise, but more Java-like
BASIC
Forth
...and an extremely rudimentary Perl 6 compiler...
What do we think?
Re:Is this... (Score:5, Informative)
This level of separation then allows a better implementation of each of these components to be more easily created. For example, a JIT that supports both Java and CLI is more easy to design and implement. No knowledge of the VM (besides the interface) is needed to do this with ORP.
Overall, a very impressive article.
Re:Is this... (Score:5, Informative)
-Static typing.
-Stack-based (vs. register-based)
The JVM and CLI are both designed for static-typed languages, like Java, C, C++, C#. Parrot's main deviation from previous VMs is its design around dynamically-typed languages like Perl and Ruby, with the corresponding techniques to make this fast.
Furthermore, the JVM and CLI are both stack-based, while Parrot is register-based. These involve different optimization techniques and a different underlying virtualization.
The framework described in the Intel paper is most definitely static-type oriented (they discuss the difference in casting-exceptions in C# and Java, and how they handle it), and most probably stack-oriented (though that doesn't seem specified).
VVM (Score:2, Redundant)
Now, all we have to do is port these to simulated hardware achitectures that exist only in memory - Like a PDP-6 or Mac-512 emulator.
The real value to Intel will be complete!
Article Distilled: (Score:5, Interesting)
All this is implemented in C++. They use opensource class libraries to provide the classpaths.
What I would find really cool is if they can release a microcode-based CPU that runs the superset bytecode. It may simply be a microcode patch to the Itanium. That would be truely wicked.
Re:Article Distilled: Phew! (Score:3, Insightful)
No Microsoft Involvement (Score:2)
machine code Java (Score:1, Interesting)
There have been great speed gains with Java, but it still has enormous memory overhead. I would like to see more numeric computation in Java, but I'm not sure it will with the memory requirements Java typically has.
I know that GCC has a Java ahead-of-time compiler in it, but last time I checked, the memory specs were comparable to the JIT/JVM/whatever it is.
Does anyone know about the memory specs on this? I looked through the paper extremely quickly, and didn't see it in there. I assumed the "performance" tables I was looking at was referring to speed.
Bytecode / microcode (Score:4, Informative)
The bytecode, if executed "as is", can be *extremely* inefficient, as the virtual machine is a stack one.
Modern JITs take a completely different approach to achieve decent performance - they reconstruct the control flow/data flow from the bytecode and then "recompile" (with heavy optimizations, that you can't really do in hardware) into native code. Translating bytecode to instructions directly (or naively) gets you very little benefit over interpretation. The problem is that you can't do more than naive translation in hardware in an efficient manner
The bytecode is very high level - so high level that you can reconstruct the sourcecode from it (modulo local var names). Hardware likes simple stuff, and as a consequence it's not good at executing it efficiently
Interesting (Score:1)
Re:Interesting (Score:1)
intel isn't a corporation?
So what does this mean for virtual machines? (Score:2)
Portable.net (Score:2, Informative)
Re:but Porable.NET is GPL (Score:1, Informative)
Relative performance to microsoft CLI...? (Score:4, Interesting)
The only thing I got from the article was an appreciation of just how much the MS.NET developers copied the Java architecture. It would seem that to achieve the grand unification of CLR and JVM the Intel engineers just had to define a 1-1 mapping between buzzwords
(
gripe: "runtime" is only one word so it should be called MRE... i guess that name was avoided because it is associated with Jim Carey's villan in Batman Forever
)
Re:Relative performance to microsoft CLI...? (Score:1)
One thing is always constant (Score:5, Funny)
Portable Runtime: Processor is constant, others can vary.
ORP Open? (Score:1, Interesting)
Where can I get a copy of this ORP that they talk about so I can make my own comparisons?
If they did release the source code to ORP, would this compete with Sun's Java JVM and Microsoft's
Re:ORP Open? (Score:1)