Jo22 wrote on 2024-05-12, 23:55:

Making a clear cut and creating a new architecture under a new name would be wiser, more mature.

That's a great idea. They could even call it something like, I dunno, Itanium. Should dominate the market.

kingcake wrote on 2024-05-13, 00:06:

Jo22 wrote on 2024-05-12, 23:55:

Making a clear cut and creating a new architecture under a new name would be wiser, more mature.

That's a great idea. They could even call it something like, I dunno, Itanium. Should dominate the market.

Um, I was more thinking of something along the lines of "x64LE" (low end), "xS64", "x86-nsfw", "x64SX" or "x64EOL". ;)

Edit: "x64LOL" would also be fitting, maybe? :D

Edit: Or how about "Genesis"? The fresh, new Intel Genesis processor architecture!
It's like "Pentium", just more radical, more religious.

PS: Using a marking like "64 BIT S/W ONLY" on the CPU would be professional to do, as well.

Jo22 wrote on 2024-05-12, 23:55:

So it would be nice if Intel would let x86 rest in peace, at least. In dignity.
Making a clear cut and creating a new architecture under a new name would be wiser, more mature.

By that logic, IBM should also make a clear cut and move away from the System/360/370/390/zArchitecture. Isn't that architecture celebrating its 60th birthday?

Legacy instruction sets are... basically the best hedge against irrelevance.

Someone else pointed out the Itanium example; if you want to look at another example, look at Motorola abandoning 68K for PPC. My guess is that if they (and their loyal customers) hadn't bought into the whole RISC hype and had just continued to develop 68K the way Intel has continued to develop x86 and IBM continued with zArchitecture, you'd have a reasonable ecosystem of 68K processors to this day. Instead... well... look at what happened to Motorola/Freescale/NXP, they've been out of the non-embedded microprocessor market for 20 years.

We'll see how Intel does with this idea of stripping out everything other than long mode from x86. But at least those processors would start off their first day in the marketplace with a huge installed base of software.

VivienM wrote on 2024-05-13, 00:28:

By that logic, IBM should also make a clear cut and move away from the System/360/370/390/zArchitecture. Isn't that architecture […]
Show full quote

Jo22 wrote on 2024-05-12, 23:55:

So it would be nice if Intel would let x86 rest in peace, at least. In dignity.
Making a clear cut and creating a new architecture under a new name would be wiser, more mature.

By that logic, IBM should also make a clear cut and move away from the System/360/370/390/zArchitecture. Isn't that architecture celebrating its 60th birthday?

Legacy instruction sets are... basically the best hedge against irrelevance.
[..]

Hi, to me it's not about age but I agree.
I just think what Intel is planning right now is essentially all about damaging and beating x86 into a cripple. Just before it has its 50 anniversary (dates back to the 8086 in 1978).

That's what's so sad about it. Intel seemingly wants to ruin x86 on purpose, to make it irrelevant and then get rid of it.

Why can't that company just wait another four years and then make x86 or original x86_64 EOL in a respectful way, without crippling it just before hand ? 🤷‍♂️

Because by that point Windows 10 (last Windows with 32-Bit / x86 edition) is history and many users will depend on x64 OSes, anyway.

All in all, the Zilog way of putting a legend to rest is more elegant, I think. It has more class. No drama, no exploitation of its anniversary, no sensationalism going on. Just a respectful press release about the upcoming discontinuity.
Considering that Zilog company was founded by ex-intel staff make the comparison a bit relevant, maybe.

Jo22 wrote on 2024-05-13, 00:13:

xS64

You're very close - it's called "x86S".
S = subset.

Jo22 wrote on 2024-05-13, 00:51:

All in all, the Zilog way of putting a legend to rest is more elegant, I think. It has more class. No drama, no exploitation of its anniversary, no sensationalism going on. Just a respectful press release about the upcoming discontinuity.

I didn't really think Zilog 'put a legend to rest'; aren't they still offering other variants?

Grzyb wrote on 2024-05-13, 01:02:

Jo22 wrote on 2024-05-13, 00:13:

xS64

You're very close - it's called "x86S".
S = subset.

I see, thanks. 🙂

What I meant to say: Why is it necessary to create this subset version, still?

By 2028, the 8086 would have its 50th anniversary. It's a good time to make x86, still intact and as a whole, EOL.

By doing so, Intel could now focus on a new and pure x64 implementation, maybe with some bug fixes, improvements and clean up.

