MSVC native port

[ZakDanger]

I am opening this issue as a place to pose questions during the port of unicorn to MSVC.

[ZakDanger]

Wow well after much work I have the x86_x64-softmmu specific part of unicorn enigne building in msvc.

One thing that I still need to fix is the atomic operations. I haven't had experience with this before and from reading about it, it sounds like something that I could do incorrectly and then cause weird random bugs that are hard to track down. So I am hoping someone can help me implement these correctly:

/* Compiler barrier */
#ifdef _MSC_VER
// TODO: fix me!!!
#define barrier()   //{ __asm volatile("" ::: "memory"); (void)0; }
#else
#define barrier()   ({ asm volatile("" ::: "memory"); (void)0; })
#endif

#if defined __x86_64__
# ifdef _MSC_VER
// TODO: fix me!!!
# define smp_mb()    //{ __asm volatile("mfence" ::: "memory"); (void)0; }
# else
# define smp_mb()    ({ asm volatile("mfence" ::: "memory"); (void)0; })
# endif
#else
# ifdef _MSC_VER
// TODO: fix me!!!
# define smp_mb()    //{ __asm volatile("lock; addl $0,0(%esp) " ::: "memory"); (void)0; }
# else
# define smp_mb()    ({ asm volatile("lock; addl $0,0(%%esp) " ::: "memory"); (void)0; })
# endif
#endif

[aquynh]

We dont have SMP or multithread anywhere, so i believe you can safely ignore these atomic stuffs.

[ZakDanger]

Ok cool. I'll leave the "TODO" markers in place to help make it clear that they are not implemented.

Hopefully porting across the other target CPUs will be easier since common code will already be done and I have solutions worked out now for lots of the "gotchas".

[aquynh]

Fantastic! You can make pull req as soon as possible.

[ZakDanger]

Are 64bit versions of unicorn working?
If so I will add builds for 32bit and 64bit.

[aquynh]

Yes, msys build works well for both 32bit & 64bit.

[Nukem9]

@xorstream I think the MSVC MemoryBarrier(); or _ReadWriteBarrier(); intrinsics would be sufficient as they prevent cpu/compiler reordering. (If you want to replace it - I'm not familiar with gcc syntax)

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684208(v=vs.85).aspx

[ZakDanger]

@Nukem9 Yes they are one of the ones I was reading about. I just wanted to be 100% sure they were the right ones and weren't too heavy handed also. It seems there are solutions that work but take much longer they they need to.

I would like for someone who is 100% sure to fill in those lines, or provide code for them so I can fill them in. If this person is you then please do so :)

[aquynh]

Unicorn is now single-thread, but not a concurrent program like original Qemu, so this really does not matter. i guess we can define all these atomic macros like (void)0.

[ZakDanger]

ok.
still working on this. small progress update:

sample_x86.c is now running in native 64bit, although crashing near the end of it's tests. maybe timer related.

sample_x86.c in 32bit mode is crashing strangely before it manages to run any of the tests. i think due to function param handling as while debugging it looks like the first param is in eax instead of on the stack.

[ZakDanger]

I am thinking that once i have x86/x64 cpu working without issues i will submit a pull request so that ppl can have a look at the various changes i have had to make so far. Then based on whether they are horrified, or have any suggestions etc I will continue with the other cpu support.

[aquynh]

Good idea, cant wait!

[ZakDanger]

Are you sure it is single threaded?
I notice uc.c : enable_emu_timer() starts a timeout thread.

[aquynh]

Yes that is the only place, and only when you emulate with timeout. But i dont think this needs memory barrier, like in original Qemu.