From Newsgroup: comp.arch

jgd@cix.co.uk (John Dallman) writes:

It was a plausible concept, but as best I remember from reading the white >paper, they were fuzzy about just how much 32-bit software it would run,
if you weren't an expert on x86 operating modes and memory models.

If it had been "16-bit goes, all 32-bit stays, including operating
systems" they'd likely have got a lot more buy-in. But would that have
been a worthwhile simplification?

The problem is that there is no sharp boundary between 16-bit and
32-bit code (whereas there is a sharp boundary between 32-bit and
64-bit code).

You can execute code from a 32-bit code segment, and then you get
operand size=32b by default (no-byte instructions work on 32 bits),
and address size=32b (32-bit address registers and the newfangled
addressing modes, including those with SIB) by default.

But you can use a operand size prefix, and your instruction will work
on 16-bit units. I expect that lots of "32-bit" code uses the operand
size prefix, e.g., for implementing Java's short type.

And you can use an address size prefix, and you will get 16-bit
address registers and the 8086 addressing modes (and 8086 addresing
mode decoding).

And you can execute code in a 16-bit code segment, where operand
size=16b by default and address size=16b by default (and the
addressing modes are those of the 8086). There you can use the
operand-size prefix to use 32-bit operands and the address-size prefix
to switch to 32-bit addresses and the newfangled addressing modes.

Let's assume that x86s would have disabled 16-bit code segments and
the address-size prefix. Given how easy it was to use these features,
can we guarantee that there is no OS and on program that is still of
interest that does not contain such stuff?

And how much would eliminating those features save? They managed to
put it into the 386 with 275,000 transistors. Ok, these days you have
decoders that can decode 3x3 instructions per cycle, but still, the
reduction in size or complexity is probably not that great.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

jgd@cix.co.uk (John Dallman) writes:

It was a plausible concept, but as best I remember from reading the white >paper, they were fuzzy about just how much 32-bit software it would run,
if you weren't an expert on x86 operating modes and memory models.

If it had been "16-bit goes, all 32-bit stays, including operating
systems" they'd likely have got a lot more buy-in. But would that have
been a worthwhile simplification?

The problem is that there is no sharp boundary between 16-bit and
32-bit code (whereas there is a sharp boundary between 32-bit and
64-bit code).

You can execute code from a 32-bit code segment, and then you get
operand size=32b by default (no-byte instructions work on 32 bits),
and address size=32b (32-bit address registers and the newfangled
addressing modes, including those with SIB) by default.

But you can use a operand size prefix, and your instruction will work
on 16-bit units. I expect that lots of "32-bit" code uses the operand
size prefix, e.g., for implementing Java's short type.

And you can use an address size prefix, and you will get 16-bit
address registers and the 8086 addressing modes (and 8086 addresing
mode decoding).

And you can execute code in a 16-bit code segment, where operand
size=16b by default and address size=16b by default (and the
addressing modes are those of the 8086). There you can use the
operand-size prefix to use 32-bit operands and the address-size prefix
to switch to 32-bit addresses and the newfangled addressing modes.

Let's assume that x86s would have disabled 16-bit code segments and
the address-size prefix. Given how easy it was to use these features,
can we guarantee that there is no OS and on program that is still of
interest that does not contain such stuff?

And how much would eliminating those features save?

We (AMD circa 2002) looked at eliminating A20-bit addressing. By that
point in time it only took about 10 gates of logic to continue having
that feature, whereby having a CPUID bit telling you it was not present
was at least 50 gates.

I suspect other bit-ed-ness would have similar low costs at that point.

They managed to
put it into the 386 with 275,000 transistors. Ok, these days you have decoders that can decode 3x3 instructions per cycle, but still, the
reduction in size or complexity is probably not that great.

- anton

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to quadi <quadibloc@ca.invalid>:

On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:

Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.

That is not the right comparison. If my old 16-bit software doesn't run at >full *native* speed on my shiny new 64-bit computer, then I still have to >run out and buy new software to get my work done faster.

That doesn't strike me as a reasonable argument. Any 16 bit application is likely to be very old, like before 2006. Microsoft ended DOS box support
with Windows Vista, 20 years ago. If the native performance of the program
was good enough 20 years ago, simulated performance today should be plenty fast.

If you want it to run faster, indeed, get newer software that takes advantage of 64 bit architecture and more than 1MB of addressable memory.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2