IT... Computing....

[Reese Riverson]

Yeah, that's pretty much what makes the Intel fiasco pretty outrageous, more so with the shady bullshittery they're doing.

 

[Steo]

It was totally outrageous, from a multi-billion dollar company at least. Refusing to give straight answers to questions, flat out ignoring some questions, sneakily editing things on their own site, and posting things publicly that were supposed to be answers to people's questions, which were clearly just done to try paint themselves in good light. This scenario was more than outrageous, it was flat out ridiculous!

They had also just simply tried to blame shift for a long time. They even went ahead and started trying to blame the motherboards, and stating all kinds of nonsensical "default" settings, which aren't even a thing. While doing so, they covered all bases in their wording, like trying to say there was a certain classification of settings that was only recommended for "compatibility", while it really doesn't make any sense. They had even been pushing microcode updates all along, as if they were trying to fix this all silently, but couldn't. Then they were trying to say that this has been an issue since 2023, "unrelated to the oxidation issue". Then later, it suddenly was an issue since 2022, and the oxidation issue "only affects a small number of products".

Original:

Sneaky edit:

Complete bullcrap, from a company who should honestly have much higher standards than to actually go blame shifting and flat out trying to sweep the issue under the rug. Then on top of all that, they are raising one of their CEO's salary's by over 5 million per year, while laying off around 10,000 employees in the process. Sounds like a very nice company to work for.

I guess there are several "outrageous" things going on here, from a company who really should have higher standards given their revenue. I was never an Intel or AMD fanboy so to speak, but I'm very happy to be an AMD user ever since Ryzen 3000 launched. I'm even more glad, when I see things like this from AMD, in comparison to the nonsense Intel have been spewing out:

I think I know that when things like this happen, consumers shouldn't have to be penalised because of multi-billion dollar companies lying and trying to sweep issues under the rug, just to try save their name while they fucked up and won't just admit there's a problem, and that they don't exactly know how to solve it. Then also just recall all the faulty CPUs instead of trying to pretend that software is going to fix something where it's very clearly a hardware issue, regardless as to whether it was caused by software originally or not; it's a hardware issue.

I'm really glad that AMD just flat out admitted something wasn't right, and that they will fix it, instead of going down the same road. It's shameful that Intel have handled this entire thing for several reasons, and I don't even feel like I would be able to trust them to ever switch back to them any time in the near future after seeing it all unfold.

 

[dr_st]

Well, the new microcode for Intel Raptor Lake CPUs is out. It supposedly tweaked the 'Intel Default' voltages to be safe. However, time will tell. Things are complicated by the fact that there are tons of performance/voltage/power related settings on modern CPUs, and the motherboard vendors have a lot of room to play. So if the "Intel default settings" affect some parameters, but there are a bunch of others that are not controlled by those, but rather by the motherboard BIOS, a lot of things can go wrong still. I've seen some videos and read some threads on the topic.

Anyhow, the latest BIOS update for my motherboard with the new microcode has been installed, and I will run some stability tests when I get around to it.

 

[LoveMetal]

We should keep it mind that Intel -and AMD for what it's worth- is trying to avoid those issues at all costs, as they're dramatic for the company: compensation costs, loss of customer trust, drop in sales, and drop of stock valuation. In my opinion, it's to mitigate the latter that they try some shady PR moves and try to fix stuff under the hood, which, don't get me wrong, is bad for everyone including them. That's just plain bad leadership.

Now, I'm pretty sure Intel spends millions of hours of quality assurance through multiple stages of testing for every new release. Yet, it's surprising how such blatant issues can arise.

I'd like to have some opinions on that. Take ARM-based processors for instance. Those dominate the mobile market and start gaining some traction in servers. For them, such severe issues never reached my ears. Is it the result of their simpler architecture? Or just a better design stage?

 

[PluMGMK]

From what I've heard, the complexity and inefficiency in designing a modern x86 processor comes from the variable-length instructions, which mean the decoder can't process multiple instructions in parallel, without fully understanding each one to find out where the next one is. Not being an expert in microprocessor design, I imagine this represents a disadvantage in the maximum achievable power efficiency. Could working to overcome this lead to these types of issues? I'm not so sure…

