OSDev.org

Well, Intel is by far much worse than AMD. They provide a LFB emulation that sucks and they fail to support wide-screen resolutions in both BIOS and UEFI. They didn't want to do a decent 64-bit extension so AMD had to do it for them. They released Itanium with the purpose of killing-off x86 with emulation.

xeyes wrote:About two decades ago AMD saved x86 from a similar move by Intel.
Remember the "let's emulate 32bit and move to the awesome 64bit Itanium (under the table: let's then drop the emulation to force a pure 64bit world)" days?

That's a flat-out myth; I'll admit that I used to think this was true, too, but I've since learned what really happened. The x86 emulation was a sop to Microsoft, and was never intended to be a major selling point (since they expected - and got - the relevant software ported natively).

Itanium was never intended as an x86 replacement, being aimed at a completely different market (HPC servers, primarily running Unix - though in the end it was mostly Linux) with no real overlap with the desktop market. Its been a modestly successful product in its niche and lasted all the way up to the present (only scheduled to be phased out this year). If it failed, it failed because HPC servers weren't a big market in the first place.

The biggest problem it had was not portability or emulation, but the complexity of the compiler needed to generate efficient code; and even then, that problem had been solved (by Intel, Microsoft, and GNU) well before the Itanium systems were actually available for sale.

The 'Legend of the Itanic' was purely the creation of people who didn't know what Itanium was all about. It's as if someone derided a John Deere harvester as being bad as a sports car.

While it is true that Intel has looking to replace x86 practically from the time it was designed (and as I have said before, never wanted to be in the consumer market, period), Itanium had nothing to do with that.

Schol-R-LEA wrote: That's a flat-out myth; I'll admit that I used to think this was true, too, but I've since learned what really happened. The x86 emulation was a sop to Microsoft, and was never intended to be a major selling point (since they expected - and got - the relevant software ported natively).

As far as I remembered their (Intels) marketing drive related to Itanium it was intended to replace x86 in the high end market. That's also why Intel never extended x86 to 64-bit. They already had Itanium, and so supporting another 64-bit environment on x86 that didn't emulate x86 would be to kill-off their own 64-bit Itanium environment. Another factor was that Intel had patented Itanium heavily so nobody could copy it, and therefore they hoped it would take over the market so they would not need to compete with AMD and other x86 manifacturers. And so AMD had to do the 64-bit environment for x86 for them (and did it pretty badly too).

rdos wrote:

Schol-R-LEA wrote: That's a flat-out myth; I'll admit that I used to think this was true, too, but I've since learned what really happened. The x86 emulation was a sop to Microsoft, and was never intended to be a major selling point (since they expected - and got - the relevant software ported natively).

As far as I remembered their (Intels) marketing drive related to Itanium it was intended to replace x86 in the high end market. That's also why Intel never extended x86 to 64-bit. They already had Itanium, and so supporting another 64-bit environment on x86 that didn't emulate x86 would be to kill-off their own 64-bit Itanium environment. Another factor was that Intel had patented Itanium heavily so nobody could copy it, and therefore they hoped it would take over the market so they would not need to compete with AMD and other x86 manifacturers. And so AMD had to do the 64-bit environment for x86 for them (and did it pretty badly too).

While that was what a lot of reports at the time said - mainly those from The Register - it wasn't actually the case. If anything, they were hoping to artificially keep their HPC and enterprise products separate from their consumer products. They saw (and still do, AFAICT) the consumer and business markets as inherently less valuable than the high-end markets, which has fewer hassles (== fewer individual customers and less variation in installations) and slightly better margins.

It has to be remembered that both high-end and consumer products are mostly 'prestige' markets for both Intel and AMD; their bread and butter is selling 30-year-old microcontroller designs for the appliance and embedded markets. Selling CPUs for PCs - often at a loss, for their highest-end models - is more about their stock valuation than it is about their bottom line.

