Intel microcode and Forth
Albert van der Horst
Scott Mueller's Upgrading and repairing PCs
He mentions that Intel processors since P II have a way to change
their microcode. This is done in the BIOS whenever a bug in the
microcode has come to light.
Patching the microcode allows to turn a processor into
a Forth processor, in principle. (And it seems to have been
done.)
Has anybody heard more about this and/or have done experiments
in relation to Forth?
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Mat
wrote:
Possibly this project is of interest for you:
http://urbanmyth.org/microcode/
AMD processor's doesn't seem to have the option for microcode updates
but a emulation work-around is known (but rarely used because paging
etc. isn't avariable) which should be usable with all IA32 cpu's from
Intel and AMD. It offers, as I know, the best possible performance for
code-emulation in software because of using a unreal like mode:
After setting up protected mode all segment gegisters (important, not
only the data but also the cs register) must be loaded with 32 bit
descriptors. After switching back to real mode, instead of standard
unreal a another, hidden mode is active which offers a flat 4 GB
address space for both code and data (it is otherwise very similar to
SMM mode). Instead of the unreal mode, this is a REAL but undocumented
processor mode ! As the paging and protected mode logic is definitly
not active, memory, register operations and (most important)
interrupts should performs faster as in all other modes.
Interrupt handling is the same as in real mode with exception of the
IRET opcode which now work with 32 bit linear addresses. If one use
the interrupt vectors for handling illegal opcodes a stack processor
can be emulated with ease.
-Mat.
Anton Ertl
>I'm reading
> Scott Mueller's Upgrading and repairing PCs
>
>He mentions that Intel processors since P II have a way to change
>their microcode. This is done in the BIOS whenever a bug in the
>microcode has come to light.
>
>Patching the microcode allows to turn a processor into
>a Forth processor, in principle. (And it seems to have been
>done.)
Tell me more about the "has been done" part. I have never heard of
anybody outside Intel successfully modifying the microcode to do
anything useful.
>Has anybody heard more about this and/or have done experiments
>in relation to Forth?
In any case, even if we could do it, I doubt that this would be a good
way towards a high-performance Forth system: AFAIK the most common and
quickly decoded instructions are decoded by hardware, not through a
microcode decoder; you could only change the others, and these can
only be decoded at at most one instruction per cycle.
Also, optimizations that a good native code compiler performs are not
performed if you just compile the Forth source to Forth instructions,
and let the microcode engine expand these instructions to microcode
sequences.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Anton Ertl
>If one use
>the interrupt vectors for handling illegal opcodes a stack processor
>can be emulated with ease.
Even in real mode, that approach is slow, probably slower than
threaded code.
Wayne
<an...@mips.complang.tuwien.ac.at> wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>> I'm reading
>> Scott Mueller's Upgrading and repairing PCs
>>
>> He mentions that Intel processors since P II have a way to change
>> their microcode. This is done in the BIOS whenever a bug in the
>> microcode has come to light.
>>
>> Patching the microcode allows to turn a processor into
>> a Forth processor, in principle. (And it seems to have been
>> done.)
>
> Tell me more about the "has been done" part. I have never heard of
> anybody outside Intel successfully modifying the microcode to do
> anything useful.
>
>> Has anybody heard more about this and/or have done experiments
>> in relation to Forth?
>
> In any case, even if we could do it, I doubt that this would be a good
> way towards a high-performance Forth system: AFAIK the most common and
> quickly decoded instructions are decoded by hardware, not through a
> microcode decoder; you could only change the others, and these can
> only be decoded at at most one instruction per cycle.
> - anton
I haven't been following this thread due to time constraints, but could
you implement Pentium colorforth in microcode, as there is a one to one
correspondence already between colorforth instructions and some Pentium
instructions? Would you be able to add improvements that make sense.
Before anybody asks, why if colorforth is already in machine code,
streamlining (if you are able to switch instructions, and remap and pack
instructions at all, you then can have more in cache (but caches are so
large now) and switch instructions for different tasks, with speed
optimizations, if any possible, that can be gained from packed
instructions).
Wayne.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Elizabeth D Rather
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>> I'm reading
>> Scott Mueller's Upgrading and repairing PCs
>>
>> He mentions that Intel processors since P II have a way to change
>> their microcode. This is done in the BIOS whenever a bug in the
>> microcode has come to light.
>>
>> Patching the microcode allows to turn a processor into
>> a Forth processor, in principle. (And it seems to have been
>> done.)
>
> Tell me more about the "has been done" part. I have never heard of
> anybody outside Intel successfully modifying the microcode to do
> anything useful.
Well, in the 80's Greg Bailey implemented a lot of Forthish primitives
in an NCR computer, which was all microcode. His system included a
microcode assembler, which was used within NCR for a lot of non-Forth
purposes. The resulting system was the basis for a product line of
hospital management systems marketed by NCR for at least 10 years.
>> Has anybody heard more about this and/or have done experiments
>> in relation to Forth?
>
> In any case, even if we could do it, I doubt that this would be a good
> way towards a high-performance Forth system: AFAIK the most common and
> quickly decoded instructions are decoded by hardware, not through a
> microcode decoder; you could only change the others, and these can
> only be decoded at at most one instruction per cycle.
>
> Also, optimizations that a good native code compiler performs are not
> performed if you just compile the Forth source to Forth instructions,
> and let the microcode engine expand these instructions to microcode
> sequences.
All true. That NCR computer was all microcode, and this was also before
any serious Forth optimizing compilers had been developed.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Mat
wrote:
Hello,
Your'e right, it is slow compared to JIT compiling. After some
testings quite faster than token threading though (on my Athlon64).
I must correct my statement above. All newer AMD cpu's other than the
first Athlon64 ones can update there microcode for all vectored
instructions but sadly in an incompatible way to Intel processors.
-Mat.
dke...@hotmail.com
Hi
My understanding is that these patch RAMs are used to solve
problems that are caused by interactions of instructions rather
than just replacing an instruction.
Most microcode has been tested to do what it is suppose to
but some times, not all the possible out-of-order or piped
combinations work correctly.
Since these patch RAMs are for this purpose, when used,
they tend actually slow the processor down quite a bit
to run. They have to first turn off all optimizations
and then execute. This takes time and regular execution
of code is usually faster.
Dwight
Mat
Hello,
I don't know if it's possible to replace microcoded instructions on
Intel cpu's but for newer AMD processors can replace microcoded
instructions already handled by hard-wired sequences. There exist one
AMD U.S. Patent Nr. 6438664 ("Microcode patch device and method for
patching microcode using match registers and patch routines") which
discuss this in detail as I know.
But yes, generally the problem with microcoded instructions (vectored
opcodes) on AMD cpu's >= K8 architecture is there serial execution so
these instructions block the DirectPath pipeline.
-Mat