Taking each one specifically:
The AMD SMRAM issue comes from a feature that existed for backwards compatibility. So yes, something without x86's baggage wouldn't have had this specific issue.
Microcode setting wrong voltages could happen with any modern architecture, but maybe making such power-hungry chips makes these mistakes more likely? Difficult to tell really… It'd be interesting to be a fly on the wall at the relevant blamestorming sessions at Intel
Via oxidation is a fab issue, so I doubt there's any connection to the design or architecture of the chip. It's just things continuing to go wrong at Intel's fabs…

 

[LoveMetal]

That’s good insights. So that definitely sound like Intel own’s problems. Indeed, being a fly on the wall during their war room meetings would be a lot of fun!

From what I've heard, the complexity and inefficiency in designing a modern x86 processor comes from the variable-length instructions, which mean the decoder can't process multiple instructions in parallel, without fully understanding each one to find out where the next one is.

Can’t we juste create an executable format where we pad every instruction with 0x90 so they’re all of equal length, then tell the decoder about this? A single word from you and I’m patenting the shit out of this.

 

[PluMGMK]

From what I've heard, the complexity and inefficiency in designing a modern x86 processor comes from the variable-length instructions, which mean the decoder can't process multiple instructions in parallel, without fully understanding each one to find out where the next one is.

Can’t we juste create an executable format where we pad every instruction with 0x90 so they’re all of equal length, then tell the decoder about this? A single word from you and I’m patenting the shit out of this.

Well, on newer processors, you don't even need to spam 0x90, as there are several multi-byte NOP instructions available: https://stackoverflow.com/questions...-commonly-understood-macros-or-other-notation

That said, good luck patenting something you've just pseudonymously disclosed on a public forum accessible to virtually any human with a web browser

 

[Reese Riverson]

Seems NVIDIA's shenanigans never stops:

Also:

I really hate Intel's naming scheme, I swear it just keeps getting worse and worse.

And a mini rant is how I miss EVGA still, my 3090 Ti AIO model is great, I just would be hard pressed to find anything else whenever I do need to upgrade again.

 

[dr_st]

On the topic of nVidia's naming scheme...

Back when I was building a PC for my parents, I wanted to equip it with a basic GPU so that at least casual 3D gaming can be done on it, if anyone needs it. So I took a GT 1030. Fortunately I read enough before finalizing the build - to learn that there were two different flavors - a GDDR5 version, and a DDR4 version, which cost maybe 10% less, but suffered 50% lower performance, and the cards were named the same! You really had to read the fine print to make sure you are not getting "scammed".

Reminded me of the 64-bit vs 128-bit buses on some identically named GPUs 15-20 years ago, with the same effect on performance.

 

[LoveMetal]

Isn't that up to the card manufacturers rather than Nvidia?

 

[Steo]

I still think it's interesting that CPU architecture was named after the instruction set, so that x86 = 32-bit, while x64 = 64-bit.

I wonder how many people would think that x86 > x64 due to the higher number.

 

[Master]

If memory serves x86 came from the fact that the ISA had come from the Intel 8086 right? (Also if memory serves I think that was a 16-bit CPU as well)

I suppose for convenience they ended up keeping that naming scheme, but I've always taken x64 to be shorthand for the "x86-64" title, as it's the 64-bit variant of the original x86 ISA.

At any rate it's kinda confusing when you start thinking about the various extensions and derivatives between both Intel and AMDs implementations of ISAs, they might support the same extensions, but not necessarily all of the same instructions, and the way they process and execute instructions, even if the results are the same, might still differ.

 

[Steo]

I suppose it's true that it's just short for "x86-64", but I wonder if the shorter version ever confused anyone who wasn't aware, where higher number = more. I believe it was named after 8086 also as you've mentioned, but I didn't even realise it dated so far back to be 16-bit. Seems in that case it would have technically been "x86-16", so that would mean what we were referring to as "x86" was really "x86-32". I could definitely see that becoming confusing in a way if anyone wasn't aware that we just refer to 32-bit as "x86":

