4 ms·
Wasn't there some dead weight dropoff† once with amd64, as a x86 CPU is unable to execute 16-bit code when in 64-bit mode? IIRC that was a notable cause of DOS
by lloeki 9y ago
Wasn't there some dead weight dropoff† once with amd64, as a x86 CPU is unable to execute 16-bit code when in 64-bit mode?
IIRC that was a notable cause of DOSBox becoming slower when going 64-bit as it had to emulate the 16-bit CPU instead of just running on metal, as well as 64-bit Windows (7?) being unable to run old DOS and Win3x software.
With an increasingly rolling-release culture on software I can't wait for X-year support for hardware instruction sets /s. Wait, this is already happening for Android phones, where ARM SoC manufacturers just flip it at OS and phone vendors (Nexus 4, OnePlus X). I just realised Apple made a damn right call getting that under their control on that front.
† the metal may still be there though, waiting to be jettisoned as the market for 32-bit OSes goes away.
- phkahler 9y ago>> waiting to be jettisoned as the market for 32-bit OSes goes away. I didn't know there still was a market for 32-bit x86 OSes. I suppose legacy systems - SCADA and such.
- bonzini 9y agoThere's a market for 16-bit OSed too, though often they run virtualized because the hardware might not even exist anymore.
- en4bz 9y agoIn long mode you no longer have access to the virtual 8086 mode which is most likely what DOSBox was utilizing.
- legulere 9y agoYep they threw out a bunch of stuff. What I remember: the CS, SS, DS, and ES segment registers, binary coded decimal instructions, protection ring 1 and 2 as only 0 and 3 are used. Probably there is a lot of more things that were removed.
- wolfgke 9y ago> protection ring 1 and 2 as only 0 and 3 are used Are they really dropped in x86-64? I thought they are still supported also in 64 bit mode.
- colejohnson66 9y agoThe silicon is still there, but it's not going away. Intel loves their backwards compatibility. It's also marketing: if Intel dropped support for some instructions, AMD could say they support more instructions than Intel even if those instructions aren't used.
- wolfgke 9y ago> as a x86 CPU is unable to execute 16-bit code when in 64-bit mode? This is still possible, though unsupported by Windows and Linux (the latter one never supported 16 bit code).
- monocasa 9y ago32 bit x86 Linux supported 16 bit code. http://man7.org/linux/man-pages/man2/vm86.2.html http://man7.org/linux/man-pages/man2/vm86.2.html
- wolfgke 9y agoThe vm86 syscall is for entering Virtual 8086 mode, which is indeed not supported in Long mode. This mode was for example used under Windows 9x for implementing the DOS box. But this is not what I was talking about. I am talking about 16 bit code in protected mode. This is/was used under Win16 and is supported in all 32 bit versions of Windows.
- badsectoracula 9y agoWin16 can run in 64bit mode as long as it is 16bit protected mode code. WINE uses that to run Win3.1 apps in 64bit Linux. For example: http://i.imgur.com/KtgLeWu.png http://i.imgur.com/KtgLeWu.png (this is an old shot of mine and yes i used a XFCE theme to make it look like Win95 :-P)
- wolfgke 9y ago> Win16 can run in 64bit mode as long as it is 16bit protected mode code. Not under Windows: https://news.ycombinator.com/item?id=14246521 https://news.ycombinator.com/item?id=14246521
- badsectoracula 9y agoDOSBox was always an emulator, at some point they added JIT but it was always emulating the CPU, it never run code on the underlying CPU directly.
- tropo 9y agoWhen in "long mode", meaning a 64-bit OS, you can execute everything other than 16-bit protected mode code. You can still run 16-bit code that was designed for real mode. This means you could run some really old DOS programs, but not ones with a 16-bit DOS extender and not 16-bit Windows programs. Of course, a 64-bit OS could pop in and out of 64-bit mode as needed.