Essentially an improved version of the x64 as we known it, minus the x86 legacy.

This would spare both users and developers from pseudo-x86 processors that have gotten x64-only, essentially.

All the upcoming confusion and half-baken software support could be avoided all together.

Win32 applications and other 32-Bit applications could still be translated on the fly under Windows, by using a dynamic-recompiler.

For what it is, the ARM versions of Windows do pretty well in emulating 32-Bit instructions, I think.
The underlying similarity between IA-32 and x64 is still there, after all.

Just like there was basic similarity between, say, the 8080 and 8086 or the AX, BX, CX DX(8086) and corresponding EAX, EBX, ECX and EDX (80386) registers.

The next step after Intel bails from 32bit support is all newer 64bit OS from MS will no longer be 32bit backward compatible....first the platform then the OS...

VivienM wrote on 2024-05-13, 01:15:

Jo22 wrote on 2024-05-13, 00:51:

All in all, the Zilog way of putting a legend to rest is more elegant, I think. It has more class. No drama, no exploitation of its anniversary, no sensationalism going on. Just a respectful press release about the upcoming discontinuity.

I didn't really think Zilog 'put a legend to rest'; aren't they still offering other variants?

Yes, they do. eZ80, most notably, I heard.
The original Z80 line is going to be EOL, rather.

Which involves some peripheral chips and Z84C00 (CMOS), which in turn had superseded the Z80, Z80A, Z80B long ago (the classic NMOS types).

To my understanding, the Z84C00 can be used as a drop-in model to the older variants.

Edit: Here's an overview of sime sorts:
https://www.cpu-world.com/CPUs/Z80/MANUF-Zilog.html

Back in the 80s and early 90s, this was being utilized to reduce power-consumptions of existing equipment.

Especially battery-powered devices could benefit from such a CMOS upgrade.

My PK-232 TNC comes to mind. I believe the company that sold it, AEA, had offered "CMOS upgrade kits" to existing owners at some point.

Anyway, the Z80 processor as such isn't EOL yet, I think that's right.
It had been produced under license in the past.

Just like Siemens or Harris/Intersil had continued to produce 80286 processors.

Or how the Motorola 68000 was being made by different manufacturers (Signetics comes to mind).

There are also Z80 clones, not unlike there are numerous 6502 variants.

Windows on ARM was Microsoft's attempt at forcing a clean break from legacy, but we all know how that went. Corporate customers rejected that. They want x86 and legacy apps.

Jo22 wrote on 2024-05-13, 00:13:

Edit: Or how about "Genesis"? The fresh, new Intel Genesis processor architecture!

Intel does what AMDon't?

Horun wrote on 2024-05-13, 01:23:

The next step after Intel bails from 32bit support is all newer 64bit OS from MS will no longer be 32bit backward compatible....first the platform then the OS...

Maybe in about... 20... years?

A lot of productivity software barely supports x64, e.g. Adobe Acrobat was only available in 32-bit form for Windows until maybe... 2 years ago? It was a bit funny to see that macOS had 64-bit Acrobat years and years ahead of Windows, but hey, they made it clear back in the High Sierra or Mojave days that 32-bit wasn't long for this world...

kingcake wrote on 2024-05-13, 02:19:

Windows on ARM was Microsoft's attempt at forcing a clean break from legacy, but we all know how that went. Corporate customers rejected that. They want x86 and legacy apps.

Not sure what non-corporate customers reacted any better. How would you feel if your grandmother got a Windows-on-ARM device that had no compatibility with... anything for Windows? (Modern Windows-on-ARM is better, obviously, but the original RT release was... Windows in name and kernel only)

Ultimately, x86 and 'legacy' apps is what defines Windows. If all you want to do is run web-based bloatware on Chrome, well, there are a lot of things other than Windows and a lot of architectures other than x86 that can do just as bad a job running that garbage as Windows on x86. And hey, some of those have twice the battery life so that's at least something.

That's why any 'clean break' is suicide. 'Clean break' means "well, gee, if all the stuff I use isn't compatible with vendor X's new platform anymore... why would I stick to vendor X's platforms rather than consider vendor Y or Z, which are equally incompatible with old vendor X platform but have some other nice advantages'

