| 1 |
BRM <bm_witness@×××××.com> [11-01-17 19:16]: |
| 2 |
> ----- Original Message ---- |
| 3 |
> |
| 4 |
> > I have two questions: |
| 5 |
> > |
| 6 |
> > 1) Do I have to enable microcode updates in the BIOS of my Crosshair |
| 7 |
> > IV Formula to activate microcodes push in the CPU by the module |
| 8 |
> > "microcode" ? (AMD Phenom X6 1090T) |
| 9 |
> |
| 10 |
> Not sure about BIOS, but the Linux Kernel you are running will certainly need |
| 11 |
> support enabled too. |
| 12 |
> |
| 13 |
> > 2) Does anyone know, what these microcodes do? They are fixes for... |
| 14 |
> > ...what? |
| 15 |
> |
| 16 |
> The Intel and AMD processors are more abstract than physical now. With i486 and |
| 17 |
> earlier the processors were typically hard wired; hardware "bug" fixes could not |
| 18 |
> be pushed out. |
| 19 |
> Intel's Pentium (and I don't know which AMD) started using micro-code to program |
| 20 |
> the processor. This enabled them to push out "hardware" bug fixes for the |
| 21 |
> processors. |
| 22 |
> |
| 23 |
> So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to |
| 24 |
> micro-code first, then it gets processed, and the result translated back to the |
| 25 |
> expected instruction result - essentially, emulating the x86 instruction set in |
| 26 |
> the processor. That's the simple version. |
| 27 |
> |
| 28 |
> So now when they discover a bug in the hardware they can push out a micro-code |
| 29 |
> update to either fix the "hardware" (microcode) bug or work around a hardware |
| 30 |
> (physical hardware) bug. |
| 31 |
> |
| 32 |
> Ben |
| 33 |
> |
| 34 |
> |
| 35 |
|
| 36 |
Hi Ben, |
| 37 |
|
| 38 |
thanks for your explanation... |
| 39 |
I meant: What is fixed the uc-patches? Does "mov" only except "17" as |
| 40 |
argument...or... |
| 41 |
I searched AMD for a changelog or something like but I ound nothing... |
| 42 |
|
| 43 |
Best regards, |
| 44 |
mcc |
Archives