tom-seddon / b2

BBC Micro emulator for Windows, OS X, and Linux
114 stars 13 forks source link

Can't build on MacOS / Apple Silicon #207

Open VectorEyes opened 2 years ago

VectorEyes commented 2 years ago

Running a command-line build on Apple Silicon fails as follows:

/src/shared/h/shared/system.h:67:2: error: Unknown gcc CPU #error Unknown gcc CPU ^ /src/shared/h/shared/system.h:101:2: error: Unknown endianness #error Unknown endianness ^ /src/shared/h/shared/system.h:198:2: error: BREAK - unknown CPU It looks like the build is specifying the correct arch (I see "-arch arm64" in the arguments passed to the compiler) but the relevant line of system.h relies on `"__arm__"` being set, which would then #define CPU_ARM 1. This isn't being defined and the build falls over as it cannot define endianness etc.
tom-seddon commented 2 years ago

If you can figure out the right define to key it off, then arranging for CPU_ARM to get defined might do the trick... you'll be a bit on your own though, as this has never really been tested. I think people have had it building on Raspberry Pi, though the performance was rubbish. Hopefully the M1 will fare better.

(When CPU_ARM, it should probably be #define DEBUG_BREAK() (__builtin_trap()) or whatever the clang intrinsic is exactly. #define DEBUG_BREAK() (abort()) is no good, though it is at least portable.)

I should get round to tidying that bit of code up anyway, CPU_PPC32 is irrelevant now.

--Tom

tom-seddon commented 2 years ago

Sazhen86 of stardot has had it running: https://stardot.org.uk/forums/viewtopic.php?p=366282#p366282

macOS fat binaries are termed Universal: https://stackoverflow.com/questions/65157483/macos-build-universal-binary-2-with-cmakebinary

Should be enough info to get AppVeyor building an Apple Silicon version? The ARM build will have to be unsupported for now though.

konsumer commented 2 years ago

I have same issue on Mac, and Linux Arm64. Is this workaround specific to M1?

tom-seddon commented 1 year ago

Yes, it could easily be, if the timer is some functionality that Linux and macOS handle in basically the same way.

If you get the opportunity to try the proposed fix from the stardot thread, any feedback is very welcome, and PRs especially so. I've still yet to try b2 on Apple Silicon myself. (But I'll have to upgrade my 2015 Macbook Pro at some point, so this will all get resolved eventually!)

Thanks,

--Tom

konsumer commented 1 year ago

I'd love to help. There is a vibrant emu-scene around those cheap Anbernic gameboy-like handhelds that is interested in a good BBC micro emulator, and those devices generally run arm/arm64 linux. I have an M1 mac, and a few Pi (3b, 4, zero, etc) that I can also test with, as well as a couple of the aforementioned handhelds.

Although I probably can't help too much with the code, I am happy to test stuff and report back.

I did look around for a possible automated clock-speed thing, and I think this might work, from here:

#include <stdint.h>

//  Windows
#ifdef _WIN32

#include <intrin.h>
uint64_t rdtsc(){
    return __rdtsc();
}

//  Linux/GCC
#else

uint64_t rdtsc(){
    unsigned int lo,hi;
    __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
    return ((uint64_t)hi << 32) | lo;
}

#endif

This looks like a nice package that works well on arm & x86, but seems to only work on linux (although might have some good ideas, either way.)

Seems like it might be a big subject, though, and require a bit of planning/analysis.