Intel's New X86-S : Eliminating Technical Debt and Adopting FRED

Need POTATO merch? There's a chip for that! merch.techtechp...
One of the legacy elements of modern computing are the 16-bit and 32-bit modes of modern processors. With the new Intel X86-S document releases in mid-2023, there is now groundwork to remove this technical debt and adopt FRED.
Starring George Cozma from ChipsAndCheese.com !
-----------------------
more-moore.com : Sign up to the More Than Moore Newsletter
/ techtechpotato : Patreon gets you access to the TTP Discord server!
Follow Ian on Twitter at / iancutress
Follow TechTechPotato on Twitter at / techtechpotato
If you're in the market for something from Amazon, please use the following links. TTP may receive a commission if you purchase anything through these links.
Amazon USA : geni.us/Amazon...
Amazon UK : geni.us/Amazon...
Amazon CAN : geni.us/Amazon...
Amazon GER : geni.us/Amazon...
Amazon Other : geni.us/TTPAma...
Ending music: • An Jone - Night Run Away
-----------------------
Welcome to the TechTechPotato (c) Dr. Ian Cutress
Ramblings about things related to Technology from an analyst for More Than Moore
#techtechpotato #64bit #x86
------------
More Than Moore, as with other research and analyst firms, provides or has provided paid research, analysis, advising, or consulting to many high-tech companies in the industry, which may include advertising on TTP. The companies that fall under this banner include AMD, Armari, Facebook, IBM, Infineon, Intel, Lattice Semi, Linode, MediaTek, NordPass, ProteanTecs, Qualcomm, SiFive, Tenstorrent.

[@sundhaug92]

I take it some of these will even be multifreded

[@christophermullins7163]

Highly underrated

[@MrSamPhoenix]

Indeed lol

[@elirantuil5003]

You're a genius

[@NightRogue77]

Dude how is this not comment of the year lmao

[@MrSamPhoenix]

@@NightRogue77 indeed!

[@__aceofspades]

This is extremely technical, but a great step forward for Intel shedding no longer necessary legacy systems in favor for better modern ones. Stuff like this is exactly what Intel needs to be doing now.

[@macyler]

Chips and Cheese is one of my absolute favourite blogs. I don't know anyone else that goes into such depth and yet consistently posts interesting articles on the nitty-gritty of computer architecture. ❤

[@sellicott]

Fancy seeing you here :-)

[@macyler]

@@sellicott Never could have expected that :P

[@kevinm3751]

It really is not x86 "protected" mode, it is x86 emulation mode. This has been a long time coming and the justification for hanging on to 16bit and 32bit is absurd and has NOTHING to do with some abstract security justification. Anyone that knows better, knows that 64bit is by and far more secure than either of the other two! What this boils down to are some lazy companies that dont want to have to update their drivers to work in the 64bit space! For anyone wanting to know FRED stands for "Flexible Return and Event Delivery".

[@Psychx_]

Ring 1 and 2 being removed is kinda a bummer. Those have been used for novel virtualization approaches and making it more difficult to escape the VM. Xen fully depends on this, and by extension also QubesOS.

[@progenitor_amborella]

This brings some significant interest, hmm. I'm hoping to especially hear from the QubesOS team about this, as well as any security researchers!

[@pitust]

i doubt xen uses rings 1 and 2 given that they don't work (AT ALL) in 64bit mode

[@pitust]

like, they """work""" but you can't use them for everything. because they share pagetables with ring0 (so you cant do anything useful there), and segmentation is ignored in 64bit mode, because nobody cared about segmentation.

[@Daweim0]

Does Xen still depend on ring1? The only references I see to Xen and ring 1 are from ~2008ish when hardware virtualization was still very new

[@Hiryu666]

