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

[DiTBho]

so, you have an architecture that was made to be CP/M compatible, and this explains why 8086 has "Real-Mode", but ... wait, what is "Unreal-Mode"?   

it has been mentioned here and there in Grub (legacy), and it looks to me like a hardware bug in the CPU design, so, it won't work on some CPUs(1), but when it works it's an exploit that you can use by setting the CPU in Protected Mode, then setting the descriptor cache's limits for your segment registers to any value higher than 64Kbyte, and finally setting back the CPU in real-mode, and ...

... and boom, the magic power of quirks breaks the 64Kbyte limit of real mode segments while retaining 16-bit instructions and the segment * 16 + offset addressing mode by tweaking the descriptor caches.

• code still limited to 64Kbyte
• data allowed accessing 4Gbyte
• CPU in real mode!!! 16bit!!!

it's useful when you're trying to load something that will run in 32-bit mode which is larger than what you are allowed to load in "conventional" (I mean without the Unreal Mode trick) Real Mode memory and you don't want to bother writing a protected mode driver yet, but you also want to avoid switching between real and protected mode to copy chunks from the conventional memory buffer into extended memory.




(1) tested on
- PC, AMI BIOS, intel 486-DX2 ---> it worked
- PC, Phenix BIOS, intel PentiumII ---> it worked
- AppleMini, Apple BIOS, intel Core2 dual ---> it worked
- Acord RiscPC/x86_guest_card, A1 BIOS, AMD 586 ---> it worked
- Acord RiscPC/x86_guest_card, A1 BIOS, Cyrix Cx486 ---> it didn't work!!! <---- Is it a problem?!?
- Acord RiscPC/x86_guest_card, A1 BIOS, Cyrix C5x86 ---> it didn't work!!! <---- Is it a problem?!?

untested on Xeon, Opteron, etc 


edit:
solved

[SiliconWizard]

Ouch. And people whine about Intel considering getting past all that.
 

[SiliconWizard]

Well, depends on how you look at it.
Their success, at least for a few decades, has largely been due to the great level of backwards compatibility. One can always claim to have been able to do better in retrospect, but that's just speculation.
Brain-dead engineers? Uh. A bit of humility never hurts.

As I said before, pretty much every time they tried to depart from that a bit too much, they failed. And no, that wasn't just because what they came up with was inferior. It's mainly because that's not what Intel's customers were looking for.
Trapped.

[DiTBho]

See how other people, those who know in detail these things, title the problem "A20 - a pain from the past", link  here

And it's referenced as "nonsense"

The 8088 in the original PC had only 20 address lines, good for 1 MB. The maximum address FFFF:FFFF addresses 0x10ffef, and this would silently wrap to 0x0ffef. When the 286 (with 24 address lines) was introduced, it had a real mode that was intended to be 100% compatible with the 8088. However, it failed to do this address truncation (a bug), and people found that there existed programs that actually depended on this truncation. Trying to achieve perfect compatibility, IBM invented a switch to enable/disable the 0x100000 address bit. Since the 8042 keyboard controller happened to have a spare pin, that was used to control the AND gate that disables this address bit. The signal is called A20, and if it is zero, bit 20 of all addresses is cleared.

Present
Why do we have to worry about this nonsense? Because by default the A20 address line is disabled at boot time, so the operating system has to find out how to enable it, and that may be nontrivial since the details depend on the chipset used.

When I updated my RiscPC to ROM v4.39 and faster companion x86 card, I spent 2 days fixing this nonsense for the x86-CPU guest card; the previous BIOS was incompatible with "!PC-v308", which was itself incompatible with the bew 586 guest cards (as they use different ASICs chip), and again, I found a dummy keyboard controller mapped to the bridge to allow DOS32 to see its 32Mbyte partition of the 128Mbyte system ram.


Anyway, the Unreal-Mode trick doesn't work with my Cyrix CPUs 

[james_s]

I feel like a broken record saying this, but backward compatibility is king, and nobody outside of a very rare few that do low level development cares what real mode is. Many really cool and innovative computers have appeared over the years, the Amiga (I have one) was fantastic, superior to the DOS PCs of the day but it couldn't run Lotus 123 or Microsoft Office. The Macintosh (I have several) was way ahead also, it could run Microsoft Office fairly early on but it was not affordable to the masses and it did not cater to game developers which everyone knows is what really drove the home PC market despite every kid saying they wanted one to do their homework. The BeBox was a neat and innovative machine but there was virtually no software for it so that one went nowhere. The NeXT was a neat machine, state of the art at the time but it had a workstation class price tag that made the Macintosh look inexpensive and again there was not really any software beyond what came with it. None of these offered backward compatibility with the established platforms and thus all of them failed in the market. As with smartphones, there is really only room for 2-3 platforms, anything else is doomed to fail and remain a niche. There is a chicken & egg problem where few are going to develop software for a platform that hardly anyone is using, and hardly anyone will use a platform that doesn't have a sizable library of software.

There's nothing "disturbing" at all about x86, it has a lot of baggage but that's because it has long offered one thing that no other platform can offer, and that is seamless compatibility with an enormous range of software. You could buy a 286 that could run almost everything you ran on your 8088, you could buy a 386 that ran almost everything that ran on your 286. You could buy a 486 that ran almost everything you ran on your 386 and so on. Given the historically high cost of software that was an *enormous* advantage and to a large degree it still is. For all but maybe 1,000 people on the entire planet, most of the x86 baggage is totally irrelevant, they never see any of it, most of the technical users never have to dive that deep and the non-technical users aren't even vaguely aware it exists and they don't care, and why should they? They just want to use their computer, they don't care how it works. It doesn't matter what whiz-bang innovations are lurking under the hood, if it can't run the software a person wants to use then it's useless. You must recognize that you are a part of an extremely small and exclusive club of people that ever touch any of the low level stuff and you cannot possibly expect the vast majority of people to care, it simply doesn't matter to them because they will never see any of the ugliness, they don't have a clue how a computer works internally nor are they interested in knowing and there's nothing wrong with that.

For some other platform to become the defacto standard, it will have to offer something tangible that normal people care about. For example it will have to be much cheaper than other solutions, or lower power, the latter is what has led to the success of ARM in the smartphone market, but smartphone users don't care about the gritty details of the architecture either, they just care about having a powerful device that fits in their pocket, goes a reasonable amount of time on a charge and runs all the popular apps.

[james_s]

Well, Professor Andrew S. Tanenbaum commented "if Intel had designed humans, we would have had some cr0 register to switch atavistic regression to chimp mode"

If anybody "designed" humans then IMO they are an incompetent moron. We have no upper boundary on the amount of fat we can store nor is there a point where we feel "full" and stop craving fat and sugar, it is literally possible to eat oneself to death. There are allergies that can be triggered and cause the body to harm itself, sometimes fatally trying to defend against harmless proteins. We have numerous vestigial features that have no known current use such as the appendix, sinuses, wisdom teeth, body hair and other bits and pieces. Other parts like the male prostate have a function but also almost always outlive their usefulness and become a liability. Our knees and hip joints are known weak points, the neck can be problematic, and there are many other issues.

Like x86, humans evolved over a long period of time from other organisms, and thus we carry a lot of baggage that no competent engineer would design into an organism today if they were starting from scratch. That doesn't mean humans are junk that should just be discarded to start over.

[Circlotron]

The original x86 architecture is like the width of two horses bums side by side.

[SiliconWizard]

These were all business decisions more so than engineering ones. Calling Intel's engineers brain-dead is completely silly.

Cost has certainly been a major concern back in the days and explains many of the mediocre solutions that had to be devised (but still allowed personal computing to exist at all in the end.)

I do agree with Tanenbaum's approach, but the irony is that x86 is still the main target of MINIX 3. Yes there's also an ARM port.

And certainly, the most popular solutions in the end are almost never the best ones from an engineering point of view.

What you called "just do it, make it cheap, and see how it goes" is pretty much what has been defining the computing business ever since it has become mainstream. Intel happens to just have been part of the beginning of this very business.

And sure since x86 is still almost everywhere, you have to deal with it.
Or stick to more niche products.

The good news is that the market is getting a lot more diverse. x86 is probably going to slowly die.

But actually most of what currently dominates in the computing industry is flawed, from software to architectures. In that huge mess, people keep devising band-aids just like Intel has done for several decades.

[Ed.Kloonk]

These were all business decisions more so than engineering ones. Calling Intel's engineers brain-dead is completely silly.

Cost has certainly been a major concern back in the days and explains many of the mediocre solutions that had to be devised (but still allowed personal computing to exist at all in the end.)

I hate to say it but honestly, kids these days scoffing at how 'dumb' we all were back in the day.

In the case of Intel and also those around at the time, these companies were pioneering pioneering technology, if that makes sense. A lot of it was guess work, some of it educated guess work but in reality, nobody really knew what the next big thing was going to be and when. A lot of companies lost a lot of money.

Nowadays, technology evolution is really down to who can time the market with the next leap forward and make it cost effective. To those who say how silly some of were back in those days, I put it to you how much be would have loved to have access to the information and tools available now. Some of us old farts are dismayed at how much possibility there is being squandered by the youth.

Having said that, I do enjoy the examination of these significant developments with all the hindsight.

[DiTBho]

These were all business decisions more so than engineering ones. Calling Intel's engineers brain-dead is completely silly.

really? Was the A20 decision, which is nonsense and causes a lot of trouble (read the article!) a business decision?
 

[DiTBho]

In the case of Intel and also those around at the time, these companies were pioneering technology

Motorola was a pioneering company as well as Intel, and if you look at m68000 there are issues as well. One regards the bus-error handling, which is unrecoverable by design (wrong), the other issue involves an instruction that leakages privileges between user mode and kernel mode (wrong).

