Hacker News Reader

Comment by silly-silly | Hacker News Reader

Looks likes emacs didnt run perfectly on the emulation/translation layer known as rosetta.. Maybe its not so perfect after all.

View on HN

On the other hand, emacs is self-modifying code. Or executable data. it's lambdas all the way down. ;)

Virtualization of operating systems is not supported in Rosetta.

I cackled.

Thanks...I needed a laugh

I haven't had any issues using the "Mac port" of Emacs here: https://github.com/railwaycat/homebrew-emacsmacport

I installed it with the x86_64 architecture.

EDIT: Was more explicit in architecture nomenclature.

I installed it with the x86 architecture.

Do the 32-bit binaries really run on M1? I thought only x86_64 would run there, emulated.

Updated my comment with the additional clarity of "_64".

I wonder if Rosetta applies to apps that are purchased from the app store or at least are compiled with Xcode, but maybe not apps compiled with gcc. Or maybe if you compile something with gcc there's a way to specify to the OS that it should run with Rosetta.

I’m sure Rosetta 2 is designed to work with gcc compiled apps but given that LLVM/Clang is largely sponsored by Apple, I’m sure the preference is on that, versus whatever version of gcc with whatever specific settings emacs is using.

Just a guess though.

I'm pretty sure the problem is that the "portable dumper" that replaces the dumpster fire that was unexec is not in fact portable across architectures.

Rosetta is designed to work on all x86_64 binaries.

Most, not all. https://developer.apple.com/documentation/apple_silicon/abou...:

“What Can't Be Translated?

Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. However, Rosetta doesn’t translate the following executables:

- Kernel extensions

- Virtual Machine apps that virtualize x86_64 computer platforms

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the sysctlbyname function to check the hw.optional.avx512f attribute.“

So, if you compiled specifically for some CPU,

> So, if you compiled specifically for some CPU,

It would be unreasonable to the point of impossibility to expect it to implement every instruction that an x86_64 CPU could possibly have. So as far as it pretends to be an x86_64 CPU, rather than every x86_64 CPU, it works on all [program] binaries.

I'm thinking it's more of the AVX instructions still being covered by patents. Some older comments [1] suggest that plain AVX will only lose its patent protection in 2031.

[1] https://news.ycombinator.com/item?id=14528591

Another factor is that Mac software was never able to rely on the availablility of AVX instructions anyway. macOS Catalina was officially supported on some systems with processors as old as Ivy Bridge, which lacked AVX support.

I thought it was up to the software (for example, a video encoder like Handbrake) to detect whether a processor supported a set of instructions, and then try to use them?

That's how it's supposed to work, yes. And any software that does that should probably work fine on Apple Silicon, by falling back to the non-AVX path under emulation.

I've seen some poorly behaved Mac software which used AVX instructions without testing for availability. It crashes if run on some older Macs, and it won't work at all on Apple Silicon.

I guess you could compile a binary that is exclusively x86_64h, but Apple silicon won't load it anyways so…

Reply on news.ycombinator.com