5 ms·
Emulating x86 on X64 on Aarch64
- manuel_w 3y agoIf anyone is wondering: With X64 the author is referring to x86_64 a.k.a. AMD64. Wondering why they're introducing yet another name for the same thing.
- linguae 3y agoWhile I personally prefer the terms x86-64 or AMD64, x64 is used by Microsoft to describe the x86-64 architecture: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/the-x64-processor https://learn.microsoft.com/en-us/windows-hardware/drivers/d... There's even a guide from Intel that uses the term x64: https://www.intel.com/content/dam/develop/external/us/en/documents/introduction-to-x64-assembly-181178.pdf https://www.intel.com/content/dam/develop/external/us/en/doc...
- TillE 3y agoJust to underline that, Microsoft has been using "x64" for about 20 years; the architecture was supported on Windows XP and Server 2003. It's probably the clearest term to use when you're talking specifically about Windows binaries (PE files).
- com2kid 3y agoMore than that, behind the scenes Microsoft helped AMD design x64. (Source: someone who was there when it happened who then told me over beer.)
- deleted 3y ago[deleted]
- monocasa 3y agoYeah, I've heard this too. Apparently Dave Cutler himself had a hand in the design.
- anaisbetts 3y agoAlso because davec hated Intel and demanded that the internal architecture name be called "amd64" in Windows itself to annoy them
- MaulingMonkey 3y agoWhich also means that if you've been dealing with anything referencing build matricies in Visual Studio, you've been using "x64" too. Perhaps exclusively. devenv.com Everything.sln /Build "Debug|Win32" devenv.com Everything.sln /Build "Debug|x64"
- deleted 3y ago[deleted]
- camel-cdr 3y agoX64 is, only beaten by Intel 64, the worst name for the architecture.
- Salgat 3y agox86 is short for 8086 family instruction set architecture, and x64 is short for x86-64. Makes sense to me and follows the same pattern.
- cameron_b 3y agoThe Grief over the use of x64 for AMD64 or X86-64 is based in the prior use of "x64" for the DEC Alpha architecture in the hardware naming: "DECchip 21x64" [0] Digital was earlier to market the Alpha as a 64 bit ISA than either Intel's Itanium ( IA-64) or AMD's x86-64 which is also called AMD64 [1] [0] https://en.wikipedia.org/wiki/DEC_Alpha https://en.wikipedia.org/wiki/DEC_Alpha [1] https://en.wikipedia.org/wiki/64-bit_computing https://en.wikipedia.org/wiki/64-bit_computing
- Salgat 3y agoMy understanding is that these were never just called "x64" though, or at least not commonly.
- wryun 3y agoMy vote is for x32. (you didn't know? https://wiki.debian.org/X32Port https://wiki.debian.org/X32Port)
- Uehreka 3y agoI wouldn’t say that they’re introducing it, I see x64 used to refer to 64-bit x86 in a lot of places. If you don’t like it or think it’s technically wrong for some reason that’s one thing, but you’ll be fighting an uphill battle if you want it to go away.
- sedatk 3y agoIt was called AMD64 when AMD and Microsoft designed it, but Intel objected using the term when they adopted the architecture and coined their own: EM64T. So, Microsoft came up with a compromise and started calling it x64.
- cesarb 3y ago> It was called AMD64 when AMD and Microsoft designed it, The original name was x86-64. Quoting myself (https://news.ycombinator.com/item?id=36075840 https://news.ycombinator.com/item?id=36075840): > I still shake my head at how they were able to successfully rebrand it from amd64 to x86-64 It's the opposite: the original name was x86-64, and amd64 is a later rebranding. See, for instance, the original web site for this (then) new architecture: https://web.archive.org/web/20000829042251/http://www.x86-64.org/about https://web.archive.org/web/20000829042251/http://www.x86-64...
- sedatk 3y agoYes, but that doesn't contradict with what I said. AMD had pivoted to "AMD64" soon after and that was before Intel had released their own name: EM64T. Microsoft coined x64 around that time, probably found it more marketable than x86-64, becuase they had used it in commercial branding such as "Windows XP Professional x64 Edition" too. (They couldn't call Windows XP "64-bit edition" because that term was used for their Itanium-based (IA64) products).
- gmokki 3y agoIntel originally named it "IA-32e" to try to make it sound it was just a small extension on the 32bit x86 architecture whereas the Itanium IA-64 architecture was the future.
- sedatk 3y agoNever heard of that one, but yeah, Intel was very hesitant to admit that IA-64, was, indeed, not the future.
- evmar 3y agoThe post says '64-bit x86 ("x86-64" or "x64")' which is also roughly what the first sentence of Wikipedia has to say about it. I personally picked it just because it was shorter to type and easily understood in context.
- notorandit 3y agoThe article is so fast that it will be written on August 23rd and published on 14th!
- deleted 3y ago[deleted]
- evmar 3y agoThanks, fixed.
- voyagerfan5761 3y agoA lot of personal sites such as this one are built on a public repo someplace, and one is often invited to submit typo corrections etc. upon finding the source. In this case, though, my search dead-ended at code for your custom, minimalist static site generator. https://github.com/evmar/cms https://github.com/evmar/cms Date stamp is part of the metadata passed into the generator, according to https://neugierig.org/software/blog/2022/10/blog-software.html https://neugierig.org/software/blog/2022/10/blog-software.ht..., but I don't see anywhere that the Go code checks whether a post's date is in the future. Did you intend to add a post-scheduling feature but haven't gotten to it?
- evmar 3y agoWow, you are thorough! I just include the date as metadata in the post input file and typed it wrong this time. I don't have any scheduling feature, the whole thing is incredibly manual ("make" followed by "rsync" to publish). I don't publish my blog's source because it includes other things like unpublished drafts.
- deleted 3y ago[deleted]
- msephton 3y agoGiven how you've been able to do this, I'm interested to hear your thoughts on Apple removing support for 32-bit code?
- burnte 3y agoIt cleaned up dramatically what Apple had to support going forward for ARM. They COULD have kept supporting it, they decided since we needed an ISA change, may as well go all 64-bit at the same time and kill off compatibility cruft.
- msephton 3y agoRight, but could they have done something like Wine/you are doing and kept it? A compromise of sorts? Edit: I see you're saying they chose a clean break.
- londons_explore 3y agoThe smart move for Apple would be to always be ready to emulate any old platform. Build the emulator as an app, so that one day, when that app gets too old, run it itself in an emulator. That way it can be emulation all the way down, and you get binary compatibility forever with minimal ongoing engineering cost. The performance would be atrocious if not for the fact computers today are faster than 1980's computers so it really doesn't matter.
- deleted 3y ago[deleted]
- MichaelZuo 3y agoThat's a pretty good point, it is odd for Apple to not have provided even a simple WINE-like utility for emulating 32 bit apps, even without any effort put into optimization it would have still been useful for M1/M2 chips.
- 3y ago
- TazeTSchnitzel 3y agoretrowin32 seems like a very cool project. Conceptually it seems very close to touchHLE. Both are written in Rust!
- deleted 3y ago[deleted]
- neaumusic 3y agoapple's game-porting-toolkit is amazing, highly recommend checking out this article: https://www.applegamingwiki.com/wiki/Game_Porting_Toolkit https://www.applegamingwiki.com/wiki/Game_Porting_Toolkit and this thread (talking about installing 32 bit with wine64): https://www.reddit.com/r/macgaming/comments/15l0onw/dark_and_darker_early_release_gptk/?onetap_auto=true https://www.reddit.com/r/macgaming/comments/15l0onw/dark_and... it's for a specific video game, but very similar (using wine)
- ajross 3y agoCame to this headline thinking "Please be about something other than running DOSBox on a Mac". But indeed, this is fairly novel. It's about running 32 bit i386 binaries in long mode (yeah, on a mac/Rosetta) via setting the compatibility/word-size bits in the code segment using an LDT. FWIW, from the article: > (PS: I love how the "base" address is chopped up into pieces and sprinkled into random seeming places. I believe it's because the format of this data was itself evolved over time across processor versions.) Sort of. The descriptor table was added in the 286 which only had 16 bit registers. The segment base/limit fields there were natural and clean. The 386 needed to squeeze in the top bits somewhere without otherwise wasting memory or breaking compatibility.
- arthur2e5 3y agoI live in a cave called "x86 Hackintosh" -- it sure looks like all this would work on an x86-64 Mac, maybe similar x86-64-only environments like WSL1. Very cool to see wine32on64 being done differently -- without a magick-infused compiler!
- giomasce 3y agoNice project, very cool! A little note about section "Wine's implementation": the implementation described in Ken's email was never really used in Wine, intentionally (in vanilla Wine that kind of hack is not accepted). It has been used for a few years in CrossOver, CodeWeavers' fork of Wine (more recently also used by Apple for its Gaming Toolkit). Wine is currently moving towards supporting x86-on-ARM emulation properly by better separating the guest and host code, in a manner similar to how Windows itself does the same thing. EDIT: Another quick thought: in the project readme you mention the observation that "win32 is the stable Linux userland ABI". The origin of that remark might have been this blog post by Arek Hiler: https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/.
- actionfromafar 3y ago“Win32 is the stable Linux ABI” I think the general sentiment has been around for much longer, but it’s very well put. For instance old Loki Linux ports became useless after only a few years, but you could then run the Windows game in Wine no problem.
- anthk 3y agoNot useless. You had to set something like OSSPD and some MESA variables and the games would run fine with the old libc libraries. I think both Debian and Slackware had "compat" libraries for a while.
- tredre3 3y agoYeah... So to use the program you have to go through a treasure hunt across the internet to find your message, then understand what it means, then follow the steps, then try running the program. Maybe it will work, maybe it won't. That's the Linux adventure!
- anthk 3y agoLinux adventure? Ever heard of PCGaming Wiki and running DX7-9 era games today? That's a clusterfuck of wrappers. Heck, Direct Draw games run dog-slow under Windows > 7 unless you use a DDraw->OpenGL wrapper from WineD3D for Windows and hex-edit the DDL's to avoid name clashes.
- account42 3y ago> One idea I'm considering is instead putting my 64-bit code at a "high" but not outside of 4gb range address, to eliminate the intermediate step. I think on win32, addresses in the 2-4gb range were reserved for the kernel so maybe I could load there, not sure. This was originally true and (theoretically) some executables might actually expect <2GB addresses and break if given unexpected pointers but eventually that restriction was lifted to allow more than 2GB per process. Windows executables can opt into the full 32-bit address space using the large address aware flag [0] but for an compatibility layer like Wine it makes sense to be able to override it and use the full address space even for executables that don't have the flag set because the emulation and/or OS/driver differences can increase the virtual memory usage compared to Windows. Or some executables don't have it set but need it when working with large enough data - this is often the case with heavily modded 32-bit games. Hence Proton's PROTON_FORCE_LARGE_ADDRESS_AWARE override. [0] https://learn.microsoft.com/en-us/cpp/build/reference/largeaddressaware-handle-large-addresses?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/largea...