Both are fixed with 68010, 68020, ... and note, 68k moved from 8bit (6800) to 32bit (68k) with the same problem you have in 80286: only 24 bits of physical addressing (68000), but note, the design was 32bit since the beginning, so this was not a problem when 68020 added 32 bits of physical addressing.

Intel ...
... let me understand, you have an 8086 CPU with 20bit of physical and logical addresses, and you think it's a good idea, while your CPU will grow over time and expand, to make a circuit in the next CPU, 80286, that disables some high address lines to make it back-compatible?

and, worse still, allowing a hardware bug like the Unreal Mode in every CPU they made? And since Unreal-Mode is known by software like DOS32 and Grub, why don't they consolidate it as a documented feature?


That's what I do find stupid and completely wrong.

[DiTBho]

the time I spent writing a bootloader.
- m68k: 25 hours (I hacked the ROM of my Apple LC475 in order to boot Linux on a 68060 CPU)
- PowerPC: 37 hours
- SH3: 51hours (I hacked my CASIO pocket graphing calculator in order to load custom math binaries)
- MIPS32: 40 hours + 32 hours to rewrite YaMon from scratch in assembly
- x86: ... 574 hours(1) and it's not yet 100% correctly working

"hours" means ... during free time, when the weather is terrible

anyway, 574 hours!!!!! that is what x86 { real-mode, unreal-mode, protected-mode, a20, ... } and all those crazy ideas mean in practice; plus, 30 hours only to setup two gdb sessions, one for the 16bit mode, and one for the 32bit mode, with glue code between them.

I just hope that I still don't have to work on the firmware of an x86-based industrial device, because if it's based on DOS16 that's one thing, but if they ask me to run different OSes, like DOS32 extension, or like VxWorks, or they pay Windriver for have support (and I am sure they won't), or will it be a similar experience to wanting to load Linux directly in protected mode.


(1) I did it wrong several times, even because the anatomy of Linux kernel binaries (bZInage, vmlinux.elf, plus the old and deprecated setup.elf) isn't entirely clear to me, the Grub and Lilo sources are tough to follow, and in between are a lot of cross-cutting issues like having a buggy PC-BIOS (Soekris ...) with services not working properly

OK, probably I would also better spend money, purchasing a  professional debugger instead of trying to develop it myself like I easily did for the other mentioned architectures.

[DiTBho]

The original x86 architecture is like the width of two horses bums side by side.

Yup, precisely 

Yesterday I found a shocking fact: although the technical manuals speak of 16-bit registers (e.g. AX is { AH, AL}), in real mode, you can still access all the 32bit registers (e.g. EAX contains AX) if you use a prefix to your "move" instruction.

So, all of the 32-bit registers are usable by simply adding "0x66" to the beginning of any instruction, and it seems to work even on Cyrix CPUs.

I don't know if it's a hardware bug, but I am happy it's there 

[dave j]

[magic]

Get UEFI hardware and forget about 16 bit modes

[DiTBho]

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.

[SiliconWizard]

For those not familiar with the A20 issue: https://wiki.osdev.org/A20_Line

[David Hess]

Yesterday I found a shocking fact: although the technical manuals speak of 16-bit registers (e.g. AX is { AH, AL}), in real mode, you can still access all the 32bit registers (e.g. EAX contains AX) if you use a prefix to your "move" instruction.

So, all of the 32-bit registers are usable by simply adding "0x66" to the beginning of any instruction, and it seems to work even on Cyrix CPUs.

I don't know if it's a hardware bug, but I am happy it's there 

That is not a bug.  It is suppose to work that way.

[james_s]

In the case of Intel and also those around at the time, these companies were pioneering technology

Motorola was a pioneering company as well as Intel, and if you look at m68000 there are issues as well. One regards the bus-error handling, which is unrecoverable by design (wrong), the other issue involves an instruction that leakages privileges between user mode and kernel mode (wrong).

Both are fixed with 68010, 68020, ... and note, 68k moved from 8bit (6800) to 32bit (68k) with the same problem you have in 80286: only 24 bits of physical addressing (68000), but note, the design was 32bit since the beginning, so this was not a problem when 68020 added 32 bits of physical addressing.

Intel ...
... let me understand, you have an 8086 CPU with 20bit of physical and logical addresses, and you think it's a good idea, while your CPU will grow over time and expand, to make a circuit in the next CPU, 80286, that disables some high address lines to make it back-compatible?

and, worse still, allowing a hardware bug like the Unreal Mode in every CPU they made? And since Unreal-Mode is known by software like DOS32 and Grub, why don't they consolidate it as a documented feature?


That's what I do find stupid and completely wrong.

Well 68k machines were available, and they were superior in many ways except for two, and that is cost and compatibility, and thus they never achieved more than maybe 10% market share.

You seem to be either forgetting or deliberately ignoring the fact that all of these machines were/are produced for one reason and that is to earn money for the company selling them. So "you have an 8086 CPU with 20bit of physical and logical addresses, and you think it's a good idea, while your CPU will grow over time and expand, to make a circuit in the next CPU, 80286, that disables some high address lines to make it back-compatible?" Yes, I think it's a great idea, and it was very obviously the right business decision to make, because it resulted in an affordable machine that was much faster yet also capable of running the large library of existing software that people had invested substantial amounts of money in, and it resulted in selling vast numbers of these machines, earning the companies making them huge profits. Compatibility is king, it is the single most important feature followed by affordability, without it few will buy. If the 286 had not been code compatible with the 8086 and 8088 it would have been just another commercial failure, a footnote in the history of the PC revolution. Real mode was absolutely instrumental in its success and that of future x86 CPUs, backward compatibility is easily the single most important factor in their success and absolute dominance in the market for decades. When the 8088 was developed, nobody had any clue that computers would grow in power by leaps and bounds the way they did, there was just no way to see that coming. 8 bit microprocessors had been around for a while at that point and it really was not unreasonable at the time to believe the now famous line that "640k ought to be enough memory for anybody", I mean that was said at a time when 32k was a lot of memory, 640k was an absurd amount that no mere mortal could have afforded.

If you have a business is it smarter to go on an ideological crusade and develop something that is technically superior, or to produce an arguably inferior product that offers something that is of the utmost importance to potential customers, backward compatibility with their existing software, and thus much greater sales? All of the companies that tried the former failed, that should tell you something.

[magic]

Keeping the trolls well fed...

[DiTBho]

That is not a bug.  It is supposed to work that way.

