OSDev.org

I'm really liking this Microcode idea..

I have a few questions though:
1) Do these new 64-bit AMD & Intel CPU's use Microcode to add new CPU instructions?
2) How long have they been doing this?
3) Can anyone implement their own extensions to these CPU's?
4) Is there any techniques for writing such Microcode or is it all proprietary and manufacture dependent?

Does each company release Microcode upgrades? And is it possible to update the aforementioned code through ones hobby OS?

And do they need to be uploaded every time you boot the system?

Thanks

@Brynet-Inc, This is too low for C coders to understand, Its a assembly only field, this is even lower than ASM.

If that ever is effectively and widely possible, you could even risk losing your CPU, just like the CIH virus used to destroy your motherboard firmware using its upgrading characteristics

Dex wrote:@Brynet-Inc, This is too low for C coders to understand, Its a assembly only field, this is even lower than ASM.

Dex, Please don't belittle my intelligence.. I tried to be polite in my original post.

This is a request for information, not a request for someone to analyze if I'm smart enough to understand the provided information.

We are here to learn...

~ wrote:If that ever is effectively and widely possible, you could even risk losing your CPU, just like the CIH virus used to destroy your motherboard firmware using its upgrading characteristics

There is risk in losing your CPU?

I would imagine manufacture updates are stored in the BIOS.. And the CPU has the original on ROM or something..

And temporary updates through the OS might be stored in RAM?

I think the CPU manufactures might update the Microcode through BIOS updates. (Getting BIOS manufactures to ship the Microcode in new updates..)

@Dex: Do you understand it?

@Brynet-INc: I'm gonna hear about micro code later this semester and even program a fpga cpu (where you design the microcode, a compiler translates this into the real low level stuff and then this is put into the chip - eeprom/flash sort of thing) - so I'll delve into the nittygritty of this very much later on.

ad 1: yes, they do. But I'd rather say they do bug-fixing - like removing floating point errors and such. Even RS6000 RISC CPU's sport micro code - it's just less and no SIMD-Instruction at all.

ad 2: Ah, sorry, this I cannot answer yet. Have to google for it.

ad 3: Yeah, anyone with the right hard & software, of course - and with the proper KNowledge. There's special languages for doing Microcode stuff.

ad 4: I do think it's manufacturer dependent, but they need to tell the os developers how to write microcode patches to the target cpu so the os can patch faulty cpu's. But alas, I am yet to hear about this in excess.

Whether the average OS Developer is gonna be able to patch up cpu microcode depends on his ambitions - delve into the linux code which does exactly this stuff and implement it in his own os.

Upload of microcode each time the os boots: I don't think so. Microcode is usually written into some kind of flash-memory on the fpga-box - the cpu. It should remain there.

I hope I could shed some elucidation on your questions. If I 've got something the wrong way around, my apologies. Me is learning, always learning.

@nobody in special: I'd wish for more politeness in the sense of giving useful answers instead of dismissing ppl with ruden sentences.

distantvoices wrote:@nobody in special: I'd wish for more politeness in the sense of giving useful answers instead of dismissing ppl with ruden sentences.

To be fair, I guess I do it myself at times...

Thanks for clearing some things up though.. but I'm thinking Microcode updates might have to be "uploaded/loaded" at boot if the BIOS/motherboard manufacture hasn't released any updates..



OT: @distantvoices, How is your OS project going btw?

Well according to the Intel manuals you have to redo the microcode update each time the cpu is hard reset:

Intel System Programming Guide Part 1 wrote: The effects of a loaded update are cleared from the processor upon a hard reset. Therefore, each
time a hard reset is asserted during the BIOS POST, the update must be reloaded on all processors
that observed the reset. The effects of a loaded update are, however, maintained across a
processor INIT. There are no side effects caused by loading an update into a processor multiple
times.

It also mentions something about encryption and that the updates are made for a specific set of processors. I don't think that it would be easy to make your own update.

Each microcode update is designed to for a specific processor or set of processors.

This is what it says about the data size field in the microcode update

Specifies the size of the encrypted data in bytes, and
must be a multiple of DWORDs.

EDIT: A bios capable of performing microcode update is expected to have a set of routines available though int 15 0D042H that allows you to get access to the microcode update and to update the microcode update to a newer version. The microcode updates are stored in NVRAM and applied on every boot up. So if you could figure out the format of the 2048 byte micro update package you could have the bios load it for you on every boot up.

hmmm..a micro-code based emulator would be very great! I think Microsoft VPC might actually support this, It has something with the NVRAM listed in their bios so..
btw forgive me if I sound stupid, as I have never known what NVRAM is..

Hi,

Brynet-Inc wrote:1) Do these new 64-bit AMD & Intel CPU's use Microcode to add new CPU instructions?

Not that I'm aware of. Microcode is used to fix bugs in some CPUs (for e.g. disabling stuff that didn't work), but not for adding new instructions.

Brynet-Inc wrote:2) How long have they been doing this?

I think Intel started doing it with P6, but it may have been earlier. I'm yet to find any official documentation that indicates any AMD CPU supports microcode updates.

