на развернуть microcode тоже imho такты нужны.

Ты некомпетентен. О каких таких «тактах» речь, когда OoO во все щели? То, что конвейер длиннее получается, никого на самом деле не колышет, с хорошим предсказанием ветвлений длинный конвейер это скорее хорошо, чем плохо.

stosd медленнее, чем
mov [es:edi], eax
add edi, 4

Потому что stosd модифицирует больше регистров.

repne scasb медленнее, чем наивный strchr()
scasb
strchr

Конечно медленней, он там не нужен вообще, а нужен lodsb.

Кури мануалы, лалка.

OoO
конвейер длиннее

Не сильно уж и длиннее.

с хорошим предсказанием ветвлений длинный конвейер это скорее хорошо, чем плохо.

Длинный конвеер хорошо когда латентность памяти говняная.

Для длинного конвеера «хорошее» предсказание ветвлений - это требование, а не скорее хорошо, лалка. Сколько стадий дропать если не правильно предсказалось?

x86 — это CISC

А щито таки ви считаете за x86?

Именно что cisc - пережиток прошлого. Ну вот как leave при этом может быть медленнее, я хоть убей не понимаю. Если так, то это откровенный недочет/баг/оплошность инженеров.

Как же M68060, например?

А что, в нем не было микрокода?

hard-wired CISC существовать не может?

Как ты себе это представляешь?

Может быть железная реализация в multi-cycle FSM

Покажи хоть одну. И каким образом это относится к x86?

RTFM: multi-cycle CPU.

Ранние x86 как раз и были multi-cycle.

А что, в нем не было микрокода?

http://www.obsolyte.com/sunFAQ/faq_m68k/

The chip is all hardwired - there is no microcode in it.

Как ты себе это представляешь?

Как control unit на жесткой логике + регистры для состояния FSM

The chip is all hardwired - there is no microcode in it.

Ну что же ты цитатку-то обрезал: This CPU has some RISC processor features. The chip is all hardwired - there is no microcode in it

Как control unit на жесткой логике + регистры для состояния FSM

И чего же это никто не догадался. Лепят как дурачки RISC ядро в x86.

RTFM: multi-cycle CPU.

И что? Каким боком это касается CISC в железе?

Ранние x86 как раз и были multi-cycle.

Ну и что, открываем педивикию, читаем: The 8086 was sequenceв using a mixture of random logic and microcode.

RISC команды выровнены на 2-4 байта, а их структура достаточно регулярна, поэтому декодировать их можно несколькими параллельными декодерами. ну максимум если одна команда влияет на следующую, можно поправить ее на следующей стадии.

х86 декодер должен принимать во внимание наличие до 4х префиксов, 1-2-байтовые команды, mod r/m, sib, смещение и непосредсвенный операнд

и желательно таких декодеров иметь хотя бы 3. ясен пень что только один из них может нормально декодировать редкие инструкции

а что касается «нативного» strchr, то он может быть реализован и на SIMD.

Ну что же ты цитатку-то обрезал: This CPU has some RISC processor features. The chip is all hardwired - there is no microcode in it

Мы CISC без микрокода обсуждали, не? Я вырезал то, что посчитал важным.

NO MICROCODE

И чего же это никто не догадался. Лепят как дурачки RISC ядро в x86.

Motorola догадалась, этого мало? если копнуть x86, очень может быть что какой-нибудь из 486 был без микрокода.

upd: я неправ, в i486 есть микрокод

Где избыточность? Вот наборы комманд MMX и 3dNow! - это трата кодов, да

вот интересно, откуда на лоре столько неграмотных, но очень наглых полудурков вроде тебя?

The 8086 was sequenceв using a mixture of random logic and microcode.

random logic

что ты только что описал SCP-[УДАЛЕНО]

откуда

ты не поверишь...

Мы CISC без микрокода обсуждали, не? Я вырезал то, что посчитал важным.

NO MICROCODE

Важно там то, что NO MICROCODE = RISC

Motorola догадалась, этого мало?

Догадалась сделать RISC? Не спорю.

Важно там то, что NO MICROCODE = RISC

во первых, там не сказано, что 68060 = RISC, а сказано что

This CPU has *some* RISC processor *features*.

во вторых, 68060 относится к семейству m68k - классический CISC набор инструкций. Вы утверждали:

CISC команды по определению выполняются через микрокод.

68060 - пример процессора, где CISC команды НЕ выполняются через микрокод.

объясни пожалуйста зачем нужен микрокод для сложных инструкций.

где CISC команды НЕ выполняются через микрокод.

И поэтому This CPU has some RISC processor features.

Вот вам выдержка из user manual:

The MC68060 variable-length instruction system is internally decoded into a fixed-length representation and channeled into an instruction buffer. The instruction buffer acts as a FIFO which provides a decoupling mechanism between the instruction fetch unit and the operand execution units. Fixed format instructions are dispatched to dual four-stage pipelined RISC operand execution engines where they are then executed.

Т.е. CISC команды выполняются через трансляцию в RISC инструкции, которые как раз hard-wired.

зачем нужен микрокод для сложных инструкций

Что значит, что инструкция сложная? Значит, что её сложно реализовать в железе. Например, загрузка числа в регистр - это просто, т.к. регистр и число из инструкции у нас уже под руками после декодирования. А умножение - это уже сложнее, т.к. нужен либо специальный модуль для умножения, либо его можно реализовать на простом железе через микрокод. Сложных инструкций в CISC много и на каждую из них делать отдельный модуль (для умножения, для деления, для stosb, и т.п.) не выгодно, т.к. большую часть времени они будут простаивать, а кристалл не резиновый. Лучше забацать 10 простых модулей сложения/сдвига и выполнять на них умножение/деление через микропрограмму 1 раз в пятилетку, зато остальное время их можно использовать для 10 сложений за такт.

Что значит, что инструкция сложная?

Это значит, что аналогичного результата можно добиться выполнением последовательности более простых инструкций.

Например, инструкция, которая берет два числа из памяти, складывает и кладет результат обратно в память - сложная, потому как этого же результата можно добиться двумя LOAD-инструкциями, сложением двух регистров, и STORE результата из регистра в память.

не выгодно

Транзисторы нынче дешевые.

т.к. большую часть времени они будут простаивать

И это хорошо - rtfm: dark silicon.

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

Правильно, это и называется микрокод.

Транзисторы нынче дешевые.

Подари мне комплект транзисторов i7-4960X.

dark silicon

Ох уж мне эти сказки, ох уж мне эти сказочники. Может на мобильных платформах это и взлетит, но на десктопе я предпочту 100500 ядер, которые я могу загрузить работой.

Пока рожаешь очередной идиотский ответ, поизучай этот детский, примитивный пример, может поймешь, наконец: http://www.public.iastate.edu/~jchargo/portfolio/MulticycleProcessor.pdf

Тест писать ну совсем влом...

Почему?

Весь вопрос об этом. Собственно, что там такого, что нельзя заменить CISC-овую enter/leave на равную последовательность RISC-инструкций и получить в худшем случае идентичную производительность?

Эм, мы говорим про x86, где выравнивания у инструкций нет... leave вон вообще однобайтовая, а аналогичная ей RISC-последовательность содержит в себе двухбайтовую «mov reg, rm». Собственно, с чего бы ей декодироваться быстрее, чем leave?

декодер обычно оптимизируют под наиболее частные команды.

Ок. Тогда остаётся такой вопрос: почему leave декодируется в большее количество микроопераций, чем RISC-последовательность? (сужу по Фогу)

можно подумать фог знает как внутри работает проц.

ну и то есть к какому выводу мы пришли-то?

(я прочитал весь тред — но не заметил какого-то явного консенсуса :))

ну и то есть к какому выводу мы пришли-то?

x86 на свалке истории - можно треды бестолковые не читать

А разве не знает?

Анонимусы задолбали.

Анонимусы задолбали

да мне смешно было читать тупняк в заголовке - не смог пройти мимо :)

ну ок... подведу итоги.

я как независимый [не разбирающийся:)] чтец этого треда пришёл к выводу что:

1. x86-процессоры сложные и как они работают — не знает ни кто. а тот кто пытается утверждать что якобы он знает — оказывается втянут в кровопролитные ругательства и высмеивания.

2. выяснить какие команды работают быстрее а какие меленные — тоже нельзя, так как в каждом синтетическим тесте могут оказаться свои результаты. потому что — см пункт 1.

:-D

И где же тупняк? Поделись тайным знанием...

