[bootstrappable] Re: GNU Mes 0.18 released

  • From: "Orians, Jeremiah (DTMB)" <OriansJ@xxxxxxxxxxxx>
  • To: "bootstrappable@xxxxxxxxxxxxx" <bootstrappable@xxxxxxxxxxxxx>
  • Date: Thu, 8 Nov 2018 13:28:45 +0000

Regarding this paragraph, we still depend on "vm", which currently is 
compiled using gcc. I know that your motivation is to implement "vm" out of 
TTL.
Actually no
The bootstrap depends on 5 small steps that can be completed for each platform 
in less than 6 Months of work 
(hex0, hex1, hex2, M0, cc_x86)
After which can be used to audit and verify other bootstraps
(The VM was just the first and there is a separate x86 one in process)

I would be interested in bootstrapping "vm" from scratch somehow on linux. 
What do you think is the best way to do that?
Well the vm is a really simple program that could manually written in x86 
assembly with about a month of effort

Here is an interesting project that is able to bootstrap a primitive language:
Yes I am very familiar with that one, my issue with it is that it is a single 
pass only bootstrap; which means no forward references.
There is a code smell about it, that just doesn't feel human written to me.

if you look at the bootstrap script:
Depends on bash to be run (That is a pretty heavy binary)

it's hard to make it simpler than that.
Actually no
https://github.com/oriansj/mescc-tools/blob/master/kaem.run
It is rather easy to make something much simpler

One can object against using "chmod" and "bash", but I don't know how to 
eliminate those.
You add support for setting the execute bit in your hex or you use 
https://github.com/oriansj/mescc-tools/blob/master/exec_enable.c  which can ;
also be made by M2-Planet and cc_x86
(Or if you want a 5 minute problem, convert 
https://github.com/oriansj/mescc-tools/blob/master/test/test5/exec_enable_amd64.M1
or
https://github.com/oriansj/mescc-tools/blob/master/test/test6/exec_enable_i386.M1
to hex by hand)

You can eliminate those if you start with "vm", but since you currently need 
"gcc" to bootstrap "vm", I rather just depend on "bash" and "chmod". 
Actually the reason for the VM is to eliminate any microcode, firmware, BIOS, 
Operating System and the possibility of cheating in the bootstrap

So I like the approach in "bcompiler", I think that's what I am after.
Well I previously did a much lower level x86 bootstrap 
https://github.com/oriansj/stage0/blob/master/x86/stage0/stage0_monitor.hex
(Hex0, self-hosting only dependent on the Bios and x86 hardware)

And already did hex0 and hex1 for x86
https://github.com/oriansj/mescc-tools/blob/master/test/test1/hex0.hex0
https://github.com/oriansj/mescc-tools/blob/master/test/test1/hex1.hex0

And AMD64
https://github.com/oriansj/mescc-tools/blob/master/test/test2/hex0.hex0
https://github.com/oriansj/mescc-tools/blob/master/test/test7/hex1.hex1

The author was able to boostrap this:
The lack of forward references and buggy backward references make me hesitant 
to put effort into using that

So one can start with that, and then implement "vm" in this?
In theory yes but having played with that language, the lack of debugging 
support or standard to compare against;
You'll end up spending more time than if you were to assume M2-Planet and 
mescc-tools
And just wrote hex2 and M0 for x86

You are right, that bcompiler is x86 only, so one would have to redo 
"bcompiler" on each platform.
The fact that the bcompiler developer skips a lot of cheap and extremely useful 
features concerns me.

The c programs one would need to hand convert:
https://github.com/oriansj/mescc-tools/blob/master/examples/hex2.c
https://github.com/oriansj/mescc-tools/blob/master/examples/M0-macro.c
To finish off the x86 bootstrap

Not hard, only a week or 2 of work (As all the other pieces have already been 
done)

Oh and per our discussion yesterday I added kaem.run to mescc-tools, so that 
one can just run: ./kaem.run or ./kaem-0 --verbose --strict
To build mescc-tools-seed

-Jeremiah

Other related posts:

  1. Home
  2. bootstrappable
  3. Archive
  4. 11-2018