[solved] how disturbing is x86? Unreal-Mode!!!

[Ed.Kloonk]

LOL

While I'm not familiar with UK law, my comments while not directly intended to offend you, are protected free speech by the laws of the USA, and legally speaking you haven't got a leg to stand on, you can't sue somebody for offending you even if it was deliberate.

You can't sue somebody for offending you. He can

I won't pollute the thread but just know that in my part of the world there are a few cases recently that beggar belief.

[DiTBho]

Going by memory, each code segment has a bit which specifies the default data width, which can be 8/16 or 8/32.  When the data width prefix is used, then the other data width is selected for each instruction.

So in real mode the default is 8/16, and when the prefix is used, the 32 bit data width becomes available.

The danger is that while this makes the 32-bit registers available, a 16 bit operating system is unlikely to save the 32-bit register state so only that program can make use of them.  This problem also sometimes comes up with vector register extensions.

Thanks! Indeed it's not clear to me. Too many pages to read, and too many exceptions.
Plus, it seems that if you force "unreal mode" interrupts don't work as expected 

edit:
I reserve details for later debugging sessions.

[DiTBho]

@Ed.Kloonk, @magic, Ok, I got the point
See, I got pissed off, and probably on that occasion I had better write that I am not even the kind who cares to report to mods. The message was that I don't care at all.

I also like it when people first insult you and your work, then troll you and finally twist things to make you look like the kind you're not.

This topic starts with "disturbing" because it's very worrying that a bootloader like Grub has to exploit a hardware bug to load the kernel Linux, an exploit that doesn't even work 100% as interrupts do not automatically save the high 16 bits of EIP, plus other weird behaviors here and there.

I had a laugh at my first answer and I meant it's funny but even Intel engineers haven't documented that bug yet. And that's where I made my second mistake.

Lesson learned, in the future, I will no longer answer questions about my thoughts, or questions about the development behind the scenes.

Maybe, just a link to a Git Repo, so who wants can read and see the commit comments to get a sense of how hard that was.

[DiTBho]

OK, I am now looking at a GRUB implementation that switches the CPU into "protected mode" but then executes the BIOS interrupt calls in Virtual 8086 mode.

I am impressed that it actually works, but so it does 

In my case, I have my assembly and C routines to fully take control of the disk controller in "PCI_mode", but since my Soekris router doesn't have a physical keyboard controller, it uses a "dummy keyboard controller" to enable the A20-gate (if disabled, the CPU.address20 is always 0), and this stuff is not standard and done by a service BIOS routine that I could not use because I was in protected mode.

Despite those second GRUB tricks actually working, I don't like to introduce more complexity in my bootloader, so I won't switch to Virtual Mode only to enable the A20-gate.

You may wonder: but if the CPU boots in real mode, why don't you immediately enable the A20-gate? For two reasons:
1) I only have 490 bytes of space to implement the first stage, and I need to read partitions, which takes ~300byte of space to be implemented
2) my BIOS is buggy about some BIOS calls and needs a procedure to be fixed, again more bytes that I cannot fit into the MBR

Code: [Select]

0000 0040 0032 bootstrap<-
0000 0680 2800 kernel
0000 2e80 8ef0 Extra
 ____________