As someone who's been writing his own hobby kernel for fun since 2008... This sounds great. It was a shock to me that I still had had to jump through the ancient hurdles to build everything up. I had to write 16-bit assembly, I had to setup *SEGMENTING* (the GDT), etc. I knew that old stuff was still there... but I didn't know it was unavoidable as a step on the way to 32-bit protected mode. This will mainly be work for the grub developers... but I'm sure Intel would help there. I'll just keep using grub and make the changes I need to once the time comes. That being said, my little hobby project is still 32-bit... I have started thinking towards 64-bit support and have already been teaching myself x64 assembly.

[@ikjadoon]

This was great to learn more about, especially 16K pages. I hadn't realized Apple transitioned to 16K apparently completely on its Silicon desktops & laptops.

[@MarkBarrett]

To be clear, running a 32-bit program on a CPU with 64-bit lanes, would be easy. They are saying it is nearly only 16 or 64-bit native. They will need a new BIOS startup.

[@00wheelie00]

A problem the hobbyists have is VESA modesetting, which is much more complicated or even impossible in 64bit mode. So they will have to resort to complicated terribly documented , if documented at all, vendor specific GPU mode setting. If GPU makers would just publish how to reclock their gpu's and set up a simple unaccelerated double or triple buffered framebuffer in a readable document that would be a massive improvement.

[@Psychx_]

VESA modesetting isn't needed anymore. UEFI GOP is the replacement and has been in use for a good while.

[@00wheelie00]

@@Psychx_ It's been a while since I had time to dabble at the hardware level. I've done some quick reading, as far as I can tell it gives you a framebuffer that is created during boot time. Can you also set up a virtual 8086 to change resolution on a running OS like you can with VBE?

[@christopherjackson2157]

Intel wants to stop finding hardware security issues once silicon is already going intp production. (think sapphire rapids delays). Thats how i read the document. It wasnt an easy read tho. This also eliminates some registers that persist unaltered through the boot process and have been used as vectors for boot kits in the past. If I'm reading the document right. The primary goal of the document seems to be to query the community about any issues this change will cause that Intel hasn't foreseen. If anyone's interested in this topic camiel from openvms has some fairly accessible talks about x86 boot process on his KZbin channel.

[@maxjames00077]

Could you explain this in simple terms? I'm interested but kinda new to the industry

[@marcin1337_]

​​@@maxjames00077asically x86 when was created never was done with security in mind, it was an afterthought. So a lot of legacy things support very insecure behavior which needs a lot of consideration when creating a safe TPM support and like. This is a security issue that you have already in your CPU at design, since you need to maintain compatibility here - even though no sane person should use that instruction/register

[@ayushde2991]

So good to see Clam Chowder behind Chips and Cheese. Been a regular follower and big fan :).

[@Brians256]

You're seeing Cheese, though, not Clamchowder. Were you thinking of another video?

[@kazriko]

Sounds like this will also put an end to most of the legacy operating systems, FreeDos, Aros, ArcaOS, Plan9, OpenSolaris, Hurd, 32 bit Haiku, etc. Some of these are open source and MAY be able to be adapted, but ArcaOS, the current developer doesn't even have the source code to it. Hurd is still stuck on 32 bit and I'm not sure they have a timetable for going to 64 bit. I think ArcaOS also uses Ring 1 for some parts of its security model.

[@capability-snob]

A debian-ports repo for hurd on x64 was created in the last few weeks.

[@Pixel-tl6fo]

I've been blown away by Chips and Cheese! Glad to see him on your channel.

[@sundhaug92]

Ring 1 and 2 was used by OS/2, not Linux etc

[@christopherjackson2157]

They play a role in platform initialization too I believe

[@bbbl67]

OS/2 1.x, as I gather. That was the 16-bit protected mode version of OS/2. I'm not sure if the 32-bit OS/2 2.x kept using it?

[@teds5047]

I don't come from a technical background. I have been a stay at home father for the last 14 years. However, I found this very interesting. I may only be understanding the most basic concept of what you are talking about, but I love learning about it and you make it accessible to a 40 yo. I personally can't thank TechTechPotato enough for introducing me to all sorts of topics I never would have stumbled on. I have been subscribed and watching your videos for quite a while now and feel much more educated. Thank you. Ted

