Re: Build Problems Resolved Paul Snively (psnively@earthlink.net)
Sun, 05 Sep 1999 10:34:16 -0500

--------------A77007D1A047F2C111EE53C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi again, Mark!

"Mark S. Miller" wrote:

> You're conjecturing here exactly the kind of coupling of issues I hope
> we don't have. I hope that achieving any one of our goals now has
> less relationship to achieving other goals "at the same time". Better
> to achieve these goals separately. While I often see benefits from
> simultaneous solutions (and as MarcS will point out, I am too often
> the perpetrator of such), I don't understand how that would occur
> here. In particular, I don't see the coupling between any of the
> other issues and EROS.
>

Thank you for clarifying that I'd failed to make myself clear. ;-) I am absolutely NOT advocating tight implementation coupling--far from it. If I'm saying anything, I'm saying that E as it stands right now strikes me as *having* too-tight coupling, in particular to being Java-based, and that *perhaps* a closer look at the parsing/interpreting components *might* lead us to an alternative approach--ANTLR/tree parsing-based or otherwise--that lends itself to *abstracting out* the entire codegen process so that we could *both* go Java bytecodes, thereby getting us everywhere we currently are but hopefully in a more modular fashion, *and* go native to various processor/OS combos, e.g. EROS on Pentiums.

>
>
>> > I'd be most interested in hearing more about this. The last I
>> > heard, ColdStore was under consideration for integration, but it's
>> > hard to see how this would happen in Java without JNI and lots of
>> > wrappers--apart from reimplementing the JVM atop ColdStore, which
>> > is what the ColdStore folks would seem to prefer anyway. But once
>> > again, if your'e going to do that, targeting EROS seems no harder.
>>
>
> While KeyKOS and EROS are the most language-like operating systems
> most of us have ever seen, EROS is still not a language runtime. I
> don't understand how EROS would substitute for ColdStore or jvms.
>
>> >
>>
My point here was just that once you introduce native anything through JNI, you might just as well put forth the moderate extra effort to get where else you wish to be. I should confess that when I think of ColdStore and EROS, the commonality I see consists of orthogonal persistence, and I gloss over the myriad implementation differences that would clearly be necessary to target the two systems.

>> > >Many of us are interested in E on Eros, the holdup there is
>> > getting a jvm >on Eros.
>> >
>> > Once again, I wasn't thinking of running E in Java on EROS; I was
>> > thinking of a native port with a native runtime.
>>
>
> How would such a native runtime benefit from being EROS specific,
> rather than portable (at least to the other 3 platforms)? Once E (via
> a port of some language-implementation platform) is on EROS, there are
> great opportunities for marrying these two systems, but this seems
> orthogonal from building a language runtime in the first place.

Truthfully, I don't know. I *suspect* by making EROS address the issue of orthogonal persistence rather than E. I haven't thought any of this through completely, nor have I groveled over the code, so I'm quite literally just thinking out loud at this point--my apologies if it's wasting too much of your time.

>
>
> In any case, no matter where else it goes, E will also stay on the
> pure-java/pure-jvm platform. The jvm is the x86 architecture of
> hardware-portable symbolic computing.
>

A true prospect as depressing as the true prospect that the x86 architecture is the x86 architecture of the personal computing world.

>
> Cheers, --MarkM

Regards,
Paul

--------------A77007D1A047F2C111EE53C3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> Hi again, Mark!

"Mark S. Miller" wrote:

You're conjecturing here exactly the kind of coupling of issues I hope we don't have.  I hope that achieving any one of our goals now has less relationship to achieving other goals "at the same time".  Better to achieve these goals separately.  While I often see benefits from simultaneous solutions (and as MarcS will point out, I am too often the perpetrator of such), I don't understand how that would occur here.  In particular, I don't see the coupling between any of the other issues and EROS.
 
Thank you for clarifying that I'd failed to make myself clear. ;-) I am absolutely NOT advocating tight implementation coupling--far from it. If I'm saying anything, I'm saying that E as it stands right now strikes me as *having* too-tight coupling, in particular to being Java-based, and that *perhaps* a closer look at the parsing/interpreting components *might* lead us to an alternative approach--ANTLR/tree parsing-based or otherwise--that lends itself to *abstracting out* the entire codegen process so that we could *both* go Java bytecodes, thereby getting us everywhere we currently are but hopefully in a more modular fashion, *and* go native to various processor/OS combos, e.g. EROS on Pentiums.
 
I'd be most interested in hearing more about this. The last I heard, ColdStore was under consideration for integration, but it's hard to see how this would happen in Java without JNI and lots of wrappers--apart from reimplementing the JVM atop ColdStore, which is what the ColdStore folks would seem to prefer anyway. But once again, if your'e going to do that, targeting EROS seems no harder.


While KeyKOS and EROS are the most language-like operating systems most of us have ever seen, EROS is still not a language runtime.  I don't understand how EROS would substitute for ColdStore or jvms.

 
My point here was just that once you introduce native anything through JNI, you might just as well put forth the moderate extra effort to get where else you wish to be. I should confess that when I think of ColdStore and EROS, the commonality I see consists of orthogonal persistence, and I gloss over the myriad implementation differences that would clearly be necessary to target the two systems.
>Many of us are interested in E on Eros, the holdup there is getting a jvm >on Eros.

Once again, I wasn't thinking of running E in Java on EROS; I was thinking of a native port with a native runtime.


How would such a native runtime benefit from being EROS specific, rather than portable (at least to the other 3 platforms)?  Once E (via a port of some language-implementation platform) is on EROS, there are great opportunities for marrying these two systems, but this seems orthogonal from building a language runtime in the first place.

Truthfully, I don't know. I *suspect* by making EROS address the issue of orthogonal persistence rather than E. I haven't thought any of this through completely, nor have I groveled over the code, so I'm quite literally just thinking out loud at this point--my apologies if it's wasting too much of your time.
 

In any case, no matter where else it goes, E will also stay on the pure-java/pure-jvm platform.  The jvm is the x86 architecture of hardware-portable symbolic computing.
 

A true prospect as depressing as the true prospect that the x86 architecture is the x86 architecture of the personal computing world.
 
         Cheers,        --MarkM


Regards,
Paul
  --------------A77007D1A047F2C111EE53C3--