|            |
|   hAllo!   |
|____________|
Installing interrupt service routines (ISRs).
Enabling external interrupts.
Initializing serial (IRQ 4).
Initializing dynamic memory ... failed, found corrupted memory
dram: 00010000 00100000
> show reg.cr0
CPU.cr0=0x00000011
> check mem
sys_mem_size=32M
app_mem_size=25K
app_mem_addr=0x00010000
addr=0x00001000 ...  4k is_eol=00000000 (skipped)
addr=0x00002000 ...  8k is_eol=00000000 (skipped)
addr=0x00004000 ...  16k is_eol=00000000 (skipped)
addr=0x00008000 ...  32k is_eol=00000000 (skipped)
addr=0x00010000 ...  64k is_eol=00000000, OK
addr=0x00020000 ...  128k is_eol=00000000, OK
addr=0x00040000 ...  256k is_eol=00000000, OK
addr=0x00080000 ...  512k is_eol=00000000, OK
addr=0x00100000 ...  1024k is_eol=00000000, corrupted
addr=0x00200000 ...  2M is_eol=00000000, corrupted
addr=0x00400000 ...  4M is_eol=00000000, corrupted
addr=0x00800000 ...  8M is_eol=00000000, corrupted
addr=0x01000000 ...  16M is_eol=00000000, corrupted
addr=0x02000000 ...  32M is_eol=00000001, corrupted
> load app 0x00100000
name=kernel
kind=elf, 32-bit, little-endian
entry=0x00100200
size=6Mbyte
> exec elf
corrupted image

The CPU has a physical pin to force the A20-gate always enabled, but the CPU package is BGA and it's very difficult to place a pull-up resistor there.

Code: [Select]

______________________
|                     |
|      CPU-x86        |
|                     |
|                     |
|      A31 ___________|___ A31
|      ...            | ...
|      A21 ___________|___ A21
|              ____   |
|  +----------|AND \__|___ A20
|  |   A20 ---|____/  |
|  |   A19 ___________|___ A19
|  |   ...            | ...
|  |   A00 ___________|___ A00
|  |                  |
|  +---------------------- #A20
|_____________________|

So,  I think the simplest solution is: to reverse engineer the BIOS to find the used procedure to enable the A20-gate. Here, as the x86 instruction set is densely packed, and many are encoded with a single byte, disassembling almost any data will yield potentially valid-looking x86 code at first glance, so the first mistake people make in disassembling junk code is assuming that it is actual code because it disassembled to valid instructions. Wrong!!!

This part will take a lot of time as the total number of x86 instructions is well above ~one thousand, and despite lof of them being rarely used, they are there, so reverse engineering requires feasible heuristics scripts(1) to better filter out junk code, which is difficult as I have always refused to deal with x86 so I have to keep learning to gauge whether the code I am looking at is junk or not.



