Hi all
I have just come across the term micro-code and after some research I'm still confused. Some says it is firmware, ie EPROM level stuff, others say that it is "lower" than Assembly laungage, ie between the machine code and the processesor.
Can somebody shed some light on the subject and how/where it fits in around the WIN32 platform.
Cheers
Kim
Posted on 2001-11-16 11:00:17 by fiddler
The original meaning (was it M. V. Wilkes?) of microcoding or microprogramming was a direct mapping from the opcode bit fields to sets of suboperations. I believe the PDP-8 took this further than other machines. I'm not familiar with the RISC architectures to know how far they've taken this idea.

The more common form of microcoding is to build a fast processor and write an interpreter for it. Because this fast processor is internal, you can design it any way that seems simple and fast. This fast processor might even use the original ideas of microcoding. Most of the IBM (360/370) mainframes are microcoded.

To take the idea further, I know of one series of projects that used a microcontroller as the "microengine". Unlike p-code, the application RAM/ROM was not the same as the microcontroller RAM/ROM, so this qualifies as microcoding.

Because of the micro- prefix, the term microprogramming has also been applied to the ordinary programming of microprocessors and microcontrollers. And that's why it's more confusing than it ought to be.
Posted on 2001-11-16 14:09:21 by tank
So you could have a processor that supports real-time C++ code?

*me starts thinking*... Probably would be slow though...
Posted on 2001-11-16 17:50:49 by Kenny
Ugh. C++ was not designed for interpretation.

However, there is the BASIC STAMP. It uses a very high speed PIC, but I don't know where it stores the (BASIC) program and data.
Posted on 2001-11-16 21:25:58 by tank
As far as mainframes, tank is correct, microcode is still the heart of the S/390 (and 360/370) mainframes. IBM uses it to adapt the standard instuction set to various hardware configurations. For example, the "logical" machine is based on 32 bit words. Back in the early days, small mainframe hardware (the 360/30) could only access memory 8 bits at a time. It was microcode's job to put 4 8 bit bytes into a logical 32 bit word, when needed. The next level mainframe (the 360/40) was a native 16 bit machine. So it's microcode only had to fetch 2 16-bit chunks to make the logical word.

Actually, the "native" 360 hardware was the 360/65, a 64 bit machine. The other models really just emulated what the 65 did naturally. While things like registers and operands are only 32 bits in the architecture, other important stuff like the Program Status Word (PSW), and Channel Command Words (CCW) are 64 bits. This is why the 65 kicked ass in things like teleprocessing, that uses long CCW chains to poll all of the terminals attached to the computer. Bit I digress...

Think of the hardware as being made up of various resources, like memory, registers and channels. Microcode analyzes the instruction, and does the actual work of fetching, operating on, and storing the result, among other things. The nice thing about microcode is that it's software, and can be changed, enhanced and improved over time. Today, microcode provides various "assists" to the mainframe. Common operating system functions that were software in the past, have been moved to microcode. Microcode can take advantage of the specific native hardware, and do the complex operation faster that the "emulated" instruction set can. You can also have different microcode do different things on the same machine. For example, most models have a different microprogram to run diagnostics on the hardware.

Hope this helps :grin:
Posted on 2001-11-16 23:08:00 by S/390
Great

Where in the WIN32 architecture does the Microcode excist and how do you access it.
Presumming that microcode is used on the WIN32 platform.
Obviously from above it is proccessor specific.
An example wouldbe great possible.

Cheers
Kim:grin:
Posted on 2001-11-17 00:46:10 by fiddler
Kim,

On an x86 processor you cannot access the microcode at all. You need to remember that even though x86 processors have made many advances over time, they are not mainframes and simply don't have the facilities of a much larger processor.

Basically the distinction on an x86 is based on the processor core, the x86 instruction set have been around for a long time and were originally hard wired into an 8088. Processor technology has changed very dramatically over 20 years and the internal structure is very different to an 8088 but because of demand, backwards compatibility and so on, the manufacturers still supply the x86 instruction set by constructing them in microcode. Microcode in this instance is a set of lower level processor capacities that can be combined at the manufacturing stage to produce the instruction set that they want.

Now the problem would be if you could get at the microcode is that it is processor model specific so it absolutely would not run on an earlier or later model. You will find that you will not have performance problems by using the existing instruction set in code.

Regards,