x86-32 = x86
x86-64 = x64

 

[dr_st]

They do sometimes call x86 x32 (rare) or ia32. The latter is confusing because ia64 is a whole different architecture - not x86_64. And I've also seen nomenclatures like i386/i686.

 

[Steo]

I've seen i686 mentioned on Linux before yeah, and I remember Windows XP having the i386 folder on the disc. The fact that ia32 and ia64 are different though also makes things even more confusing in that sense. I also remember modding the Nintendo Switch a few years back and installing Arch on it just to try it out, and I recall things being very limited at the time, because it wouldn't have been able to run anything x86 or x64 based.

 

[Reese Riverson]

If memory serves x86 came from the fact that the ISA had come from the Intel 8086 right? (Also if memory serves I think that was a 16-bit CPU as well)

Yeah, I think 32-bit came around with the 386, if I remember correctly?

 

[Master]

Sounds about right, though I'll admit the minutae of old school CPUs isn't something I'm too well versed in, we were well in the Core 2 era by the time I had the beginnings of understanding of there being a 32/64 bit distinction between CPUs.

As for the topic of running x86 on ARM, I think I did briefly touch on it in the Phones thread but seeing as it's been lightly hinted at with the Steo's Switch, I do wonder if we're seeing the beginnings of it becoming mainstream, we've already seen Apple's transition to ARM for their desktop, and I know there's been an x86 to ARM layer in Windows for a while now. It'll be interesting to see if we do end up seeing lower powered PCs eschew traditional x86 CPUs in lieu of ARM ones. I have high hopes that it is feasible because I would love laptops and lower powered PCs that can run cooler.

 

[PluMGMK]

I suppose for convenience they ended up keeping that naming scheme, but I've always taken x64 to be shorthand for the "x86-64" title, as it's the 64-bit variant of the original x86 ISA.

Correctamundo!

If memory serves x86 came from the fact that the ISA had come from the Intel 8086 right? (Also if memory serves I think that was a 16-bit CPU as well)

Well, the 8086 (which like you said was 16-bit) was followed by the 80186, 80286, 80386 and 80486, and each one brought new features. When you're targetting some subset of those features, but it's not really relevant which, it's basically 80x86, as in, the middle digit doesn't matter. Then that's shortened to just x86!

Yeah, I think 32-bit came around with the 386, if I remember correctly?

Correctamundo, the i386 brought in 32-bit registers and addressing, and most importantly, paged virtual memory!

They do sometimes call x86 x32 (rare) or ia32. The latter is confusing because ia64 is a whole different architecture - not x86_64. And I've also seen nomenclatures like i386/i686.

Yup. IA-32 is Intel Architecture 32, which refers to the mainstream 32-bit architecture introduced with the 386. They were originally hoping that IA-64, the Itanium, would supersede it, since it included an x86 compatibility layer. But AMD outflanked them with their 64-bit extensions to x86, which gained way more mainstream acceptance, since they worked much better for most usecases.

Also, from what I've heard, x32 is a slightly different thing, at least in Linux-land. It refers to binaries compiled to use a 32-bit address space (and hence smaller pointers) while otherwise operating in 64-bit mode. So the code size is smaller, but it can still use the extra registers R8-R15 and do efficient 64-bit integer arithmetic.

I've seen i686 mentioned on Linux before yeah, and I remember Windows XP having the i386 folder on the disc.

So i386 refers to the baseline 32-bit architecture introduced by the 386 processor, which includes paged virtual memory, 32-bit addressing, etc. Then i486 and i586 are supersets of that using features introduced with the 486 and Pentium respectively.

Then i686 refers to the Pentium Pro, and it's a major milestone because it adds Physical Address Extension, which allows using up to 64 GiB of physical RAM (whereas i386 only allows 4 GiB). It is in fact a misconception that 32-bit OSes can only address 4 GiB of RAM: an i686-targetting OS can address up to 64 GiB! However, Microsoft disabled this extension on desktop Windows, to prevent PAE-unaware third-party drivers from crashing the system. So in practice only 32-bit Linux can address 64 GiB, not 32-bit Windows…

 