Поделись тайным знанием..

на современных x86 процессорах простые и часто используемые инструкции исполняются непосредственно - без ссылки на microcode engine (hard-wired control), как реализованы конкретные комплексные инструкции я не знаю - в сортах говна не разбираюсь :)

Анонимусы задолбали.

Они меня тоже задолбали. Надо бы запретить, я щетаю.

Сложных инструкций в CISC много и на каждую из них делать отдельный модуль (для умножения, для деления, для stosb, и т.п.) не выгодно

для умножения — приходится. Оказывается даже в говноатоме есть аппаратный умножитель. Я уж не говорю про нормальные процессоры.

А вот деление — да, нужно очень редко, потому на него забивают, и делают микрокодом.

Впрочем, AFAIK на сегодня ВСЁ делается микрокодом, хотя бы потому, что РОН вовсе не 8, а намного больше. Потому, какая нить XCHG EAX, EDX это на самом деле переименования R73 в EDX, а R31 в EAX. И такая ерунда ещё со времён i8086.

потому как этого же результата можно добиться двумя LOAD-инструкциями, сложением двух регистров, и STORE результата из регистра в память.

забудь про LOAD/STORE, кеш L1 давно уже внутри CPU. Потому твои «сложные» команды преобразуются в точно такой же микрокод, как и «простые». И если предвыборка команд не даст сбой, то «сложные» команды выполняются ровно за то же время, как и «простые».

На практике случается по разному. Иногда одно быстрее, иногда другое. И разница незначительная.

1. x86-процессоры сложные и как они работают — не знает ни кто. а тот кто пытается утверждать что якобы он знает — оказывается втянут в кровопролитные ругательства и высмеивания.

на самом деле, это важно лишь создателям компиляторов. Лично мне пофиигу, что быстрее, LEA или IMUL. Я всё равно буду писать x*=67342;

2. выяснить какие команды работают быстрее а какие меленные — тоже нельзя, так как в каждом синтетическим тесте могут оказаться свои результаты. потому что — см пункт 1.

можно убедится, что разница если и есть, то она не принципиальна, и сильно зависит от порядка команд, типа CPU, и погоды на Марсе.

на современных x86 процессорах простые и часто используемые инструкции исполняются непосредственно - без ссылки на microcode engine

пруф?

Когда средняя производительность программиста была две машинные команды в сутки.

пруф?

Computer Organization and Design: The Hardware/Software Interface, Third Edition By David A. Patterson, John L. Hennessy

Chapter 5 The Processor: Datapath and Control

Using the multicycle datapath and a microprogrammed controller pro- vides a framework for implementing the IA-32 instruction set. The challeng- ing task, however, is creating a high-performance implementation, which requires dealing with the diversity of the requirements arising from different instructions. Simply put, a high-performance implementation needs to ensure that the simple instructions execute quickly, and that the burden of the com- plexities of the instruction set penalize primarily the complex, less frequently used, instructions. To accomplish this goal, every Intel implementation of the IA-32 architecture since the 486 has used a combination of hardwired control to handle simple instructions, and microcoded control to handle the more complex instructions. For those instructions that can be executed in a single pass through the datapath—those with complexity similar to a MIPS instruction—the hardwired control generates the control information and executes the instruction in one pass through the datapath that takes a small number of clock cycles. Those instructions that require multiple datapath passes and complex sequencing are handled by the microcoded controller that takes a larger number of cycles and multiple passes through the datapath to complete the execution of the instruction. The benefit of this approach is that it enables the designer to achieve low cycle counts for the simple instructions without having to build the enormously complex datapath that would be required to handle the full generality of the most complex instructions

Computer Organization and Design: The Hardware/Software Interface, Third Edition By David A. Patterson, John L. Hennessy

год какой? «every Intel implementation of the IA-32 architecture since the 486» конечно впечатляет. Авторы наверное машину времени использовали.

К тому же, авторы про другое говорят. То же умножение вполне может быть реализовано и аппаратно, если есть умножитель. Тем не менее, это никак не исключает использования микрокода. Просто в микрокоде будет команда умножения. Возможно умножитель только 32х битный, потому инструкция IMUL32 является «простой», а вот «IMUL64» — сложной, т.к. реализована за 4 IMUL32. Как оно на самом деле — я не знаю, но это можно проверить, если есть желание.