XPost: alt.folklore.computers
From: gneuner2@comcast.net
On Thu, 7 Aug 2025 17:52:05 +0200, Terje Mathisen
wrote:
>John Ames wrote:
>> On Thu, 7 Aug 2025 02:22:05 -0000 (UTC)
>> Lawrence D'Oliveiro wrote:
>>
>>> That disparity between CPU and RAM speeds is even greater today than
>>> it was back then. Yet we have moved away from adding ever-more-complex
>>> instructions, and are getting better performance with simpler ones.
>>>
>>> How come? Caching.
>>
>> Yes, but complex instructions also make pipelining and out-of-order
>> execution much more difficult - to the extent that, as far back as the
>> Pentium Pro, Intel has had to implement the x86 instruction set as a
>> microcoded program running on top of a simpler RISC architecture.
>>
>That's simply wrong:
>
>The PPro had close to zero microcode actually running in any user program.
>
>What it did have was decoders that would look at complex operations and
>spit out two or more basic operations, like load+execute.
>
>Later on we've seen the opposite where cmp+branch could be combined into
>a single internal op.
>
>Terje
You say "tomato". 8-)
It's still "microcode" for some definition ... just not a classic
"interpreter" implementation where a library of routines implements
the high level instructions.
The decoder converts x86 instructions into traces of equivalent wide
micro instructions which are directly executable by the core. The
traces then are cached separately [there is a $I0 "microcache" below
$I1] and can be re-executed (e.g., for loops) as long as they remain
in the microcache. If they age out, the decoder has to produce them
again from the "source" x86 instructions.
So the core is executing microinstructions - not x86 - and the program
as executed reasonably can be said to be "microcoded" ... again for
some definition.
YMMV.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
