[LispM-Hackers] Who is doing what?

[John Morrison]

Hi;

Nyef wrote:
> I'd _much_ rather see a stand-alone stand-alone system, rather than one
> that lies upon DOS or a Linux kernel... But if you're doing that, why not

Me, too.

> write a Lisp more suited to running on the x86 instead of just emulating
> the explorer?

Well, I'd like to know what Steve and Paul think about whether it would
be possible, after we get the macroinstruction stuff right and running,
whether we could do a JIT type compiler stunt here.  

Could we add another function DTP that actually had x86 (position
independent, obviously) opcodes in it instead of macroinstructions?  If
so, shouldn't we do that in Lisp (well, mostly, obviously there would
have to be parallel ersatz-microcode changes to recognize the new
stuff)?  Or, is it more sensible to use the existing microcode trap
stuff and just (re?)populate the table (dynamically)?

What would be the smartest way to do this in the longer term?

One of my big complaints about JIT stuff is that the JVM/JIT has to redo
the work every time it gets the new code.  I am presuming that we could
JIT stuff and then save it in the load band.  Maybe we'd JIT the entire
Lisp world just before we saved to disk (JIT, gc, save band).  I don't
know how the microcode-extension way (if it is feasible at all) would
handle that kind of thing.

> And writing device drivers should be a lot less painful in Lisp. Write
> them in Lisp where you can (basically everything except the disk driver,
> and maybe even that).

I'm with that.  As I said earlier, why should I have to rebuild my
kernel (and change the basic kernel I'm running to one that would accept
the enormous patches) just to support some new IDE commands to support a
big disk?????

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com