i386 subproject

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> Dear Sean,
>    I think you're being unfair.
> 
> > 	1. There's already too many people working on the project.
>    Well, personally, I'd say that there are *not enough* people
> *actually working* on the project (and I don't even count myself as
> actually working a lot on it).
> 
> > 	2. There is no clear cut decision on anything.  No LLL, no HLL.
>    To have a clear cut decision, we need have data on which to base decision.
> Next time I take a decision, you'll tell it's arbitrary and I haven't
> consulted anyone !

  Not if you give some form of rational behind the decision, even if the
rational is "Well, we NEED something!".  But I guess it depends upon your
view if a bad decision is better than no decision, or vice-versa.  I've seen
quite a bit of talk, but no real head way, but if that is not the case, I
stand corrected and will appologize.

>    As for the LLL, I proposed that we took all the standard FORTH computation
> words, without parsing and I/O words for which we'd do something else; but
> nobody commented. And for the HLL, I've written lots of requirements, and
> we've come to the conclusion that a new language should really be designed,
> as no existing one could remotely fit our specs.
> 
  FORTH is not a bad language for the LLL.  There are some problems with it,
mostly due to stack noise (DUPs, ROTs, ROLLs, PICKs etc) and the rather
clumsy vocabulary paradigm.

  Don't get me worng.  I'm crazy about Forth, but I don't like Forth.  Or, I
like the idea, but not the implimentations so far.  I did create my own
Forth like language called VIth (pronounced "sixth") that, IMHO, had a
better way of dealing with vocabularies, and it did have overloading ('+'
for instance, can add two integers, floats, or strings) but it's not perfect
either (you can't add an int and a float without an explicit conversion of
the mismatching type to the other type, and the overloading is clumsy in
certain reguards).

  I have made some refinements to VIth that have yet to be actually coded
up, but I'm a bit busy with other projects to get much work done on it.

  As to your HLL, I'm not even sure it's possible.  At least some of the
requirements seem theorectically impossible (and I'll be responding to this
later when I find the references I need).

> > And I'm still not sure what higher order reflective lanauges are.  
>    *That* is a good objection. I guess I should write some clear
> explanation in the TUNES pages.
>    Basically, higher-order means that functions, structures, and types
> are first-class citizens. Reflective means that the whole system itself can
> be abstracted over, that the language can manipulate itself...
> 
  I'm not exactly sure what first-class means.  I can take a stab in that
arrays in C are not first-class (as an example).  If that's the case, then I
understand what you are talking about.  If not, you'll need to define
first-class (it probably wouldn't be a bad idea anyway).  

  There are some gaps in my knowledge here.  I tend not to trust the
theorectical side of CompSci that much.  Too much hand waving (not to
mention a prof at the university I attend who specialty is "Software
Engineering" but hates programming).

> > 	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.
>    How that "in check" ? I think we're together to collaborate rather than
> fight; of course, anyone is free to have his own point of view on things.

  True.  But by "in check" I mean that the theorists don't go off the deep
end trying to get something that is impossible to impliment, and that the
engineers don't lock the system into a particular implimentation paradigm
and preclude futher advancements.  Both sides balance each other without one
side overwhelming the other.

  But coming from the States, I'm probably biased towards a system of
"checks and balances".

>    Moreover, I consider myself as a low-level people, too. I've been hacking
> assembly for years (those sweet Apple ][ days...), have always loved low-level
> details, and for TUNES alone, I've written the boot stuff and a lot of the
> FORTH system already. Of course, low-level is not my *only* concern, and
> actually, I believe there are already more than enough people doing low-level
> things and not enough doing the high-level things, so I'm focusing on the HLL.
> 
  But my impression of you is not as a LL type of guy.  Then again, that's
me.  I tend to be pragmatic myself.  Theory is nice, but the Real World (TM)
often gets in the way of a nice theory.

> 
> >   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)
B> > is that it's never going anywhere.  It's too lofty.
>    Well, the project may be lofty, but I've done my best to divide it in
> mostly independent subprojects, each being much narrower. But seemingly,
> no one is willing to work on a project before somethings run already.
> I know I'm very bad at leading people (which is another reason why I never
> wanted to take the head of the project), and this sure hasn't made things
> better. However, until I find someone to replace me, I'll keep being the
> project coordinator, because I'm committed in having it succeed.
> 
  The key is to find a few (and by that, I mean two or three) people that