(Part of this too is related to the concept of bikeshedding; most investors know more about PCs than they do about MCUs, so they focus on that part of the business even though it is only a small and low-margin part of the company's operations.)

If the PC market were to vanish tomorrow, Intel's stock would tank, but their income would, if anything, improve. They stay in that business because stock valuation is far more important to a modern corporation than sales figures.

I think most of that is an after-construction. It was Intel themselves that marketed Itanium as "high-end". We all know that today's high-end is tomorrow's mainstream. No doubt, Microsoft also had a stake in it. They wanted to dominate the PC market, and the Itanium platform offered them a possibility to get rid of OS/2 and get Windows & Office to take over the PC market. With new compilers and tools they got a head start, and all the old PC hardware could still run, but very slowly due to emulation. They succeeded to make Windows take over the PC market, but not on Itanium.

rdos wrote:I think most of that is an after-construction. It was Intel themselves that marketed Itanium as "high-end". We all know that today's high-end is tomorrow's mainstream.

That's only true if there's a path upward, and Intel's whole goal seems to have been to prevent there from being one. My impression is that they wanted 'high-end' to mean 'hands off of this, you PC peons!'. Still, you may be right, and I am willing to let this drop.

Schol-R-LEA wrote:

xeyes wrote:About two decades ago AMD saved x86 from a similar move by Intel.
Remember the "let's emulate 32bit and move to the awesome 64bit Itanium (under the table: let's then drop the emulation to force a pure 64bit world)" days?

That's a flat-out myth; I'll admit that I used to think this was true, too, but I've since learned what really happened. The x86 emulation was a sop to Microsoft, and was never intended to be a major selling point (since they expected - and got - the relevant software ported natively).

Itanium was never intended as an x86 replacement, being aimed at a completely different market (HPC servers, primarily running Unix - though in the end it was mostly Linux) with no real overlap with the desktop market. Its been a modestly successful product in its niche and lasted all the way up to the present (only scheduled to be phased out this year). If it failed, it failed because HPC servers weren't a big market in the first place.

The biggest problem it had was not portability or emulation, but the complexity of the compiler needed to generate efficient code; and even then, that problem had been solved (by Intel, Microsoft, and GNU) well before the Itanium systems were actually available for sale.

The 'Legend of the Itanic' was purely the creation of people who didn't know what Itanium was all about. It's as if someone derided a John Deere harvester as being bad as a sports car.

While it is true that Intel has looking to replace x86 practically from the time it was designed (and as I have said before, never wanted to be in the consumer market, period), Itanium had nothing to do with that.

Sounds like you might be an insider or have some insider friends who worked for HP or Intel on the project back then? In order to write off mainstream understanding of the matter as a "myth".

What's your take on why the world moved on and forced Intel to implement AMD64 arch if any Itanium issues are either non-issues or solved-before-actually-available-for-sale issues? Assuming that you are not bound by NDA to not talk about related matters.

I was working for a video hardware company at the time of Itanium and what I remember is that it was meant to be used for servers / backend / high-CPU loads. It wasn't meant to replace the ia32 in consumer hardware (i.e. the plan wasn't to put the Itanium in PCs or create a new type of PC).

From what I can remember, Intel didn't see a market for a 64-bits CPU in consumer PCs and wasn't trying to replace the ia32 with it. This was in retrospect a total lack of vision.

AMD came up with AMD64 because they believed that there was a place for a 64-bit CPU in the consumer space. They were also looking for ways to compete and beat Intel in the consumer space. History has proven them right. Contrary to some comments I've read above, I think they did an excellent if not amazing job with AMD64. They removed some useless opcodes to add new ones, kept things mostly the same and increased the number of registers, something that was very much necessary but impossible to do on ia32 because of backward compatibility concerns.

Their success with AMD64 was immediate and Intel had no choice but to follow and implement long mode. Otherwise they would have been kicked out of the consumer market entirely.

So based on what I remember of discussions between my coworkers, company and Microsoft at the time, Intel never intended the Itanium to replace the ia32. The Itanium was a new thing meant to be used for specialized applications like backend infrastructure or high-end workstations.

kzinti wrote:I was working for a video hardware company at the time of Itanium and what I remember is that it was meant to be used for servers / backend / high-CPU loads. It wasn't meant to replace the ia32 in consumer hardware (i.e. the plan wasn't to put the Itanium in PCs or create a new type of PC).

From what I can remember, Intel didn't see a market for a 64-bits CPU in consumer PCs and wasn't trying to replace the ia32 with it. This was in retrospect a total lack of vision.

I don't believe in the idea that a huge giant like Intel didn't anticipate that 64-bit would sooner or later become mainstream. They have very long road-maps far into the future, and of course, they weigh these issues into these. However, given the plan to get rid of x86 competitors that Intel had with their Itanium design, I'm sure they didn't want to be too clear about what their strategy was. So, apparent lack of vision actually fits into the picture.

