java interpreter/compiler hosted with Spur?
Locked
12
12
multiple bytecode sets (was: java interpreter/compiler hosted with Spur?)
 
|
Re: java interpreter/compiler hosted with Spur?
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On Jan 29, 2014, at 11:53 AM, Eliot Miranda <[hidden email]> wrote:
In Elib, the refs are involved in a reference state machine, as promises eventually resolve or break, or a remote ref breaks. Here’s the Elib page on this, with diagram: http://www.erights.org/elib/concurrency/refmech.html. I would prefer to get java going with promise-pipelining, but without a wrapper. That requires a JVM that allows reference mutation. I’ve always thought of Cog and building a SqueakJDK. - Robert |
smime.p7s (3K)
Re: java interpreter/compiler hosted with Spur?
|
|
Re: java interpreter/compiler hosted with Spur?
|
|
On Jan 30, 2014, at 8:22 AM, Frank Shearar <[hidden email]> wrote: > On 29 January 2014 18:39, Robert Withers <[hidden email]> wrote: >> >> On Jan 29, 2014, at 7:41 AM, Frank Shearar <[hidden email]> wrote: >> >>> On 29 January 2014 14:16, Robert Withers <[hidden email]> wrote: >>> >>>> The other reason is that I wanted the returned promise to be typed as the real return and let the inferencer do its thing and rewrite send sites from dynamic lookup to direct calls. I was told that Hindley-Milner was what I wanted. *shrug* >>> >>> Um, that sounds a bit weird, to be honest. A promise surely _can't_ be >>> typed as the real return since there _is_ no real return: a promise >>> can break! In Scala-ish terms (I've not written any Scala for about >>> two years...), a Promise[Int] is fundamentally different to an Int >>> because the latter is just a value whereas the former may or may not >>> result at some point in a value. It's only once a Promise has resolved >>> that things get interesting. And it sounds here like this is when >>> you'd like to optimise the Promise wrapper away, right? >> >> I was under the impression that Hindley-Milner was able to construct union types, which is why it was recommended to me. > > Just to be clear, when you say "union" what do you mean? Union like > the C structure, where you can interpret some chunk of memory in > several ways? Or do you mean sum types, where "this variable may > contain a Left or a Right”? - Robert > > frank > >>>> The strategy behind my request is to see if Cog could support multiple languages and modern languages - i.e. broadly used languages. It seems a dynamic runtime is better than a static vm to support both flavors of languages, though runtime feedback type inferencing seems important, in my gut. Maybe it is just cool tech, great for ops. >>> >>> Cog _does_ support multiple languages: Squeak and Newspeak. Given that >>> Ruby can run on top of Gemstone (Maglev), there shouldn't be an issue >>> with running other languages on top of Cog... assuming there's someone >>> sufficiently interested/available to actually _do_ that. (Oh, and of >>> course IBM ran Java on top of a Smalltalk VM in Visual Age for Java.) >> >> It may be clearer for me to say that it would be awfully nice if Cog allowed for bytecode virtualization. In 64-bit values, a couple of bits for bytecode index (have a cache of 4 bytecode sets, so 4 different languages, concurrently executing). Add a bit for a capability/promise for pipelining. All at the expense of the range of the immediates, but maybe that’s ok, I do not know. >> >> >> - Robert > |
for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
Re: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
RE: for the operation MAP := B bitOr:( M bitShift:3) given MAP how do I derive B and M?
|
|
| Free forum by Nabble | Edit this page |