[@geoffstrickler]

Dropping real mode is long overdue, even though that means DOS and other old OS’s won’t be able to run on those CPUs. It also means mean BIOS and boot loaders will need to be updated, and will require changes to hypervisors. I’m not sure eliminating Rings 1 & 2 is a good idea, it certainly has implications for many virtualization systems, and for some drivers. Eliminating real mode and 16-bit operation will allow dropping some legacy instructions and addressing modes, simplifying CPU design and testing. Legacy 16-bit and real-mode programs can be executed via emulation, so there is little impact even if legacy systems are still in use.

[@ApplePotato]

To be honest ring 1 and 2 aren’t really being used by the majority. And ARM also only have 2 privilege levels.

[@ADB-zf5zr]

Love the Chips and Cheese bloke's hilarious campness 😂

[@Veptis]

Hope there is an upcoming video about the changes of new Intel Fabs in Israel and Germany and how the economics turn out for the next decade. Fred was the codename for Intel Arc really early on.

[@ArbitraryConstant]

me: grumble it's not really 64-bit only george: it's not really 64-bit only me: THANK YOU

[@ViktorFerenczi]

This brings back some good memories of writing assembly from 8086 up to Pentium MMX. They cannot replace the bloated instruction set. I suggest introducing a new RISC like ISA as a new 64 bit execution mode. It should include standardized scalable vector and tensor instructions as well. Maybe they should just implement RISC-V in that mode for compatibility.

[@mgeb101]

I'd say the next CPUs will already internally support Fred and can be enabled, just not from users... (Intel is always testing/shipping new CPU features in production silicon before it is enabled by default)

[@Mr.Morden]

This seems like a really important and overdue change, but there are going to be masses of people with old devices using paleolithic 32bit drivers. This change will be a real investment opportunity since it'll drive peripheral upgrades.

[@FrankHarwald]

5:00 Drivers under Windows from NT onwards did run in Ring 1.

[@capability-snob]

I was mildly inconvenienced by dropping support for portio outside of the kernel, but to be fair, the existing support for that was extremely clunky. If you wanted to delegate only some ports to a userspace process, you had to setup a large bitmap and point your TSS to it. Systems that wanted to do delegate portio securely mostly just moved portio into the kernel and managed access explicitly, so now we're following suit.

[@quantumdot7393]

this collaboration makes me hungry.

[@bik3r230]

Love this thenical info stuff, all jokes aside its amazing love seeing the people working on this stuff and know what they are talking about cant wait for the futre of SILICON and if in my life time we will see personal quantum computers, even if they are 1 mil each that would be incredible

[@esra_erimez]

This is exciting news. I'm very enthusiastic about this. This will simplify the architecture and I'm looking forward to the possibilities of how the freed up real estate on the die can be used.

[@bbbl67]

The Protected Mode features, if they had been adopted by more OS designers would've eliminated a lot of zero-day exploits in their OS's. But once the 32-bit Protected mode came out with page-based protections in addition to the segment-based protections, it pretty much ended the need for segment protection. Page protection was easier to implement, and less secure, but easier to program for. This is the final end of the segmentation system, which was genius, but underappreciated.

[@bbbl67]

@suction379 This universe: segmentation was far more secure, you had 4 levels of security, you could give user apps the lowest privileges, device drivers higher privileges, and the OS the highest privilege. And you still had one more intermediate level of privilege left over for fun. With paging, it's either high or low privilege.

[@bbbl67]

@suction379 You find having more than 2 privilege levels pointless because you're used to having only two privilege levels. You can imagine a world where they put misbehaving device drivers on their own rung of the privilege ladder and the OS could stop those device drivers from taking the whole system down. It would eliminate zero-day exploits. With the 4-level privilege system, you could have used that for OS virtualization, a decade before they finally came out. You'd still need paging, but only for virtual memory, not security.

