From mboxrd@z Thu Jan 1 00:00:00 1970 From: "kazumi iwane" To: <9fans@cse.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <200105011730.NAA24756@augusta.math.psu.edu> Subject: [9fans] RE: native limbo Date: Sun, 6 May 2001 23:11:15 +0900 Topicbox-Message-UUID: 9a7ac738-eac9-11e9-9e20-41e7f4b1d025 > From: Dan Cross > In article you write: > >2) a dis interpreter and plan9 native modules > > > >Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova, > >there already is a limbo-to-dis compiler on plan9 (right? don't know how > >inferno/emu-dependent it is, though). You'd invoke a dis interpreter, > >which would provide gc, syscall i/f and whatnot, to execute limbo apps. > > Hmm, not to be contrary, but isn't this basically what emu does > already? It provides a dis interpreter, plus modules which map native > limbo services into native Plan 9 services (eg, a call to Sys->open() > gets mapped into open(2)). Maybe I'm missing something. In this scenario, I dreamed of having modules that closely match plan9 native system calls, device drivers interface and namespace conventions, but not necessarily those of inferno. Significant overlap, sure. Gratuitous incompatibilities, maybe. In areas where inferno is ahead, notably Tk, I'd steal them and adopt them to plan9 native services :-). Also, a dis interpreter should be a plan9 native executable, so that limbo apps would be just like C apps but interpreted; a web browser written in limbo would run directly in a rio window, you could write a plan9 user level file server in limbo, etc.. I gues I'm on the "yet another language" camp. - kazumi