DOS ain't dead

64-bit only CPUs being considered:

https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/

Already saw this on Phoronix, not a shock. Doubt it will save even 5% of heat / energy / fabrication cost or speed much up. (They probably waste more money on senseless marketing.)

For example, the Venix/86 emulator is "currently running using vm86 on a FreeBSD/i386 bhyve instance hosted on a FreeBSD/amd64 machine".

Since I don't expect VT-X to disappear, this doesn't hurt much. (Many projects like VirtualBox and QEMU no longer run atop 32-bit host OSes anymore.)

> Doubt it will save even 5% of
> heat / energy / fabrication cost or speed much up. (They probably waste
> more money on senseless marketing.)

IMHO, main profit is reduce complexity of instruction decoding (into CPU).
x86/amd64 decoding is a hell, but intel does not stop - invent more and more new instructions sets.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

Hello all,

Well, the new proposed mechanism for CPU reset does not look simplified to me:

"The CPU starts executing in 64-bit paged mode after reset. The Firmware Interface Table (FIT) contains a reset state structure containing RIP and CR3 that defines the initial execution state of the CPU."

I wonder why Intel did not decide to do the "more obvious" thing, i.e. allow for a 64-bit long mode without virtual memory paging (cr3).

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Yes, I read that too... https://www.cnews.cz/konecne-procisteni-architektu...x86-intel-navrhuje-legacy-free-platformu-x86-s/

I predicted it many years ago that PC de-legacying process will continue by UEFI without CSM and then, when PC already starts in 64b mode in UEFI, booting 64b OS then no need to keep RM, V86, even 32b stuff. I think this circuits consume only small amount of silicon (now we have mag of 1e9-1e10 transistor while 386 needed <1M) but it takes a lot of testing and time to prepare and do such test. Even intel in the last years is in deep $H.. (AMD kick a$$) so they needs to cut costs heavily to not bankrupt. So this is the last goodbye to x86 then only emulators and VM. There may be not much differences running a dosbox or Qemu on x64 or ARM or RiscV or something else...

---
DOS gives me freedom to unlimited HW access.

> Already saw this on Phoronix, not a shock. Doubt it will save even 5% of
> heat / energy / fabrication cost or speed much up. (They probably waste
> more money on senseless marketing.)

I think it is more that they have been spooked by various chip and chipset (management engine) bugs/vulnerabilities, and are moving to decrease the possible attack surface by cutting relatively unused features.

> I wonder why Intel did not decide to do the "more obvious" thing, i.e.
> allow for a 64-bit long mode without virtual memory paging
> (cr3).

What would be the benefit ? (for them I mean)

Hello marcov,

> > I wonder why Intel did not decide to do the "more obvious" thing, i.e.
> > allow for a 64-bit long mode without virtual memory paging
> > (cr3).

> What would be the benefit ? (for them I mean)

It is likely going to be simpler to set up — if not for Intel, then at least for the firmware writers.

Intel's proposed arrangement seems to be that the firmware writers need to set up some sort of table in firmware which their CPU microcode will have to parse in order to figure out how to run the first x86-64 instruction. None of this looks "simplified" to me in any way.

Also, 64-bit ARM (AArch64) CPUs are perfectly able to simply start up without virtual memory paging.

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> So this is
> the last goodbye to x86 then only emulators and VM. There may be not much
> differences running a dosbox or Qemu on x64 or ARM or RiscV or something
> else...

I don't think so. As long as VT-X exists, it only takes a new type of VMM to make X64s x86 compatible again. Most of you run your DOS in v86 already, so what's the difference. For me, it's like a race, like whether they can deprecate services faster than we can come up with their replacements. To be honest, I kind of enjoy the game and it has been so for decades: as PC's support for DOS shrinks, DOS' support for PC grows. What's more, I rarely see any practical reason of using DOS, it's mostly a "because I can" thing, tbh. Now, thanks to UEFI class 3 we already need to have our own BIOS anyway and I don't see what chages if it has to include a VT-X VMM in this case. It would even make writing drivers easier, I mean, make it less a pain in the a** than it is to make them work in v86 and be compatible with everything.

---
DOS isn't about why. It's about why not.

It's not clear to me how/mutch the VT-X will be reduced but it wouldn't make sense of simplyfing it they will keep whole 16bit and V86 modes available at least for virtualized OS as it would need HW stuff similar to native execution. So I expect they plant to cut it too and then it would need to be SW emulated...

---
DOS gives me freedom to unlimited HW access.

> 64-bit only CPUs being considered:
>
> https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/

So, if they do it then sometime in the future brand-new computers
will no-longer have the capability of booting directly into DOS.

Well, it was only a matter of time.

Heck, is it possible to boot any home computer
newer than say 1990 directly into CP-M ?

---
--
http://glennmcc.org/

> > Doubt it will save even 5% of
> > heat / energy / fabrication cost or speed much up. (They probably waste
> > more money on senseless marketing.)
>
> IMHO, main profit is reduce complexity of instruction decoding (into CPU).
> x86/amd64 decoding is a hell, but intel does not stop - invent more and
> more new instructions sets.

I think the document didn't mention SMM. So, if SMM remains there, all those 16-bit things remain there as well.

This is (mostly?) sarcasm, but why didn't they just remove AVX instead? Does anybody here care about AVX-512? Wouldn't that save them more space? (I'm sure some Fortran nerd needs it, but I don't.)

> This is (mostly?) sarcasm, but why didn't they just remove AVX instead?

AVX(2) is used a lot (nearly everything that is low precision calculation, images, codecs etc, even memory moves often use AVX instructions) That booting has a 16-bit phase isn't used other than a mandatory stage by many people.

> Does anybody here care about AVX-512? Wouldn't that save them more space?
> (I'm sure some Fortran nerd needs it, but I don't.)

Currently AVX-512 is still in its infancy. A new instruction set needs a certain seeding time to reach critical mass.

The AVX512 seeding time however takes very long. This because Intel first postponed migrating to the "cove"design because of factory trouble and then because they took a different road with the big.little design in the 12th generation where while the big cores supporrt avx512, the little ones do not.

(and AMD only just supports it, in Zen4 aka Ryzen 7000+ using 2 AVX256 pipes to implement)

So the bulk of the machines sold NOW don't have AVX512 yet.

Here's it in details: https://cdrdv2-public.intel.com/776648/x86s-EAS-v1-4-17-23-1.pdf

Interesting part is chapter 3.20.3 Legacy OS Virtualization
A VMM can choose to emulate legacy functionality as required:
1. VMM changes required for mainstream Intel64 guest using legacy SIPI or non-64-bit boot
a. Emulate 16-bit modes (real mode, virtual 8086 mode)
b. Emulate unpaged modes
c. Emulate legacy INIT/SIPI
...

So it seems that all legacy code triggers VMexit and VMM will need to emulate it fully by software - slow :\

---
DOS gives me freedom to unlimited HW access.

> I think the document didn't mention SMM. So, if SMM remains there, all
> those 16-bit things remain there as well.

Even if SMM prevails unchanged it'not usable for running dos or 16b apps. I guess they would modify SMM to 64b mode then...

---
DOS gives me freedom to unlimited HW access.