| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This continues a line of thought sparked in commit 2831. I spent a while
trying to avoid calling size_of() at transform-time, but there's no
getting around the fact that translating names to addresses requires
knowing how much space they need.
This raised the question of what happens if the size of a container
changes after a recipe using it is already transformed. I could go down
the road of trying to detect such situations and redoing work, but that
massively goes against the grain of my original design, which assumed
that recipes don't get repeatedly transformed. Even though we call
transform_all() in every test, in a non-testing run we should be loading
all code and calling transform_all() just once to 'freeze-dry'
everything.
But even if we don't want to support multiple transforms it's worth
checking that they don't occur. This commit does so in just one
situation. There are likely others.
|
| |
|
|
|
|
|
| |
If you accidentally use a recipe name in an ingredient you usually get
an error because types don't match. But jumps need to be flexible enough
to support both addresses and booleans, so they were accepting recipe
literals as well. Now a useful error results.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out we don't need a primitive to return an empty value of
arbitrary type. Just create it on the heap using 'new'.
But this uncovered *yet* another bug, sigh. When I specialize generic
functions I was running all transforms on the generated functions after
specialization completed. But there's one transform that includes code
from elsewhere. If such code included type-ingredients -- kaboom. Now
fixed and there's a test, so I've got that going for me which is nice.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Be more consistent that 'return' is the name of the instruction, and
'reply' just a synonym. Maybe I should take it out. It wouldn't affect
the recipe/ingredient terminology while I teach..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an interaction between two transforms. The first turned:
return-if ...
into:
jump-unless ..., 1:offset # skip next instruction
return ...
The second added an unconditional return at the end of the recipe if it
didn't already exist (so that functions always end with a return).
However, it was getting confused by the return instructions generated
above, which look unconditional but sometimes get skipped.
To fix this, conditional returns are now transformed into this:
{
break-unless ...
return ...
}
Since the final instruction is now no longer a reply (but rather the '}'
label), the second transform triggers and adds the unconditional return
after it.
This commit removes the final place marked 'BUG:' in the codebase
yesterday (see commit 2870).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The solution for avoiding deadlock is for routines to close channels
before they exit. So that's good.
Once I implemented 'close', I also found and fixed 2 unrelated bugs in
chessboard.mu:
a) one long-missed and long-masked case of forgetting to store
character literals in character variables
b) one typo in translating get-address to put
So that's good.
What's not so good: in the process of fixing this I've found three
unrelated bugs (marked 'BUG:' in the changes). All three have
workarounds, so existing tests pass for now. But they are my top
priority next.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Now that we no longer have non-shared addresses, we can just always
track refcounts for all addresses.
Phew!
|
| |
|
|
|
| |
Finally after much massaging, the 'address' and 'new' layers are
adjacent.
|
| |
|
|
|
| |
Layers 0-29 are now a complete rudimentary platform except for pointers
and indirection.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This reinfoces that it's only really intended to be used by
'wait-for-location'. To reinforce that we also move it to the same layer
as 'wait-for-location'.
|
| |
|
|
|
| |
This pass will need redesigning for 'put'. But let's get rid of
get-address first..
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Phew!
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Turns out one of my chessboard tests has been silently deadlocking and
therefore not actually checking its results since at least commit 1620
last June.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Only apps left now, and the wait-for-location uses in the channel
primitives.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
On reflection I think I'd rather add a duplicate test that's closer to
how I discovered the problem, without the masking bug in type-matching
that was masking the simpler test in the previous commit.
|
| |
|
|
| |
Thanks Caleb Couch for finding and reporting this.
|
| |
|
|
|
|
|
|
|
|
| |
I have a tack now for issue 2 of 2829 (dealing with wait-for-location):
have get-address and index-address return a type that can't be looked
up. That way the worst that can happen with an address pointing to a
freed location is a routine that randomly hangs and starts working
again. And even that won't happen if you disallow transferring the new
type across routines in ingredients or channels, just like I plan to do
with 'address:shared'.
|
| |
|
|
|
|
|
| |
Previously to watch an address we had to perform a lookup of it, which
the instruction then proceeded to undo. This way wait-for-instruction no
longer supports literal ingredients, but the real-world usage becomes
cleaner.
|
| | |
|