Transmeta were using something similar much earlier. Their CPUs had something like a RISC core and dynamic translation, where the code that does the dynamic translation (called the "code morphing software" or CMS) can be updated (and AFAIK was stored in the L1 cache). I've seen attempts at reverse engineering Transmeta's CMS updates, but they weren't complete enough to be useful.

Brynet-Inc wrote:3) Can anyone implement their own extensions to these CPU's?

In general, no.

To increase the amount microcode updates can do CPU manufacturers would need to reduce the amount that is hardwired, and therefore reduce performance. Intel would carefully select which parts are hardwired and which parts are effected by microcode. The idea would be to maximise performance while also attempting to maximising their ability to fix CPU bugs later.

For example, allowing the behaviour of the "ADD" instruction to be changed via. microcode updates would cause performance problems and wouldn't be worthwhile (as the ADD instruction is rarely buggy anyway), while allowing the default setting of the enable/disable flag for the "fast string instructions" optimisation to be set by microcode updates won't seriously effect performance (and might be useful, as this feature may be buggy due to complex cache consistancy problems involving string operations that cross boundaries between areas with different caching types) .

Also, (for Intel CPUs) without extremely detailed information that would only be available within Intel itself it'd be almost impossible to create your own microcode update. The first problem is that the microcode updates themselves have some form of encryption. The next problem is figuring out what the microcode update contains.

I would assume for Intel CPUs there's a set of flags that enable/disable certain features of the chip, plus an array of bits that controls which instructions are undefined, plus some actual microcode (which is only used for larger more complex instructions - smaller instructions are hardwired AFAIK). It would be extremely unlikely that you'd be able to significantly change the CPU itself (for e.g. uploading some microcode to make it run SPARC code would be impossible, and adding your own instructions would be extremely unlikely). It may be possible to modify exisiting larger instructions (like CPUID, LOOP, ENTER/LEAVE, etc) that use microcode, but you'd need to think of a reason to bother first.

Even with the necessary information any microcode update will only work for CPUs with the correct stepping. For e.g. an update for one Pentium III chip won't work on all Pentium III chips.

Basically it'd take a huge amount of time to create something that would be almost useless.

Brynet-Inc wrote:4) Is there any techniques for writing such Microcode or is it all proprietary and manufacture dependent?

AFAIK the method of updating the microcode is manufacturer specific, while the updates themselves are "CPU stepping" specific and proprietory.

Brynet-Inc wrote:Does each company release Microcode upgrades? And is it possible to update the aforementioned code through ones hobby OS?

Mostly, each company that uses microcode updates releases them to BIOS/motherboard manufacturers. BIOS/motherboard manufacturers include them in their "BIOS updates", and end users download the BIOS updates and re-flash their BIOS.

The BIOS itself has several different microcode updates stored in flash memory (and chooses the most suitable microcode update to upload into each CPU during boot). Intel did release specifications for BIOS functions that were meant to be used to change the microcode updates stored in the BIOS' flash memory. I'm not sure anyone actually uses them in practice though, as normal end users can't get the microcode updates (except as part of BIOS updates).

I see no reason why a hobby OS couldn't use these BIOS functions to change the microcode updates in the BIOS' flash memory (and therefore effect which microcode update is uploaded into the CPU the next time it does a hard reset). I personally can't see the point - it's easier for end users to reflash the BIOS.


Cheers,

Brendan

Dex wrote:@Brynet-Inc, This is too low for C coders to understand, Its a assembly only field, this is even lower than ASM.

Then I guess it's good that most people aren't solely C coders, right?

That was pretty rude Dex...

ehird wrote:That was pretty rude Dex...

Have you ever heard the story of the Pot and the kettle?

As for microcodes... something similar that did allow creation of instructions could be useful to OS's that want to support high end processor comands on a low end system. It might cause slowdown, but that will teach the cheap skates to not have a top of the range processor

As for the current implemention, i can't see it being very useful beyond fixing faults in the processors hard wiring.

I would say something, but Dex probably wouldn't understand the abstractness of it.... jk, but not really. That was just stupid...

anyway though..I guess I'll leave it alone now...

Tyler wrote:

ehird wrote:That was pretty rude Dex...

Have you ever heard the story of the Pot and the kettle?

As for microcodes... something similar that did allow creation of instructions could be useful to OS's that want to support high end processor comands on a low end system. It might cause slowdown, but that will teach the cheap skates to not have a top of the range processor

As for the current implemention, i can't see it being very useful beyond fixing faults in the processors hard wiring.

It's as far as I'm concerned mainly a processor creators way of hiding ugly x86. You move the instruction decoder to a transcoder, add caching on the intermediate layer and make a microarchitecture below it that has more pleasant architectural bits. You then transcode all code fully automatically at 2 instructions per cycle or such and further ignore the input code.

Side advantage is that you can replace an eeprom or sram image when you appear to have made a mistake in silicon or production to avoid certain bits of silicon and you can in theory tune each of the chips for their own performance characteristics or such.