• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Zen 6 Speculation Thread

Page 397 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
You're seriously underestimating the cost of desgin and more the one of validation, and the impacts on how you can let an ISA progress with such dead 50 years old weight.
It's small potatoes legacy stuff - it's already been done, no new changes are made, no way this increases complexity by more than 1%, which is fine cost to maintain 100% backwards compatibility rather than anything less.
 
It's small potatoes legacy stuff - it's already been done, no new changes are made, no way this increases complexity by more than 1%, which is fine cost to maintain 100% backwards compatibility rather than anything less.
It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.

Out of curiosity, do you really run 16-bit code?
 
It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.

Out of curiosity, do you really run 16-bit code?
Awww. The good old days!

void (far *funcPtr)(void);

Haven't seen or used it for maybe 20 years. I doubt that 16bit is needed; however, 32 bit is a VERY different story as are a number of extensions.

Backwards compatibility is definitely a real thing in PC's.
 
I doubt that 16bit is needed; however, 32 bit is a VERY different story as are a number of extensions.

Backwards compatibility is definitely a real thing in PC's.
I agree that killing 32-bit is premature. My point is that the much praised compatibility is an illusion. As I previously wrote trying to run >20 yo 32-bit programs is much easier by using simulation rather than trying to tweak a modern Windows and finding the needed DLL that might fail to work completely anyway. It took me less than an hour to build from scratch a 86Box that could run a game that required Glide (for 3dfx Voodoo), and I had never used 86Box before that. When I used to have a Windows machine with Windows 7 I never succeeded at that (of course that might be me, but I couldn't find any relevant help to get around my issues).

Are all current Windows app 64-bit now?

This is getting way off-topic and the rest of my thoughts belong more to the iBOT thread 🙂
 
no they ain't.
You'll struggle to find non-amd64 builds anywhere now (outside of older video games. Curse you Total War Attila).
Mmm surprising, I really thought most apps were stupidly compiled (to push it : 386 target 🤣).
That’s good news.

We’re still obligated to use 32 bit version off 365 ´cos a stupidly old work-related app is based on Access with compiled module. Impossible to run it with 64 bit Access.
Yes, that’s prehistoric (both Access and 32bit).

IMO a lot of specific software like used in industries and certainly those used in school (industry sections)are so old they both require 32bit and Win 7 so not to be broken. I tend to laugh but it really isn’t that funny …
 
Mmm surprising, I really thought most apps were stupidly compiled (to push it : 386 target 🤣).
That’s good news.

We’re still obligated to use 32 bit version off 365 ´cos a stupidly old work-related app is based on Access with compiled module. Impossible to run it with 64 bit Access.
Yes, that’s prehistoric (both Access and 32bit).

IMO a lot of specific software like used in industries and certainly those used in school (industry sections)are so old they both require 32bit and Win 7 so not to be broken. I tend to laugh but it really isn’t that funny …
Well, we have customer where one production line is controlled by max. 75MHz Pentium (and DOS of course). Faster than 75MHz and good old Pascal compiled code goes grazy 😅
 
It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.

Out of curiosity, do you really run 16-bit code?
I think 16-bit usermode has been deprecated since Zen1, it's only supported for legacy boot stuff.
 
Intel disabled the loop stream detector on Skylake & sons because it crashed when using partial registers (AH, BH, CH, DH) with Hyperthreading.
That's such an obscure thing to validate so understandable Intel didn't catch it (anyone that lived through the Pentium Pro learned to avoid partial registers like the plague) yet still managed to affect someone.
 
Haven't seen or used it for maybe 20 years. I doubt that 16bit is needed; however, 32 bit is a VERY different story as are a number of extensions.
The big problem for 16-bit was InstallShield. It's a proprietary install packager that half the world used for most of the 32-bit windows generation, because it was cheap, unobtrusive and worked well. It's mostly 32-bit, but installers created with old versions of it start with a 16-bit loader that checks whether you are running in 32-bit mode, and if not, exit with an error message that tells you that 32-bit OS is needed. This was a huge problem when 16-bit support was dropped, because no-one was updating their installer creator program, and so like half of all 32-bit software could not be installed because of this. Microsoft fixed this before 64-bit Windows became common by binary patching any InstallShield installers it could detect to jump over the 16-bit code.

This then became a problem because some people modded installers for programs they created to strip off all InstallShield branding, and in the process made them undetectable to Windows. So now every copy of windows running everywhere has a database of some 90's and early 00's programs, and entry points to jump into to skip over the 16-bit parts. That's the cost of compatibility.
 
Last edited:
So now every copy of windows running everywhere has a database of some 90's and early 00's programs, and entry points to jump into to skip over the 16-bit parts. That's the cost of compatibility.
Meanwhile this is what it takes to get the windows version of Sim City 2000 to run modern day.


I honestly don't imagine there is much going on in terms of compatibility these days anyways. Everything old that people want to run needs some form of patch regardless. The real compatibility comes from the registry and other underlying systems being so close enough, that software can be relatively quickly fixed to run, without even needing source code. If community fixes weren't possible IMO windows would have been dead 10 years ago.
 
I agree that killing 32-bit is premature. My point is that the much praised compatibility is an illusion. As I previously wrote trying to run >20 yo 32-bit programs is much easier by using simulation rather than trying to tweak a modern Windows and finding the needed DLL that might fail to work completely anyway. It took me less than an hour to build from scratch a 86Box that could run a game that required Glide (for 3dfx Voodoo), and I had never used 86Box before that. When I used to have a Windows machine with Windows 7 I never succeeded at that (of course that might be me, but I couldn't find any relevant help to get around my issues).

Are all current Windows app 64-bit now?

This is getting way off-topic and the rest of my thoughts belong more to the iBOT thread 🙂

All new games are 64 bit, a lot of old games are 32 or DOS (16 bit).

Most new productivity software, browsers are 64 bit.
 
32 bit will never be killed in x86, zero chance - ever.
of course 32-bit wont die, that would disrupt a lot of industries and software.

But could be translated? Of course it can. That’s the future of computing. It’s foolish keep to 32-bit support forever natively.
 
But could be translated? Of course it can. That’s the future of computing. It’s foolish keep to 32-bit support forever natively.
And get killed in reviews that will point out that classics like Borderlands 2 run slower? There is just very little to gain doing such non-trivial things, and a lot to lose. There is plenty of modern 32-bit code around, Steam only recently got 64 bit version, and this is like 20 years since amd64 was out!
 
Back
Top