On Mon, Feb 21, 2011 at 08:44:35AM -0600, Scott Duplichan wrote:
This really isn't relevant, but microcode patch source code certainly exists, as does source code for the main microcode that the patch modifies. A microcode assembler converts the source code into binary form.
I think it's relevant. In any case, thank you for the information.
Think about what it would take for public microcode patch source code to be useful. First, the processor vendor would have to publish the thousands of lines of source code for the microcode that will be patched. Next, the microcode assembler and related tools would have to be published. At that point, a lot of training is needed to even understand the microcode. Microcode is not written in any standard programming language. The language is completely different for different processor vendors, and even for different processor models in some cases. Anyway, assume that somehow a non-employee became a microcode expert for a particular processor model. Why would the patch need to be modified? The patch corrects a processor erratum. To modify microcode in a way that works around a processor erratum usually requires details of the processor design that are not published.
Yes, I know the processor is not open hardware. Yet, the issue does not vanish just because of this.
You say it would require an expert. Well, that's what average people think of free software, it takes an expert to modify a program, so who needs software freedom. I won't untangle that fallacy here to avoid preaching to the choir. Sure, there may be more experts apt at modifying emacs than certain microcode source, but so what? Before I knew coreboot I didn't think the expertise necessary to write firmware could be had in a free software project, and now I'm arguing with one of those experts I thought didn't exist.
There are several free software projects that work around or reverse engineer secret designs. The fact that it is unlikely or difficult is no excuse to use other people's work against the license they have choosen. It's not me you have to convince or you I have to convince, it's any copyright holder to code linked to this microcode if we want to make a derivative work.
When a processor is purchased, its source code is not provided. The microcode patch is a modification of the processor design, so it is not surprising the source code is not supplied.
That's a particular point of view, seeing microcode patches as some kind of binary soldering iron of sorts. I don't see it like that. Changing microcode does not change the microprocessor design any more than changing documentation or firmware. The circuits are so that given some microcode perfom some function. They'd do something else with a different microcode but they would still be the same circuits. Otherwise any software would be a circuit metamorphoser.
I see microcode as a preloaded propietary program for a VLIW processor whose purpose is to emulate a CISC processor that happens to have more application software available. The x86, amd64 or whatever instruction set works just like an ABI, similar to parrot or java bytecodes allowing people to write once and run anywhere, and makes economic sense. But it does not change the nature of the VLIW processor.
The processor design is information, VHDL programs if you like. The only thing that distinguishes the logic that goes to silicon from what goes to software is the possibility to change it without building another device. Therefore, microcode is software for a (nondocumented) machine as soon as it can be modified. This VLIW nondocumented machine could have compilers for any language that generate microcode or interpreters for other instruction sets, and maybe I could have the compiler generate a new opcode to optimize a tight loop or run ARM or PPC binaries in my Phenom. Not that I'm interested, I'd rather recompile free software for amd64. And not that it would be economic to build such a compiler backend for such a small number of CPUs out there.
All this is not trying to bash any cpu vendor or imply any wrongdoing by anyone. When I bought my CPU it was advertised as amd64, x86 , MMX , etc. compatible, not as a VLIW processor I could reprogram by microcode patches. And I'm not claiming I have a great business model for paying the engineers and factories to build open hardware of similar power (although if someone does, I'd like to get some advertising). And I'm not saying that I'm surprised to know that sources or documentation for microcode or cpu designs are not published. I'm just surprised to find microcode linked into GPL binaries. My intent is just to explain that those wanting these binary parts left out of their coreboot image are not some kind of luddite zealots, simply people that like to apply uniform criteria to their free software.
And this is just too much for a rationale for a 69 lines patch, so I'll leave it here and sorry for the noise.