| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.
So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.
A couple of things have gotten dropped in this process:
- I had old ways to run on just a Linux kernel, or with a Soso kernel.
No more.
- I had some old tooling for running a single test at the cursor. I haven't
used that lately. Maybe I'll bring it back one day.
The reorg isn't done yet. Still to do:
- redo documentation everywhere. All the README files, all other markdown,
particularly vocabulary.md.
- clean up how-to-run comments at the start of programs everywhere
- rethink what to do with the html/ directory. Do we even want to keep
supporting it?
In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Make strncpy a little less error-prone.
Just use memcpy where that suffices:
https://stackoverflow.com/questions/56782248/gcc-specified-bound-depends-on-the-length-of-the-source-argument/56782476#56782476
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
So far we hardcoded the translation process and it only supported SubX.
Now we pass in an ELF binary and outsource how it's generated.
|
| |
|
| |
|
|
|
|
| |
https://futureofcoding.org/two-minute-week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I built this in 3 phases:
a) create a helper in the bootstrap VM to render the state of the stack.
b) interactively arrive at the right function (tools/stack_array.subx)
c) pull the final solution into the standard library (093stack_allocate.subx)
As the final layer says, this may not be the fastest approach for most
(or indeed any) Mu programs. Perhaps it's better on balance for the compiler
to just emit n/4 `push` instructions.
(I'm sure this solution can be optimized further.)
|
| |
|
| |
|
|
|
|
|
| |
Trace browser: Don't let the background color get too light, and cycle
back to darker shades so I'm not squinting at low depths.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Signed and unsigned don't quite capture the essence of what the different
combinations of x86 flags are doing for SubX. The crucial distinction is
that one set of comparison operators is for integers and the second is
for addresses.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Follow stupid GNU convention, because why not:
https://www.gnu.org/prep/standards/html_node/Releases.html
|
|
|
|
| |
Move script to create a Linux-based boot image into a sub-directory.
|
|
|
|
|
|
| |
Move script to create a Soso boot image into a sub-directory.
I'm trying to streamline newcomer attention to just a couple of use cases.
|
| |
|
|
|
|
| |
Minor tweaks to stop wasting horizontal space in the trace.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The problem: when I hit 'G' to go to the bottom of the trace, if the bottom
is visible on screen, the screen scrolls so the bottom of the trace
is the bottom-most line on screen. But the cursor moves to where the trace
used to end rather than the new location of the bottom of the trace (the
bottom of the screen).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|