ARM Macs.

[bobingabout]

Now that Mac is moving for ARM CPUs for their new Macs, what does that mean for Factorio Mac support?

[Koub]

I guess this and this will have to be updated with an additional line : x86 CPU.

[Squelch]

I guess this and this will have to be updated with an additional line : x86 CPU.

I do hope that is only a temporary limitation. I don't really care much for Macs, but ARM is coming/already here for desktops and it might be prudent to explore venturing into supporting the architecture.

[orzelek]

I guess this and this will have to be updated with an additional line : x86 CPU.

I do hope that is only a temporary limitation. I don't really care much for Macs, but ARM is coming/already here for desktops and it might be prudent to explore venturing into supporting the architecture.

My guess would be that it might get support with disclaimer about not being able to play multiplayer with x86 PC's. Making sure that it's consistent between different architectures might be problematic.

[Koub]

Yeah the main issue is the need of absolute determinism down to the tick. There were desyncs because some mathematical functions had different results on the similar hardware depending on the OS (source). If one adds an additional hardware type, I fear the need of efforts to keep the determinism in multi would be an order of magnitude higher.

I am also inclined to think that the real issue would be multiplayer, as single player does not care for determinism.

[Yoyobuae]

How's the 3D support on ARM systems these days?

I remember that being one of the limiting factors for cross portability between x86 and ARM devices. Granted that was true for ARM SoC based devices (so integrated 3D gpu).

I think a beefy GPU is not all that required for Factorio but there might be some things here and there that might not work in ARM GPUs, like the shaders for the water (though I guess those could be turned off).

[bobingabout]

Yeah, I think there are Microsoft Surface Pro tablets (which are used as PCs) that have ARM CPUs in them already too. And they have an x86 emulation built in to run older software.

The catch is that they run x86 software NOT x64, so, Factorio wouldn't run on them. Also Emulation, eww.

Though, an X86 based CPU already have Virtualisation, dedicated hardware for virtual machines... why can't they just make a new hybrid CPU that runs both? (I mean... there's reasons for moving to ARM, and one of them is that it apparantly uses less POWER to do the processing, which is an advantage you'd lose if they also had an X86 component built in)