[@bbbl67]

@suction379 Putting the driver code at the same privilege as user mode stuff means user mode stuff can access it and attack it. Putting drivers in a slightly higher rung prevents user mode stuff from accessing it directly and potentially attacking it. The drivers can still work walled off from both the OS and the user mode stuff. The OS can also quickly distinguish whether certain requests are coming from user mode or driver mode stuff, and quickly allow access to hardware from drivers, without doing big credential checks.

[@bbbl67]

@suction379 Still there is a level of reduced latency if you go through a multi-level segmentation which can't be had with just a two-level page table. A device driver can be given automatic permission to access hardware, without much checking by the OS to see if it has rights to use it.

[@petergerdes1094]

@@bbbl67True, but I doubt there is that much benefit there. There are too many clever games you can play once you get direct hardware access to really add that much to security. I mean if it's storage or display hardware than your essentially pwned if malware gets control of that. Any hardware that can do DMA or is on the pcie bus can get up to all sorts of mischief if under malware control (and what the driver can make the hardware do is often undocumented). You might even argue that it encourages a too lax attitude to code with direct physical access. Ok, so it's really just about poorly written but non-malicious drivers. However, I'm not sure you need full processor level protection for this.

[@shodanxx]

This is Itanium again. The purpose is simply to reinforce wintel finance over the PC market, you will not get a discount. Also forget every running Windows XP or any operating system before windows 7

[@DeinonychusCowboy]

Honestly reminds me a lot of the bios to efi transition, it was painful (especially early non-apple efi) and took a long time but we got through it.

[@shanent5793]

Intel still salty about Itanium

[@smasherxs]

😂😂😂😂

[@johngangemi1361]

And the 80286

[@casperes0912]

I was surprised there was no video on this by anyone I follow. This happened all the way back in April. As far as I'm concerned this is a good chance that's at least a decade too late. When I wrote an OS and boot loader all the legacy stuff was horribly annoying to deal with. And I've started again with a Rust based OS and it's annoying all over again. I understand the home-brew OS/Bootloader dislike here, if you want to support both this and regular x86_64, but if you want to only support x86-S, which at some point in the future you can get away with, it makes it significantly easier to get started with your own OS and that to me is a great thing. Drivers also didn't use Ring 1 and 2 in Windows, Linux or macOS. It was intended by Intel to be used for drivers, but for a variety of reasons, none of the big operating systems used it at all. On CPUs without virtualisation technologies, VMWare and VirtualBox used Ring 1 but that's one of the only things I know of relevant to the way systems work today, and it isn't really relevant anyway since modern x86_64 has ring -1 with hypervisor support. I know hobbyist operating systems that use the ring system to full effect and it's sad on their end, but it also was never really a very portable design since most other architectures adopted the Unix-philosophy of "kernel or user space" binary privilege separation. Adding in hypervisor modes as well potentially. So if your OS is based on having 4 rings, it's very x86 exclusive already.

[@bbbl67]

I believe Gamers Nexus had a news story about this a few months back, that's why I wasn't surprised to hear about this, I was already semi-prepared.

[@casperes0912]

@@bbbl67 hm. Strange I missed that. I tend to watch all of GN news videos

[@garyp3472]

His friends know him as the charismatic one.

[@MarcoComercibjt2]

I have read the document (and i have actually sent an e-mail to the specified address because the old IDT stuff it still supported and i suggested to have a FRED-only CPU, scrapping the IDT and scrap also GDT, LDT and TSS), but the thing of other page sizes it interesting! I don't know if there is a new version of the document, but I am curious of knowing how this works: the PC will still boot in 4K page mode and there will be some transition instructions? or the page size will be a parameter in the 64-bit EFI boot structure? Very curious!

[@stefanmisch5272]

Cheese and potatoes, a good combination 😋

[@jannegrey593]