[dr_st]

However, Microsoft disabled this extension on desktop Windows, to prevent PAE-unaware third-party drivers from crashing the system. So in practice only 32-bit Linux can address 64 GiB, not 32-bit Windows…

Oh, I remember Geoff Chappell had a post or a series of posts on the subject. Turns out it was actually enabled pre-WinXP-SP1, and then they disabled it. Their excuse was that it's a stability guard against third-party PAE-unaware drivers as you say, and then Geoff discovered, that the only actual "offending" drivers are those coming from Microsoft itself.

According to Microsoft's own nomenclature, this was actually a matter of licensing. Because 32-bit editions of Windows Server builds (as long as they existed) have supported PAE and >4GB of RAM.

 

[PluMGMK]

Oh, I remember Geoff Chappell had a post or a series of posts on the subject. Turns out it was actually enabled pre-WinXP-SP1, and then they disabled it. Their excuse was that it's a stability guard against third-party PAE-unaware drivers as you say, and then Geoff discovered, that the only actual "offending" drivers are those coming from Microsoft itself.

According to Microsoft's own nomenclature, this was actually a matter of licensing. Because 32-bit editions of Windows Server builds (as long as they existed) have supported PAE and >4GB of RAM.

Ah, thanks for linking that, it's very insightful and interesting! Yes, I knew about the server builds, so it makes more sense that it's a "product grade" thing rather than about dodgy drivers, but I guessed they hoped people would believe that there are more faulty drivers at the consumer level (probably impossible to prove or disprove). I must say, after reading all that, it sounds a bit shadier than I had thought!

Another misconception that comes from a Microsoft restriction comes to mind: a lot of people think that x86 processors in 64-bit mode (i.e. Long Mode) can't run 16-bit code at all, which is false. A processor in Long Mode can run 64-bit, 32-bit and 16-bit code in segments of the appropriate type! What it cannot do is run code in Virtual-8086 mode, which is required for 16-bit code that expects to run in Real Mode, e.g. DOS and applications written for it. But Protected-Mode 16-bit code, e.g. Win16 applications, can run just fine under a 64-bit OS. This is easily verifiable by taking SOL.EXE from Windows 3.x or 9x and running it under Wine on 64-bit Linux (but unfortunately Wine is transitioning to a new architecture which will make this impossible, or perhaps already has on the newest versions ).

However, 64-bit Windows kernels don't provide any means to set up a 16-bit code segment, so it is impossible to run any kind of 16-bit code on 64-bit Windows. For Win16 apps, this isn't a hardware limitation, but a choice by the Windows kernel developers. Granted, it's an understandable choice, as AMD and Intel made supporting this quite a bit trickier than it needed to be. Linux has to do some ugly stuff to make it hang together. I'll just quote myself from another forum when I realized how messed up it was:

Oh man… Let me get this straight:

• Intel messed up the IRET instruction for returning from privileged 32-bit code to unprivileged 16-bit code in the i386, and nobody seemed to notice
• AMD messed it up in the same way in the Am386 (were they an official manufacturer of 386es at the time, and that's why they were bug-for-bug equivalent?)
• In the two decades that followed, even with all the microarchitecture updates / redesigns, this bug never got fixed by Intel or AMD
• As the years went by, people noticed there was funky stuff going on and started trying to work around it
• Eventually, when the 64-bit processors came out, it became abundantly clear what the bug was, and it took almost another decade to get a satisfactory workaround into Linux (whereas Microsoft said screw it)
• And this is just one of many such bugs that screwed up kernel functionality…

100% cursed indeed! I guess this is why people advocate for open-source hardware as well as software…

IIRC Intel are finally gonna fix this (for the few people who still care ) with FRED – but then they're gonna eliminate the ability to run 16-bit code altogether with X86S