kzinti wrote: AMD came up with AMD64 because they believed that there was a place for a 64-bit CPU in the consumer space. They were also looking for ways to compete and beat Intel in the consumer space. History has proven them right. Contrary to some comments I've read above, I think they did an excellent if not amazing job with AMD64. They removed some useless opcodes to add new ones, kept things mostly the same and increased the number of registers, something that was very much necessary but impossible to do on ia32 because of backward compatibility concerns.

More like they understood Intel's strategy and wanted to stay on the x86 market, something they would not have achieved if 64-bit went the Itanium way (since it was heavily patented), and so they had to design the 64-bit standard themselves to stay on the PC market.

This makes sense to me. Thanks for your insights.

kzinti wrote:Using UEFI to boot your OS is no more difficult than using the BIOS.

kzinti wrote:Imagine that... using a different firmware requires you to use a different APi. Who would have thought?

You said that it's no more difficult. In reality it is, that's what I've exampled, UEFI interface is a lot more complex. By a lot.
You argument that it's "no more difficult" does not stand with the interface.

kzinti wrote:Who cares where you bootloader is loaded in memory? It doesn't matter.

It does, because using a fixed address with a statically linked kernel is a hell lot easier than to detect dynamic addresses and apply relocations for a PIC linked kernel.
You argument that it's "no more difficult" does not stand with the memory layout either.

kzinti wrote:But when I want to update my bootloader I just copy the file where i want it on the partition and it works just fine.

You silently forget about the fact that you have to a) mount that partition b) have a file system driver for it in order to copy files to it. Under Windows, which does not support mounting disk image files this is quite problematic (you need 3rd party tools in your toolchain to come around). And if you're creating an image file yourself programmatically, then it's a lot simpler to do memcpy(buff, mbr, 512) than to generate GPT with all the CRCs and a FAT partition with files into the image.
You argument that it's "no more difficult" does not stand with the disk layout either.

kzinti wrote:That is not my experience. The UEFI memory map looks very much like the BIOS one.

Not by far. BIOS memmap usually has no more than 10-12 records. By the time your BOOTX64.EFI gets called, any UEFI memmap would have at least 40-50 records, but in my tests there were usually more than 100 records.

kzinti wrote:something that doesn't even exist with the BIOS.

And doesn't even needed. All the BIOS bootloaders are pretty fine without dynamic memory allocations, in fact, it's easier to arrange the memory when they know the layout is standard on all machines and firmware won't interfere for sure. With UEFI memmap, you can't be sure of anything (except that it won't run with less than 64M of RAM), you must parse the memmap and make no assumptions.

kzinti wrote:Sounds like all your complaints are about UEFI not being BIOS or POSIX.

Not by far. I have absolutely no clue what makes you think that (if you are serious and aren't just trolling). I don't like UEFI because it is a particularly badly designed, resource wasting firmware with a very bad and unuseful interface that your kernel can't rely on, which in turn might lock out hobby OS developers and alternative OS users (read: non Windows OSes) pretty easily. I can't be more straightforward than that.

xeyes wrote:Wow that's a nice wiki page done in such short period of time, thanks!

You're welcome! It was long overdue, and it might be useful to many other members too!

Cheers,
bzt

bzt wrote:It does, because using a fixed address with a statically linked kernel is a hell lot easier than to detect dynamic addresses and apply relocations for a PIC linked kernel.
You argument that it's "no more difficult" does not stand with the memory layout either.

I have no problem with this. I load the kernel at a virtual address, not a physical. The loader also doesn't need relocation (it sets up selectors).

bzt wrote:You silently forget about the fact that you have to a) mount that partition b) have a file system driver for it in order to copy files to it. Under Windows, which does not support mounting disk image files this is quite problematic (you need 3rd party tools in your toolchain to come around). And if you're creating an image file yourself programmatically, then it's a lot simpler to do memcpy(buff, mbr, 512) than to generate GPT with all the CRCs and a FAT partition with files into the image.
You argument that it's "no more difficult" does not stand with the disk layout either.

GPT is ok. MBR is a lot worse will all links, cylinders & heads, and incompatible ways of setting them up. GPT also allows more than 4G sectors.

