[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Internet C++

From: Marco Manfredini
Subject: Re: [DotGNU]Internet C++
Date: Wed, 08 Aug 2001 07:58:49 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801

Jose Gonzalez wrote:
> Hello everybody.
> I'm new in this forum so i'm sorry if what I say has already been
> mencioned before or it's not right at this moment
> (anyway, I haven't seen anything about this in the FAQs)
> If my ideas are OK, Melody is a intermediate step to accommodate several
> high level languages, with
> different features (pointers, multiple inheritance,...) over a bytecode
> choosen from several posibilities (JVM, M$ CLR ,..)
> My question is: it's not posible to solve this problem using the an
> appropiate bytecode? I mean something like Internet C++

Regarding Internet C++. I quote Rhys Weatherley's comment from the dotGNU-arch list here:

 "This project cropped up on Slashdot last October.
 It isn't really "open source", so much as "available source".
 The core VM engine was over 200,000 lines of
 autogenerated C code, generated from some template
 that wasn't supplied.

The Slashdot article is

 My message pulling it apart is there: search for
 "rhysweatherley".  In a nutshell: wrong design,
 and totally insecure.  If this was used for DotGNU,
 it would need to be completely rewritten.  It looks
 like the code hasn't been updated since October,
 so the maintainer has dropped off the map."

A quick and clean kill.

Melody is (would be), to have a high-level representation of code, which removes the need for the compiler implementor to put implementation details into the generated code. For example, a C++ compiler must somehow stem destructor cleanup into the byte-code and he would, say, generate tables with cleanup handlers, which an exeception handler would need to interpret. In other words: we had to define /the one ABI/ for that, which every language must to follow. But the JavaVM and the M$-ABI already have their own ways to deal with exceptions - And this would mean, that our compiler would need to know, for which target they produce, in order to know which ABI they had to serve.

Melody then, would offer the source language a way to say: "I introduce a variable here, and it is valid during this expression and after that expression is done (not matter if it succeeded), I want that this cleanup expression is done". And now it's a matter of the Melody=>M$-IL or Melody=>JavaVM or Melody=>GCC translator to figure out how that constraints can be mapped on the ABI of the target architecture.

In short: Melody would be like a firewall between the source language and the target platform. And hopefully efficient if interpreted as target machine itself.

Greetings, Marco


I am not sure if that's official. But I doubt that everyone one this list endorses HTML posts. multipart/html triples the traffic without adding one bit of information. Also you can expect, that not everyone has a mail client that can display HTML, and if he could, I would bet that the feature has been turned off.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]