Replies: 1 comment
-
I think you are the person to manage the behavior for the JIT compiler, which means you should provide the correct type for MIR API and generate certain code for exec. To my understanding, you need to compile your JS code into strong-typed form before you actually call into JIT level. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, i'm trying MIR as a JIT for a Javascript interpreter. I will start the implementation using the MIR C compiler, and then later refine it using the generated intermediate binary as a guide.
For testing, i added a Javascript API to play with the MIR compiler as a Javascript object. It seems like a handy feature worth keeping in my project, security and stability issues aside.
Run
While developing the type conversions for MIR_interp_arr, i discovered that in the func_item object, the type information for the arguments and return value are ambiguous for pointers.
The type fields seem to always use MIR_T_U64 to store pointers of any type. If the Javascript does not know what type of pointers they are, then it cannot do automatic type conversion.
For example, if a C function takes a string, then depending on whether the argument is int8*, int16*, or int32*, the Javascript would convert the string to UTF8, UTF16, or UTF32. It would throw an error if the argument is float*.
Also, it seems that because MIR_T_U64 is used for pointers, the func_item object shows long-unsigned arguments as having the same MIR_T_U32 type as 32 bit arguments.
To neatly integrate the C compiler as a Javascript object, i would need the function signatures to include distinct basic pointer types instead of being generalized as uint64s.
But for now it wont stop me from continuing to try MIR as a JIT. Thanks for all your hard work getting this to version 1
Beta Was this translation helpful? Give feedback.
All reactions