| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop requiring jump instructions to explicitly provide a ':label' type
for jump targets.
This has been a source of repeated confusion for my students:
a) They'd add the ':label' to the label definition rather than the
jump target (label use)
b) They'd spend time thinking about whether the initial '+' prefix was
part of the label name.
In the process I cleaned up a couple of things:
- the space of names is more cleanly partitioned into labels and
non-labels (clarifying that '_' and '-' are non-label prefixes)
- you can't use label names as regular variables anymore
- you can infer the type of a label just from its name
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A long-standing problem has been that I couldn't spread code across
'run' blocks because they were separate scopes, so I've ended up making
them effectively comments. Running code inside a 'run' block is
identical in every way to simply running the code directly. The 'run'
block is merely a visual aid to separate setup from the component under
test.
In the process I've also standardized all Mu scenarios to always run in
a local scope, and only use (raw) numeric addresses for values they want
to check later.
|
| |
|
|
| |
Bugfix for the "remaining bug" mentioned in commit 3391.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix failing scenarios in channel layer. We do so by introducing a kludgy
new instruction to explicitly signal when a routine is stuck ('blocked')
and waiting on another.
All this locking and blocking may well be a crap design. We'll see if we
find ourselves using these primitives again. Ideally we don't need them
for anything else now that we're done building channels.
Still some failing scenarios left in chessboard.mu. Let's see how that
goes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously our channels were based on an unconventional
`wait-for-location` primitive that waits for a specific address to
change its contents. This only works as long as a channel has a single
reader and a single writer routine. To support multiple readers and
writers we switch to a more conventional compare-and-set primitive.
There's still a couple of failing scenarios, though -- the ones using
`wait-for-routine-to-block`, because the new approach never blocks on an
empty or full channel, just yields CPU for a time before polling. Hmm,
how to fix this?
|
| |
|
|
|
| |
In the process I've uncover a couple of situations we don't support type
abbreviations yet. They're next.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the process of debugging the last couple of commits (though I no
longer remember exactly how) I noticed that 'wait-for-routine' only
waits until the target routine stops running for any reason, including
when it blocks on something. That's not the synchronization primitive we
want in production code, even if it's necessary for some scenarios like
'buffer-lines-blocks-until-newline'. So we rename the old 'wait-for-routine'
primitive to 'wait-for-routine-to-block', and create a new version of
'wait-for-routine' that say callers of 'start-writing' can safely use,
because it waits until a target routine actually completes (either
successfully or not).
|
| | |
|
| |
|
|
|
|
|
|
| |
For example usage of file operations, see filesystem.mu.
Is it ugly that we don't actually write to disk unless we wait for the
writing routine to exit? Maybe there's a nice way to wrap it. At any
rate, all buffering is explicit, which seems a win compared to *nix.
|
| | |
|
| |
|