The only thing I'm worried about is some shenanigans that AMD will have to pay Intel license or Intel will refuse AMD license and take it to court. Otherwise Honestly that is long overdue. If it wasn't for "questionable practices" (mainly by Intel, but it's not like AMD can't do stuff like that as well), I would be going for it with let's say "real next gen" CPU's (so maybe Zen 7 - after AM5). Though given that N+3 or N+4 are being designed already, realistically it would be either very close shave to make it into Zen 7, or impossible. Due to a bit shorter lifespan of Motherboards, Intel is in better position to leverage it. Also if they adopt it - I beg Intel and AMD - release full x86 and x86-64 as open source, so that people who have money and don't want to go with ARM or RISC-V, might try to think of something innovative. Though costs would be prohibitive - my pipe dream probably.

[@scz0]

Things are made closed source not just to monopolize technology but also to add to its integrity and longevity. Lots of open-source projects come to die simply because of limitless control. Despite the relative success of RISC-V, people are hesitant to adopt to it since there are plenty of headaches when using said architecture in comparison to other CPU vendors that have modular software ready and available. Where as in RISC-V land, they have to create their own program for each and every new iteration, recall how many companies are still on the old java 8 and windows xp, specially when vulnerabilities start popping up. And that's just the first of part of the problem. Software and Hardware are now stacked together by the same company and beg that developers would specialize their software on their products as it would beneficial for them and the ones that are invested in both its longevity. Imagine the insanity of some developers have to deal with, specially in the android ecosystem in which optimization is horrendous and that each different version of chips would perform worse despite having a better spec in cpu, driver problems, etc..., now imagine them on the server stack of ampere, fujitsu, amazon, etc...(iirc, most of the arm cpu licensee owner, such as mediatek, qualcom and unisoc are not developing anything above spec but instead uses the base architecture for their products. There are still some overhead with the phone makers such as xiaomi, samsung and others which have different layers of drivers.) Despite me being negative about it, I truly want and support the idea of open source, but without acknowledging the problems ahead. We become headless chicken in-front of an overarching problem of a hungry tiger.

[@Jaker788]

Yeah, they've had a cross licensing agreement for a long time now. New instructions like much of what comes with AVX-512 and even AVX2 further back was introduced by Intel, but AMD is automatically allowed to implement it. Many many additions have been made with both able to adopt each others change to the ISA, what they cannot copy exactly is stuff like micro code or copy the implementation of X86 like a specific microarchitecture. You may remember how AMD created x86-64 while Intel was busy with Itanium to get away from sharing due to court rulings at the time. AMD made an extension and sold a 64bit X86 CPU. It was the new standard essentially, Intel was granted use of the license and they couldn't really make their own incompatible implementation. Intel and AMD can break away from each other without a clean slate ISA not based on X86 or newer extensions of it at all. And yes this change to the X86 ISA counts as an extension, it's still very much based on x86-64 as well (though it doesn't matter either way)

[@jannegrey593]

@@Jaker788 Yes. But Intel could like back in the day say: "This doesn't count" and stop AMD for couple of years and lose the battle in court. While AMD would lose couple of years in development and production of CPU's.... I'm simply a bit worried that courts can be weaponized like this.

[@Jaker788]

@@jannegrey593 They're not gonna pull a move like that. They've been hit hard plenty in multiple countries to know doing that will land them major penalties in multiple countries and reparations to AMD yet again. The gains would be small for the long term hurt

[@erkinalp]

@@jannegrey593 Removals alone cannot be patented.

[@dolex161]

Technical dept hurts, it hurts to move away from it, but it hurts more to keep it and not have a migration path. A necessary evil.

[@treyquattro]

x86-64 has 4K and 2M page sizes

[@NorthWay_no]

Did you report anything on their shadow stack thing to stop hacking of return programming?

[@hingsunhome]

Yeah, this is a must in order to survive. Intel has been losing the power / performance ratio to arm for way too long. The only way of which people will switch back to Intel is to match or exceed that ratio compared to the upcoming M3 on 3nm.