hutch@movsd.com
Posted on 2001-11-17 05:07:36 by hutch--
Hutch, it's not entirely true you can't get at the microcode. With
intels ppro core, and later models, you can apply microcode paches.
These patches must be applied early before too much initialization
goes on, which means BIOS. They are effective until the processor
is reset. This means the only way (that I know of, at least) to get
a microcode update, is to flash a newer bios. And of course the
microcode patch format is intel proprietary. *but it can be done*.
And intel even documents how to apply the patches...
Posted on 2001-11-17 09:14:53 by f0dder
Well the only thing I know about mainframes now is that you can apply microcode, ha.
So it's sort of like applying the status/mode word to a UART chip.
Easy.
Its always interresting when you see something you haven't heard of before.

Thanks
Kim
Posted on 2001-11-17 15:03:04 by fiddler
f0dder,

Patching a BIOS is one thing, writing microcode at an application level is another, basically FOR-GET-IT until Intel or AMD or whoever else makes a processor that has the access to this level of code.

Regards,

hutch@movsd.com
Posted on 2001-11-17 19:06:20 by hutch--
If you get access to the core micro-code, surely it stops being an x86...
So writing micro-code for the x86 cannot be done!

Mirno
Posted on 2001-11-17 19:54:23 by Mirno
Like f0dder said, it is theoretically possible to rewrite the micro-code for the x86 processor, therefor making your own instrction set. But, this would require a brand new OS, and a whole lot of time :) So, as hutch said, forget it :)
Posted on 2001-11-18 00:57:27 by Kenny
I agree hutch, forget it. I was just saying that it can be done. However,
not by *us*. Only intel knows the format of their patches, and even
if you made a patch yourself, getting it into the bios would not be
easy.

And who knows what those patches can do? I know they have fixed
bugs in some instructions, and have done speedups as well... but
adding totally new instructions? Probably not, as that would require
rewriting the decoders and pipelines and whatnot... something I don't
think you can do in microcode on x86 processors =). Except perhaps
the crusoe...
Posted on 2001-11-18 07:41:07 by f0dder
Yes, in theory you could add new instructions by updating the microcode. This is exactly what IBM did with the decimal inscructions on the mainframe. Decimal instructions allow you to do math on variable length packed decimal numbers in memory. Since the source and destination are in memory, no additional hardware is needed (unlike floating point that needs hardware registers). The new microcode recognized the new op codes, and included the logic to do the math.

:)
Posted on 2001-11-18 09:25:30 by S/390
Actually, getting new microcode into BIOS is not too hard, there's even tools for that, like this one:
ftp://ftp.heise.de/pub/ct/ctsi/ctmc10.zip

Also, I think that the BIOS is not the only program that can load microcode updates. At least Win2K seems to have its own microcode update loader, the question is, why?

How the updates are actually loaded, is described in Intel Architecture Software Developers Manual vol 3. Anyway, the format of microcode update data is still Intel's secret.
Posted on 2001-11-18 11:12:04 by Janne
Aha, didn't know about that tool... so my idea of getting the microcode
into the BIOS sorta involved disassembly and crossing fingers, hoping
you I did it correctly ;).

As for only the BIOS being able to load the update, this is what
the intel p3 docs have to say:

The microcode update must be loaded to the processor early on in the POST, and always
prior to the initialization of the P6 family processors L2 cache controller.
Posted on 2001-11-18 11:29:43 by f0dder
Whast I suspect after having upgraded the bios on a new p4 is that reflashing the bios probably adds the microcode only to the bios and does not touch the processor at all.

This is something like a program storing a pile of settings or adjustments in the registry as the form of binary cannot be accessed.

Microcode as I understand it in current x86 processor design is hard wired at the hardware level and its an adjustment that can only be done in the fabrication stage. It does make sense to be able to tweak bits and pieces depending on usage.

Where I see the problem is if the info becomes public so that the virus ratbag fringe find a way to access the flashable part of the bios. I am fortunate that the Intel board that came with the p4 has a jumper setting that reloads the bios with default settings so it can be restarted. A trashed bios is a pain but if you can fix it without having to remove it and send it away, the recovery is no big deal.

Regards,

hutch@movsd.com
Posted on 2001-11-18 15:48:52 by hutch--
Yes hutch, the microcode updates are temporary (ie, until processor
reset).

As for the microcode being hardwired... well, that would be a logical
assumption. But it seems the "microcode patches" can do quite
a bit... iirc, they managed to add some impressive speed improvements
to some instructions, enough that just "tweaking a few values"
sound improbable.

It wouldn't hurt if the microcode patch format became public, as
it will be no worse than a mal-flashed BIOS. And information on how
to flash BIOSes has been public knowledge since CIH hit the streets,
which is quite a while ago.

Knowing the format of the microcode patches probably isn't
terribly useful anyway... ok, we already know the basic "file" structure
of the patch (it's in the p3 docs), but the contents... oh well, I don't
care much :).
Posted on 2001-11-18 16:12:04 by f0dder