| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Make segment management a little more consistent between initial segments
and add-on segments (using `mmap`).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now simulated 'Memory' isn't just a single flat array. Instead it knows
about segments and VMAs.
The code segment will always be first, and the data/heap segment will always
be second. The brk() syscall knows about the data segment.
One nice side-effect is that I no longer need to mess with Memory initialization
regardless of where I place my segments.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Attempt #3 at fixing CI.
In the process the feature gets a lot less half-baked.
Ridiculously misleading that we had `has_metadata()` was special-cased
to one specific transform. I suck.
|
| | |
|
|
|
I'd been planning to add segment address computation after all labels were
computed, including labels in the data segment (which isn't built yet).
But now I realize that won't work, because labels in the data segment will
require segment start addresses. We need to deal in absolute addresses
rather than relative offsets as with the jump instructions that use code
labels.
Layer 34 is now broken by this change in a way that isn't obvious right
now: it is oblivious to imm32 and disp32 operand tags that are now going
to be present in the programs it sees. It's a lucky accident that everything
still works, because we're only using segment names right now for the very
first (code) segment in a program.
|