(1) that's what professional tools like "IDA/x86" do.
If you have money to buy it (it's very expensive), I recommend using it.

[David Hess]

Thanks! Indeed it's not clear to me. Too many pages to read, and too many exceptions.
Plus, it seems that if you force "unreal mode" interrupts don't work as expected 

Yea, I think unreal mode was not an intentional feature and just worked out that way, but allowing 32 bit instructions in 8/16 bit real mode was very much intended.

[CatalinaWOW]

Get UEFI hardware and forget about 16 bit modes

eheheh I wish 
My Soekris net5501 is a 2006 design, and its Geode CPU is ~i586
So, it's pre-UEFI.

I find it humorous that you are discounting Intel's decisions about backwards compatibility while you are constraining yourself to write code for 20 year old hardware.   It would be less brain dead to just redo the whole thing in a RISC architecture.  But apparently you are dealing with marketplace and economic constraints and have to deal with less than optimum solutions.   And quite possibly someone twenty years from now will be posting a thread about how anyone could be so dumb as to use that x86 architecture in 2023.

[DiTBho]

It would be less brain dead to just redo the whole thing in a RISC architecture
less than optimum solutions

Thanks for your zero technical contribution, it's not useless as it confirms I am right to refuse to sign a contract, as x86/16 and x86/32 are too much pain, and I am not even paid enough for that.

Sorry, I won't give more details.

[DiTBho]

Fluke, I got the exact point on the fifth attempt.

So, I reverse-engineered that piece of BIOS code and found how things are managed for the A20-gate.
(the dummy keyboard controller is much worse than the 8042, that's it)

Then I modified the kernel setup to enter directly into protected mode.
so, the bootloader directly loads the uncompressed kernel as elf32, and jumps into it in protect-mode!
I rewrote all the setup parts and the relative Makefile to compile everything in 32bit, there are really no 16bit parts.

So, the unreal mode is neither needed nor considered an option.

Problem solved. It works!
Restyling the code, and finalizing.

Thanks for your contribution 

[T3sl4co1l]

OK, I am now looking at a GRUB implementation that switches the CPU into "protected mode" but then executes the BIOS interrupt calls in Virtual 8086 mode.

I am impressed that it actually works, but so it does 

Can confirm, have [briefly] used a ST-412 interface HDD in Win95.  It detects it and complains that it will be slow (meaning not just that the device is slow, but because it has to service it in real mode!), but it is indeed usable as a drive in all the usual ways.

A lot of this frustration could have been saved by historical study -- all the bizarre quirks of the PC have been long and well documented over the decades.  It's...

Hm, gosh, that might even be my own historical bias creeping in, come to think of it -- I heard of many of these things (granted, not in nearly enough detail to be able to implement with them; I'm neither bragging nor able to offer help here, alas), back in the days when, you know, you could actually find things on the internet.  I wouldn't be surprised if just the opacity of modern search engines is a large part of your frustration, even?

So then, having to discover all this, anew, for a project, that wastes hundred of hours of your time -- yeah, I sympathize, that's frustrating as hell.  It's knowable, the information is out there (or, it sure as hell WAS!?), but it ain't pleasant having to hack your way through it with no map.

But also don't let frustration cloud your judgement; these things absolutely existed for a reason, and that reason is money, and backwards compatibility.  Every single attempted mainstream PC, that broke backwards compatibility, lost market share and died an ignominious death.  Microsoft may have a lot of problems with their OSs (and software, and, y'know, everything else), but -- despite how janky it may seem -- they did a TREMENDOUS amount of work ensuring most published software continued to be functional through history.  The fact that old software on newer Windowses is as glitchy as it sometimes (often?) is, is a backhanded testament to all that work -- that is, that they were able to maintain enough compatibility that those poorly-written programs ran at all, let alone mostly usably, is a remarkable feat.  And that line of compatibility extends all the way back to the earliest PC hardware, and the programs written for it -- not in a continuous unbroken line, but with enough overlap between multiple generations that you could continue to migrate all your work, and many of your programs, without loss of data or added expense.  THAT is how the PC won, and that is how Microsoft dominated it.

And so, A20, and real mode, and all the other bullshit -- is just other aspects of the same dynamic.  It ain't pretty, but success isn't always pretty, or easy.

Tim

[SiliconWizard]

Fluke, I got the exact point on the fifth attempt.

So, I reverse-engineered that piece of BIOS code and found how things are managed for the A20-gate.
(the dummy keyboard controller is much worse than the 8042, that's it)

Then I modified the kernel setup to enter directly into protected mode.
so, the bootloader directly loads the uncompressed kernel as elf32, and jumps into it in protect-mode!
I rewrote all the setup parts and the relative Makefile to compile everything in 32bit, there are really no 16bit parts.

So, the unreal mode is neither needed nor considered an option.

Problem solved. It works!
Restyling the code, and finalizing.

Thanks for your contribution 

So you're gonna sign the contract?

[CatalinaWOW]

It would be less brain dead to just redo the whole thing in a RISC architecture
less than optimum solutions

Thanks for your zero technical contribution, it's not useless as it confirms I am right to refuse to sign a contract, as x86/16 and x86/32 are too much pain, and I am not even paid enough for that.

Sorry, I won't give more details.

I think Tim, (T3sl4co1l) gave a more sensitive and complete version of what I was trying to say.  I agree I had no technical contribution.  And would suggest that many of those who actually have such expertise would value their time enough to not give it away for free solving your problem for you.   I would also suggest that if the job was as easy as you would like it to be, your potential customer might not be searching for someone else to do the job.

[james_s]

You can't sue somebody for offending you. He can

His laws don't apply to me so it doesn't matter. There is zero chance of somebody being extradited over such a petty offense, especially when it is not even against the law here. I would actually love to receive a court summons over such an absurd charge, I would frame it and hang it on the wall and show it off to my friends and colleagues, they would find it hilarious.

[james_s]

But also don't let frustration cloud your judgement; these things absolutely existed for a reason, and that reason is money, and backwards compatibility.  Every single attempted mainstream PC, that broke backwards compatibility, lost market share and died an ignominious death.  Microsoft may have a lot of problems with their OSs (and software, and, y'know, everything else), but -- despite how janky it may seem -- they did a TREMENDOUS amount of work ensuring most published software continued to be functional through history.  The fact that old software on newer Windowses is as glitchy as it sometimes (often?) is, is a backhanded testament to all that work -- that is, that they were able to maintain enough compatibility that those poorly-written programs ran at all, let alone mostly usably, is a remarkable feat.  And that line of compatibility extends all the way back to the earliest PC hardware, and the programs written for it -- not in a continuous unbroken line, but with enough overlap between multiple generations that you could continue to migrate all your work, and many of your programs, without loss of data or added expense.  THAT is how the PC won, and that is how Microsoft dominated it.

And so, A20, and real mode, and all the other bullshit -- is just other aspects of the same dynamic.  It ain't pretty, but success isn't always pretty, or easy.

Tim

That was exactly the core of the point I have been trying to make. All these ugly hacks existed for very good reasons that made sense at the time they were done. There are numerous examples that prove beyond any doubt that backward compatibility at the hardware level in a time before software emulation was feasible was absolutely crucial to market success. If you don't offer compatibility with existing software then your platform will fail in the marketplace. These hacks are the primary reason for the dominance of the x86 PC, not because hacks are desirable in and of themselves, but because they allowed for backward compatibility which is an extremely valuable feature, and the cost is virtually entirely hidden from users and even from most developers. I suppose it's less obvious to younger people who were not around when a PC cost as much as a nice used car, the software often cost more than the PC and if it couldn't run Lotus 123 or Wordperfect no corporation would buy it.

[DiTBho]

So you're gonna sign the contract?

nah, let's say it was a personal *challenge*, but definitively x86 is not for me.

In parallel, one month ago, I challenged a PCI RAID card i960-based which I hacked in order to turn into an evaluation board to have an idea about how stressing is playing with Intel's i960.

How much? Not so much compared to x86! Don't get me wrong, I don't like i960 so much, and it was a discontinued processor in 2007, so it's also 0xde.ad.be.af stuff, however, as much as bizarre it goes and as much niche it is/was, if you have two choices, and for both of them they pay you by project and not by the hour, you'd better work on what takes you fewer hours and effort, so i960 is "better" than "x86" as I have fewer things to study, and there is much less engineering ugliness that can make waste your time.

That's why today I signed a contract to support BPUM's few military applications that still use i960. and when I think about it... it's sad to think that it could have replaced x86 and evolved to modern stuff when BiiN and Myers tried to get the Intel management to market the i960 instead of the Intel 80286 and i386, even because at that time, in computer history, the emerging market was RISCish for Unix systems, including a presentation to Steve Jobs for use in the NeXT system.

Unfortunately for people like me, Myers couldn't get Intel management to support the i960 as a Unix processor, so the chip only found a ready market in early high-performance 32-bit embedded systems: Xterminals, PCI controllers- RAID, slot machines, and the ARING legacy avionics equipment for which today I signed a contract.

that's life 

[SiliconWizard]

Well it was again all business decisions. As I said, the better technical solutions rarely win.

I do agree that Intel did come up with lots of stuff better than x86 and that these were killed for business reasons. Whether those decisions were the best ones for the company is almost impossible to tell in retrospect, but we can't deny it worked for them, Intel is still alive and kicking. Possibly getting into the "wrong" markets while neglecting the juicy ones would have killed them. We'll never know.

I would also much rather invest time in the i960 than in the x86, not perfect but much more interesting.

As I said, I'm pretty sure x86 is going to die eventually. It's already a lot less relevant these days than it used to be. But that's just one piece. The whole computing world is pretty much made out of crap that just works. Am I exaggerating? 

[newbrain]

The whole computing world is pretty much made out of crap that just works. Am I exaggerating? 

You know you are!
'Just works' is quite the the exaggeration.

[james_s]

As I said, I'm pretty sure x86 is going to die eventually. It's already a lot less relevant these days than it used to be. But that's just one piece. The whole computing world is pretty much made out of crap that just works. Am I exaggerating? 

It probably will fade away gradually. These days computers are powerful enough that software emulation is feasible to run a lot of the legacy stuff and Apple has demonstrated that it can be integrated pretty seamlessly into the operating system.

I'd say "crap that just works" is a fair assessment. I've spent most of my career in software development and people do ugly hacks all the time. The reality is that hard deadlines are a thing, and much more so back when software was shipped on physical media. You HAD to be done by a certain time or you'd miss the window for things like holiday sales and delays could easily cost millions.

[DiTBho]

This morning I saw this computer in the corner of a warehouse two floors underground. During the lunch break, I switch it on, but it didn't boot up as the hard drive was likely wiped out for security reasons.

A pity, even if it was abandoned in an area where no one ever enters ... I'm probably the only human being that computer has seen for at least 15 years, resulting in a dead NVRAM battery and CMOS all messed up.

Anyway, I found the paper manual in a soft bag near the machine and it's outstanding, even better than the one shown in the video, and of the same quality as the early IBM manuals released for 8088, 8086, and 80286 computers (3 volumes of 200 pages each, with a full assembly list of the BIOS!!!), as it gives a full list of the ARC Monitor and more technical details on the ISA and VESA buses, and how the memory is mapped.

Umm, as far as I can see, "PC boards compatibility" means, the first 1Mb needs to accommodate the video adapter, and the serial port, with a dedicated bridge to map the ISA_IO into a memory-mapped area (because MIPS doesn't have IO instructions, so no IO space, only MEM space), but from the first MB up memory is linearly addressed, so all the compatibility is software and no A20-gate nonsense!

Great!!! I love this 

[David Hess]

Most critics of Intel's x86 miss that Intel was selling compatibility.  That is the feature which made x86 successful.  The 8080 was intended to be compatible with the 8008 through translation.  The 8086 was intended to be compatible with the 8080, also through translation.  And x86 maintained binary level compatibility with itself after that.

The alternatives largely relied on "just recompile" between generations.  This mostly works for embedded devices, including smartphones, but did not work for personal computers, workstations, and servers, except maybe for IBM and Apple, and at least Apple gave up a lot of market share in return.  Personally I would not touch an Apple system because I have no interest in a increasingly locked down glorified smartphone, and I have many legacy applications which work just fine now.

[DiTBho]

recompile" between generations.  This mostly works for embedded devices, including smartphones, but did not work for personal computers, workstations, and servers, except maybe for IBM and Apple

it works perfectly for every workstation and server made from POWER4 to POWER9 because DARPA allocates money for it, so IBM engineers thought about it not once but 5-6 times(2) before finalizing the design of their POWER machines, including a plan to produce the 970 as a light version of their POWER4: great move, it saves a lot of money, which is reinvested in research and development!

Like predicted by Tanenbaum, it also works perfectly for everything that you can always recompile from GNU or BSD sources instead of commercial binary-only software that you can only try to disassemble and hack.

OpenSource Workstations and servers, like POWER9 ones running nothing but GNU/Linux, PPC64/LE, or PPC64/BE!

- - -

Looking back, and considering that "Miins" is not a physical person but a group of engineers from Intel sustaining the project, by judging their preliminary and i960 designs, they have my respect, so I think I can basically redirect my disdain towards the Intel ruling class, those assholes who first abandoned the i960 MMU, condemning it to certain death as ARM was coming and everyone was bullying the UNIX world, a world you either had an MMU for... or it was very hard to run a kernel and applications profitably(1), then they took away more and more resources from development and research budget - "we sell x86 for compatibility, not i960" - intel! and eventually dropped almost everything except what paid for the military, as the 960 went on almost solely for the military.

if Steve Job had chosen the i960 chip for his Next line of computers, we probably would have seen those assholes in the ruling class of Intel devote much more engineering resources and at least Intel would have churned out i960 chips with TLB, so not only could NewOS (BeOS) or Mach ( the future MacOS), but even Unix and Linux!

When Jean-Louis Gassée, a former Apple Computer executive, founded BeOS, he thought PowerPC 603/4 (G2) was a good platform to develop BeOS, imagine if he also had the i960 at his disposal. Most likely his BeBOX PPC-G2 would not have wasted millions on research and development before realizing that there was no future with PowerPC because it was too niche.

Later development releases of BeOS/PPC were ported to run on the Macintosh, and Macintosh clone makers, including Power Computing and Motorola, signed deals to ship BeOS with their hardware when the OS was finalized.

In light of this, Be stopped production on the BeBox after selling only around 2000 units, and focused entirely on the development of BeOS/x86.

I bought, and developed on/for two of those BeBox/PPC 2000 units 

If Intel had churned out the i960, the whole market would have gone after it, and today we would have peripherals that work not only on those cursed PCs but everywhere! On any platform!

If there's one thing intel engineers are good at is making chips, they're the best in the world at it, so imagine what firepower we would have with a sane alternative made by intel itself!

A fancy policy like this:
do you want Unix? buy our i960 with MMU!
do you want dos/windows? buy our i386, i486, ...
do you want military devices? buy our i960 MILSTD
do you want embedded devices? over time we produce Atom technology based not on i486, but on i960!

(atom was a business failure because too slow compared to ARM alternatives)

They could have even avoided the epic fail of Itanium since i960 could very well have offered 64bit evolutions

And it would have brought much more benefits, as had been discussed by the same intel engineers. It is a pity that the ruling class did not want to listen to them.

The more I delve into the alternatives, the more I think they had that money and several opportunities to successfully and mutually benefit change the x86 legacy.

Now they are researching quantum computing, and they already have a product ...

We will see ... 


(1) the xterms HP 700/RX, Entria, Envizex, are hw X-Terminals based on i960, no MMU, so they run a VxWorks kernel + custom embedded X11 + mwm and/or twm and misc ad-how applications all as statically compiled tasks in a flat linearly addressed space, which perfectly works for the X11-term purpose but it is not ok for a general purpose OS.
(2) with more money they relax the "ready to market" deadline. They can allocate more time to develop a product.

[james_s]

When Jean-Louis Gassée, a former Apple Computer executive, founded BeOS, he thought PowerPC 603/4 (G2) was a good platform to develop BeOS, imagine if he also had the i960 at his disposal. Most likely his BeBOX PPC-G2 would not have wasted millions on research and development before realizing that there was no future with PowerPC because it was too niche.

Later development releases of BeOS/PPC were ported to run on the Macintosh, and Macintosh clone makers, including Power Computing and Motorola, signed deals to ship BeOS with their hardware when the OS was finalized.

In light of this, Be stopped production on the BeBox after selling only around 2000 units, and focused entirely on the development of BeOS/x86.

The BeBox was a very cool piece of hardware, and BeOS was very innovative for its day, but this is practically a poster child for the point I've been pushing all along, Be failed miserably in the marketplace because while offering a lot of very innovative features, it lacked the single most important feature to most users, compatibility. It couldn't run any of the popular software of the day and that made it a non-starter because for almost everyone the entire reason they buy a computer is to run software. It doesn't matter what CPU was used or how great it was, it was doomed from the start to fail. I ran BeOS on a Mac for a while out of curiosity ~15 years ago, it was neat to see something other than MacOS on a Mac but it just wasn't very useful to me because there was almost no software for it. Compatibility is king, period. Any system that doesn't offer compatibility either at the hardware level or via software emulation will fail, period. i960 would have failed for exactly the same reason, it wasn't compatible, it couldn't run existing software. I can't figure out why you are so blind to this fact.

[SiliconWizard]

The reason Intel abandoned the i960 is relatively simple and summed up in the Wikipedia article.
It was tightly linked to them acquiring StrongARM, all a consequence of a lawsuit with DEC, etc, which basically replaced  the i960.

You know very well the reason why x86 has lingered on, and it's mainly centered around software development.

Even the infamous A20 trick you mentioned was all due to the fact that software developers (and hardware developers of third-party extensions) had come up with various ugly tricks to "take advantage" of the 20-bit address bus of 8086 processors wrapping around.
After which a ton of existing software relied on those tricks and would fail miserably with larger address buses, unless you could just mask A20.

It's just how things work in general, ecosystems get built around existing solutions with their limitations and after a while, it all becomes very inflexible.

But in this case, it's more a matter of "laziness" (in terms of business) and inertia of software development rather than hardware itself. Then hardware becomes constrained by software, which is kind of ironic, as software is supposed to be the flexible part of the equation. But in reality, it isn't to a large extent.

Apple has successfully managed to completely change hardware architectures several times over the years with little friction, but this is almost an exception, due to the fact they have a very specific business approach (can't be denied) that has yet to be copied, and the fact they entirely control boith the hardware and the software, which has allowed them a lot of flexibility.

[james_s]

Apple has successfully managed to completely change hardware architectures several times over the years with little friction, but this is almost an exception, due to the fact they have a very specific business approach (can't be denied) that has yet to be copied, and the fact they entirely control boith the hardware and the software, which has allowed them a lot of flexibility.

Apple has historically at least had an attention to detail and polish that few others have come close to. They pulled off architecture changes by having seamless emulation baked into the operating system in addition to the traits you mention. Apple is also a niche, with <10% market share they are by far the biggest and most successful competitor to "Wintel" in the desktop/laptop market followed by Linux, everything else combined is down in the noise floor. As lousy as Windows is, it still runs on around 90% of all personal computers in the world, not because it is great, but because it offers compatibility with the largest range of software.

[nigelwright7557]

I feel like a broken record saying this, but backward compatibility is king,

Who would have thought in 2023 we would still have DOS mode or command prompt mode.
A lot of programming languages are controlled through the terminal.

Ironically we still have DOS but have lost 16 bit mode.
I had a couple of 16 bit program I used a lot but they wont run now.

[DiTBho]

The reason Intel abandoned the i960 is relatively simple and summed up in the Wikipedia article.
It was tightly linked to them acquiring StrongARM, all a consequence of a lawsuit with DEC, etc, which basically replaced  the i960.

The PXA (Xscale, ARMv5TE) used by Sharp for their PDA line? Intel ARM ... is only a part of the reason, and not reported in any Wikipedia article, but it reads very clearly in the various notes that the i960 developers were more inclined to go ahead with the i960 and that intel itself didn't believe much in Xscale, so much so that I didn't even invest that much.

Was Xscale a success? Yes and no. It certainly worked with Linux v2.4 on Sharp PDAs, as well as other WindowsCE-v1/ARM devices and some phones but ... Why did Intel disband their XScale ARM division in 2006?

Again, the same policy from the ruling class, and that's exactly the point: they didn't want to do anything except x86 because, according to them, x86 would bring in more money.

The funny thing is that they are so bad at evaluating things that they then invested in Itanium and today have to pay AMD a lot of money to be allowed to produce x86-64.

Which is LOL