Has anyone ever updated their CPU microcodes to run the latest

>>52236336
That's not how it works.

Good luck finding a verifiable sub-sector GDI manipulator with hash 12 sprites.

I don think that's even technically possible

Highly related: https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_microcode_updates

>>52236398
I coded my own sub instructor chain with a reverse python backdoor.
It's easy anon, if I can do it you can too.

>>52236511
This. My cpu has not received an update since 2013 unfortunately :^(

File: g.png (155KB, 845x794px) Image search: [Google]

155KB, 845x794px

Did a bit of search.

Microcodes are heavily encrypted and kept secret and has digital signature that must match before it can be used . What little is availble to users/oem is done as a temporary patch via some type of cache (kept powered by battery).

Probably won't ever be done in any effective way until we can get more info from intel/amd or a leaker from intel/amd shares the secret.

>>52236787
So then the reason Assembly got forked so hard is because different processor families encrypted their microcode instruction sets? Interesting.

>>52236787
Open hardware when.

AMD does the same I suppose?

>>52236973
when glorious RISC-V gets picked up by someone who knows microprocessors and pipelines and manufacturing are open and possible for small tech companies/ rich individuals.
I.e. never

>>52236787
I assume this isn't the case for ARM given that it is a RISC processor
Am I correct?

>microcodes encryption are hacked and reverse engineered
>old 2600k gets newest instruction set, HEVC
>it lives on for another 10 years
>intel bankrupts itself
kek