Build Problems Resolved

[Mark S. Miller]

--=====================_67959250==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 09:34 AM 8/31/99 , Paul Snively wrote:
>That's also good news, but does it get us closer to accomplishing other 
>goals at the same time? My point from my original e-mail on the subject 
>was that a rewrite might afford us the opportunity to unify what currently 
>would need to be disparate approaches to things, e.g. bytecode-generation 
>would be one thing and getting on EROS would be another, whereas a rewrite 
>of the interpreter/compiler could get us closer to both by accomodating 
>the notion of multiple targets, where Java bytecodes were one such target 
>and native Pentium-family code with an appropriate native runtime for, 
>e.g. EROS would be another.

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.

>>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.

>> >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.

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.


         Cheers,
         --MarkM

--=====================_67959250==_.ALT
Content-Type: text/html; charset="us-ascii"

At 09:34 AM 8/31/99 , Paul Snively wrote:

> That's also good news, but does
> it get us closer to accomplishing other goals at the same time? My point
> from my original e-mail on the subject was that a rewrite might afford us
> the opportunity to unify what currently would need to be disparate
> approaches to things, e.g. bytecode-generation would be one thing and
> getting on EROS would be another, whereas a rewrite of the
> interpreter/compiler could get us closer to both by accomodating the
> notion of multiple targets, where Java bytecodes were one such target and
> native Pentium-family code with an appropriate native runtime for, e.g.
> EROS would be another.


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.


> > 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.


> > >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.


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.



        Cheers,

        --MarkM


--=====================_67959250==_.ALT--