Add Win64 Virtual{Alloc,Protect,Free} wrappers for mmap,munmap,mprotect

[michaeljclark]

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. The asm/riscv-types.h definitions are compatible with ILP32, LLP64 and LP64, which supports Windows and SVR4 ABIs for x86 and RISC-V.

    typedef signed int         s32;
    typedef unsigned int       u32;
    typedef signed long long   s64;
    typedef unsigned long long u64;

The minimum Windows target will be Visual Studio Community 2015.

[jmonesti]

Caution, the SysV and Win64 ABI differ significantly

• SysV passes parameters in RDI, RSI, RDX, RCX, R8, R9
• Win64 passes parameters in RCX, RDX, R8, R9

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

[michaeljclark]

Thanks for the note. I am indeed aware of the Windows ABI calling convention differences, so yes, we probably should add a comment there.