| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Mu will be a language with generics -- but no static dispatch.
|
| |
|
| |
|
|
|
|
| |
Tighten up some function signatures.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Every time you press a key the depth increases by 1, and then the tree
re-renders.
|
| |
|
|
|
|
| |
baby steps: rendering a tree node with just one child
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test input:
fn foo {
var y/edx: int <- copy 0
y <- shift-left 2
y <- shift-right 2
y <- shift-right-signed 2
var x: int
shift-left x, 2
shift-right x, 2
shift-right-signed x, 2
}
output:
foo:
# . prologue
55/push-ebp
89/<- %ebp 4/r32/esp
{
$foo:0x00000001:loop:
ff 6/subop/push %edx
ba/copy-to-edx 0/imm32
c1/shift 4/subop/left %edx 2/imm8
c1/shift 5/subop/right-padding-zeroes %edx 2/imm8
c1/shift 7/subop/right-preserving-sign %edx 2/imm8
68/push 0/imm32
c1/shift 4/subop/left *(ebp+0xfffffff8) 2/imm8
c1/shift 5/subop/right-padding-zeroes *(ebp+0xfffffff8) 2/imm8
c1/shift 7/subop/right-preserving-sign *(ebp+0xfffffff8) 2/imm8
81 0/subop/add %esp 0x00000004/imm32
8f 0/subop/pop %edx
}
$foo:0x00000001:break:
# . epilogue
89/<- %esp 5/r32/ebp
5d/pop-to-ebp
c3/return
test input 2:
$ cat x.mu
fn main -> o/ebx: int {
o <- copy 3
o <- shift-left 2
}
output 2:
$ ./translate_mu x.mu
$ ./a.elf
$ echo $?
12
|
|
|
|
|
|
| |
Bit-shifts aren't quite right yet. We need to emit /imm8 rather than /imm32.
This commit introduces the field, though we don't use it yet.
|
|
|
|
| |
I'm not happy with the names.
|
| |
|
| |
|