[@1schwererziehbar1]

Sounds like they're closing a deprecated backdoor.

[@treyquattro]

is that what all the banging in the background is about?

[@oscarcharliezulu]

Best Fred wver

[@brandonedwards7166]

I thought that's what uefi was designed for.

[@Psychx_]

Variable page sizes are possible and currently being used w/ regular X86 aswell. There's transparent hugepages in Linux (2MB and 1GB pages) and support for 5 level page tables in current (Ice Lake and newer) Intel CPUs, which allows for chosing other, arbitrary sizes.

[@snowwsquire]

the variable page sizes are not implemented in the same way, on linux its basically a bunch a of smaller pages grouped together, but on macos its just a genuinely bigger page. which results in better perf

[@Psychx_]

@@snowwsquire You can get larger native page sizes aswell. The options can be selected before compiling the kernel.

[@snowwsquire]

@@Psychx_ that’s true, but you can’t swap between them seamlessly in one address space like you can on apple silicon

[@danwat1234]

So... will device polling still be an enabled legacyfeature? Fred(dy) Got Fingered (2001).

[@Neeboopsh]

You are lucky that Lawrence O'Donnell wasnt there. he would have been yelling at everyone. STOP THE HAMMERING!!!

[@m_sedziwoj]

Lest tech debt, better the future. Not matter that some people complain, they will always complain about changes until they die.

[@sydtopia1]

Great video, someone needed to take the hammer of the person using the hammer in the background.

[@shmookins]

Finally.

[@jrherita]

Yay - Chips and Cheese!

[@dantheman1998]

Is this about security or is this about saving silicon?

[@Brians256]

Yes. Both. To be clear, the parts of boot that are before 64-bit is fully enabled are less secure. Also, fewer complications make for a chip that is easier to audit and make secure. Fewer transistors is also good, though.

[@seanC3i]

As long as my 32 bit stuff continues to work (e.g. old games, things in VM software) I'm OK with this.

[@shodanxx]

You can count on them clawing back virtualization in consumer products eventually. This is just seeing the stage.

[@mysterium364]

@@shodanxx I feel like they would need to handicap the cpu's pretty damn hard for qemu not to be able to emulate retro stuff. I know qemu with no virtualization support is slow, but I'm sure it's fast enough for 99% of retro games. Do I have some misconception about this?

[@Gameboygenius]

@@mysterium364 depends on what you classify as retro. Arguably, the Windows XP era of games is starting to enter "retro" now. We'll probably start to see those games become less and less compatible natively as time moves on. Native virtualization might be an option for those games if you can sort out the graphics acceleration. If you still have 32 bit user mode support, some middle layer, like DxWnd, could also be an option. But Qemu without virtualization probably wouldn't be too pleasant for that era of games.

[@Psychx_]

Intel FRED Ultra 9 with 24 efficiency cores and 16KB pages when?

[@nngnnadas]

Would I be able to install a 32-bit OS (e.g Windows XP) on it?

[@johngangemi1361]

No

[@TheEVEInspiration]

I still think they can get more from axing a bit more.

[@Gindi4711]

I am wondering what this means for all the legacy applications that do not run on 64 bit operating systems and are currently running in virtual machines.

[@TechTechPotato]

They'll continue to run in virtual machines.

[@johngangemi1361]

​@@TechTechPotato via emulation?

[@emteiks]

in other words, if you use some drivers that were not designed by Intel but are free and opersource (coreboot, Libreboot, linux drivers etc) then basically you will not be able to run the machine you paid for?

[@technerd9655]

