mu-spec issueshttps://gitlab.anu.edu.au/mu/mu-spec/-/issues2018-01-26T04:47:41+11:00https://gitlab.anu.edu.au/mu/mu-spec/-/issues/8Calling an exposed Mu function in Mu2018-01-26T04:47:41+11:00John ZhangCalling an exposed Mu function in MuThis problem has been raised before and discussed, but has not been properly documented. How existing (especially reference implementation) handles it also needs to be documented. This thread shall serve these purposes
### Problem Des...This problem has been raised before and discussed, but has not been properly documented. How existing (especially reference implementation) handles it also needs to be documented. This thread shall serve these purposes
### Problem Description
RPython allows casting a function pointer to and from an address. A situation can occur when the code loads a function address, cast it back to a function pointer and calls it.
This poses some problem for Mu because the function is of type `funcref`, and currently `Address` is translated as `uptr<void>`. `ufuncptr` in Mu is specifically for native interface. A Mu function can be 'exposed' to get a `ufuncptr`, but it is expected that it will be called from C rather than from within Mu itself.
What should Mu do in such case? Should the instruction be `CALL` or `CCALL`?
I do acknowledge that the deeper issue is the mismatch of type system assumptions that's built into RPython compiler. Handling it though can be quite tricky.
In previous discussions, Yi did point out that in the Zebu implementation this is not a problem. But I believe that this is a problem for the current reference implementation.https://gitlab.anu.edu.au/mu/mu-spec/-/issues/17Swapstack exc_caluse2017-08-08T01:22:09+10:00Isaac Garianoisaac@ecs.vuw.ac.nzSwapstack exc_caluseCurrently the swap stack instruction requires an exception clause, this makes no sense if the current_stack_clause is 'KILL_OLD'.
I suggest making a minor change:
* If the current stack clause is 'KILL_OLD', require that the exception cl...Currently the swap stack instruction requires an exception clause, this makes no sense if the current_stack_clause is 'KILL_OLD'.
I suggest making a minor change:
* If the current stack clause is 'KILL_OLD', require that the exception clause is absent (and have control flow analysis treat this instruction in the same was a thread_exit, I.e. it has no successor)
* Otherwise, require an exception clause
Also am I correct in assuming it's undefined behaviour to do a swap_stack/new_thread where the new stack clause is THROW_EXC but the last thing executed on the swappee was not a swap stack instruction with an exception clause?https://gitlab.anu.edu.au/mu/mu-spec/-/issues/9Void type allocation2018-01-26T04:47:41+11:00John ZhangVoid type allocationJust wondering, does Mu permit `NEW <@void>`?Just wondering, does Mu permit `NEW <@void>`?