i386 subproject

[Francois-Rene Rideau]

[Follow-up from tunes@ens.fr]

>: Paul Dufresne

> First I have tought to contribute to the i386 subproject.
You'd be welcome!
However, I think the OTOP subproject might be a better start
for the LLL, if you're interested.

> My understanding is that in old times [...]
Yeah. We used to have somehow working boot code in m4|as86.
But I'm not sure that code is worth much,
since there now are generic boot loaders available, like GRUB or SOLO.
Jecel tried them, and recommends SOLO for OS development.
Once we get Tunes up&runnin', it's still time to produce
a Tunes-native boot loader, if useful/necessary
(for instance because of copyright purposes),
perhaps out of a 8086 version.

> our new asm86x(?) which is written in our new HLL- language
It is not compulsory to use my not-yet working asmx86 code.
Of course I'd appreciate someone getting it running.
Patrick Premont demonstrated that code could be easily
generated from s-expressions to externally assembled stuff;
If you're to choose a portable assembler backend, get NASM.

> which is a subset of our to come HLL written in Scheme
Yeah, the HLL- is currently being hacked up in Scheme.

> (more precisly from the Elk 3.0 implementation of Scheme,
> and will soon support the Stk implementation as well)
Or move to it, or move to EuLISP, or to EuScheme, or to anything
whoever gets it working will feel useful.

> and which asm86x(?) is the new assembler that we will used
Not forcibly. Like the ITF, we believe in working code when we see it.
The asmx86 as it is sketches
what could be the sources for a native assembler,
written in such a way that a disassembler is automatically produced
from the same source [of course, a disassembler should be directed
by non-trivial heuristics, whereas assembling is easier].

> to make our Forth LLL (Low-Level language),
> and the base of the booting process provided by the i386 subproject.
We've not decided yet what exactly our LLL would be.
Again, the first to produce working code will win.
Anyway, it will be a functional language,
whether free-syntaxed postfix like FORTH,
or s-exp'ed prefix like LISP, or whatever.

> It is my understanding that there is actually as86+m4 code to be translated
> in our new assember.
> In what internal version this code to be translated is?
> I think I read 0.0.0.20, but it seems so far away that I don't believe it.
Well, latest as86+m4 code is in 0.0.0.25, if you wanna try it.
Yes it's old, and there's not much to it, actually:
boot code, lots of inspired (and debugged) m4 macros,
just enough to setup protected mode and say hello,
broken interrupt support that seemingly fails to properly
reflect them to either real-mode or vm86 mode.

> My understanding was that we used a simple assembler,
> to make a simple Forth, that we make evolve in writing Forth in Forth
> to the point of having a new
> implementation of H-- written in Forth rather than Scheme.
That's one possible way.
The problem with Tunes is that it is staying in the *potential* area,
because there is currently a lame maintainer
who am not able to tie (it) to reality :-(

> But now we seem to use a high-level written assembler to make our Forth.
> Seems very strange to me.
> Does the forth will implement his own assembler,
> or will it make assembler code to be assembled by an assembler (I don't see
> how it could use a assembler written in HLL- which it is supposed to 
> implement.)
That's a bootstrap problem, to which there are several ways out.
If the FORTH implements enough for the HLL- to run,
then we can use the HLL- to run.
Meanwhile, we can use external tools
to have the HLL- run and generate assembly.
And if you want assembly into Forth,
it is always possible to steal the 486asm package from Win32Forth.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"