No, this doesn't affect current or near production release CPUs or systems. It means that on systems that drop legacy functionality that is currently the only/primary method to boot an OS on x86 (16/32/64bit) CPUs in favour of this new method that those firmwares/drivers you listed would need to be updated based on the documentation Intel (and presumably AMD and the other legacy x86 licensees such as Via and DM&P) release on this, just as they have released this documentation for developers from the beginning. If these are open source, all it takes is one person to volunteer their time and expertise to delve into the documentation, learn it, test it, and implement it for each of these projects to allow them to run on new CPUs that drop legacy support. It also sounds like the first few generations of CPUs supporting FRED will still support the legacy functionality allowing those systems to boot in 16bit mode, transition to 32bit, then 64bit, or 5o boot directly to 64bit using FRED. So those systems would still run legacy code, but later generations likely would drop legacy support and be FRED only. I'd say we're a good 10-15 years away (maybe closer to 10) from most systems being FRED only. I suspect server CPUs will go FRED only first, and sooner, desktop and laptop CPUs next, and embedded/industrial CPUs (such as the ones DM&P make, like thier 1GHz 486 class CPUs) would be the last to transition. This could take 20+ years to get every new x86 CPU manufactured transitioned. Maybe DM&P won't transition, who knows, I don't think they have even started making 64bit CPUs yet). Anyways, that's my interpretation. The only dependency on Intel (and AMD possibly) is physical hardware, and documentation, no code dependency.

[@GegoXaren]

AMD is working with CoreBoot to make it avalible for EPIC. They will probobly be giving some guidence for how to adapt to the new paradigm.

[@timmy112kirk]

