Tim wrote:
Bob F wrote in news
Remember, the actual hardware natively only executes instructions like
compare, add/subtract, move, etc. The kinds of things one would load by
hand in binary back in the old days. CPU designers have layered microcode
on top of that to allow compilers to issue more complex instructions that
the microcode will then break down into the atomic instructions the
hardware recognizes.

I don't know how old some of you are, but back around the turn of the
century there was a big foofurah about RISK (reduced instruction set)
processors. What those did was reduce or eliminate the microcode, so that
the compilers were forced to actually output atomic instructions that
could be run immediately without microcode. The thought was that there
were times when the microcode was executing instructions that weren't
really needed. The Holy Grail of RISK processors was 'one instruction,
one clock cycle', as opposed to the multiple cycles most microcode
instructions took. It made the compiler do more work, but that was seen
as a one time thing, and was counter-balanced by faster execution. At the
time, this was early Pentium days, it did make a difference. Now that the
hardware has gotten so fast, there really is no advantage to using the
RISK architecture, so for the most part it has gone by the wayside.

What I am trying to show here is that the actual hardware can only
execute the few atomic instructions designed into the die. Most of the
complete processor instructions set is actually executed in microcode
that breaks each complex instruction down into multiple atomic
instructions for execution. So yes, microcode is loaded every time the
processor resets/powers up, and can thus be upgraded by a new BIOS
version.

RISC is still around. And MIPS "isn't dead yet", because chips
based on it, are used in routers and the like. A venture capital
firm bought the MIPS group. So if new MIPS chips are to be spun,
there is a body to help.

https://en.wikipedia.org/wiki/MIPS_Technologies

The CISC instruction set doesn't have to take multiple cycles
for every instruction. Some instructions (especially ones
register to register), should execute in a single cycle.
They wouldn't need microcode.

More complex instructions may require microcoding, to
save on dedicated resources to make the instruction work.

Most of the instruction store will be non-volatile (ROM).

The Writeable Control Store (Microcode) allows trapping
an instruction, and replacing it with a sequence of
simpler operations. And that's how a "bad" instruction can
be patched. I could replace a "bad" 4 cycle instruction, with
a repaired 4 cycle instruction. I could trap a bad single
cycle instruction, and replace it with a 3 cycle sequence.
Generally, the replacement should not be faster. If the
instruction is infrequently used, nobody notices this.

Instruction trapping has been around for a long time.
When you added a FPU to your CPU back in the old days,
an "F line" instruction would trap, and the FPU would
do the work instead of the CPU. If the FPU was not
present on the motherboard, the operation could be
emulated in some (very slow) stream of instructions
by the CPU. Almost like "taking an interrupt". This allowed
computer owners to pony up some $$$ for an FPU chip, if
they wanted the equivalent of Excel to run faster.
In current times, you can have two FPUs on the CPU
die, and no tricks are needed.

Even an FPU doesn't complete complex math instructions
in one clock cycle. Every FPU is a space/time tradeoff,
and the slower they make it, the fewer square mm it takes
to implement. And then you have room for multiple of them,
and can retire two floating point operations in the same
tick. An FPU is microcoded in a sense, as you have
normalize and denormalize as part of the sequence.

https://electronics.stackexchange.co...-point-numbers

If I use Booths Algorithm, I can cut the multiply part
of the Mantissa by a factor of two.

http://www.cs.cornell.edu/courses/cs314/2004fa/l12.pdf

https://en.wikipedia.org/wiki/Booth%...tion_algorithm

Handling the exponent, normalizing and so on, comes after that.

On 1/15/2018 11:54 AM, Andy Burns wrote:
mike wrote:

Exactly what is microcode in this context?
Recent intel processors don't natively execute x86 or x86_64
instructions that compilers or humans produce, they use a lower level
internal microcoded instruction set. So to a limited degree they can
issue new microcode (which the CPU will only accept if it recognises a
signature on it) that alters how the processor actually runs.

It appears that there's a new class of microcode that can directly
change persistent code within the microprocessor itself???
No intel CPU microcode needs to be loaded into the CPU at every reboot
(by the BIOS, or by the O/S)
Part of the BIOS is microcode for each processor it can handle. I have
gone through the process of modifying the BIOS for motherboards to allow
them to handle processors they were not designed for. I would think this
is the microcode they are talking about.

The BIOS typically has room for 8 microcodes (the ones I dissected
were like that). Since a particular socket ("LGA775") only supports
a limited range of CPUs, that's "complete coverage" as far as the
motherboard maker is concerned.

An example of a failure, would be my Tualatin on the P2B-S. The
BIOS used to call it a "Pentium II", because it didn't know any
better. By manually installing a 2KB microcode for the Tualatin,
in the Award BIOS microcode cache (a storage area outside of
microcode.dat), I was able to patch the P2B-S so that it said
"Pentium III" when it booted :-) That's an example of a situation,
where a user didn't need the motherboard maker, to fix stuff. I doubt
you can do this any more, as microcode lengths now are variable
length, in multiples of 2KB. And I don't know if the Award-specific
API exists any more.

Whereas the microcode loader for the OS, has microcode for *hundreds*
of CPUs. All the way back to the dawn of time. I doubt they even
bother trimming off the irrelevant ones, as the file from Intel
is relatively small, and can just be pumped into the loader
sight-unseen. Each microcode is signed and has a family code
in the header, and as long as Intel has unique identifiers
for processors, there's no danger a "P5" microcode will go into
a "Coffee Lake" by accident.

Paul