Thanks! My doubt comes from the comments in a boot.S file (grub or Linux, I don't remember now), and it was a bit shocking the first time I opened it due to several comments telling the user how to force the assembly compiler.

something like if you put this prefix, you can access the 32bit EAX

Code: [Select]

[16 bit]
check_bz:
    pusha

    ; Test magic number of the BZ header
    mov     eax, dword [hdraddr + 0x202]
    cmp     eax, 'HdrS' ; <-------------------------- yeah, 32bit, it works!
    mov     dx, msg_sys_error1
    jne     panic

    ; Test jump instruction is there
    mov     al, byte [kernseg * 0x10]
    cmp     al, 0xeb
    mov     dx, msg_sys_error2
    jne     panic

    popa
    ret

Interesting, anyway, it's *VERY* useful for things like this!
I mean, it makes things simpler.

[DiTBho]

(
"nasm" can automatically put the "0x66" prefix in every "move" and "compare", etc, instruction if you mention a 32bit register as the argument

nice 
)

[David Hess]

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.

[james_s]

Dude .... 

I HAVE a business, I said several times that I develop ICEs and debuggers, plus other stuff, and if x86 takes me 500 hours to develop something, while other architectures/platforms take 50 hours, I think I am right to say that x86 is bad, especially if customers don't pay enough!

(and they don't)

We are in the "programming section" of the forum, it's supposed to talk about software/hardware problems (the title is "Unrel Mode"), but instead, you see and focus on "ideal" crusades for which you have to feel to defend (with x86 fanboyism) something with zero technical background just to see if your useless bullshit can make your life better.

Frankly, it's a troll attitude, and if last time I gave you the benefit of the doubt, now I have enough: stay on my ignore list!

p.s.
you also like to offend people personally, which LOL, it's fine with you that I don't give a shit about filing lawsuits against random people on the internet as I have many more interests in my life that spending my time making bad blood with people like you.

That's quite the word salad. You don't have a business selling CPUs back in the 80s and 90s do you? Because that's specifically what I was referring to. Your current business of writing debuggers is irrelevant to that discussion, nobody back in 1982 when the 80206 was released was thinking "oh yeah I bet there's gonna be this guy 40 years from now writing debuggers, let's really piss him off by designing the CPU in a way that will seem totally stupid at that time because that will be hilarious". That was not even a consideration at all. You're ranting and raving (how many threads have you started now?) and essentially calling the engineers that designed these chips decades ago bumbling idiots for doing things the way that they did, and I'm simply explaining that they were not idiots, in fact there were very good reasons they designed them the way that they did, it made good sense at the time, and I outlined what some of these reasons are.

I wouldn't call myself an x86 fanboy, I've never claimed that they are the best CPU architecture from a technological standpoint, indeed I openly acknowledge that there are other CPU architectures (several of which I own and use) which came along later that are technologically superior. I have merely explained why x86 chips have been dominant for so long, and defended many of the choices that made them the way they are and tried to explain why those choices made sense at the time and why in many cases they still make sense because compatibility with the existing software library is important to most users. I also have tried to explain that you can't reasonably expect the world to share your hatred for x86 because for the vast, VAST majority of users its warts are irrelevant. Not to you, I get that, but you are doing something that very, very, very few other people ever do. If you choose to take this personally that's on you, but you've started multiple threads ranting about x86 which frankly have the appearance of being a bit unhinged. I get that it makes your life more difficult, I get that you wish everyone was using something more modern, it would make your job easier, but right now as things stand it would make everyone else's life harder. You simply cannot expect people to spend more on hardware that does less for them because it can't run all the software they use.

Now I don't know why you even brought up lawsuits, if that's some kind of thinly veiled threat then it's a rather idiotic one because the courts in your country have no jurisdiction in mine. 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. If I told some incriminating lie about you then under exceptional circumstances you may be able to sue me for slander, but I have not done any such thing so cool it and stop taking everything personally. Whether you have better things to do than sue random people that rubbed you the wrong way on an online forum, or you are the most litigious person on the planet suing anyone you possibly can is absolutely irrelevant to me, you couldn't sue me even if you wanted because I have broken no laws and I'm not a citizen of your country nor am I located there so none of your laws apply to me. You said you were adding me to your ignore list weeks ago so this shouldn't even be an issue.

[magic]

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

[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 

[DiTBho]

I had a couple of 16 bit program I used a lot but they wont run now.

Yup, there is a modified version of DosBox that runs on RiscOS v6/32bit modern ARM.
The Video Games performance is outstanding to the point you don't not any glitches.
I think DosBox on GNU/Linux can run dos/16-bit applications on AMD64.

[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.

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,

https://en.wikipedia.org/wiki/Intel_i960

[DiTBho]

Intel's i960 (or 80960) was a RISC-based microprocessor design that became popular during the early 1990s as an embedded microcontroller. It became a best-selling CPU in that segment, along with the competing AMD 29000. In spite of its success, Intel stopped marketing the i960 in the late 1990s, as a result of a settlement with DEC whereby Intel received the rights to produce the StrongARM CPU. The processor continues to be used for a few military applications.

Indeed I cannot see any of the "notes" I was talking about, except in the proofreading of the page where what I'm talking about wiki-columnists are still deciding whether or not to put it in the article because they are not sure.

Unfortunately, I wasn't with the folks in the trenches, but from what a couple of seniors I spoke to get some i960 development stuff told me, there seems to have almost been an outcry among developers, and years later it happens the same when Intel disbanded its XScale ARM division completely.

Facts:
- Intel acquired StrongARM from DEC in 1996
- Intel rebranded it as "XScale"
- Intel sold XScale to Marvell in 2006
- Intel invested in Atom(1) as the new low-power product line
- Intel announced the Atom/Bonelli architecture in 2008

The intel core strength seems:
- focus on IA-32, rather than a "competing" architecture i960
- focus on IA-32, rather than a "competing" architecture ARM

So, it seems that the Intel leadership has repeated the same error of judgment first with i960 and then with Arm, plus a third error of judgment, even in the opposite direction (allocating money to a wrong solution), with Itanium.


(1) Atom was designed to compete with things like AMD's Geode mounted on the Soekris router that started this topic. The circle closes right here.

[David Hess]

The intel core strength seems:
- focus on IA-32, rather than a "competing" architecture i960
- focus on IA-32, rather than a "competing" architecture ARM

So, it seems that the Intel leadership has repeated the same error of judgment first with i960 and then with Arm, plus a third error of judgment, even in the opposite direction (allocating money to a wrong solution), with Itanium.

Considering Intel's success, I would hardly call the first two errors in judgement, and I think the lack of success with Itanium shows that.  Supporting x86 means AMD is Intel's only x86 competition.  If they had gone with an Intel alternative like i960, then they would have lost a majority of their customers.  If they had gone with ARM, then they would have lost a large majority of their customers and be competing with many other ARM producers.  X86 is still paying Intel's bills.

Even Itanium with hardware support for x86 emulation was not able to displace x86, although I think Intel really wanted it to.  That was their attempt to ditch x86.

There is still a thriving market for expandable x86 personal computers, workstations, and servers, but there is no such market even now for ARM.  Apple sure does not count; the Apple equivalents of my x86 workstations with massive expandability going back three or four generations do not exist, and such an ARM alternative has never materialized.  Texas Instruments had some potential processors for such a system but they abandoned that market a couple years ago.

If anything replaces x86 personal computers, workstations, and servers, I suspect it will be cloud based services which have the advantage of massive scaling and economy of scale.

[DiTBho]

Considering Intel's success

sure, success ... worst intel cpus 

[DiTBho]

There is still a thriving market for expandable x86 personal computers, workstations, and servers, but there is no such market even now for ARM.

Sure, indeed my Boss's Ampera 80 cores workstation is what? ARM/64? With what? eight 4xePCI and two 8xePCI slots?
And what about the new RPI-CM-based boards with one or two miniPCIe slots?

Times are changing, wait a few years, and it will be even more competitive 

[DiTBho]

the Apple equivalents of my x86 workstations with massive expandability going back three or four generations do not exist, and such an ARM alternative has never materialized.

My Boss's IBM-Tyran POWER9 workstation is superior by every means to every XEON-based workstation.
Consumes less electricity, it's more efficient and has the same expandability in terms of the number of PCIe slots, and it's even more reliable than XEON and its multi-core mechanisms are more robust.

Only three problems
1) only produced in the US, you have to export, and it's *VERY* expensive (~2x the price for a XEON PC)
2) there are only two OS: AIX(1) and GNU/Linux (3)
3) GPUs don't work correctly and cards that have x86 firmware usually just don't work(2)


(1) wanted and paid for by DARPA for government agencies
(2) that's why I have no sympathy for PCs at all, because they rarely/never respect the specifications, and so the fleet of devices available only on the PC platform is concentrated, which in fact does not allow other platforms to thrive.
(3) POWER is ~PPC64 (subset), I do support the Linux Kernel and Gentoo/PPC64, so my boss has full open-source support for her workstation! Lucky woman and I'm fortunate too, to have been in charge of technical support!

[james_s]

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 

x86 *did* bring in more money, it brought in huge amounts of money, it has dominated the marketplace for decades and absolutely crushed everything else that has tried, nothing else has even come close. Have you looked at the sales numbers? More x86 processors have been sold than every other desktop/laptop/server CPU combined, not because they are the best technologically but because they offer something nothing else does, compatibility. It's odd that you completely ignore the fact that Intel has for decades been the most successful and profitable CPU company in the world by a HUGE margin, and despite losing some of their luster in recent years as the PC market saturated they are still dominant. In what reality is that stupid? They are so bad at evaluating things that they have been a massively successful multi billion dollar company for decades. I wish I were that bad at evaluating things 

Itanium ironically just further proves the point that Intel should have just stuck with x86 because that was their bread & butter and that's where the money was. They tried to develop something new and different and like so many before them, they failed miserably. The history of computing is littered with failures, and so is business in general. Success sometimes involves taking risks and sometimes those risks lead to failure, it happens, it takes a warped view of reality to take that one failure as an indication that the company is overall bad at what they do.

[james_s]

My Boss's IBM-Tyran POWER9 workstation is superior by every means to every XEON-based workstation.
Consumes less electricity, it's more efficient and has the same expandability in terms of the number of PCIe slots, and it's even more reliable than XEON and its multi-core mechanisms are more robust.

Can it run Adobe creative suite? Can it run Altium? Can it run Vivado? Solidworks? Can it run games that require Windows? If it can't do those things, then it is not superior if those are things you need a computer to do. The best most technologically advanced computer in the world is absolutely useless if it can't run the software you want to use. Normal people don't care how the computer works, they want to run software.

[james_s]

sure, success ... worst intel cpus 

Once again you completely ignore their massive financial success and cherry pick some of the turds they've produced. Do you not realize that any company exists for only one reason, to earn a profit? Look up how much profit Intel has earned over the past 40 years and tell me with a straight face that they have not been successful.

[CatalinaWOW]

I'm not sure what drives DiTHBo's hatred of the X86 family.  He is not wrong about some of the difficult issues, but those don't explain the level of antipathy.

The answer for X86s success isn't as simple as compatibility.  If any of you remember the Intersil 6100 processor, it was designed to emulate Digital Equipment Corporations PDP-8 which was part of the dominant minicomputer line of the era.  There was more software available for that family, and more trained programmers than for virtually any other computing system.  While it didn't totally fail, it did not take the market by storm.  If software compatibility was the dominant issue it would have owned the market.

I suspect that plain old FUD marketing also played some role in X86 survival.  This is in some way like compatibility, but is its own unique niche.  Desktop computing is littered with the corpses of failed attempts.  Companies don't want to invest in something that will be unsupportable in just a few years.  Most business applications last decades or more.  The thought of starting over on interfaces, staff training, software and the whole nine yards is terrifying.  So looking forward will you be able to buy another or a replacement for your computing widget.  AFAIK only two families have a positive track record in this regard.  X86 and Apple.  X86 does it with hardware compatibility.  Apple with a closed ecosystem and a lot of work, that still leaves some holes as they went from 68000 to PowerPC to X86 to custom.

[Ed.Kloonk]

I've been too scared to mention byte order.

[magic]

not sure what drives DiTHBo's hatred

I sort of know or suspect but won't post publicly

[SiliconWizard]

So, it seems that the Intel leadership has repeated the same error of judgment first with i960 and then with Arm, plus a third error of judgment, even in the opposite direction (allocating money to a wrong solution), with Itanium.

You're assuming, even claiming, that this was an error. But Intel is still here, and financially well off. Is this an error?

As to the Itanium, there were some pretty interesting things in that. The reason it failed is more complex than just it being "the wrong solution". It just didn't meet its market and by the time it was close to good enough, it was too late.

You seem pretty angry with Intel and seem to think you would have done better. Not very humble, but oh well.

As to the difficulties of decision-making in large corporations with a ton of legacy, as I suggested before, "The innovator's dilemma" is a great book.
Helps understand why often only newcomers can disrupt markets with really new solutions, while the well established companies are more or less cornered into iterative developments rather than real innovation.

[Nominal Animal]

I'm not sure what drives DiTHBo's hatred of the X86 family.  He is not wrong about some of the difficult issues, but those don't explain the level of antipathy.

As I see it, the answer is both simple and complicated at the same time.

Consider all the old hardware developments, and all the various architectures that generated the real innovations.

Was MS-DOS an innovation?  Heck no, it was quite a step backwards compared to what the architecture ended up being capable of, but because of backwards compatibility and other business reasons, ended up being a construct of compromises than a clean design.

Was Windows an innovation?  Heck no.  You can look at Xerox Alto and then Apple Mac OS for innovations in that area.

The key innovation, perhaps, was how IBM allowed clones of their x86-based PC's, while retaining compatibility.  Thus, the reason for the success and prevalence of x86 isn't so much because of technical reasons, but because of business choices.  Not exactly VHS versus Betamax, but you get the idea.

Why the antipathy, then?  What is the difference whether something becomes popular because of technical ability or just business choices?  Popular is popular.
The complex answer to that is the same as why some people do woodworking only with hand tools, or metalworking with half-a-century or older tools, instead of CNC'ing it all.  There is inherent beauty in the now-rejected technologies, that makes it a joy for some of us (well, not me, but DiTBho) to work with them.

It is complex, because it can be hard to understand why someone would use nearly century old tools to do actual work, but also happily draw plans for them using latest 3D CAD software.  There are many aspects to the reasoning, with possibly the 'inherent beauty' and admiring and appreciating technologies that were rejected not because of their own failures, but because of business and cultural reasons, at the heart.

Me, I differ in that I do not perceive that beauty myself – although I can perceive others perceiving it –, and just treat most of these things as tools.  They make it possible for me to do things I otherwise could not.  Woodworking and cooking is special to me only because the tactile and olfactory information cuts straight through the analytical part of my mind, directly affecting my mood and emotional state, thus giving me a tool to not be a slave to the analytical part of my mind.  (I did use to paint, and especially draw with wax pastels on dark canvases, but I haven't been able to do that in the last 15 years or so for some reason.)
So, I can certainly understand the antipathy, even if I do not feel strongly about the issue myself.

[DiTBho]

I'm not sure what drives DiTHBo's hatred of the X86 family.  He is not wrong about some of the difficult issues, but those don't explain the level of antipathy.

A lot of reasons, but it's very simple and I have already mentioned that I design ICEs.
When architecture has ~1000 instructions is nothing but pain.

compatibility

everyone repeats it, over and over - compatibility - and what do you want? Atom x86 even on smartphones? to be binary compatible with your PC? Would you like to run DOS on your smartphone?

LOL 

no one sane would put an x86 on phones and tablets because it sucks about power consumption, when we talk about ARM and Intel's decision to decommission Xscale, we talk about this, and I don't understand why we need to bend reality to justify that it was objectively - by facts - a wrong choice by the leadership Intel, as all phones and tablets use ARM!

[DiTBho]

You're assuming, even claiming, that this was an error. But Intel is still here, and financially well off. Is this an error?

I am assuming nothing, I am talking about facts!
From financial articles, Itanium and Atom were two big financial flops for intel itself.

[DiTBho]

Was MS-DOS an innovation?

recently the Microsoft DOS sources have been published ... a design that to call "mediocre" and "not innovative at all" is not to be bad but objective.

retaining compatibility.  Thus, the reason for the success and prevalence of x86 isn't so much because of technical reasons, but because of business choices

Yup, precisely.
Popular is popular 

So, I can certainly understand the antipathy, even if I do not feel strongly about the issue myself.

Talking about "compatibility" I still have some customers' embroidery machines with DOS-based software, but not DOS/Extended mode like the DukeNuken3D engine (protected mode), stuff that runs in real mode, and I let you imagine how happy it makes me hear the managers say "ah, well, just change the x86 mobo with a modern one, it's compatible, won't it be a problem, will it?"

I am rarely so sure!

Their software runs in real mode, it's very ugly when you have to patch it, and I have to because replacing a 486 SBC with a (AMD) Geode introduces a series of problems on the bus. Not to mention incompatibilities with BIOSs.


My bootloader takes about 408 bytes for the first stage, and about 25Kbytes for the second stage but only because it contains a monitor and a network stack, if you look at bootloaders like Grub, or Lilo and wonder why they are so full of code while offering fewer features? (neither grub nor Lilo offers a monitor, Lilo doesn't even have tftp, grub .. if you want) ... well, you realize that many more lines of code are needed to keep up with all the various inconsistencies between different PC BIOS.

Worse if you look at the BIOS of XEON machines, and worse if you look at how XEON machines, supposedly flagship intel stuff, do their multicore work.

Frankly, I would be really worried about their reliability if I had to write my own kernel/metabare application.

While I have no fear with POWER9 as just two lines of code are enough and if I'm sure it's a strong solution, with intel ... after reading five manuals of 300 pages each, I still haven't found anything that makes me feel less worried.

PCs, from the BIOS to the bootloaders to the kernel, require too many patches, and too many layers on top of each other.

And that's what bothers me a LOT, plus all the difficulties to debug, and worse still, designing a debugger without going nuts!

Now think that in C it's not even safe to write a library for thread support.

It's not a problem for 80 Core ARM/64 Ampera, not a problem for 64 Core POWER9, literally less than 100 lines of assembly, but how the hell do you do it on multi-core XEON machines?

Respect for Linus, and for the patience the developers have!

[David Hess]

retaining compatibility.  Thus, the reason for the success and prevalence of x86 isn't so much because of technical reasons, but because of business choices

Yup, precisely.
Popular is popular 

There were plenty of poplar systems available when the IBM PC was released and they did not survive.  The IBM PC plus MS-DOS, or CP/M-86 if you remember, was already compatible with the existing base of 8080/8085/Z80 CP/M systems, so there is that compatibility thing again.  CP/M was already being used for business and development systems and Intel and IBM leveraged off of that.

Was MS-DOS an innovation?  Heck no, it was quite a step backwards compared to what the architecture ended up being capable of, but because of backwards compatibility and other business reasons, ended up being a construct of compromises than a clean design.

MS-DOS and CP/M-86 did not do anything that CP/M did not, but they did do it better while maintaining a level of compatibility.  CP/M itself was pretty good for what it did.

Was Windows an innovation?  Heck no.  You can look at Xerox Alto and then Apple Mac OS for innovations in that area.

I did not consider Window usable until Windows 95.  The only application that I ran on Windows was Mathematica.  I much preferred Desqview for business applications and development.

I've been too scared to mention byte order.

X86 byte order stores least significant byte first so that multiword operations can proceed starting with the word pointed to by the pointer.  It also allows operations with multiple data widths to use the same pointer.

[james_s]

You're assuming, even claiming, that this was an error. But Intel is still here, and financially well off. Is this an error?

I am assuming nothing, I am talking about facts!
From financial articles, Itanium and Atom were two big financial flops for intel itself.

So? Those are two examples of where Intel tried to do something new and failed, and yet if they hadn't tried to do something new you would criticize them for that too. They had those two fairly high profile failures, and a whole lot of successes, overall they have been extremely successful. Name one CPU company that has earned more profit since inception than Intel.

[james_s]

I'm not sure what drives DiTHBo's hatred of the X86 family.  He is not wrong about some of the difficult issues, but those don't explain the level of antipathy.

Mental illness I suspect, I'm not qualified to diagnose anybody but it is certainly not rational behavior.

Also his job is apparently doing something extremely esoteric that involves low level programming requiring him to deal with all these ugly hacks that 99.9999999% ofPC users never sees. Of course if not for the difficulty of this low level development he may well be out of a job, if it were as easy as it is with some more modern architectures there would be a lot less reason to pay somebody good money to do it, engineering is relatively highly paid specifically because it is hard. He completely ignores the fact that x86 has been by far the most successful CPU architecture in the world in terms of units sold and profit earned and the fact that companies exist precisely to sell products and earn as much profit as possible, not to further some ideological agenda. Countless companies have introduced superior machines over the years and they have all failed, every single one that he has mentioned the virtues of is an obscure niche in the PC/workstation world. As the saying goes, the biggest enemy of "the best" is "good enough" and x86 has been good enough to sell billions of chips. I suspect he was not born yet during the PC revolution when all this early development was taking place.

[james_s]

everyone repeats it, over and over - compatibility - and what do you want? Atom x86 even on smartphones? to be binary compatible with your PC? Would you like to run DOS on your smartphone?

LOL 

no one sane would put an x86 on phones and tablets because it sucks about power consumption, when we talk about ARM and Intel's decision to decommission Xscale, we talk about this, and I don't understand why we need to bend reality to justify that it was objectively - by facts - a wrong choice by the leadership Intel, as all phones and tablets use ARM!

No, who has said that? That's called a strawman argument. Absolutely nobody is saying x86 makes sense on a smartphone, smartphones are totally different than PCs, they have totally different use cases and needs. Power efficiency and compactness are of the utmost importance on a smartphone, they have closed ecosystems so compatibility with legacy software isn't needed. Nobody wants to run Photoshop, Solidworks or some obscure DOS based utilities on smartphones. Nobody runs Windows games on smartphones. This is precisely why more modern CPUs like ARM have dominated on smartphones, it's a totally new platform with a totally new ecosystem so backward compatibility isn't needed. There is only one person in this thread that is bending reality and that is you.

Desktop/laptop PCs must have compatibility with mainstream software to sell, do you seriously think otherwise? Can you name one single alternate architecture for desktop/laptop workstations or servers that has been as successful? (success = profit)

[T3sl4co1l]

Mental illness I suspect,

Aaaand any rational argument, any hope of convincing the other party of your position, is gone.

(Actually you probably did that with your earlier reply but you're really doubling down now.)

Tim

[Monkeh]

Mental illness I suspect,

Aaaand any rational argument, any hope of convincing the other party of your position, is gone.

(Actually you probably did that with your earlier reply but you're really doubling down now.)

Tim

Now we're completely off the rails: Hitler would have loved x86.

[james_s]

Mental illness I suspect,

Aaaand any rational argument, any hope of convincing the other party of your position, is gone.

(Actually you probably did that with your earlier reply but you're really doubling down now.)

Tim

I gave up seriously trying to convince him a long time ago when it became blatantly obvious that his mind was made up, he was not interested in rational discussion and would simply deflect and ignore anything that didn't support his strange assertions and unhinged rants. I don't have any other explanation for such bizarre and irrational behavior, do you? Everyone else here knows why x86 has been successful, agrees that it has been extremely successful and understands that the warts it has are due to business decisions that made sense at the time they were done. The fact that it has absolutely dominated the entire marketplace for decades, sold billions of units and remains dominant today while numerous technologically superior platforms have failed due to not offering compatibility speaks for itself. Compatibility is king, everyone else knows that, if a PC can't run existing software then it fails to sell, even if it's "better" because without software any computer is useless no matter how good it is, we've seen that over and over and over. The only time and new and different approach has succeeded is when it's a new and different application (smartphones, tablets) where existing software doesn't matter. This is just fact.

There's just no rational explanation I can think of for claiming that such an enormously successful business was not a success or that it was run by idiots because they didn't do what other companies that failed did means they didn't know what they were doing, and the arrogance in thinking that had he been calling the shots 40 years ago he could have done better.

[T3sl4co1l]

I gave up seriously trying to convince him a long time ago

So you left the thread and ticked "ignore" on it..?

"Try, try again; then give up.  There's no point being a damned fool about it."

Tim

[magic]

Is the purpose of this thread convincing the OP to like x86?

We gotta try harder

[SiliconWizard]

Is the purpose of this thread convincing the OP to like x86?

We gotta try harder

I don't know what the purpose is. At first the OP ranted about some low-level x86 annoyances. Fair enough if you have to deal with these.
Then his rant turned into blaming it all on Intel engineers and claiming they all have been morons.
Then he apparently figured out the initial issue he encountered, but it was too late already and he gave up nonetheless. Because, heaven forbid.
Then he claimed Intel has kept making strategic errors, in spite of its success.
Not sure how it would all help him move forward with his technical issues, but we all rant sometimes.
The funny part would be if he had typed this all on some x86 computer.

[retiredfeline]

We gotta try harder

🐴. 🌊. (Neigh)+. !Drink.

[magic]

The funny part would be if he had typed this all on some x86 computer.

Doubt it. Too loud a RISC fanboy to touch one.

I was about to add that I'm reading them on x86 though, and there is nothing he can do about it, but actually I'm using ARM now

[DiTBho]

Mental illness I suspect,

Aaaand any rational argument, any hope of convincing the other party of your position, is gone.

(Actually you probably did that with your earlier reply but you're really doubling down now.)

Tim

james_s is in my ignore list for insulting me personally, I see from your quote he is doing it again, and I haven't read it for a while, as I clearly wrote, and why does it continue when I don't care what it says?

Again, it's called trolling

And why do you have to *convince* me that x86 is cool? I don't have to approve myself in front of anyone, and the purpose of the forums is precisely to bring different positions because you can learn new stuff this way, that's why I offered my honest thinking, otherwise discussing is completely useless.

You know what, don't be offended, but this forum has lost a lot of polish, which is disappointing

Greetings.

[DiTBho]

I don't know what the purpose is. At first the OP ranted about some low-level x86 annoyances. Fair enough if you have to deal with these.

I opened this topic in the hope that someone would tell me something about the "unreal mode" and found that everyone talks well about x86 then nobody ever knows anything, yet everyone talks.

that's indeed its "being popular"

Then his rant turned into blaming it all on Intel engineers and claiming they all have been morons.

so I solved the various problems by myself, and I wanted to let you know that even to write a trivial bootloader you have to read lots and lots of technical documentation.

you can call this part a "rant" against technical nonsense, I called them "morons"(1) due to the technical nonsense, it's easy for you to talk, but for me that nonsense costs hours to fix learn and fix them, anyway then I considered that it was not engineers' fault because they just followed directives from the leadership.

Then he claimed Intel has kept making strategic errors, in spite of its success.

people always want to justify Intel, so I've compiled some facts, and if you don't even recognize the fact that leaving the ARM world and thinking about replacing it with Atom wasn't a failure, then there's really no point in talking but not because I have a different opinion but rather because of the bias that everything Intel does is ok as it's "popular".

Facts are that Intel gave up on XScale, their ARM-compatible effort and turned down the opportunity to make the iPhone's chip and gain a foothold in the mobile market, and a more direct source, from Intel's own CEO at the time:

The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do... At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it.
[..]
It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought

meaning that Intel bet that ARM would take as long to reach x86-level of performance as Intel would take to reduce x86 power consumption to SOC levels.

In the last post, I pointed out how they bet on being able to maintain a hair above the level of "decent" multi-core support for the machines, and how much they underestimate, again, their "botched solutions", specifically that it won't be a problem when the machines have more than 80 cores or an interface to the quantum computing engine.

I foresee more catastrophic loss of money, and I will stand here and watch them fail, again, but this time without investing in their products. I remember XSCALE not only because used on my SHARP PDA but also because at the time I spent a lot of time and money on their SA-1* (Strong Arm) dev boards, reading their manuals, doing stuff for customers, and you can imagine how *we* were all happy to see me drop chip making with, as my only option, having to switch to the Atom platform.

-

Then this thing about that-James-dude having to "convince me" that otherwise, you are mentally ill, really I find it pathetic to the point I wonder how much of a loser someone must be for finding it helpful to troll people on a forum 


- - -

At least, it was a great social experiment on how people are circuited on "good because popular" things.
Having said that, I greet you all, have a good day.

edit:
(1) post was deleted, makes no sense if people continue to reface it to me.

[T3sl4co1l]

james_s is in my ignore list for insulting me personally, I see from your quote he is doing it again, and I haven't read it for a while, as I clearly wrote, and why does it continue when I don't care what it says?

Again, it's called trolling

Ah, my apologies for echoing it then.  Matter of fact, that sounds like a  good enough vote that moderators may want to get involved.  Cheers.

Tim

[Monkeh]

I opened this topic in the hope that someone would tell me something about the "unreal mode" and found that everyone talks well about x86 then nobody ever knows anything, yet everyone talks.

that's indeed its "being popular"

Well I'm certainly not going to go around talking up a platform which is too slow, too expensive, and doesn't even run the software I need, just because it's nicer at a level I don't have to deal with.

I think you might want to replace 'popular' with 'practical'.

You're very much in the wrong place for discussions on the relative merits of architures. The vast majority of us couldn't care less if it gets the task done.

[David Hess]

meaning that Intel bet that ARM would take as long to reach x86-level of performance as Intel would take to reduce x86 power consumption to SOC levels.

It is not ARM which has reached x86 levels of performance, but Apple.  X86 CPUs can be purchased by anybody for any purpose.  Apple's ARM implementation is only available for use inside Apple's products.  If Apple's vision does not support your application, then x86 has higher performance.

Two advantages Apple has are on package memory, which significantly reduces power consumption at the expense of more limited memory capacity, and more limited expansion support.  X86 may gain those advantages when it makes economic sense.

In the last post, I pointed out how they bet on being able to maintain a hair above the level of "decent" multi-core support for the machines, and how much they underestimate, again, their "botched solutions", specifically that it won't be a problem when the machines have more than 80 cores or an interface to the quantum computing engine.

The coherency implementations for x86 have been *better* than ARMs, and most or all other RISC processors.  This gets back to memory ordering where the strict memory ordering of x86 is advantageous in practical implementations.  The loose memory ordering common in RISC processors, which was suppose to be an advantage, causes more problems than it solves.

[james_s]

I gave up seriously trying to convince him a long time ago

So you left the thread and ticked "ignore" on it..?

"Try, try again; then give up.  There's no point being a damned fool about it."

Tim

No, I'm just pointing out how absurd the OPs rants are, you might not have noticed they started multiple threads ranting and raving about their hatred of x86, and then not  being able to articulate why a normal person should care. You could have left the thread just as easily if it did not interest you.

[james_s]

And why do you have to *convince* me that x86 is cool? I don't have to approve myself in front of anyone, and the purpose of the forums is precisely to bring different positions because you can learn new stuff this way, that's why I offered my honest thinking, otherwise discussing is completely useless.

You know what, don't be offended, but this forum has lost a lot of polish, which is disappointing

Greetings.

Nobody is trying to convince anyone that x86 is cool, that's another strawman. What people are arguing is that Intel engineers were not idiots, they knew what they were doing and x86 evolved the way it did for very good reasons that were sound business decisions at the time. It isn't "cool", it's wildly successful. Scores of other companies tried to do something different and none even came close to the success of x86, because being "cool" doesn't count for squat in the marketplace.

If you are offended that's on you, I don't know where this strange idea that one has the right to be shielded from being offended came from.

[james_s]

Ah, my apologies for echoing it then.  Matter of fact, that sounds like a  good enough vote that moderators may want to get involved.  Cheers.

Tim

I'm not trolling at all, go back and read through all of my responses here and point out where you think I'm trolling, or where I have said something meant as a direct insult to anyone here. If you think the moderators should be involved then please do flag the relevant posts and let them decide, I respect their judgement.

[SiliconWizard]

Well, IMO, while ARM (we should be writing 'arm' though, as it's been 'arm' for some years now, bye bye ARM) is a decent RISC architecture, it's not nearly perfect either. It kind of sucks on a number of levels.
And then there are the licensing issues, the behavior or arm's management, the funding, and the uncertainties around its future.

Historically speaking, arm's sucess almost happened completely by chance. The original ARM CPUs were pretty close to getting trashed and forgotten, due to them having at the time basically no market outside of the Acorn Archimedes line, which was a great engineering adventure but didn't end well.

But I could certainly rant about arm as well.

And yes, Apple did a good job with the M1 and M2, but I'm not convinced that what they came up with 1/ can scale up, and 2/ that Apple won't just go for something else right at the moment they find someting better suited, a few years from now.

Anything can suck depending on your perspective.
Nothing wrong with refusing to work with some particular tech though, assuming you can afford not to.

If I could, I would probably throw away pretty much everything that currently makes the computing industry. It's sort of rotten. But it sort of works, so it's still useful and while I have some neat ideas (like many others I guess), I'm not sure they would end up resulting in anything significantly better. I'm afraid I (as most of us) would tend to focus on details while missing out on the big picture.

[james_s]

If I could, I would probably throw away pretty much everything that currently makes the computing industry. It's sort of rotten. But it sort of works, so it's still useful and while I have some neat ideas (like many others I guess), I'm not sure they would end up resulting in anything significantly better. I'm afraid I (as most of us) would tend to focus on details while missing out on the big picture.

I'd love to ditch Windows, it's pretty much a steaming turd and it just keeps getting worse. But it is the defacto standard, it runs on ~90% of PCs in the world, so if I were writing a commercial software product I would primarily target Windows. Not because it's technologically superior necessarily, but because it's what most of my potential customers will have.

[DiTBho]

It is not ARM that has reached x86 levels of performance, but Apple

Arm chips exist for all markets.
Apple makes the Arm chips that can compete in the desktop and laptop consumer space, while Ampere(1), Amazon, and Nvidia supply the Arm chips which can compete in data centers!

(1) I think I already mentioned my boss's 80-core "Ampera", right? here we are not the only ones using this technology, and it's the smallest one, compared to the "Neoverse N1" that has 128 cores, and the "Neoverse v2" has 172 cores!! All ARM big chips, and then there is also Amazon, which has come out with the Graviton3 chip with 64 Neoverse V1 cores. Meanwhile, Nvidia has announced their Grace super-chip which will have 144 Neoverse V2 cores!


Intel is working on this stuff and doing a lot of propaganda.

[David Hess]

It is not ARM that has reached x86 levels of performance, but Apple

Arm chips exist for all markets.
Apple makes the Arm chips that can compete in the desktop and laptop consumer space, while Ampere(1), Amazon, and Nvidia supply the Arm chips which can compete in data centers!

Apple makes ARM microprocessors which are available only as part of Apple's complete systems.  If the later do not meet my needs, then the former are unavailable to me.  Apple competes with various system makers, but they do not compete directly with Intel or AMD.

[DiTBho]

I'm afraid I (as most of us) would tend to focus on details while missing out on the big picture.

And precisely you focus on details while missing out on the big picture: I am just saying -1- do not buy x86 only because it's the most popular when you can buy something else, and -2- inform yourself before pointing the finger only at the most popular solutions!


Note, again, it talks about ARM, and people in this forum only mention Apple Silicon ARM, ignoring all the other ARM solutions I mentioned!

[DiTBho]

Apple competes with various system makers, but they do not compete directly with Intel or AMD.

Talking about data centers and scientific simulators, the fastest supercomputers today are built using Arm and POWER9, not x86 chips, why? well, have you seen the last Intel and AMD CPUs?


(Intel Xeon Platinum 8468)

Sure, they are able to outperform the chips made by Apple, Ampere, and NVidia, but only at the cost of insane power usage!

When you have a 20Kwatt cabinet it makes a BIG difference!


p.s.
I feel sympathy for this comment

I used to own a cloud computing company - we were not massive but we had racks filled with Intel Xeon CPU. I was often asked why we didn't consider AMD and the reason is one I never hear you mention: you have to cripple CPU features to allow hot transfer of workload between AMD and Intel. So in an environment where we were counting cores in the thousands or higher, introducing new CPU that are not "compatible" with the fleet would be an insane choice. You'd have to prevent live migration of workload between heads or alternatively, modify hypervisors to limit features to guest workloads. Because of this, we were effectively "married" to Intel. Moving some devices to AMD would have required too much development time to modify control systems, limited interoperability or have meant that we would have had to make very large purchases on AMD to essentially split into two, distinct farms, and that would have been quite a bet to have taken.

I can confirm it's a BIG problem in a farm!

[magic]

Show me how well live migration works between different ARM core types or different SOCs, and for how long will those SOCs be supported.
 

ARM is the most rubbish arch in the world today. And it goes mostly into smartphones, hmm, mabye not a coincidence.

[DiTBho]

ARM is the most rubbish arch in the world today. And it goes mostly into smartphones, hmm, mabye not a coincidence.

LOL 

I prefer to read Linus' answers to a question that particularly interests me: the ARM transactional memory extension support, the decision of IBM to remove tr-mem from POWER10, note that neither of them has ever done aggressive propaganda either on television, on youtube, or in shopping malls, like Intel has been doing since a while, and they are both intellectually honest in saying "we acknowledge that it was a bad idea", while intel ... Intel's TSX was plagued with functionality bugs and security bugs, yet after 5 iterations, all unsuccessful, once again Intel has announced that it's going to bring back a new version of TSX in the Sapphire Rapids processors, hopefully having fixed the bugs of prior versions.

Linus Torvalds to Andrey, March 31, 2021

> You obviously have to write non-transactional path, and it will have its pitfalls, but the point
> is that you could have better best-case and average performance with TSX.

No, you really really don't.

TSX was slow even when it worked and didn't have aborts, and never gave you "best-case" performance at all due to that. Simple non-contended non-TSX locks worked better.

And TSX was a complete disaster when you had any data contention, and just caused overhead and aborts and fallbacks to locked code, so - no surprise - plain non-TSX locks worked better. And data contention is quite common, and happened for a lot of trivial reasons (statistics being one).

And no, TSX didn't have better average performance either, because in order to avoid the problems, you had to do statistics in software, which added its own set of overhead.

As far as I know, there were approximately zero real-world loads that were better with TSX than without.

The only case that TSX ever did ok on was when there was zero data contention at all, and lots of cache coherence costs due almost entirely due to locking, and then TSX can keep the lock as a shared cache line. Yes, this really can happen, but most of the time it happens is when you also have big enough locked regions that they don't get caught by the transactional memory due to size overflows.

And making the transaction size larger makes the costs higher too, so now you need to do a much better job at predicting ahead of time whether transactions will succeed or not. Which Intel entirely screwed up, and I blame them completely. I told them at the first meeting they had (before TSX was public) that they need to add a TSX predictor, and they never did.

And the problems with TSX were legion, including dat aleaks and actual outright memory ordering bugs.

TSX was garbage, and remains so.

This is not to say that you couldn't get transactional memory right, but as it stands right now, I do not believe that anybody has ever had an actual successful and useful implementation of transactional memory.

And I can pretty much guarantee that to do it right you need to have a transaction success predictor (like a branch predictor) so that software doesn't have to deal with yet another issue of "on this uarch, and this load, the transaction size is too small to fit this lock".

I'm surprised that ARM made it part of v9 (and surprised that ARM kept the 32-bit compatibility part - I really thought they wanted to get rid of it).

Linus

which is just useful for making AMD waste money and time, just so as not to give the customers the impression of staying backward.

When Linus pointed his finger at ARM in the last two lines of his answer, is for this (2021), but note, it's not the ARM support for trMem is done for propaganda or for a sneaky marketing reason, but rather to push researchers and developers on a different level.

so, sorry, but ARM is less intellectual garbage than the marketing garbage that Intel makes 

[magic]

Yes, it's garbage. You can't even migrate a disk with Linux installation from one SBC to another, but you complain that live migration of VMs is fussy on x86 because of some chipset differences between Intel and AMD.

Yes, they could have agreed on hardware standards instead of hiding it all behind an abstract turd like ACPI.
But look at the level of hardware standardization in ARM SOCs

[james_s]

And precisely you focus on details while missing out on the big picture: I am just saying -1- do not buy x86 only because it's the most popular when you can buy something else, and -2- inform yourself before pointing the finger only at the most popular solutions!

Some of the software I use only runs on x86, so you're saying I should buy hardware that doesn't support all of my software for... reasons? Because something else is available? Just to be different? For ideological reasons? This is something I've been trying to figure out throughout all of these threads. Why should I spend more on something that does less for me? I need a solution that will run x86 software, I don't care what CPU architecture is inside the box or how it accomplishes what it does, so what is the suggestion here?

[james_s]

Yes, it's garbage. You can't even migrate a disk with Linux installation from one SBC to another, but you complain that live migration of VMs is fussy on x86 because of some chipset differences between Intel and AMD.

Yes, they could have agreed on hardware standards instead of hiding it all behind an abstract turd like ACPI.
But look at the level of hardware standardization in ARM SOCs

ARM is quite good IMO, for platforms where low power is a priority and backward compatibility is not needed. Most smartphones are arm based, most settop boxes are, the enormously popular Raspberry Pi is arm based, as are most consumer broadband routers, it works very well for that and I own and use quite a few devices that have it. But it can't run x86 software so it is useless as a desktop for me, it simply doesn't meet my needs. It is totally irrelevant how technologically superior a platform is if it doesn't support the software you need. This is the core issue and why this whole argument is rather pointless.

[David Hess]

I have migrated my FreeBSD router and NAS between multiple generations of x86 hardware and between Intel and AMD without issues.  When I migrated the network interface cards as well, I did not even have to reassign them.  Everything just worked.

In order the top hardware failures have been ATX power supplies, Flash memory running out of endurance and retention, and the ice machine upstairs springing a leak and dripping water onto the machine.  Hard drives outlasted Flash drives.

[DiTBho]

from commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7
Paul Mackerras, Mar 2018
KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9
To account for this different POWER9 chips have TM enabled in different ways.

POWER9
On POWER9N DD2.01 and below, TM is disabled. ie HWCAP2[PPC_FEATURE2_HTM] is not set.

On POWER9N DD2.1 TM is configured by firmware to always abort a transaction when tm suspend occurs. So tsuspend will cause a transaction to be aborted and rolled back. Kernel exceptions will also cause the transaction to be aborted and rolled back and the exception will not occur. If userspace constructs a sigcontext that enables TM suspend, the sigcontext will be rejected by the kernel. This mode is advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set. HWCAP2[PPC_FEATURE2_HTM] is not set in this mode.

On POWER9N DD2.2 and above, KVM and POWERVM emulate TM for guests (as described in commit 4bb3c7a0208f), hence TM is enabled for guests ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest userspace. Guests that makes heavy use of TM suspend (tsuspend or kernel suspend) will result in traps into the hypervisor and hence will suffer a performance degradation. Host userspace has TM disabled ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (although we make enable it at some point in the future if we bring the emulation into host userspace context switching).

POWER9C DD1.2 and above are only available with POWERVM and hence Linux only runs as a guest. On these systems TM is emulated like on POWER9N DD2.2.

Guest migration from POWER8 to POWER9
will work with POWER9N DD2.2 and POWER9C DD1.2. Since earlier POWER9 processors don't support TM emulation, migration from POWER8 to POWER9 is not supported there.

So, with IBM POWER we know TM is a problem, and we somehow know how to handle it, but I have never seen anyone from the IBM department, not even their traders, doing "sneaky innovation" propaganda when they have nothing but bugged features!

Intel does it, and it's frankly annoying!

[DiTBho]

I have migrated my FreeBSD router and NAS between multiple generations of x86 hardware

you could do this because there are layers and layers of compatibility software, just like I've already pointed out for Grub and Lilo that work at the cost of putting several orders of magnitude higher the number of lines of code that would be needed!

Which is annoying for devs and maintainers!

[Monkeh]

I have migrated my FreeBSD router and NAS between multiple generations of x86 hardware

you could do this because there are layers and layers of compatibility software, just like I've already pointed out for Grub and Lilo that work at the cost of putting several orders of magnitude higher the number of lines of code that would be needed!

Which is annoying for devs and maintainers!

Apparently less annoying than doing it for ARM SBCs. Or just far, far more worthwhile because there are many more useful x86 machines in the world.

[DiTBho]

You can't even migrate a disk with Linux installation from one SBC to another

if we talk about binaries, within the same processor family and endianness, the "rootfs" is rarely a problem unless compiled with implementation-specific stuff.

the real problems are
- firmware
- hypervisor
- kernel
- kernel modules (drivers)
- Device Tree (specifically, maps, and constraints)

look at the level of hardware standardization in ARM SOCs

Within each family people try to be as consistent as possible ... then, yeah, we have companies like Allwinner ... who do not even really contribute to GNU/Linux and/or U-boot and even at designing hardware make things all a mess up.

But whose fault is it?

Say, well, in Allwinner(1) it's not that they are so bright, and MediaTek(1) is a bit better but not that much, but for sure the Intel propaganda does not help here, even now telling people to buy Atom instead of ARM SBCs because it reduces the budget companies can allocate to better design and develop their products.

(1) I know these two well because I have worked with several of their SBC products.

[DiTBho]

Apparently less annoying than doing it for ARM SBCs

oh, yeah, it's really less annoying than doing it for ARM SBCs!!! In fact, it took me 1/4 of the hours to fix the Neo  (ARM) SBC, get my hands on both the kernel and u-boot, and work on less trivial stuff than the number of hours I spent on the AMD/Geode of the Soekris router to make a simple bootloader, having then to modify the Linux kernel to directly boot in protect-mode, as the default bZimage requires to be booted in real-mode, which. due to the 8086-platform constraints, is all a mess as you have to move things within the first 1Mbyte, plus a lot of nonsense things to handle BIOS incompatibility, all of this in assembly, and with a space constraint!

Really WOW!

Nah, let me say, it's okay for you to take, "turnkey" (ready out of the box), things that have already been done by the devs (this happens because x86 is mainstream due to its popularity), if you had to get your hands on it (which usually happens for industrial applications) ... you wouldn't be so happy to work with Intel/Amd.

First, because you have to read and study a thousand pages, even for simple things.
Second, because it is really difficult to give an estimate of the deadline both to the customers and to oneself for the calculation of the hours, and therefore we often end up "working practically for free".

And good luck debugging layers of layers of layers of compatibility things 

[SiliconWizard]

I'm afraid I (as most of us) would tend to focus on details while missing out on the big picture.

And precisely you focus on details while missing out on the big picture:

Uh? I didn't see this coming.
Humility is probably not one of your strong points.

I am just saying -1- do not buy x86 only because it's the most popular when you can buy something else, and -2- inform yourself before pointing the finger only at the most popular solutions!

That's a very general statement that can be said for almost anything. And it does look sad in a way. Now I'm guessing you're addressing this to the world in general - you can't hold that against me as I've been repeatedly talking about alternatives for various different topics rather than always going for what's trendy and what everybody else uses just because it's popular.

That said, what I've been trying here is to say that there is usually a reason why such decisions are taken, and you are refusing to understand those reasons. And the reasons are not just all because everyone is a stupid moron. It's a bit more complicated than this. If you had just said what you said right above, I don't think your thread would have triggered the reactions it did.

I've refered you (and anyone interested) to a book that talks about it in details and that I find pretty interesting. Basically again, innovation can't really happen in a large established corporation. Pretty much all people that had good ideas that turned out to be great innovations made them happen after quitting their job and starting their own company, or joining a small one. Just the way it works.

Understanding and even accepting a situation doesn't mean that you have to agree with it. But just keep in mind - as you have probably noticed over the years - that fighting a reality, especially in the business world, comes at a cost.

As to:

Second, because it is really difficult to give an estimate of the deadline both to the customers and to oneself for the calculation of the hours, and therefore we often end up "working practically for free".

Yep, that is already true for software development in general. Estimation is a very hard thing to do right - many argue that it's impossible.
I feel the pain, but what you do in such a case is that 1/ either you refuse the project altogether (again if you can afford to) or 2/ you manage to get paid hourly (which the client may not want, in which case, the client will refuse and you're good), or 3/ you make your best estimate and multiply it by 2 or 3. Probably 3 or 4 in your case for anything x86 related.

As a general rule, computing systems can be more or less defined as a triangle (a bit like the concept of the project management triangle): hardware, low-level software, and application software.
One of the vertices always has to give in. It tends to turn around a bit over time, but in most cases, it's the low-level software side of things that has to be the adjustment variable (and thus has to suffer).
So as another example, while writing application software on Windows has always been rather easy with a good level of backward compatibility, writing device drivers for Windows is close to a nightmare. (I think it has become a bit easier, I think mainly because you can now write many drivers as just filter drivers. But I still wouldn't want to have to touch that ever again.)

Regarding ARM, the issues are different. Calling ARM rubbish as magic did was extreme, but he probably wanted to make it sound a bit trollesque (as he likes to) while mimicking your own bold assertions. Now the issues have more to do with fragmentation, which is precisely what you tend to get over time when you don't/can't favor compatibilty. You can't have it all.

In that regard, RISC-V with its heavily modular ISA runs the risk of ending up even more fragmented. While I fully support RISC-V, mostly in the sense that it's an open-source ISA and allows anyone to design their own CPU, royalty-free and with no potential licensing issues ever (which opens a world of new possibilities), I don't know how the fragmentation problem is going to get solved if it's to be used for general-purpose computing (unless it gets gobbled up by a big fish which will dictate a standard all on its own, which would not be good news.)

[Nominal Animal]

Just a note for everyone: precise communication in linear human languages is difficult.  Moreso, when it is not in ones native language.

In my opinion, this thread is veering too close to the 'analyzing the tone' or 'reading between the lines' domain, which is not really useful.

When I catch this happening to myself, I combat it by re-reading the entire thread as if it was by other people, in order of posting.  It is illuminating, and also gives 'distance' so one is less likely to mistakenly take things personally.

[DiTBho]

In my opinion, this thread is veering too close to the 'analyzing the tone' or 'reading between the lines' domain, which is not really useful.

probably yes, but I prefer to give up.

[ejeffrey]

I have migrated my FreeBSD router and NAS between multiple generations of x86 hardware

you could do this because there are layers and layers of compatibility software, just like I've already pointed out for Grub and Lilo that work at the cost of putting several orders of magnitude higher the number of lines of code that would be needed!

Which is annoying for devs and maintainers!

Apparently less annoying than doing it for ARM SBCs. Or just far, far more worthwhile because there are many more useful x86 machines in the world.

It's relatively little to do with x86 vs arm, it's the system standard.  It's "IBM PC compatible" vs nothing.  ARM system makers make basically no attempt to support any system level standard.  A new PC today can boot up using bios emulation and legacy devices that emulate the keyboard, display, and serial ports from the 80s.  Then it can use a combination of probing for well known devices, looking up ACPI tables, and PCIe enumeration to find all the relevant hardware settings it needs to operate.  ARM has none of that other than possible PCIe, but on chip peripherals connected via AXI do not support plug and play enumeration.  Even very common peripherals are often located at random addresses.  Every ARM os has to be customized for the particular hardware platform it's running on, with a custom device tree to tell the bootloader and OS where everything is.

So yes the PC standard is crufty with lots of layers but the alternative isn't a better designed platform with nicer APIs for system configuration , it's nothing.

The ARM approach is nice for fast booting of fixed configuration platforms and deterministic device naming.  It's super inconvenient for having a modular system that you can download an OS for and boot it up.

[james_s]

That said, what I've been trying here is to say that there is usually a reason why such decisions are taken, and you are refusing to understand those reasons. And the reasons are not just all because everyone is a stupid moron. It's a bit more complicated than this. If you had just said what you said right above, I don't think your thread would have triggered the reactions it did.

This is the main thing that has bothered me from the start here, I feel a need to defend a lot of really smart people that developed all these things way back in the early days of the PC revolution, people that are being called morons that are not here to defend themselves or explain why they did things the way they did, and even if they were here, I strongly suspect the OP would simply ignore everything they said and continue to argue from a point of having 40 years of hindsight. It's one of those "debates" where the person doesn't actually want to debate, they have started with a conclusion, cherry picked only tidbits that support their conclusion, ignored everything else and then argue that everyone back then was stupid and they would have had the foresight to do better.

[james_s]

So yes the PC standard is crufty with lots of layers but the alternative isn't a better designed platform with nicer APIs for system configuration , it's nothing.

The ARM approach is nice for fast booting of fixed configuration platforms and deterministic device naming.  It's super inconvenient for having a modular system that you can download an OS for and boot it up.

Yes just look at the Raspberry Pi situation for example. The supply chain issues continues to make those virtually impossible to get, there are a handful of potential alternatives but none of them are compatible, I can't just take the OS build for my home automation system for example and pop it in some other arm SBC and expect it to boot up and work. On the other hand if Lenovo is sold out everywhere I can buy Dell, HP, or any number of other makes, install Windows or Linux and off I go. They're standardized and more or less interchangeable. There's huge value in that.

The cruft in the PC standard just doesn't matter in most cases, it's only a pain for a very small handful of people doing specialized low level work, for everyone else it is essentially zero cost, it's buried behind the walls, they never see it, there's no reason for them to care what it looks like.

[ejeffrey]

Also, a few people have, from time to time, made systems with x86 processors but most of the IBM PC "cruft" removed.  Among the most notable were the SGI Visual Workstations.  I don't think there is any world in which extremely expensive SGI branded workstations with x86 CPUs and running Windows were going to be a commercial success, but they also had the distinct problem that they could only run a specific modified versions of Windows NT.  Once booted it looked mostly like a regular PC at least from the application level, but you couldn't just boot a standard OS that worked on every other x86 system out there.

[james_s]

The SGI and Sun workstations were incredibly cool machines, I used to have a SGI Indy and an Indigo, and I still have several Sun workstations. The engineering that went into those is incredible and at the time they were very powerful, but even if they had not been vastly more expensive than IBM compatible PCs they never would have succeeded in the broader PC market because they were not compatible with the commodity software that most people used. They were specialized systems for specialized uses.

[David Hess]

It's relatively little to do with x86 vs arm, it's the system standard.  It's "IBM PC compatible" vs nothing.  ARM system makers make basically no attempt to support any system level standard.  A new PC today can boot up using bios emulation and legacy devices that emulate the keyboard, display, and serial ports from the 80s.  Then it can use a combination of probing for well known devices, looking up ACPI tables, and PCIe enumeration to find all the relevant hardware settings it needs to operate.  ARM has none of that other than possible PCIe, but on chip peripherals connected via AXI do not support plug and play enumeration.  Even very common peripherals are often located at random addresses.  Every ARM os has to be customized for the particular hardware platform it's running on, with a custom device tree to tell the bootloader and OS where everything is.

So yes the PC standard is crufty with lots of layers but the alternative isn't a better designed platform with nicer APIs for system configuration , it's nothing.

The ARM approach is nice for fast booting of fixed configuration platforms and deterministic device naming.  It's super inconvenient for having a modular system that you can download an OS for and boot it up.

Linus Torvalds has made that point before.  ARM lacks a standard for enumeration so each system requires a customized OS.  Well, there *is* a standard for ARM, but nobody implements it.

Note that nothing prevents fast booting with enumeration, and some x86 PCs support this, however there are fixed minimum timeouts on some legacy devices, for instance hard drives which must spin up, which cannot be shortened.

[james_s]

Note that nothing prevents fast booting with enumeration, and some x86 PCs support this, however there are fixed minimum timeouts on some legacy devices, for instance hard drives which must spin up, which cannot be shortened.

I see no reason these delays couldn't be bypassed if no legacy hard drives are found to be present though. Even a lot of older legacy systems that are still in service have been upgraded with modern SSDs.

[David Hess]

Note that nothing prevents fast booting with enumeration, and some x86 PCs support this, however there are fixed minimum timeouts on some legacy devices, for instance hard drives which must spin up, which cannot be shortened.

I see no reason these delays couldn't be bypassed if no legacy hard drives are found to be present though. Even a lot of older legacy systems that are still in service have been upgraded with modern SSDs.

Some commercial and consumer grade BIOSes, and many embedded x86 BIOSes, support exactly that.  For example Coreboot:

- Extremely fast
   - coreboot is designed to do the minimum amount necessary and get out of the way.
   - Especially for servers, coreboot provides faster boot up.
   - Desktop and Notebooks boot up in 400ms - 2.5s.
   - Server boot time can be as low as a quarter of the OEM BIOS boot time.

Thinking about it now, my relatively recent laptop does BIOS POST, BIOS enumeration, and starts and finishes booting Windows before my desktops even get through part of their BIOS POST and enumeration.  My laptop even gets to its Windows login prompt before my Android phone gets to its security login.  I think recovering from standby mode on my laptop might actually take longer, although then there is more startup stuff after logging in to complete.

[james_s]

There are cases where faster booting can be nice, but in practice I don't really care how long any of my devices take to boot, I boot them very rarely and normally just let them go to sleep. No matter how fast they boot it takes me much longer to get everything I was working with opened back up.

[Bruno_PT]

Apple competes with various system makers, but they do not compete directly with Intel or AMD.

Talking about data centers and scientific simulators, the fastest supercomputers today are built using Arm and POWER9, not x86 chips, why? well, have you seen the last Intel and AMD CPUs?


(Intel Xeon Platinum 8468)

Sure, they are able to outperform the chips made by Apple, Ampere, and NVidia, but only at the cost of insane power usage!
When you have a 20Kwatt cabinet it makes a BIG difference!

Lets check the top 500 then to see if that is actually true:
from www.top500.org/statistics/list/
x86 - 88% of the share
ARM - 1.6% (FUJITSU A64FX)
POWER9 - 1.4%

The Green 500 is equally dominated by x86, because even if intel isn't doing so good, Amd is doing a fenomenal work in the server space.

[DiTBho]

The Green 500 is equally dominated by x86, because even if intel isn't doing so good, Amd is doing a fenomenal work in the server space.

well, I just visited a couple of studios where they do professional video editing, and guess what they told me?
They replaced all thier x86/64 and AMD computers with "mac-mini studio", so M2 Pro chip, because

• Premiere on x86/64 is good, but Premiere on Apple Silicon is not optimized
• DaVinci is optimized (software-performance side) on both platforms, however on x86 machines it consume (electricity-performance side) 6 times the electricity of an M2 [/b]to produce the same results[/b]

Ampera is doing a fenomenal work, however, when you look at their budget, well ... Apple' shares are no longer worth a few pennies per share, they are worth hundreds of dollars, so much so that Apple is one of the companies with the most capital in the world, which can invest in research and development.

POWER is partly financed by DARPA and partly supported by the IBM business, which however makes more money with mainframes, and therefore not many financial resources are allocated. Something, but not enough compared to Apple, Intel and AMD.

And Ampera, in comparison, is a very small island with very little capital. Always compared to Apple, Intel, AMD, and IBM.

So, the only big competitor to intel/Amd x86/64 is Apple Silicon, and what do I think frankly?
Well, some companies still buy x86/64 only for a matter of contracts and ties to software that is x86/64-only.

Personally, if I had to pay myself the electricity bill out of my own pocket, and could run my pleasure GNU/Linux, rather than BSD/freebsd, and could recompile the programs myself (as I do with Gentoo, so ... no bin-blobs in none of packages), then I certainly wouldn't find spending money on smart way 6 times as much electricity to have x86 server in the computer room.

oh, then I have to say that, in my opinion, it's strange that Adobe didn't want to optimize Premiere for Apple Silicon, and this makes me think that they did it, in agreement with Intel/AMD, just as a "backroom deal" to try to sell more x86/64 chips.

I think this because DaVinci is open source software and it didn't take them long to optimize it. There are no technical problems when migrating sources from Windows10 to { MacOS, Linux }

Adobe didn't do it because they didn't want to do it! And for this reason, there are people who still buy some x86 machines, since Premiere on Apple Silicon sucks a lot, indeed people use FinalCut when it's possible!