| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Super slow; each frame is cleared as a sort of progress indicator while
it computes the next frame.
In the process I realize I need to adjust every single trace in the
shell sources to be more fault-tolerant to a filled-up trace stream.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
In the process I found a bug in the Mu compiler. Limitations of just asserting
the emitted code but not running it.
|
| | |
|
| |
|
|
|
| |
It's bad enough that metadata comments are restricted to integer literals;
let's at least make them work on _all_ integer literals.
|
| |
|
|
| |
Convert comments about magic constants into metadata.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Metadata is always ignored. It's purely for documentation purposes. But
as long as Mu has no named constants it's starting to feel increasingly
essential.
I'm still not going to bother to add metadata to other parts of the language.
Let's see if we need them. Even though it's a little warty that the rules
vary throughout the stack:
- bare SubX: metadata everywhere
- SubX with syntax sugar: no metadata in calls or addressing-mode sigil-expressions
- Mu: metadata only for literal integers
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was tedious for three reasons beyond the usual one of having to
track and update offsets several time while I debug:
- The Bochs troubles of the previous commit kept polluting my brain
even though they were irrelevant.
- I had to keep some changes locally to allow myself to use Bochs,
which polluted my working directory.
- I had to travel the long way to the realization that I'm not
actually initializing the stack anywhere. BIOS was starting my stack
off at 0x10000, which was promptly clobbered by my second read from
disk.
The good news: while I'm here I grow the interrupt descriptor table. So
I don't have to go through this exercise when I get back to supporting
the mouse.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/GNU_Unifont#The_.hex_font_format
http://unifoundry.com/unifont/index.html
Since GNU Unifont is covered under the GPL v2, so I believe is this repo.
|
| | |
|
| | |
|
| |
|
|
| |
Bring baremetal variant up to date with recent changes.
|
| |
|
|
| |
Switch survey_elf to the new approach.
|
| | |
|
| | |
|
| |
|
|
| |
Go back to commit 7448.
|
| |
|
|
|
| |
Snapshot: this approach of disambiguating /disp32 based on metadata doesn't
work. The `survey` phase runs after `pack`, which gets rid of most metadata.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
A new phase for baremetal compilations. Doesn't work yet, but it passes
all its tests, so we can add it to CI.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
is right, no need to mess with the status port at the start.
|
| |
|
|
|
|
| |
I think https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
has more insight to provide. Among other things the comment about grub
may answer the distinction between entry 0x21 and entry 9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Snapshot. Keyboard interrupt being triggered.
This was hard to debug until https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
reminded me that I'd forgotten to enable IRQ1 on port 0x21.
For a while I was confused by never hitting a breakpoint at the start of
the keyboard handler. Then I found https://sourceforge.net/p/bochs/discussion/39592/thread/5e397455
and started skipping one instruction in my breakpoint.
I still don't understand the discrepancy between some people installing
the handler at entry 9, and others installing at entry 0x21 = 33.
|
| | |
|