Open michaeljclark opened 7 years ago
Caution, the SysV and Win64 ABI differ significantly
As is, under Win64, the jitt'ed code can't call back jit_runloop::mmu_sw() for instance (when using mmu-proxy)
Plus, create_load_store()
& create_trace_lookup()
shall handle the 'shadow space' on the stack (sub rsp, 0x20
), or else the consecutive callbacks in rv8 are likely to corrupt the stack when spilling parameters passed in registers.
Regards
Thanks for the note. I am indeed aware of the Windows ABI calling convention differences, so yes, we probably should add a comment there.
The current emulator code has been written with Win64 in mind however current testing is being performed on macOS, Linux and FreeBSD. There are some sections of code that need to be abstracted.
The POSIX ABI proxy currently works with the Windows Services for Linux emulation layer however it can be ported to Win64 by using a subset of the Windows compatible POSIX APIs. e.g. std::thread but no fork.
The privileged emulator (when complete) can be made to run as a native Win64 application as it only needs to emulate virtual hardware (timer, framebuffer, virtio block, virtio net), not the POSIX API.
The primary changes required at present are memory mapping abstractions for Virtual{Alloc,Protect,Free} and mmap/munmap/mprotect.
Platform neutral type aliases are defined in
asm/riscv-types.h
instead of using stdint.h types due to the use of signed long int and unsigned long int for s64 and u64 by some library headers. Theasm/riscv-types.h
definitions are compatible with ILP32, LLP64 and LP64, which supports Windows and SVR4 ABIs for x86 and RISC-V.The minimum Windows target will be Visual Studio Community 2015.