mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-11-21T14:37:55+11:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/93Issues before enabling GC2017-11-21T14:37:55+11:00Yi LinIssues before enabling GCThe GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help f...The GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help find references in stack/heap. They need to be fixed for correctness. And also `set_low_water_mark()` should be called by the VM to set a limit for stack scanning. Alternatively we may also let GC know about stack bounds so it won't go beyond the stack memory.
* inserting yieldpoint.
* Allowing finding base reference for internal references. As we have 16 bytes min size and 16 bytes min alignment of objects, for any reference we mask it to 16 bytes, and see if it contains a valid object encoding (non-empty, or with certain bits set).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/42Exception handling for native frames2017-09-09T14:19:11+10:00Yi LinException handling for native framesCurrent implementation will fail for being unable to find information about native frames.Current implementation will fail for being unable to find information about native frames.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/73Signal handler for Zebu2017-08-05T00:16:06+10:00Yi LinSignal handler for ZebuThis issue tracks what signal we need to be able to identify for Zebu:
* stack overflow/underflow (access to protected guard page)
* `INT3` code patching trap
There are a few rust crates that abstracts over signal handling on Unix, we m...This issue tracks what signal we need to be able to identify for Zebu:
* stack overflow/underflow (access to protected guard page)
* `INT3` code patching trap
There are a few rust crates that abstracts over signal handling on Unix, we may consider using them instead of doing it in a C/FFI approach:
* [chan-signal](https://github.com/BurntSushi/chan-signal)
* [signal](https://github.com/tailhook/signal)
* [rust simple signal](https://github.com/swizard0/rust-simple-signal)Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/17Implementing ALLOCA/ALLOCA_HYBRID2017-07-19T15:07:32+10:00Yi LinImplementing ALLOCA/ALLOCA_HYBRIDCurrently the compiler assumes that frame size is constant at compile time.
For *x86_64*, stack pointer needs to be 16-bytes aligned before a function call. The compiler ensures this by:
* `rbp` is always 16-bytes aligned.
* frame ...Currently the compiler assumes that frame size is constant at compile time.
For *x86_64*, stack pointer needs to be 16-bytes aligned before a function call. The compiler ensures this by:
* `rbp` is always 16-bytes aligned.
* frame size is a multiple of 16-bytes (align up to 16-bytes if it is not, see `frame.rs`).
* if any call argument is passed on stack, if necessary, push a padding value to stack so that `rsp` is still 16-bytes aligned after pushing call arguments.
* restoring from an exception will set `rsp` from `rbp` and the constant frame size.
We can implement `ALLOCA` by computing allocating size during compile time, and frame size is still a compile-time constant. However, the implementation of `ALLOCA_HYBRID` will break this assumption. A straightforward solution is to make the alloca'd size always a multiple of 16-bytes (for alignment requirement), and record a *current frame size* somewhere (for restoring from exception) - this would keep most of the above unchanged. This issue tracks related discussion.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/44Implementing TagRef642017-07-19T15:00:38+10:00Yi LinImplementing TagRef64reference: https://nikic.github.io/2012/02/02/Pointer-magic-for-efficient-dynamic-value-representations.htmlreference: https://nikic.github.io/2012/02/02/Pointer-magic-for-efficient-dynamic-value-representations.htmlYi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/31[x86_64] floating point/int128 conversion2017-06-13T13:38:11+10:00Yi Lin[x86_64] floating point/int128 conversionunimplemented for nowunimplemented for nowYi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/37[x86-64] Passing a 128-bit integer to a C function using CCALL2017-06-11T19:34:41+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[x86-64] Passing a 128-bit integer to a C function using CCALLPassing a 128-bit integer to a C function (ussing CCALL) dosn't work on x86-64, e.g:
I wrote a test to check that 128-bit integers are passed correctly when calling functions (it is designed to cause the last argument to be placed on th...Passing a 128-bit integer to a C function (ussing CCALL) dosn't work on x86-64, e.g:
I wrote a test to check that 128-bit integers are passed correctly when calling functions (it is designed to cause the last argument to be placed on the stack on x86, but on aarch64 it should be in a register).
arg_overflow.uir:
```
.funcsig test_arg_overflow_sig = () -> ()
.funcdef my_main<()->()>
{
entry():
CCALL #DEFAULT <ufuncptr<test_arg_overflow_sig> test_arg_overflow_sig> <ufuncptr<test_arg_overflow_sig>>EXTERN "c_test_arg_overflow" ()
CALL <test_arg_overflow_sig> mu_test_arg_overflow()
RET
}
.funcsig arg_overflow_sig = (int<64> int<128> int<128> int<128>) -> ()
.funcdef mu_test_arg_overflow<test_arg_overflow_sig>
{
entry():
int128_0 = ADD <int<128>> <int<128>>0 <int<128>>0
int128_F = ADD <int<128>> <int<128>>0 <int<128>>0xFFFFFFFFFFFFFFFF0000000000000000
CCALL #DEFAULT <ufuncptr<arg_overflow_sig> arg_overflow_sig> <ufuncptr<arg_overflow_sig>>EXTERN "arg_overflow" (<int<64>>0 int128_0 int128_0 int128_F)
RET
}
```
It needs to be compiled with the following C code:
arg_overflow.c
```
#include <stdint.h>
#include <stdio.h>
void arg_overflow(uint64_t a, __int128_t b, __int128_t c, __int128_t d) {
printf("d = %016lX%016lX\n", (uint64_t)(d >> 64), (uint64_t)d);
}
void c_test_arg_overflow()
{
arg_overflow(0, 0, 0, (__int128_t)(0xFFFFFFFFFFFFFFFF) << 64);
}
```
On x86-64 using the line ` ./muc -r -f my_main arg_overflow.uir arg_overflow/arg_overflow`, (using the latest commit in the aarch64 branch) it fails to compile, giving the error:
```
thread '<unnamed>' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_sel.rs:3181
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:355
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:371
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:549
5: std::panicking::begin_panic
6: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_c_call_ir
7: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::instruction_select
8: <mu::compiler::backend::x86_64::inst_sel::InstructionSelection as mu::compiler::passes::CompilerPass>::visit_function
9: mu::compiler::passes::CompilerPass::execute
10: mu::compiler::Compiler::compile
11: mu::vm::vm::VM::make_boot_image_internal
12: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
13: main
14: __libc_start_main
15: _start
fatal runtime error: failed to initiate panic, error 5
Aborted (core dumped)
```
On aarch64 it compiles (well Zebu fails at linking, but it works if I add 'arg_overflow.c' to the clang command) and runs correctly, printing:
```
d = FFFFFFFFFFFFFFFF0000000000000000
d = FFFFFFFFFFFFFFFF0000000000000000
```Yi LinYi Lin