Even Apple, which has had more breaks than just about anybody else (and doesn't need to worry about Lenovo or HP or Dell sabotaging its vision for the future of its platforms), has never been suicidal enough to do any kind of 'clean break' since the original OS X/Rhapsody vision got shot down and they were forced to add Carbon. Hell, people forget that the original iPhone wasn't starting from scratch either - it had full iPod compatibility, including with all the cars/external speakers/etc that used the 30-pin connector.

VivienM wrote on 2024-05-13, 02:34:

Not sure what non-corporate customers reacted any better. How would you feel if your grandmother got a Windows-on-ARM device tha […]
Show full quote

kingcake wrote on 2024-05-13, 02:19:

Windows on ARM was Microsoft's attempt at forcing a clean break from legacy, but we all know how that went. Corporate customers rejected that. They want x86 and legacy apps.

Not sure what non-corporate customers reacted any better. How would you feel if your grandmother got a Windows-on-ARM device that had no compatibility with... anything for Windows? (Modern Windows-on-ARM is better, obviously, but the original RT release was... Windows in name and kernel only)

Ultimately, x86 and 'legacy' apps is what defines Windows. If all you want to do is run web-based bloatware on Chrome, well, there are a lot of things other than Windows and a lot of architectures other than x86 that can do just as bad a job running that garbage as Windows on x86. And hey, some of those have twice the battery life so that's at least something.

That's why any 'clean break' is suicide. 'Clean break' means "well, gee, if all the stuff I use isn't compatible with vendor X's new platform anymore... why would I stick to vendor X's platforms rather than consider vendor Y or Z, which are equally incompatible with old vendor X platform but have some other nice advantages'

Even Apple, which has had more breaks than just about anybody else (and doesn't need to worry about Lenovo or HP or Dell sabotaging its vision for the future of its platforms), has never been suicidal enough to do any kind of 'clean break' since the original OS X/Rhapsody vision got shot down and they were forced to add Carbon. Hell, people forget that the original iPhone wasn't starting from scratch either - it had full iPod compatibility, including with all the cars/external speakers/etc that used the 30-pin connector.

Oh I fully agree. Just citing another example of clean breaks being rejected.

kingcake wrote on 2024-05-13, 02:19:

Windows on ARM was Microsoft's attempt at forcing a clean break from legacy, but we all know how that went. Corporate customers rejected that. They want x86 and legacy apps.

Hi, I think there's a misunderstanding.
I didn't mean Windows 8.x on ARM (MS Surface computers etc) but the current Windows 10/11 ARM builds.
And they're doing well, actually. Mac users with Apple Silicon use Windows/ARM in Parallels Desktop, afaik.

Sample video: https://m.youtube.com/watch?v=40Wf7yTjtpU

Edit: I mean, at this point in history, it's all "WinTel" again. That x64S looks specifically tailored to be able to run Windows 10/11.
There also was "Windows 10 S", another a cut-down technology.

The little bits of rudimentary IA-32 (i386) compatibility that's left in x64S can merely be used by user space code (Win32 applications) on an OS like Windows x64, but not by full-fledged 32-Bit OS anymore.

But if a future Windows 11 x64 build can also use full x86 emulation instead (like it already can in the ARM builds) the whole compatibility concept of x64S is questionable here.

Edit: Such a concept isn't new, by the way.
Windows NT for RISC machines had supported DOS and Win16 applications on MIPS, Alpha and Power PC.

Emulation level was on an 80286/16-Bit (iAPX) basis first, but got levitated to 80486/32-Bit (IA-32) level in NT 4.

That upgrade allowed to run newer DOS programs (i386 instructions), as well as Win16 programs that required Windows 3.1 386 Enhanced-Mode kernal.

Third-party add-ons like "FX!32" allowed to run normal Win32/x86 applications on foreign processor architectures.

So really, application level compatibility doesn't depend on Intel or the pitiful remainings of x86 in x64S.

In fact, a clean x86 emulation might be more compatible in the end.
Just like DOSBox is more compatible/stable than a virtualized installation of MS-DOS 6.2x on the latest PC hardware.
Modern dynamic recompilers can help to overcome certain performance issues, as well.

Edit: What's also interesting is that Win10/11 on ARM has recently gotten x64 emulation, in addition to plain x86 emulation.
So this is another parallel development to what happened in the 90s (80286 vs 80486 support).

https://blogs.windows.com/windows-insider/202 … nsider-program/

Edit: And then there's hardware-assisted virtualization..
I wonder how Intel VT and AMD-V will fit into the picture and how x64S will affect them.
If it remains functional, the WoW64 sub system of Windows could be built around hypervisor technology. Microsoft uses it for years in its server field.