New Intel Simplified Architecture

I don't think that will go over well with Windows users - other than websurf-only users of course. Many people who use their PC locally have little collections of programs that they use, with 32 bits mixed in. An example are audio plugins that were never updated to 64 bits but do some trick the user still wants. When Apple removed 32 bit support from Intel OSX that did not go over so well with many users that aren't websurf-only.

By extension Wine users on FreeBSD would be affects, for example those that run old games.
 
cracauer@ said:
I don't think that will go over well with Windows users - other than websurf-only users of course. Many people who use their PC locally have little collections of programs that they use, with 32 bits mixed in. An example are audio plugins that were never updated to 64 bits but do some trick the user still wants. When Apple removed 32 bit support from Intel OSX that did not go over so well with many users that aren't websurf-only.

By extension Wine users on FreeBSD would be affects, for example those that run old games.
Click to expand...
I don't think that the proposed architecture totally gets rid of the ability to run 32-bit protected mode. Posts elsewhere have suggested that there will still be a legacy mode, but just for 32 bits.

Last time I checked, Office was still a 32 bit application, which for MS seems kind of pathetic. Hopefully BSD/Linux/OSS can adapt more easily as long as there are developers around to maintain the code.
 
I think in some ways much of the 32-bit mash of programs in Windows could be solved by adding a usermode emulator, similar to qemu-static to their WoW64 (Windows on Windows) compat layer. Doesn't Microsoft already have access to similar tech for their Snapdragon experiments?
This translation is generally going to be fast enough for many programs (possibly even games) because it only deals with the logic, not with i.e graphics and things like that.

I am hoping this will actually improve Wine though. In many ways that 32-bit/64-bit FreeBSD userland stuff is a bit messy. If they can integrate a decent x86 translator in there (i.e box86) so that Wine becomes "not an emulator" but also "an emulator" at the same time, I think this will clean up the tech stack a little. It will become a little more like DOSBox (a strange hybrid emulator).
 
cracauer@ said:
I don't think that will go over well with Windows users - other than websurf-only users of course. Many people who use their PC locally have little collections of programs that they use, with 32 bits mixed in. An example are audio plugins that were never updated to 64 bits but do some trick the user still wants. When Apple removed 32 bit support from Intel OSX that did not go over so well with many users that aren't websurf-only.

By extension Wine users on FreeBSD would be affects, for example those that run old games.
Click to expand...
Haven't used wine in a while, and freebsd support for wine or versa visa has always been an added complication. But at what point do you run legacy wintel software on dosbox (ie full CPU emulation) instead of wine (ie legacy windows ABI)?
 
This doesn't bother source-built things like FreeBSD a bit... unless... you rely on some binary blob. Apps run in Wine count.

cracauer@ said:
When Apple removed 32 bit support from Intel OSX that did not go over so well with many users that aren't websurf-only.
Click to expand...

And they all had to suck it up. Windows 11 doesn't have a 32-bit version. Whatever weird 32-bit things that still exist are going to have to get re-compiled, re-implemented, or re-verse engineered.
 
msplsh said:
And they all had to suck it up. Windows 11 doesn't have a 32-bit version. Whatever weird 32-bit things that still exist are going to have to get re-compiled, re-implemented, or re-verse engineered.
Click to expand...

Windows 11 (64 bit OS) runs 32 bit Windows apps just fine.
 
Thunked through WOW64. I guess the difference there is that Apple could have done it but chose not to.
 
BSDUser97 said:
Last time I checked, Office was still a 32 bit application, which for MS seems kind of pathetic.
Click to expand...
That was when, in '00s? You can choose either x86 or x64 when installing for a lot of years now.
1686068239506.png
 
Up until 2022, wasn't Visual Studio a big mix of i686 and amd64? So much so that it installed in Program Files(x86). I am fairly sure that some of it still is.
 
One of my arguments for realmode, albeit being weird, was that at least you can still play DOS games there if you wanted. But as motherboard firmware is slowly starting to drop the CSM and have only UEFI firmware there's really no reason for CPU to start in RM with all its memory limitations. This will definitely simplify the startup.
Judging from the timeline Intel shared in that link many was already dropped.

Dropping 32b support would be significant (it drags down the VM86 with it too). But I agree with you kpedersen , if such support is needed most likely some sort of emulator would suffice. Probably not for games though.
On the other hand I still play some Atari games I used to play on emulator and I'm ok with it. I think it will be the same for 32B too.
 
