i386 subproject

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> Dear Joyous Tunespeople,
>    I know some of you (at least Dan and Sean) are i386 asm hackers.
> Would any of you take the i386 subproject, and help finish implement it ?
> 
  You wouldn't happen to mean me, right?  I'm currently working on my own
project right now, and even if I wasn't, I'm not sure I would want to work
on TUNES.  There are several problems I see currently:

	1. There's already too many people working on the project.  
	2. There is no clear cut decision on anything.  No LLL, no HLL.  And
	   I'm still not sure what higher order reflective lanauges are.  
	3. There are no low level people keeping the high level people
	   in check.  The worst thing that happened to TUNES is when Mike
	   Prince left.  He was probably the only thing keeping Francois in
	   check.

  I signed up on this list just to keep tabs on what other people are
working on (never hurts to study).  But my gut feeling (at least with TUNES)
is that it's never going anywhere.  It's too lofty.  

  And I'm sorry, but LISP is high level.  

>    The goal is to produce
> a) a small 32-bit protected mode FORTH core (the easy part)
> b) add callbacks to real-mode to it, so we are able to call the BIOS.
> c) prepare hooks for further protected-mode interrupt management.
> which I consider would be the minimal "exokernel" and library on which
> to write everything else.
> 
>    The constraints are to keep the programming style as high-level and
> abstract as possible, so that
> 1) decisions like register layout, threading method, implementation
>  of the dictionaries, memory allocation, garbage collection, etc, can
>  be modified, tuned, added later.

  It's very difficult to design with that amount of potential change in
mind.  Change the way the registers are used, and you'll end up recompiling
large amounts of code.  The other things can probably be done in an abstract
manner, but if it gets too abstract, there's nothing to hold on to.  It's
all castles in the air.

> 2) Almost the same sources can be used to generate code for other assemblers
>  on other machines [see what I have done already for sharing with C, the
>  portable assembler].
> 
>    So, ain't anyone interested ? Ain't the goal and constraints clear enough ?
> 
  The goals are too vauge (Really Francois, have you ever considered the
language DWIM?) and the constraints are almost non-existant.

  My advice (and this applies to Francois in particular) is to study the
implimentation of as many OSs as possible, even those you don't think are
relivent.  Understand WHY they designed it the way they did and the
ramnifications of their tradeoffs.  So far, I've studied MS-DOS, OS/2, CP/M,
OS-9, AmigaDOS, QNX and Unix.  I understand the tradeoffs made, why they
were designed.  Does anyone else on this list?

  -spc (Just Do It)