Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of kumpera@gmail.com designates
 64.233.170.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nzzzha5ukzBMS0JGrJQMaBe3rIBtE0wz0G3FmhnBA+8R6N83odIbRXsJ4h5JwMahjgMPu5WHkxtbN7lIi86/dHC2r5Eijo0umrI7/DEa4Ijq/fGyvA0ayp1gZ0fEVo5pZNL3JQNUPh2+uslVLECWOlyLJPiwKVjsfIph3Ye/Xns=
Message-ID: <8cca42d805051419354d39f0f4@mail.gmail.com>
Date: Sat, 14 May 2005 23:35:34 -0300
From: Rodrigo Kumpera <kumpera@gmail.com>
Reply-To: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Compilation of other languages
In-Reply-To: <138269925.1116109657731.JavaMail.root@set.superlinksoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <A7874652-9AB7-4CBD-8AAC-811A889FBEAE@mac.com>
	 <1ae253ac05051411416b7c96d4@mail.gmail.com>
	 <138480906.1116096976967.JavaMail.root@set.superlinksoftware.com>
	 <1116105962.5879.21.camel@localhost>
	 <138269925.1116109657731.JavaMail.root@set.superlinksoftware.com>

It's never that simple. Python have some HUGE diference in terms of
semantics and runtime behavior for Java or .NET. People already
mentioned about the fact that it uses reference counting, this makes
object lifetime more predictable and all libs uses this fact.
Emulating this big semantic diference is not a simple talk.

Not to mention the fact about the C native api that must be present as
most libs use that and that it uses cooperative multi-threading.

ORP seens to be the JVM with more work on this area, it allows the
plugged GC to interfere with the JIT process (insert write barriers /
card marking) in a nice modular way.

Using Java for writing a JVM is good for academic and educational
purpoises only. I mean, even JikesRVM doesn't use Java, it's a
proprietary extension with provisionings for pointer arithmetic and
unsafe operations.

Compare that to C/C++, that once the code is generated it's a single
system call away from execution.

There is too much kludge required to have Java doing trivial things
like atomic compare and swap, flushing the TLB, using memory barriers,
doing a cpu id, changing the some bits of the configuration register
for the FPU, etc...

Again compare that to C/C++, most of then are trivial inline asm statements=
.


Rodrigo

On 5/14/05, acoliver@apache.org <acoliver@apache.org> wrote:
> I'm disinterested in the discussion of the value of other language
> support from the perspective that you've given, but I
> do disagree with your premise that multiple language support at the VM
> level requires API agreement.
>=20
> API agreement is only required if you do not have open implementations
> or bytecode implementations of the API.  Meaning
> if I have all of the python APIs and a way to interpret/compile python
> bytecodes then no API agreement is required.  There
> might be issues required for cross language expression.  (calling
> conventions etc)  That however is another issue entirely.
>=20
> I do not think it is practical to create this type of VM for C/C++.  I
> think harmony's focus should be a JVM but if a desire is expressed
> for more cross langauge capabilities, then basically focus on higher
> level languages like Java, C#, Python etc.. C/C++ require a much lower
> level effort in my opinion.  (though it is a very interesting idea :-) )
>=20
> -andy
>=20
> Matthew French wrote:
>=20
> >On Sat, 2005-05-14 at 12:19 -0700, acoliver@apache.org wrote:
> >
> >
> >>I'd actually like to at least entertain the architectural idea implied
> >>by other "language" support.
> >>
> >>
> >
> >I think supporting other languages should be easy enough. Structs and
> >enumerations, for example, can be mapped to specific types of classes. A
> >VB variant is just another class. Pointer arithmetic would require some
> >interesting hacks but could be done.
> >
> >The problem for me would be mapping API's to the class libraries. To get
> >code written in other languages to work in a Java would require not only
> >a mapping from the API of the original language, but also an
> >understanding of the semantics.
> >
> >.Not[1], er, .Net manages this by, for example, making Visual Basic .Net
> >a different language to the previous versions. AFAIK it also requires
> >C/C++ developers to learn a new API, but C/C++ developers should be used
> >to that by now. :(
> >
> >So you either have the ability to write Java code in other programming
> >languages but cannot compile something written for a different set of
> >API's (interesting, but not particularly helpful). Or you use an
> >enormous amount of effort to produce something with dubious value.
> >
> >- Matthew
> >
> >[1] My own private joke, not to be taken literally: Java is write once,
> >run anywhere. .Net is write many times, run once.
> >
> >
> >
>=20
> --
> Andrew C. Oliver
> SuperLink Software, Inc.
>=20
> Java to Excel using POI
> http://www.superlinksoftware.com/services/poi
> Commercial support including features added/implemented, bugs fixed.
>=20
>