By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), February 4, 2013 8:08 am
Room: Moderated Discussions
none (none.delete@this.none.com) on February 4, 2013 3:03 am wrote:
[snip]
> And there also is the validation nightmare that this increased complexity requires.
> As an example, microcode was mentioned in another thread as something quite complex.
I suspect that for Intel and AMD the tools and other institutional knowledge have become sufficiently mature that this "validation nightmare" might be more of a validation unpleasant dream. This may be a significant barrier to entry beyond the barriers of patents.
Microcode presumably actually helps reduce validation pressure by being more amenable to late fixing, by greater isolation (complexity can be mostly limited to the microcode itself), and by generally being considered less performance sensitive. (In a sense, Transmeta took this to the extreme.)
(Microarchitectural support for and/or designer experience with microcode has the potential advantage of facilitating support for complex operations across a broader range of hardware resources [or familiarity with tradeoffs in different types of implementation] while hiding implementation details so that they are free to change. Alpha PAL code gains some of this advantage, and trap to software execution on undefined opcodes [or use of potentially inlined functions] can also provide broader compatibility; but both tend to sacrifice more performance than microcode sacrifices [compared to a 'hardware' implementation]. Both of these alternative may also introduce more friction to change [the OS vendor producing PAL code does not care as much if a change in hardware would provide benefits since it adds cost to the OS vendor; adding new hardware primitives to accelerate a software implementation would become less attractive since legacy software would not support such and they would need to be supported as part of the ISA indefinitely].)
I suspect that a significant portion of x86 baggage can be made less burdensome by de-emphasizing performance of legacy features. Such de-emphasis can reduce validation effort and perhaps sometimes even improve performance and/or energy-effciency (beyond the benefit from reduced validation effort).
[snip]
> And there also is the validation nightmare that this increased complexity requires.
> As an example, microcode was mentioned in another thread as something quite complex.
I suspect that for Intel and AMD the tools and other institutional knowledge have become sufficiently mature that this "validation nightmare" might be more of a validation unpleasant dream. This may be a significant barrier to entry beyond the barriers of patents.
Microcode presumably actually helps reduce validation pressure by being more amenable to late fixing, by greater isolation (complexity can be mostly limited to the microcode itself), and by generally being considered less performance sensitive. (In a sense, Transmeta took this to the extreme.)
(Microarchitectural support for and/or designer experience with microcode has the potential advantage of facilitating support for complex operations across a broader range of hardware resources [or familiarity with tradeoffs in different types of implementation] while hiding implementation details so that they are free to change. Alpha PAL code gains some of this advantage, and trap to software execution on undefined opcodes [or use of potentially inlined functions] can also provide broader compatibility; but both tend to sacrifice more performance than microcode sacrifices [compared to a 'hardware' implementation]. Both of these alternative may also introduce more friction to change [the OS vendor producing PAL code does not care as much if a change in hardware would provide benefits since it adds cost to the OS vendor; adding new hardware primitives to accelerate a software implementation would become less attractive since legacy software would not support such and they would need to be supported as part of the ISA indefinitely].)
I suspect that a significant portion of x86 baggage can be made less burdensome by de-emphasizing performance of legacy features. Such de-emphasis can reduce validation effort and perhaps sometimes even improve performance and/or energy-effciency (beyond the benefit from reduced validation effort).
