32-bit CPU worse for 16-bit code than a 16-bit CPU..?

[SerialThriller]

Why is it that a Processor optimized for let's say...32-bit code, several years ago, runs 16-bit code slower and less efficiently than a processor that can only run 16-bit code?

 

[PWMK2]

Care to give examples?

If you're talking about old 16-bit games, that's a software issue, not a hardware one.

 

[robberbaron]

Why is it that a Processor optimized for let's say...32-bit code, several years ago, runs 16-bit code slower and less efficiently than a processor that can only run 16-bit code?

Depends on the CPU.

The Itanium, for example, is an IA64 type 64bit cpu. It sucks at 32 bit due to having to emulate it.

Either way, unless the CPU has the hardware requirements in the chip itself, it will have to require software emulation. In which case, the faster the chip, the faster the emulation. I'm sure any CPU nowadays can emulate 16bit code faster than any 286 processor, regardless of application.

 

[SerialThriller]

yea, i was referring to the Pentium 16-bit CPU in comparison to the following 32-bit Pentium Pro, which because it was 32-bit, was better on the high end of things, but didn't perform as well as the original Pentium w/ DOS and the version of Windows that was out at the time...i don't quite remember

 

[FreedomFGHTR]

yea, i was referring to the Pentium 16-bit CPU in comparison to the following 32-bit Pentium Pro, which because it was 32-bit, was better on the high end of things, but didn't perform as well as the original Pentium w/ DOS and the version of Windows that was out at the time...i don't quite remember

IIRC (because it was a long long long time ago) The last 16 bit CPU's made by intel were 386's... and the 486's were 32 bit.... I remember this because I saved up $3k for my first computer ever (back in 1992) and that was a LOT of lawns I had to mow... (2 years worth)

I ended up getting the 486 33mhz based system over the 386 40mhz machine even though the computer store said go with the higher clocked cpu because back then windows 3.1 was 16 bit.... all the pentium pro was over a regular pentium was better SMP support and more cache... basically its the originator of the XEON line (even though that name wasn't applied until PII came around)

The reason why 32 bit apps work better on 32 bit procs and 16 better 16 bit procs and 64 on 64 is because the apps are programmed to run with the specific instruction sets in those given processors. So when a 32 bit proc gets a 16 bit program it's like WTF what am I supposed to do with this data do I send it down pipe a or b, wheras the 16 bit proc knows to send it down pipe a...

if I'm wrong please feel free to correct me...

 

[Scali]

Actually, the 386 was the first 32-bit processor.
The 286 was the last 16-bit processor.
There was a 386SX-processor, which was basically a 32-bit processor with a 16-bit bus, so it could be used on a 16-bit motherboard.
But afaik, even the 386SX was not slower than a 286 with 16-bit software.
(The biggest difference between 386 and 486 was the built-in coprocessor with the 486... but at the time there wasn't a lot of software that made use of one, and the coprocessor wasn't all that fast either, so it was not that much of an advantage. The bigger cache, localbus videocards/hdd controllers and higher clockspeeds were, though).

The difference between a Pentium and Pentium Pro is HUGE, by the way.
The Pentium Pro was the first to have out-of-order execution. The Pentium still executed all code exclusively in-order.
Because the Pentium Pro could re-order the code on-the-fly, it depended a lot less on the level of optimization in the code.
On the other hand, the PPro was a terribly complex CPU because of this, and had a much longer pipeline. That is part of the reason why the Pentium could still outdo the PPro when running properly optimized code.

Another part of the reason is that Intel hadn't implemented the 16-bit emulation all that well in the Pentium Pro.
The Pentium II was basically the same core, but it had MMX added, and the 16-bit emulation was improved aswell.

Generally there's no reason why a CPU with 'more bits' should run code with 'less bits' less efficiently. You just switch the CPU to the proper modus operandi, and it decodes and runs the code as if it were in its native format.
There was just something 'wrong' in the PPro, making it decode and run 16-bit code less efficiently... I don't recall exactly what it was, but it could have been a bug in the use of partial registers. In 32-bit, the CPU is also slow when you modify a partial register, and then try to read the entire register again. The pipeline then has to flush before the register can be recombined from the parts, and then read out as a whole. Perhaps the PPro had this happen pretty much all the time when in 16-bit mode.

No CPU before the PPro had an issue with 16-bit code anyway... and I don't really know about CPUs since the PPro, because 16-bit code was out of fashion by then, and the clockspeeds and technology had gone up so far, that comparisons with 'real' 16-bit processors make no sense whatsoever anyway.

 

[SerialThriller]

hm, thanks a lot for replies so far. So, if indeed a 16-bit CPU runs something faster than a 32-bit CPU because that code is 16-bit, the reason is because of the architecture of the two CPUs in comparison to the code and also the particular instruction set in the two CPUs. And from what i'm told elsewhere...instruction sets are made for the type of CPU? so like a 16-bit proc has an instruction set better suited for 16-bit code...etc

And btw, i'm just using 16-bit vs 32-bit as an example, since that's what i've come across so far, and i don't know about the situation w/ current CPUs

 

[Scali]

Well, x86 is its own universe where the logic of other CPUs doesn't really apply.
In general each CPU has its own instructionset, that best matches the kind of applications that the CPU was designed for.

But with x86, backward compatibility is more important than optimum performance. So the instructionset is never redesigned, it is just constantly extended. The 32-bit instructionset is very similar to the 16-bit instructionset. And the same with the new 64-bit instructionset. It is again very similar.
This is done because it makes it easier to design a CPU that runs 16, 32 and 64-bit code well. Ofcourse the downside is that it isn't optimal for any of the three.

Anyway, the hardware is just one half of the story. Software is the other half. You also have to design your software for the target CPU. That makes the x86-story even more complicated. Sometimes an application that is well-optimized for eg a Pentium will run terribly inefficient on a PII, for example.
That makes it all hard to compare 16-bit, 32-bit etc...
Is the problem in the hardware, or is it in the software?