It has no impact on FreeBSD what so ever. Completely different paths. FreeBSD exists in different ports. For Intel one 32bit version (tier 2, so slowly on its way out) and amd64 (tier 1) with an additional 32 bit layer. This is the main x86 port today. On windows they still have parts written 16bit code, 32bit code and 64bit code. It is a complete mess because of backwards compatibility. So warning that some level of cleanup (incompatibility) will happen some day might be what they need. But nothing that has anything to do with FreeBSD (maybe except for wine).
 
kpedersen said:
Up until 2022, wasn't Visual Studio a big mix of i686 and amd64? So much so that it installed in Program Files(x86). I am fairly sure that some of it still is.
Click to expand...
The IDE was 32 bits. You could choose to compile your code using the 32 bit compiler - which could run out of space compiling very, very large projects. Switching to the 64 bit compiler solved this. To clarify - I'm talking about the compiler itself running as 32 or 64 bits, not the code it emitted.
 
FreeBSD would still need to support these "legacy" modes. I see this proposal as a win for slightly reducing the attack surface on 64 bit Intel hardware. I can imagine seeing a future CVE for some UEFI bug that would not apply to this newer processor.

The downside is ... more work to get FreeBSD to boot on these new processors. Some early adopter will buy a shiny new computer and complain they can't install FreeBSD on it because the boot code has yet to be written. This will happen.
 
unitrunker said:
Expect AMD to answer with "AMD64S" (and it won't be compatible).
Click to expand...
I don't see how that follows from my post. The reason why AMD64 was so successful, and why it obliterated the Itanic is precisely that it is backwards compatible with x86-32.
 
Hi Jose !

Always good to read your posts.

Jose said:
I don't see how that follows from my post. The reason why AMD64 was so successful, and why it obliterated the Itanic is precisely that it is backwards compatible with x86-32.
Click to expand...
It follows from your post in this way.
  • The X86S whitepaper purposely omits any mention of AMD.
  • You rightly point out AMD's contribution to the story (thank you).
  • Now that AMD is part of the conversation, I'm making a prediction as to how AMD might respond to the adoption of X86S.
We're both talking about compatibility. You're emphasizing x86 compatibility. I'm emphasizing amd64 vs x86-64 compatibility.

Put another way - Intel adopting amd64 into their processors marked the end of a battle, not the war. What followed were competing enhanced instruction sets and special VMM register bits. amd64 and x86-64 are compatible to a point. My cynicism comes from code fragments in FreeBSD like this:

github.com

freebsd-src/sys/amd64/vmm/vmm.c at 9cc67e43610e34a692398a65adcc5e8846e84250 · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src
github.com github.com

It would be nice if x86s reduced the amount of "if (amd) {} else if (intel) {}" logic. We'll see.

I should add, I'm not trying to cast shade on AMD or Intel. They are for-profit corporations doing what they think best. I expect this competition to result in new bits of if/else logic in the FreeBSD kernel. It is what it is.

Regards.
 
unitrunker said:
Always good to read your posts.
Click to expand...
Thank you for your kind words.

unitrunker said:
Put another way - Intel adopting amd64 into their processors marked the end of a battle, not the war. What followed were competing enhanced instruction sets and special VMM register bits. amd64 and x86-64 are compatible to a point. My cynicism comes from code fragments in FreeBSD like this...It would be nice if x86s reduced the amount of "if (amd) {} else if (intel) {}" logic. We'll see.
Click to expand...
I had no idea. Thank you for educating me.

I don't think x86S has legs, and therefore don't think AMD will bother to respond at all. Both of them are currently under enormous pressure from ARM, which is gaining a ton of momentum on hyperscalers. It uses power far more efficiently than any flavour of x86, and the cloud providers are pushing the savings on to their customers. We're currently doing a big push to move to Graviton instances at work. I'd be surprised if most medium-to-large businesses weren't doing the same.

I'm a lot more interested in RISC-V, which has a better chance of eliminating vendor-specific annoyances like the ones you list. It's very early days for that ISA, and there's still a lot that can go wrong and kill it, though.

unitrunker said:
I should add, I'm not trying to cast shade on AMD or Intel. They are for-profit corporations doing what they think best. I expect this competition to result in new bits of if/else logic in the FreeBSD kernel. It is what it is.
Click to expand...
Yeah, I had to check my AMD fanboism. I'm still so grateful to them for killing both the Itanic and RDRAM. Intel almost got away with closing the PC architecture in the early aughts. That would have been incredibly damaging to the entire industry, and to my favourite hobby as well!
 
You must log in or register to reply here.
Back
Top