Tom,
Thanks for being on topic. This thread has drifted all over the place.
I wasn't thinking clearly on the proposed interface. Your suggestion
is the correct way to go. I was originally thinking that the below
interface would be macros that are used to pull the relevant bits out
of the
Geir,
Any update on when Apache will have a license in place so that code
can be donated to Apache Harmony project?
Thanks
Weldon
On 6/24/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
On 6/23/05, Geir Magnusson Jr. [EMAIL
Hi Rafal,
My guess is that there are a dozen people on this list right now who,
given a month, could build a simple VM from scratch, on their own.
However, building something like ORP or Jikes RVM is an enormous task,
well beyond the scope of any individual.
In other words, I don't think
On 6/26/05, Rafal Lewczuk [EMAIL PROTECTED] wrote:
Hi,
Newbie's thoughts below.
On 6/25/05, Ahmed Saad [EMAIL PROTECTED] wrote:
2. which current VM implemention would we start refining as a core for
Harmony? (or we would write it from scratch)
Newbie's random thought: start with some
Hi Steve,
First of all, I'd like to say I've found the discussions on this list
very interesting. I don't want anybody to take my comments the wrong
way. I'm not annoyed or offended in the slightest by people saying
JamVM is simple or trivial -- I simply wanted to put the record
straight. Many
On 6/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Where is code we can start examining? What do the the java-on-java
implementations do?
geir
Geir,
I can't talk about code just yet. But I think we can at least get
started on the basic, low controversy APIs. For example, the
On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
On 6/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Where is code we can start examining? What do the the java-on-java
implementations do?
geir
Geir,
I can't talk about code just yet.
I know, but I'm going to taunt you anyway!
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.
The API between a Java JITer and a C JVM should be coarse grained
since cross-language calls are slow. ORP defines a very nice
On Jun 24, 2005, at 5:47 PM, Rodrigo Kumpera wrote:
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.
The API between a Java JITer and a C JVM should be coarse grained
since
On 6/24/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know, but I'm going to taunt you anyway! Taunt!
Seriously, how about referring us to code in ORP at sourceforge?
You can download the last research posting of ORP from
http://sourceforge.net/projects/orp.
Two files in the bundle are
On 6/25/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
So this API is really for the classes Method, Field and Class, rather
than a bigger C API. Does this make it harder for other languages to
use or implement? (I have to admit it's going to take a few to start
thinking in C again...)
Jikes RVM has similar kinds of abstractions, but in Java of course ;-)
It's a pretty wide API since there are lots of things the JIT wants to
know about the program being compiled.
The javadoc for the system is online at
http://jikesrvm.sourceforge.net/api/index.html. The package of
12 matches
Mail list logo