will actually DO something.  And fight out the details.  And be willing to
compromise.  A project I'm working on has only three people, and just
between the three of us, we've gotten quite far (although the amount of mail
we generated doing so has already exceeded 1M).

> >   And I'm sorry, but LISP is high level.
>    It sure is higher-level than C. However, by many aspects, LISP is
> low-level (please compare to ML, and you'll see). I won't expand on it
> now, but see how LISP program use cons cells, etc, as an *explicit encoding*
> for higher-level constructs. Here is what I call low-level: making
> implementation details explicit.
> 
  Cons cells?  LISP?  LISP - everything is a list.  Code.  Data.  How a list
is implimented is left up to the implimentation.  Certainly there are
classical methods for storing lists in LISP (Forth has a similar problem in
that a particular implimentation became the de facto standard and hampered
advancements of that language for years), but that still doesn't make LISP
low level.

  'cons' just takes two elements (lists or atoms) and creates a new list
with those two elements.  How it does that I don't care about.  That is an
implimentation detail, wether it's done via linked lists, arrays, cons cells
or some method we can't even imagine today.

> >>    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.
>    Before he could get an idea of what his F21 forth compiler should do,
> Jeff Fox wrote twenty versions for it. Why makes you think we could choose
> the right calling convention at the first try, without having tried a lot
> of different versions ?

  I think you made my point.  How can you know what's best if you don't get
your hands dirty and impliment something?  VIth went through four previous
versions (right now, the latest version is 3) and I'm working on a fifth
implimentation (or 12th or something.  I know I started v3 several times and
v4 several times as well).

  I would plan to throw away the first implimentation anyway and start over
from scratch.

>    Of course, we'll have to recompile, but that's the most trivial part
> of the problem. As for holding things, please tell me what's wrong with
> the generic code I've begun to write. All that seems truely feasible to me.
> (actually, I already got many ideas about how to improve it, but I'll
> do it in HLL rather than m4, if I can).
> 
  Guess I should take a look at the generic code before I comment further on
it.

> >>    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.
>    Err, what's DWIM ?

  I should appologize for that snide remark.  DWIM stands for "Do What I
Mean" and is usually followed by "Not What I Say".  Often heard in computer
labs (at least where I'm from).

>    The constraints are quite existant: keeping everything generic, modular,
> and extensible is an especially hard constraint, especially being considered
> that this low-level coding is done with traditional tools (currently,
> the m4 preprocessor generating code for a parametrized assembler) !!!
> 
  Generic, modular and extensible.  Okay.  They're pretty broad constraints
though.  And personally, I'm not a real fan of genericity.  I do apply it,
but not everywhere.  The real trick is to find out how generic it needs to
be and leave it at that.  Too generic and you may suffer performance
problems or induce more bugs (as there are more cases to test - I'm a real
nut when it comes to reliability).  It is a tough call sometimes.

(This isn't to say I'm totally against genericity, just blatant genericity
just to say "My code is generic!"  There has to be a good justification I
feel).

> >   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.
>    That's what I've been doing for years. But of course, even then, my
> knowledge is very reduced. I'd be glad you point us to any major idea
> you could learn, and to warn us from any mistake we may be doing.
> 
> >  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?
>    I know MS-DOS, CP/M and Unix perfectly. I understand QNX, and I don't
> know anything about the other two. 

  AmigaDOS has taken the concept of a monolithic kernel and done away with
it (technically, it's a microkernel).  But in doing so, they (those that
wrote Exec - the "kernel" of AmigaDOS) and made it into a standard shared
library, no different from any other shared library (except that it, unlike
other shared libraries, does not have to be explicitely opened - it's always
available) and replacable.  Also, the language a shared library is written
in does not matter.  Exec is written in Assebler.  Intuition in C.  DOS (the
filesystem bascially) in BCPL.  AmigaDOS's kernel (in this case, Exec,
Intuition and DOS) are written in three different languages and are
partitioned in such a way as that each part can be replaced.

  AmigaDOS is also a message-based kernel to some extent.

  OS-9 is like Unix, but is also a messaged-based kernel to some extent and
resident modules (almost like shared libraries) can be written in any
lanauge and used by any system (although I don't think there's a set calling
convention like on the Amiga).  A pretty clean design, but I think AmigaDOS
comes closest (well, at least Exec) to being the cleanest kernel design I've
ever seen.

  -spc (Although if QNX dropped the POSIX support, it may be the best
	OS design I've seen as well ... )