| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Mu can now compute (factorial 5)
|
| | |
|
| | |
|
| |
|
|
| |
See shell/README.md for (extremely klunky) instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both LBA and CHS coordinates are now working for the primary disk on the
primary bus.
Failure modes I ran into:
- ATA ports are 16-bit values. Using instructions with 8-bit immediates
will yield strange results. (I had to debug this twice because I missed
poll-ata-primary-bus-primary-drive-regular-status-word the first time
around.)
Mu's toolchain has been found out here. bootstrap has good
errors but doesn't support the instructions I need in boot.subx. The
self-hosted phases support the instructions but provide no error-checking.
Might be worth starting to add error-checking as I encounter the need.
In this case, a vote for validating metadata sizes even if we don't
validate that instructions pass in the right metadata sizes.
- Can't poll readiness first thing. Maybe we need to always select the
drive first.
- Reading 8-bit values from a 16-bit port (data port 0x1f0) returns garbage.
Reading 32-bit values however works totally fine; go figure. (Maybe
it won't work on real hardware?)
https://forum.osdev.org/viewtopic.php?t=36415
- Passing in a 0 segment will never return data.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CI will fail from this commit onward. Currently working:
$ bootstrap translate init.linux 0[4-7]*.subx 080zero-out.subx -o a.elf && ./a.elf test
$ bootstrap run a.elf test
$ chmod +x a.elf; ./a.elf test
Plan: migrate functions that used to return handles to pass in a new arg
of type (addr handle). That's a bit of a weird type. There should be few
of these functions. (Open question: do we even want to expose this type
in the Mu language?)
Functions that just need to read from heap without modifying the handle
will receive `(addr T)` or `(handle T)` types as arguments.
As I sanitize each new file, I need to update signatures for any new functions
and add them to a list. I also need to update calls to any functions on
the list.
|
| |
|
|
|
|
|
|
|
|
|
| |
At the SubX level we have to put up with null-terminated kernel strings
for commandline args. But so far we haven't done much with them. Rather
than try to support them we'll just convert them transparently to standard
length-prefixed strings.
In the process I realized that it's not quite right to treat the combination
of argc and argv as an array of kernel strings. Argc counts the number
of elements, whereas the length of an array is usually denominated in bytes.
|
| | |
|
| | |
|
| | |
|
| |
|