At the end of the day, Apple really doesn't care about backwards compatability, they've changed CPU Archetecture twice before, starting on 68k, then moving to PowerPC, and then to x86, so the oldest software that still runs on a modern mac could only be as old as about 14 years.
In contrast, your PC is actually fully capable of running software that was written in the early 80s for MS-DOS, the only reason why it won't run on Windows itself is because you have a 64bit operating system that is only using the 32 and 64bit instruction sets, and ignoring the 16bit instruction set, yet you can still run A LOT of software designed for windows 95 on it.
You could most likely plug a USB Floppy disk drive into your modern PC, Boot from it into DOS, and nativly(no emulation) play a 1980s DOS game on it.(Except likely without sound, because sound cards back then needed drivers or specific channels, and your modern PC probably won't have a motherboard speaker in it)
it only becomes a little awkward if you need a storage medium larger than a floppy disk, as then you run into issues with trying to find drivers for your new 64bit hardware for an old 16/32 bit operating system. Even with something like Windows XP, you'll have trouble trying to find SATA drivers for it, let alone NVMe drivers.

[blahfasel2000]

Though, an X86 based CPU already have Virtualisation, dedicated hardware for virtual machines... why can't they just make a new hybrid CPU that runs both? (I mean... there's reasons for moving to ARM, and one of them is that it apparantly uses less POWER to do the processing, which is an advantage you'd lose if they also had an X86 component built in)

Well, Apple specifically couldn't do it because they have neither the know-how to build a competitive x86 CPU nor the necessary cross-licensing agreements that exist between AMD and Intel that would be needed to implement some of the more recent additions to the x86 architecture.

Other than that there's no law of nature or something that would prevent such a hybrid, in fact every recent AMD CPU (Ryzen, Threadripper and Epyc) contains an ARM Cortex-A5 CPU core that provides key management functionality for AMD's Secure Memory Encryption (this core can't be used to run arbitrary ARM software though, it only runs AMD provided firmware).

In contrast, your PC is actually fully capable of running software that was written in the early 80s for MS-DOS, the only reason why it won't run on Windows itself is because you have a 64bit operating system that is only using the 32 and 64bit instruction sets, and ignoring the 16bit instruction set, yet you can still run A LOT of software designed for windows 95 on it.

The main reason why support for old 16 bit real mode software was dropped with the introduction of 64 bit is that the Virtual 8086 Mode that existed since the Intel 80386 and was needed to run those old programs under modern operating systems can't be used together with x86-64 Long Mode due to lack of hardware support for it. It was resurrected again on the hardware side with the introduction of VT-x and AMD-V hardware virtualization support, but now requires basically a full hypervisor to function, so it wasn't brought back on the OS side (at least not on Windows, Linux still supports it).

[bobingabout]

In contrast, your PC is actually fully capable of running software that was written in the early 80s for MS-DOS, the only reason why it won't run on Windows itself is because you have a 64bit operating system that is only using the 32 and 64bit instruction sets, and ignoring the 16bit instruction set, yet you can still run A LOT of software designed for windows 95 on it.

The main reason why support for old 16 bit real mode software was dropped with the introduction of 64 bit is that the Virtual 8086 Mode that existed since the Intel 80386 and was needed to run those old programs under modern operating systems can't be used together with x86-64 Long Mode due to lack of hardware support for it. It was resurrected again on the hardware side with the introduction of VT-x and AMD-V hardware virtualization support, but now requires basically a full hypervisor to function, so it wasn't brought back on the OS side (at least not on Windows, Linux still supports it).

I'd say that's only Partially true... Basically, it's like "Here's 3 instruction sets, 16bit, 32bit and 64bit. But you can only use 2 side by side.", and AFAIK, most of the "You can only pick 2" is mostly down to Windows (Which was first done in XP at the time, but nobody liked 64bit XP). Basically, rather than totally re-writing the architecture of the operating system to be able to handle all 3 at once, they just swapped out the 16bit stuff with 64bit stuff... or depending how you look at it, swapped 32bit for 64bit, then 16bit for 32bit.
In theory, they could have done all 3 side by side with Vista, but chose not to, I mean, even in XP, the DOS side of things was already being Emulated, and you also have to draw the line at some point, I mean, Factorio dropped XP support with 1% of people using it. when you consider the amount of software the average person was using that was still using 16bit instruction sets when they were moving to Vista was probably around that number already, and MOST of it was rooted in installers... (I know, sounds odd that 32bit software would have a 16bit installer, but it's true!)

[blahfasel2000]

I'd say that's only Partially true... Basically, it's like "Here's 3 instruction sets, 16bit, 32bit and 64bit. But you can only use 2 side by side.", and AFAIK, most of the "You can only pick 2" is mostly down to Windows (Which was first done in XP at the time, but nobody liked 64bit XP).

You have to differentiate between 16 bit real mode and 16 bit protected mode software.

For 16 bit protected mode you are right. x86-64 long mode still has support for it, so in theory they could have continued to support older 16 bit Windows software (from Windows/286 2.10 onwards). However, the main problem were the handles that are used by the Windows API for practically everything. While they were stored and passed as 32 bits on win32, they only had 16 significant bits so that they could be truncated when passing between 32 bit and 16 bit code. This meant that many things (open files, open windows/widgets, etc.) were all still limited to 2^16 on 32 bit Windows. With the introduction of 64 bit support they decided to grab the opportunity and finally extend handles to 32 significant bits, which meant ditching support for old 16 bit Windows applications. Wine under Linux can still run the old software even on a 64 bit system, but that's because unlike Windows Wine doesn't actually have to deal with running a mix of 16, 32 and 64 bit software at the same time, since it only runs one application at a time per Wine instance, so they weren't forced to remove the 16 bit support.

But for 16 bit real mode (ie. DOS) software it's a different story. To run old DOS software virtual 8086 mode is needed to emulate real mode CPU behaviour. You can't use virtual 8086 mode together with x86-64 long mode, the hardware simply doesn't support it (virtual 8086 mode requires hardware task switching, which was removed for x86-64 long mode). That's why DOSEMU on Linux actually does a full CPU emulation when running on a 64 bit system, while using virtual 8086 mode when running on a 32 bit kernel.