https://github.com/akkartik/mu/blob/37c859058/apps/desugar.subx#L440
open()
?
I've spent some time in the past staring at the abyss that is http://pubs.opengroup.org/onlinepubs/009695399/functions/open.html, and much of its complexity seems needed only for Things That Are Not Files.
At the syscall level it's pretty ugly that sockets are not files. Alternative client-side syscalls that unify file system and network:
- PUT
- GET
- POST
- DELETE
Just have them take a resource name and maybe a Go channel for synchronizing. What am I missing?!
SubX can now build itself! 9kLoC in 1.5s. Caveats:
- Zero error checking. You still need the C++ translator for development (just like a text editor and other tools).
- Some programs compile with the C++ translator but not the self-hosted one. Ones with no `Entry` labels, no `data` segments, or with uppercase hex will throw errors. However, it's a bug if a program successfully compiles but generates a different binary.
What's next? I have a few ideas.
All example apps now translating correctly, and the result is bit-for-bit identical with the results of the C++ translator.
The last remaining step, the final frontier: SubX-in-SubX in SubX-in-SubX. Translating the self-hosted translator using the self-hosted translator. Still seeing some discrepancies there.
I fixed just one bug since yesterday, but had to cope with a 4.4GB trace for it.
https://github.com/akkartik/mu/blob/70a0776031ff/subx/Readme.md
Standard library is now self-hosted!
apps/factorial is also translating successfully, and the binary is the exact same size as before. However there are diffs to track down.
I'm ignoring emulated mode for now, and am testing ELF binaries natively. 5k lines of input take 26 seconds to translate. The cost: having to slum it with some light debug by print action in the absence of time-travel debugging.
Test harness done. The self-hosted translator now handles all 12 example programs. A beach-head for reproducible builds.
Time to start translating the standard library. In emulated mode things get slow fast:
$ time ./translate 049*.subx 05[0-n]*.subx
35 lines in 9s
84 lines in 20s
219 lines in 59s
262 lines in 68s
382 lines in ... ERROR
In native mode, translating 262 lines takes 0.1s.
https://github.com/akkartik/mu/blob/90538f232a/subx/Readme.md
Another day, another bug fixed, another example program working.
But now I've hit a missing feature: code-generating the special run-tests
function, which just calls all functions starting with 'test-'. Pretty much all remaining programs are now bottlenecked on this.
Next few tasks:
-
run-tests
- '\n' in string literals
- it's dog slow. Probably the linear search. But no profiling yet.
https://github.com/akkartik/mu/blob/3af52436dfa/subx/Readme.md#roadmap-and-status
2 bugfixes later, 10/12 example programs building correctly.
There's one known hole in my implementation: it doesn't support '\n' in string literals. Now may be the time to plug this gap.
https://github.com/akkartik/mu/blob/5030d67c85/subx/Readme.md
First example program successfully translated!
4 programs now translating:
✓ ex1
✓ ex2
ex3
✓ ex4
ex5
ex6
✓ ex7
ex8
ex9
...
Sample run:
$ cat examples/ex1.subx |dquotes |assort |pack |survey |hex > a.elf
https://github.com/akkartik/mu/blob/294a15206329/subx/Readme.md
All phases are done and passing tests separately. However I haven't yet managed to actually put the final phase together with the rest to build any actual programs.
Here's what I have so far in the final phase: http://akkartik.github.io/mu/html/subx/apps/survey.subx.html
I've also started working on the next step: a simple list of steps for building a minimal Linux kernel to go with SubX. It's the final dependency.