bzt wrote:And doesn't even needed. All the BIOS bootloaders are pretty fine without dynamic memory allocations, in fact, it's easier to arrange the memory when they know the layout is standard on all machines and firmware won't interfere for sure. With UEFI memmap, you can't be sure of anything (except that it won't run with less than 64M of RAM), you must parse the memmap and make no assumptions.

Agreed. This is really bad. I count on certain adresses (0x110000 and up) to always be free, and if they are not, booting will fail.

rdos wrote:I have no problem with this. I load the kernel at a virtual address, not a physical. The loader also doesn't need relocation (it sets up selectors).

I also load my kernel at the VMA I want. Not sure why bzt keeps insisting you can't do it when people are doing it. I think he is talking about loading the kernel directly from UEFI which is not the way to go here... You want UEFI to load a bootloader that will in turn load your kernel where you want it. This is another example where instead of using UEFI as it is meant to be used, he insist on emulating how he it could/would work under BIOS. Then he complains that it is more complicated when he is the one making it more complicated.

bzt wrote:You silently forget about the fact that you have to a) mount that partition b) have a file system driver for it in order to copy files to it. Under Windows, which does not support mounting disk image files this is quite problematic (you need 3rd party tools in your toolchain to come around). And if you're creating an image file yourself programmatically, then it's a lot simpler to do memcpy(buff, mbr, 512) than to generate GPT with all the CRCs and a FAT partition with files into the image.
You argument that it's "no more difficult" does not stand with the disk layout either.

You are completely wrong here on almost every account here. It is not hard to mount a hard drive or partition. It's not even hard to mount a disk image. It do all this in 3 lines in my makefile and/or I can just right click the image and select "mount" and manually copy the files in the image. I didn't have t install any driver and never had to manually generate GPT, CRCs or FAT partitions. Just use existing tools instead of trying to reinvent the wheel.

kzinti wrote:Not sure why bzt keeps insisting you can't do it

Erm, where did I said that, exactly? Never said you can't do it, I do it like that too. Setting up paging is a lot more difficult than having to do nothing. Your argument that it's "no more difficult" does not stand with VMM either. (And before you ask, yes, setting up paging for long mode is a lot more difficult with UEFI than with BIOS, because with BIOS you can use whatever mapping you want, while with UEFI you must make sure of that the dynamically allocated areas are mapped properly in your new paging table, otherwise your loader will crash.)

kzinti wrote:You are completely wrong here on almost every account here. It is not hard to mount a hard drive or partition.

Explain, how am I wrong here? Mounting IS needed, file system driver is needed, and it ain't portable, and it is pretty hard if your OS does not support it natively. But my toolchain for example doesn't rely on the OS mount at all, I generate the disk image programmatically for portability reasons, so yes, I know exactly what I'm talking about. (Fact: my image creator works on MacOS, Windows, Linux and BSDs as well. Does your Makefile too?)

Cheers,
bzt

bzt wrote:Erm, where did I said that, exactly? Never said you can't do it,

Fair enough, you didn't say that explicitly. But you did say this:

bzt wrote:It does, because using a fixed address with a statically linked kernel is a hell lot easier than to detect dynamic addresses and apply relocations for a PIC linked kernel.

Which I took as you implying that you can't load your kernel at the address you want (which is not true). There is also no need to handle relocations or even have a PIC linked kernel. Mine is currently statically linked at a fixed address and I can load it just fine. No rellocations. I understand where your statement comes from, and it is misleading. It is only true if you have UEFI directly load your kernel, which I argue you shouldn't be doing in the first place.

bzt wrote:(And before you ask, yes, setting up paging for long mode is a lot more difficult with UEFI than with BIOS, because with BIOS you can use whatever mapping you want, while with UEFI you must make sure of that the dynamically allocated areas are mapped properly in your new paging table, otherwise your loader will crash.)

Mmm no it's exactly the same. It is so much the same that I use the same code for both my BIOS and my UEFI bootloader to setup long mode with paging. UEFi starts with everything identity-mapped. So it's logically the same as not having paging enabled. With BIOS, you also have to make sure you properly map your bootloader before you enable paging. In both cases, you can just identity map most of the memory (except the kernel itself, which you map where you want it). In practice, it's the same thing.

bzt wrote:my toolchain for example doesn't rely on the OS mount at all, I generate the disk image programmatically for portability reasons, so yes, I know exactly what I'm talking about.

You decided you wanted to generate your disk image programmatically and more power to you. But this doesn't make UEFI itself as complicated as you make it out to be. Like I said, reinventing the wheel. Whatever floats your boat.

I am out, I think we've covered the subject.