But But.... How am I going to boot into Windows 98 now? :(

[@olifyne6761]

why not just call it x64

[@boobio1]

so......................

[@nagi603]

So.... will this nuke the current ways to nuke the management engine? And also by the sounds of it, any factory running very legacy systems will be VERY nuked due to the changes. This completely nukes anything still using DOS (or any non-64bit OS) for instance. (Who uses that? I saw a DOS screen when I was at my doctor the other day.)

[@snowwsquire]

its not like they are recalling all cpus with support for real mode, the new ones just wont be compatible anymore

[@UCkjk379HHBJLRSgfx_ezt6g]

you could have recorded this video anywhere (surrounding environment is entirely irrelevant), and chose this?

[@GegoXaren]

x86-32+64 only would be a good start, then x86-64S in a decade.

[@BixxPlays]

this explains intel removing the i from theyer cpus they didn't want an intel fried7 joke.

[@ShadoFXPerino]

Does this mean all device drivers need to be rewritten, or just the OS?

[@snowwsquire]

32bit device drivers will have to be rewritten, or anything in ring 1 or 2

[@capability-snob]

This change formalises the way that Windows, Linux and the BSDs use the chip, so drivers for those platforms are unlikely to need any change.

[@tristan7216]

This sounds like allofa sudden you buy a new computer and your printer, scanner, and every other peripheral won't work any more, because all the old drivers won't run. I hope I'm wrong about that. It's already bad enough when the OS changes, now the CPU is also a planned obsolescence threat.

[@CaudaMiller]

just 2 stooges?

[@TheBackyardChemist]

They should have completely nuked the X87 FPU as well and made AVX-512 the least common denominator. Maybe add a few more masking modes to AVX-512 to make FP80 emulation easier for the the whopping 15 people in the world who care about that.

[@Blzut3]

Given that 32-bit applications typically depend on x87 that really isn't viable. They could decide to drop MMX though.

[@TheBackyardChemist]

@@Blzut3 OS's that wish to keep running 32-bit userspace code could run them sandboxed and emulate x87 isns with AVX. Is that harsh? Maybe, but so far it looks like Intel gets one chance every 20 years to make a radical change. Last time it was Itanium, which failed for various reasons. If Intel does not drop x87 now, we are going to be stuck with its archaic BS until 2045.

[@nunyobiznez875]

Oh, I thought FRED stood for "F%#K Retro Enthusiasts and Developers".

[@user-me5eb8pk5v]

Pentium Pro Rascally

[@ssl3546]

Since new computers are UEFI out of the box and you can't even use a Pascal card without first using another GPU to change the boot settings, the backwards compatibility ship has unfortunately already sailed. Wish we could still boot MS-DOS and use the computer as god intended but at this point they might as well get rid of the rest of the backwards compatible stuff like Intel wants.

[@itstheweirdguy]

It's fortunate that in Windows 11, at least Legacy + UEFI (CSM) mode is a supported configuration, even though secure boot can't be activated in this situation.

[@theexplosionist2019]

You write absolute drivel. UEFI works even using a dual-link DVI monitor with no scaler that only supports its native resolution.

[@MrSamPhoenix]

Long story short “FRED” is very popular with the ladies. In all seriousness though, Intel wants to get rid of legacy stuff because it frees up space on the chip for other things… which has the potential to increase performance.

[@Fractal_32]

And potentially some security issues.

[@MrSamPhoenix]

@@Fractal_32 indeed

[@Psychx_]

Platform initialization would be easier and comparable to modern PPC64 and AARCH64 platforms. This should be a big win when it comes to cross-platform codesharing of UEFI-level and bootloader-level code, aswell as for trusted boot processes. Let's just hope that SMM is also removed, since that has proven to be a never ending security nightmare.

[@lightward9487]

@@Fractal_32 You are wrong like that, but Intel, if it is worth saying its day and stopping AMD, means AMD will lose everything that cannot be done because Intel is the main CPU for x86, it is that eliminating the inherited of mains any, the countries mean they lost inherited bits 64x over AMD will be guilty until it learns to avoid monster intel

[@stormrider01]

I would rather have only 64 bit and more efficiency and power instead of 32 and 64 bit support and have efficiency degradation and power loss.

[@cj09beira]

at this point cpus are so complex that the added complexity of supporting 32 bit instructions is negligible, said by Jim Keller no less.

[@eliadbu]

@@cj09beira I think it boils down to verification and getting the CPU out to the market ASAP, remember sapphire rapids had numerous steppings, issues and delays ? I would not be surprised if significant part of the time was spent on supporting these legacy features and searching for security vulnerabilities that they may cause, support for 32 bit software is still there but support for old OS natively will be out. overall faster more efficient developing cycles are also good for the end users.

[@Dave102693]

Will this mean we will get power efficient x86 laptops and tablets to counter Apple silicon and non Apple arm chips?

[@dark666king]

No, this doesn't affect the efficiency of the CPUs, let's say you take same architecture generation CPU, ie 13900K, and "castrate" it down from full X86 to X86S, the energy efficiency and performance will remain the same. It's about dropping backward compatibility and theoretically, but dubiously, freeing some silicon-die real estate. It will force everyone to rewrite their drivers, their operating systems, boot loaders, all the virtualization based sandboxing/VMs, etc. so it creates "a lot of business opportunities" for companies by forcing you, the end user, to buy new hardware as everything you've got today will not work with it.

[@doltBmB]

more like getting rid of AMD as a competitor by making a new architecture they don't have a license to and that doesn't need amd64 lmao itanium 2

[@stuw5376]

Fred Rippa

[@wtflolomg]

Sweeping away the last vestiges of Intel's x86 legacy in favor of AMD64, erm, I mean "Intel 64". Ironic.

[@EraYaN]

Most of the ISA will stick around anyway

[@em00k]

There’s a lot of incorrect information spouted in the video. Claims that x86 processors still boot into 8086 mode is out of date nonsense. 😂

[@rjScubaSki]

Fred has been pretty rubbish at Man United. He’d be even worse at Intel

[@stuw5376]

Exactly my thoughts, terrible signing… Can’t help but think Intel would be better with a younger, more dynamic midfielder.

[@HDRPC]

Intel is the best

[@iancurrie8844]

This looks incredibly awkward. There's something so incredibly off-putting to this I cannot watch it.

[@josiahsuarez]

Wow!!1 too long have I suffered through previous gen boot loaders but welcome to the future zòooom