There was a thread about this on the os2world forum as well if anyone wants to check that out (don't have the url offhand..)
Essentially, all legacy 16-bit support would be removed from the hardware itself, as well as some of the 32-bit support (no Windows 7 or 10 32-bit, OS/2 nor ArcaOS). VirtualBox & others would no longer virtualize any of these either (i.e. No VBox Win7 BBS with DOS support, proxmox Windows guest, etc)
Seemingly the available options would be Windows 64-bit with the NTVDMx64 (which DM mentioned breaks stuff now) or DOSBox/PCEm/etc type emulators.
https://www.intel.com/content/www/us/en/developer/articles/technical/envis g-future-simplified-architecture.html
https://www.intel.com/content/www/us/en/developer/articles/technical/ g-future-simplified-architecture.html
i will skin who ever thought this is a good idea alive! >:(
What about linux? Wouldn't that still offer the same options?
It's actually a pretty good idea if they intend to keep
x86 relevant for new product development for much longer.
It costs Intel an enormous amount in validation to do a
new microarchitecture; much of that comes from the intrinsic
complexity of keeping 16-bit support around.
It really doesn't change that much for modern operating
systems; the boot sequence changes, and it's not clear to
me how you set up the initial page tables for starting the
BSP (they seem to defer that to some hidden core prior to
x86 coming out of reset), but the updated SIPI stuff is
kind of nice.
32-bit mode remains for userspace applications, so it won't
affect much software written in the last 30 years for real
operating systems.
The solution for DOS etc is to run it under a full-system
emulator.
it's just a proposal though. i think AMD broke some of this stuff oni use retro shit all the time though.
early ryzen cpus and people complained so we're not the only ones using
it still..
claw wrote to fusion <=-
What about linux? Wouldn't that still offer the same options?
;_; this means if this rolls out then the X86 to me is dead and the original PC line dies with it....
fusion wrote to All <=-
Essentially, all legacy 16-bit support would be removed from the
hardware itself, as well as some of the 32-bit support (no Windows 7 or
10 32-bit, OS/2 nor ArcaOS). VirtualBox & others would no longer virtualize any of these either (i.e. No VBox Win7 BBS with DOS support, proxmox Windows guest, etc)
Nightfox wrote to fusion <=-
I suppose this was bound to happen at some point. In some ways, I
think we users of x86 architecture have been lucky that at least some amount of backwards compatibility has continued this long. There are
some computer platforms (such as Mac) that have swapped their hardware architecture more than once, with official backwards compatibility (via emulation) only lasting a limited time.
Since Marketing is Evil, I'd venture that they'd come up with:
1. A Mainstream line with 16-bit support removed at the same price point as we're paying now.
2. An Intel Legacy(tm) line of processors, identical to what we can buy now, except in limited quantities and *much* more expensive.
I wanted to go into marketing, but they found out my parents were warm-blooded.
We spoke here previously about DOS support after 2038.. it would seem we have another potential enemy in the form of a proposal from Intel :)
https://www.intel.com/content/www/us/en/developer/articles/technical/envisio nin g-future-simplified-architecture.html
Funny how they refer to it as "Intel 64 mode" when AMD actually invented it. --
https://www.intel.com/content/www/us/en/developer/articles/technical/envisi
o nin g-future-simplified-architecture.html
Funny how they refer to it as "Intel 64 mode" when AMD actually invented it.
Re: X86S
By: Digital Man to fusion on Mon Apr 22 2024 08:29 pm
https://www.intel.com/content/www/us/en/developer/articles/technical/envisi
o nin g-future-simplified-architecture.html
Funny how they refer to it as "Intel 64 mode" when AMD actually invented it.
I've seen it refered to as "AMD64" fairly often, and sometimes I've seen people confused about whether something built for AMD64 will run on an Intel system. Even some people I worked with at Intel were sometimes confused about that (sometimes we'd download Linux ISOs to install on some of our test systems, and they were often labeled as x86 or AMD64).
of our test systems, and they were often labeled as x86 or AMD64).
Yeah, that's because AMD did it first and Intel followed. FreeBSD (at least) still refers to the x86_64 architecture as "amd64" everywhere. I prefer just to refer to it as "x64" and certainly never "Intel 64" - that
was definitely created by Intel). But Intel had its go with the Itanium (IA64) architecture, which flopped, so if they want to claim invention/ownership of a 64-bit PC/server architecture, they should claim that one.
Yeah, that's because AMD did it first and Intel followed. FreeBSD (at least) still refers to the x86_64 architecture as "amd64" everywhere. I prefer just to refer to it as "x64" and certainly never "Intel 64" - that would just be misattribution (though the base archicture/instruction set was definitely created by Intel). But Intel had its go with the Itanium (IA64) architecture, which flopped, so if they want to claim
Was going to point out as I started reading, the Itanium arrived first, I don't remember seeing it for anything other than server class hardware, and everything had to be re-written/compiled for it. Where as AMD64 was more an extension for X32 and was backwardly compatible.
Was going to point out as I started reading, the Itanium arrived first, I don't remember seeing it for anything other than server class hardware, and everything had to be re-written/compiled for it. Where as AMD64 was more an extension for X32 and was backwardly compatible.
AMD led quite the coup with x86_64. What happened there was that Digital Equipment Corporation was in its death throes, and they hemorrhaged some of their best Alpha designers (Alpha, at the time, was the fastest microprocessor in the world) to AMD. At the time, Intel was pushing Itanium hard, and refused to entertain the idea of a 64-bit x86. This extraordinarily talented team, now at AMD, didn't want to futz about with an also-ran x86 clone, so they came up with x86_64. It was fast, supported a large virtual address space (x86 had had PAE for several years by then, so they already had a large physical address space), and retained compatibility with 32-bit x86 applications.
That was kind of what the OEMs all wanted, which meant that the desktop market and low-end servers all went x86_64, and Itanium was relegated to the high-end, where it only had marginal market penetration. Eventually, x86_64 took over there, too (at least by volume), in part thanks to the hyperscalars paving the way for large-scale x86 deployment in server environments.
Was going to point out as I started reading, the Itanium arrived firs don't remember seeing it for anything other than server class hardwar and everything had to be re-written/compiled for it. Where as AMD64 more an extension for X32 and was backwardly compatible.
I know I'm just being pedantic, but the 32-bit mode is called x86, not x32. I think the name comes from Intel's early processor, the 8086.
I think it's interesting that it happened that way. I think moving forward while maintaining backward compatibility has been an advantage with x86 processors.
Apple seems to have the opposite strategy, where they have no problem swapping out the processor in their Mac lineup to something entirely different. They've done that several times in the history of the Mac. I've done some software development work on an M1 Mac not too long ago, and one of the frustrations was having to use its x86 emulation
sometimes to do some builds, as there were some 3rd-party software libraries that were still only supporting x86 and didn't support M1 yet.
I know I'm just being pedantic, but the 32-bit mode is called x86, not x32. I think the name comes from Intel's early processor, the 8086.
By my count, the Mac is on its 4th hardware architecture (68k,
PowerPC, x86, and now ARM).
Their observation, and it's not a bad one, is that it doesn't
matter all _that_ much: once you've got decent binary translation
support in place for the transition, very few people are writing
assembly language directly anymore; you can just recompile for a
new ISA and go with that. Of course, issues like you described
are irritating for software developers, most that's an edge case.
I think it's a bit of the same idea that led to the removal of floppy disk drives from Apple computers, before many people were ready to let them go. But now when I look back, I think it's more strange how long mostly-unused floppy disk drives kept being installed in PCs. (used maybe for a driver install, because PCs weren't forced to move on to a better standard, because the floppy drives stuck around.)
tenser wrote to Spectre <=-
That was kind of what the OEMs all wanted, which meant that
the desktop market and low-end servers all went x86_64, and
Itanium was relegated to the high-end, where it only had
marginal market penetration. Eventually, x86_64 took over
there, too (at least by volume), in part thanks to the
hyperscalars paving the way for large-scale x86 deployment
in server environments.
tenser wrote to Spectre <=-
That was kind of what the OEMs all wanted, which meant that
the desktop market and low-end servers all went x86_64, and
Itanium was relegated to the high-end, where it only had
marginal market penetration. Eventually, x86_64 took over
there, too (at least by volume), in part thanks to the
hyperscalars paving the way for large-scale x86 deployment
in server environments.
It seems lots of people underestimated the power of lots of cheap Intel boxes. Central Computers in San Francisco was my idea of an auto-scaling group - traffic increases on the web site? I could call them and get a server built in 24 hours. They were 4 blocks away.
The year before we'd been running Sun for both the database and front-end of a web site using some Netscap web server - the following year the front-end was all cheap white boxes running Apache on Linux.
I'm not a big fan of things being removed before their usefulness has passed. Now that I actually stopped using floppy disks years ago, I'm
fine with my PC not having a floppy drive.
Hmmm Even though I "like"floppies, older computers - Hey even my "home server"is probably 20 years old already, and "main desktop"is over 12...
- It's prpbbaly more than 15 years I don't use a flopp disk. Even USB
I'm not a big fan of things being removed before their usefulness has
passed. Now that I actually stopped using floppy disks years ago, I'm
fine with my PC not having a floppy drive.
Hmmm Even though I "like"floppies, older computers - Hey even my "home server"is probably 20 years old already, and "main desktop"is over 12... - It's prpbbaly more than 15 years I don't use a flopp disk. Even USB drives, to be real, I havent used for about 4 years... except when I want to install/reinstall OS on some of those machines and older laptops I have here... even on those machines I really ddidnt need the floppies anymore...
I'm not a big fan of things being removed before their usefulness
has passed. Now that I actually stopped using floppy disks years
ago, I'm fine with my PC not having a floppy drive.
Hmmm Even though I "like"floppies, older computers - Hey even my
"home server"is probably 20 years old already, and "main desktop"is
over 12... - It's prpbbaly more than 15 years I don't use a flopp
disk. Even USB drives, to be real, I havent used for about 4 years... except when I want to install/reinstall OS on some of those machines
and older laptops I have here... even on those machines I really
ddidnt need the floppies anymore...
telnet://bbs.roonsbbs.hu:1212 <<=-
| Sysop: | Eric Oulashin |
|---|---|
| Location: | Beaverton, Oregon, USA |
| Users: | 103 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 08:49:40 |
| Calls: | 3,512 |
| Calls today: | 5 |
| Files: | 8,461 |
| Messages: | 337,036 |
| Posted today: | 1 |