| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Move some implementation around for floating-point.
I originally thought I wouldn't bother supporting sigils like %xmm0. But
it turns out I need them to pass floats into SubX function calls. And it
turns out the sigils work fine for free.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
For most of Mu's history we've selected between primitives based on types
just by checking whether a type is a literal or not. Now we've started
checking if it's a float as well. However, floats need one additional check:
the call site may have an (addr float) that is dereferenced.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The realization of commit 6916 means that we should be using jump-if-addr*
after comparing floats. Which is super ugly. Let's create aliases to them
called jump-if-float*.
|
| |
|
|
|
| |
We don't yet support emulating these instructions in `bootstrap`. But generated
binaries containing them run natively just fine.
|
| |
|
|
| |
Some bugfixes to the previous commit.
|
| | |
|
| |
|
|
| |
(Though the generated code doesn't work yet.)
|
| |
|
|
|
| |
New fields for primitives to support code-generation for floating-point
primitives.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make a few tests more self-contained.
I'd prefer to just run a function called `setup` first thing on startup
and move this portion of convert-mu to it:
# initialize global data structures
c7 0/subop/copy *Next-block-index 1/imm32
8b/-> *Primitive-type-ids 0/r32/eax
89/<- *Type-id 0/r32/eax # stream-write
c7 0/subop/copy *_Program-functions 0/imm32
c7 0/subop/copy *_Program-functions->payload 0/imm32
c7 0/subop/copy *_Program-types 0/imm32
c7 0/subop/copy *_Program-types->payload 0/imm32
c7 0/subop/copy *_Program-signatures 0/imm32
c7 0/subop/copy *_Program-signatures->payload 0/imm32
However, this approach doesn't fix my run_one_test tooling.
|
| | |
|
| | |
|
| |
|
|
| |
Using it will currently emit incorrect programs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This issue hasn't been noticed until now because I haven't been using variables
on the stack much.
|
| |
|
|
|
|
|
| |
Regression: segfault on `fn foo` without a block
I really need to turn the list of scenarios considered before populate-mu-function-header
into tests.
|
| |
|
|
| |
This was surprisingly hard; bugs discovered all over the place.
|
| |
|
|
|
| |
We still need a few primitives, but we can implement these as needed. I'm
ready to call the fake screen done.
|
| |
|
|
| |
Also more error-detection for this case all across the toolchain.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
1000+ LoC spent; just 300+ excluding tests.
Still one known gap; we don't check the entirety of an array's element
type if it's a compound. So far we just check if say both sides start with
'addr'. Obviously that's not good enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a question of how we should match array types with a capacity on
ones without. For now we're going to do the simplest possible thing and
just make type-match? more robust. It'll always return false if the types
don't match exactly. For ignoring capacity we'll rely on the checks of
the `address` operation (which don't exist yet). This means we should do
this to pass an address to an array to a function f with signature `f (addr
array int)`:
var a: (array int 3)
var b/eax: (addr array int) <- address a
f b
rather than this:
var a: (array int 3)
var b/eax: (addr array int 3) <- address a
f b
Similar reasoning applies to stream types. Arrays and streams are currently
the only types that can have an optional capacity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
fn main -> r/ebx: int {
var x/eax: grapheme <- copy 0x9286e2 # code point 0x2192 in utf-8
print-grapheme-to-real-screen x
print-string-to-real-screen "\n"
}
Graphemes must fit in 4 bytes (21 bits for code points). Unclear what we
should do for longer clusters since graphemes are a fixed-size type at
the moment.
|
| |
|
|
|
|
|
|
|
|
| |
Both have the same size: 4 bytes.
So far I've just renamed print-byte to print-grapheme, but it still behaves
the same.
I'm going to support printing code-points next, but grapheme 'clusters'
spanning multiple code-points won't be supported for some time.
|
| | |
|
| | |
|
| |
|
|
| |
There was a bug in defining types containing other user-defined types.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a hacky special case. The alternative would be more general support
for generics.
One observation: we might be able to type-check some primitives using `sig`s.
Only if they don't return anything, since primitives usually need to support
arbitrary registers. I'm not doing that yet, though. It eliminates the
possibility of writing tests for them in mu.subx, which can't see 400.mu.
But it's an alternative:
sig allocate out: (addr handle _)
sig populate out: (addr handle array _), n: int
sig populate-stream out: (addr handle stream _), n: int
sig read-from-stream s: (addr stream _T), out: (addr _T)
sig write-to-stream s: (addr stream _T), in: (addr _T)
We could write the tests in Mu. But then we're testing behavior rather
than the code generated. There are trade-offs. By performing type-checking
in mu.subx I retain the option to write both kinds of tests.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Slices contain `addr`s so the same rules apply to them. They can't be stored
in structs and so on. But they may be an efficient temporary while parsing.
Streams are currently a second generic type after arrays, and gradually
strengthening the case to just bite the bullet and support first-class
generics in Mu.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We need to remember to clear local variables. And there's a good question
here of how Mu supports variables of type stream or table. Or other user-defined
types that inline arrays.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function signatures can now take type parameters starting with '_'.
Type parameters in a signature match any concrete type in the call. But
they have to be consistent within a single call.
Things I considered but punted on for now:
- having '_' match anything without needing to be consistent. Wildcards
actually seem harder to understand.
- disallowing top-level '_' types. I'll wait until a concrete use case
for disallowing.
We still don't support *defining* types with type parameters, so for now
this is only useful for calling functions on arrays or streams or handles.
|
| |
|
|
|
| |
I think I've got all the stack management down. Time now for the business
logic. There's one failing test.
|
| |
|
|
| |
type-match? is no longer symmetric; we have to be careful about arg ordering.
|
| | |
|
| |
|
|
| |
We still need to perform pattern matching.
|