Hardware references.

[Ray Dillinger]

On Fri, 9 Oct 1998, John Morrison wrote:

>Hello Ray (et al);
>
>Well, it's more like the Death Of a Thousand Cuts.  If you need
>something more functional (e.g., you actually need native-code drivers
>for lots of devices), than you might want to either hack the Linux
>kernel (good luck to you) or use the FluxOS Toolkit (I think they pulled
>their most recent distribution back -- I forget why).

The problem, I think, is that the existing native code drivers
and tools are married to C/++ calling conventions, which is
going to be a mis-match requiring interface and "glue code" to
be used.  A different execution model is better for the
dynamically typed paradigm.  

The flipside, of course, is that it is entirely possible to 
modify the c/++ compiler to generate machine code which uses the 
dynamically-typed calling conventions -- so the fact that the
source code comes with Linux/GNU drivers can probably be turned 
to our advantage.

>Can you not just have the box interpret FACE right off?  It would be
>most expedient, and enable other people to help you at the earliest
>possible time.  You could get to self-hosting sooner, and it's always
>instructive to "eat your own dog food" (to quote David Cutler).

Yes, that's where I'm starting.  I've got the FACE interpreter
working, in fact. 

>Frankly, building such a complete toolchain could take years, and it's
>entirely machine-specific.  (By that time, nobody might remember Lisp!)

Um, not really.  Most of the tools are specific to the (virtual)
FACE machine, but the FACE-to-Machine-code translation is
supposed to be easy to implement on any particular machine.

>Understood -- however, trying to implement a Java box, I don't have much
>choice about whether to use bytecode, eh?  Hmmm..., what's wrong with
>JIT compilation for FACE?

Not a thing.  Translating FACE to machine code ought to be
at least as easy as translating Java bytecodes to machine
code.  Probably easier, in fact. 

>Well, there is a lot to be said for compiling to C/C++ code, because
>then you could use existing tools, which have hundreds if not thousands
>of FTE-years invested in them, and some of which are pretty damned good

Yes, that's true.  But there are fundamental underlying reasons
not to, and, well, those are the fundamental reasons why most
Operating systems are hostile to LISP. And that is the level at
which I'm approaching the problem. 

>I'm not sure I agree there.  I see DLLs/DSOs as poor substitutes for
>dynamic Lisp (or Java) bindings.  

How odd.  I was seeing dynamic bindings as one of the possibly
best implementations of DLLs.

>Sorry for the length, but you raised some very good points.  (And I hope
>I didn't alienate anyone with my "get it running ASAP" philosophy.  I
>must be betraying my raw-hardware and UNIX roots.)

No, no alienation.  You've got a good viewpoint and you know
things I don't; this interaction is *good*.  I'm just addressing
what I see as fundamental issues by going in a fundamentally new
direction. 

					Ray