mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-07-19T15:07:32+10:00https://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/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/33Rework on pin/unpin2017-07-19T15:02:01+10:00Yi LinRework on pin/unpinCurrent `PIN`/`UNPIN` directly get translated into a runtime call into GC to pin/unpin the object, which simply push/remove the object reference to/from a root set (synchronisation required). This is inefficient, and also the behaviour i...Current `PIN`/`UNPIN` directly get translated into a runtime call into GC to pin/unpin the object, which simply push/remove the object reference to/from a root set (synchronisation required). This is inefficient, and also the behaviour is different from the spec (in which you need unpin operations to match every pin operation).
This will need rework, probably along with #12 .
And it is also related with https://gitlab.anu.edu.au/mu/mu-spec/issues/7, which proposes to separate immovability and immortal semantics of `PIN` instruction.https://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/48Set user-defined thread local when launching boot image2019-04-09T16:39:56+10:00Yi LinSet user-defined thread local when launching boot imageCurrently Zebu assumes no user-defined thread local due to the fact that at the time the code was written, we cannot persist heap objects.
However, there is no reason preventing us implementing this now. Currently Zebu assumes no user-defined thread local due to the fact that at the time the code was written, we cannot persist heap objects.
However, there is no reason preventing us implementing this now. Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/51Memory order in store/load API calls2018-09-10T06:31:05+10:00Yi LinMemory order in store/load API callsFor API calls `load()`/`store()`, they take memory order as an argument. However I am uncertain whether we need to do anything special for different memory orders. Current implementation just does a plain load/store in `vm.handle_load()`...For API calls `load()`/`store()`, they take memory order as an argument. However I am uncertain whether we need to do anything special for different memory orders. Current implementation just does a plain load/store in `vm.handle_load()` and `vm.handle_store()`.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/60[aarch64] Unimplemented Backend Features2018-09-10T06:31:05+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[aarch64] Unimplemented Backend FeaturesI noticed there are lots of things that zebu doesn't implement, so I decided to make a list, and will try and keep it up to do (I would like to implement stuff here specifically the mu specific things like traps, watch points, threads an...I noticed there are lots of things that zebu doesn't implement, so I decided to make a list, and will try and keep it up to do (I would like to implement stuff here specifically the mu specific things like traps, watch points, threads and stack related things, as I feel currently Zebu is mostly just LLVM with exceptions and a garbage collector that doesn't collect..)
I'm not entirely sure what the x86-64 backend implements, so i've only listed things for aarch64: (note features with a * next to them haven't been tested properly yet), I have also included things I believe are not implemented on x86-64 but are on aarch64:
Types:
* [ ] `int<n>`:
* [x] n = 1 (some arithmetic)
* [x] * n <= 64 and n != 8, 16, 32, or 64
* [x] * n = 128, floating point conversions
* [ ] n > 64 and n != 128
* [ ] `struct` SSA variables
* [ ] `hybrid` SSA variables
* [ ] `array` SSA variables
* [x] `tagref64`
* [x] `threadref`
* [x] `stackref``
* [ ] `framecursorref`
* [ ] `irbuilderref`
* [ ] `vector<t n>`
Instruction Clauses:
* [ ] keep Alive Clauses
* [ ] Exception clauses
* [x] CALL
* [ ] binop (divison by zero)
* [ ] NEW/NEYHYBRID (allocation failure)
* [ ] LOAD/STORE/CMPXCHG (null referenced)
* [ ] CCALL (implementation defined)
Instructions:
* [ ] `TAILCALL`:
* [x] When the callee's stack argument size is less than or equal to the caller's
* [ ] When the callee's stack argument size is greater than the caller's
* [ ] For unimplemented types:
* [ ] `EXTRACTVALUE`/`INSERTVALUE`
* [ ] `EXTRACTELEMENT`/`INSERTELEMENT`
* [ ] `SHUFFLEVECTOR`
* [ ] Memory
* [x] `ALLOCA`/`ALLOCAHYBRID`
* [x] * `CMPXCHG`
* [x] * `FENCE`
* [ ] `ATOMICRMW`
* [ ] Traps/watchpoints
* [ ] `TRAP`
* [ ] `WATCHPOINT`
* [ ] `WPBRANCH`
* [x] Thread/stack instructions
* [x] `NEWTHREAD`
* [x] `SWAPTSTACK`
Common Instructions
* [x] thread and stack things:
* [x] new_stack
* [x] kill_stack
* [x] thread_exit
* [x] current_stack
* [x] set_threadlocal
* [x] get_threadlocal
* [x] tr64.*
* [ ] futex.*
* [ ] kill_dependency
* [ ] native.* (except nativ.pin and nativ.unpnin)
* [ ] meta.*
* [ ] irbuilder.*https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/64[x86_64] Unimplemented Backend Features2017-07-20T20:57:04+10:00Yi Lin[x86_64] Unimplemented Backend FeaturesThis issue tracks Mu specification coverage in x86_64 backend.
Types:
* [ ] `int<n>`:
* [ ] n = 1 (some arithmetic)
* [ ] * n <= 64 and n != 8, 16, 32, or 64
* [ ] * n = 128, floating point conversions
* [ ] n > 64 and n != 128
* ...This issue tracks Mu specification coverage in x86_64 backend.
Types:
* [ ] `int<n>`:
* [ ] n = 1 (some arithmetic)
* [ ] * n <= 64 and n != 8, 16, 32, or 64
* [ ] * n = 128, floating point conversions
* [ ] n > 64 and n != 128
* [ ] `struct` SSA variables
* [ ] `hybrid` SSA variables
* [ ] `array` SSA variables
* [ ] `tagref64`
* [ ] `threadref`
* [ ] `stackref``
* [ ] `framecursorref`
* [ ] `irbuilderref`
* [ ] `vector<t n>`
Instruction Clauses:
* [ ] keep Alive Clauses
* [ ] Exception clauses
* [x] CALL
* [ ] binop (divison by zero)
* [ ] NEW/NEYHYBRID (allocation failure)
* [ ] LOAD/STORE/CMPXCHG (null referenced)
* [ ] CCALL (implementation defined)
Instructions:
* [ ] `TAILCALL`
* [ ] For unimplemented types:
* [ ] `EXTRACTVALUE`/`INSERTVALUE`
* [ ] `EXTRACTELEMENT`/`INSERTELEMENT`
* [ ] `SHUFFLEVECTOR`
* [ ] Memory
* [ ] `ALLOCA`/`ALLOCAHYBRID`
* [ ] * `CMPXCHG`
* [x] * `FENCE`
* [ ] `ATOMICRMW`
* [ ] Traps/watchpoints
* [ ] `TRAP`
* [ ] `WATCHPOINT`
* [ ] `WPBRANCH`
* [ ] Thread/stack instructions
* [ ] `NEWTHREAD`
* [ ] `SWAPTSTACK`
Common Instructions
* [ ] thread and stack things:
* [ ] current_stack
* [ ] thread_exit
* [ ] new_stack
* [ ] tr64.*
* [ ] futex.*
* [ ] kill_dependency
* [ ] native.* (except nativ.pin and nativ.unpnin)
* [ ] meta.*
* [ ] irbuilder.*https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/67[x86_64] JIT backend2017-10-09T17:34:52+11:00Yi Lin[x86_64] JIT backendI will probably be working on a JIT backend for x86_64. Currently I am considering using Intel XED (https://intelxed.github.io/), which is a C library from Intel under Apache 2.0 license for encoding x86/x86_64 instructions. This tool (h...I will probably be working on a JIT backend for x86_64. Currently I am considering using Intel XED (https://intelxed.github.io/), which is a C library from Intel under Apache 2.0 license for encoding x86/x86_64 instructions. This tool (https://github.com/servo/rust-bindgen) can generate Rust bindings from C/C++ headers, with which I can easily use the library in our implementation.
As I implement the JIT backend, I expect a lot of changes to the existing code (as we switch from AOT focus to adapt both). So I suggest we postpone the JIT backend for aarch64 for a while until I have reached some milestones for x86_64, such as
* JIT compile an add function
* JIT compile a function that contains a loop
* JIT compile a function that contains a call
* JIT compile a function that uses VM runtime
Whether doing JIT or AOT is a build-time option for Zebu. Please let me know if you think this is problematic.Yi LinYi Lin