| 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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
|
| |
Decouple layer 61 test from layer 62 dependency.
|
| |
|
|
|
| |
The implementation is quite hacky. Let's see how future needs develop
before we try to clean it up.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Reorganize layers a bit so I can add a couple of scenarios testing
static dispatch *before* I add `stash` into the mix.
|
| |
|
|
|
|
|
| |
Process type abbreviations in function headers.
Still a couple of places where doing this causes strange errors. We'll
track those down next.
|
| |
|
|
| |
Process type abbreviations in container definitions.
|
| |
|
|
|
| |
In the process I've uncover a couple of situations we don't support type
abbreviations yet. They're next.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old approach with '&' and '@' modifiers turned out to be a bad idea
because it introduces notions of precedence. Worse, it turns out you
want different precedence rules at different times as the old test
alluded:
x:@number:3 # we want this to mean (address number 3)
x:address:@number # we want this to mean (address array number)
Instead we'll give up and focus on a single extensible mechanism that
allows us to say this instead:
x:@:number:3
x:address:@:number
In addition it allows us to shorten other types as well:
x:&:@:num
type board = &:@:&:@:char # for tic-tac-toe
Hmm, that last example reminds me that we don't handle abbreviations
inside type abbreviation definitions so far..
|
| | |
|
| | |
|
| |
|