G>Они простенький такой (по сравнению с остальным фаршем) блок внедряют в декодер команд, в самом начале конвейера, который преобразует х86 в нормальный трехадресный код.

Коллеги по Prosoft жалуются, что им пришлось использовать китайский клон x86. Он был сделан на китайском же варианте какого-то RISC, с нашлёпкой в виде декодера x86 команд.

Так вот, им пришлось отыскать и обойти в ПО плавающую ошибку в этом процессоре — pop ss иногда срабатывал неправильно.

Поэтому этот простенький блок только выглядит простеньким. На самом деле он очень сложен.

G>И весь основной конвейер у таких процессоров построен примерно на тех же принципах, что и конвейер RISC-процессора.

Сложней. Тебе нужны ещё блоки переименования регистров туда и обратно.

G>Оверхэд по площади — смешной для суперскалярного проца на 6 каналов арифметики, а производительность, как ни парадоксально, при таком подходе выше.

Если ты посмотришь на floorplan любого x86, то там здоровенную часть будет занимать x87, хотя даже 2xdouble должно быть в районе, не знаю, миллиметров 16 по площади. А x87 занимает десятки.

Всё потому, что надо переводить из стековой системы команд в регистровую.

G>А знаешь, почему? CISC код более компактен, чем RISC, что снижает требования к пропускной способности памяти, размеру кэшей, итд. А именно это — узкое место в настоящее время.

http://sourceforge.net/mailarchive/forum.php?thread_name=200609161650.k8GGoBSr028429%40pandora1.cs.utsa.edu&forum_name=math-atlas-devel

I've been puzzling over why the best Core2 code uses only 8 active registers,
where the best AMD can use all 16. Dean sent in the missing piece, by
pointing to this technical info goldmine:
http://www.agner.org/optimize/

Turns out that the weakest link on Core2 (and, I think, pretty much all
Intel procs) is the decode step. When you use registers the registers greater
than 7 (eg., %xmm8), this adds a byte to all such operations. 8 output
registers give you only a few instructions that require larger storage,
resulting in ATLAS's kernel using 114 bytes for a given iteration of
the kernel loop. This is important, because this is two 64-byte gulps by
the decoder. Once you add another register as output, this increases the
computation to 3 windows, which apparently is the killer.