Современные CISC процессоры и их RISC ядра
лол
Пора с этим завязывать!
ёпта
Богачева что ль на мехмате наслушался?
Богачева что ль на мехмате наслушался?
рановато ты пьятницу начал отмечать =)
рановато ты пьятницу начал отмечать =)А вот у нас пятница уже со вторника на среду началась
А у нас их целых семь штук в неделе!
внутреннее устройство процессора тебе никто не расскажет.
Скорее всего это корпоративный секрет Интела или АМД.
За такое могут и замочить, наверно, даже на западе
Скорее всего это корпоративный секрет Интела или АМД.
За такое могут и замочить, наверно, даже на западе
Откуда такая уверенность?
Я вот, например, только недавно узнал, что, оказывается, Майкрософт раздаёт исходники ядра Win2k3 по академической программе.
> Богачева что ль на мехмате наслушался?
Нет. А кто это?
Я вот, например, только недавно узнал, что, оказывается, Майкрософт раздаёт исходники ядра Win2k3 по академической программе.
> Богачева что ль на мехмате наслушался?
Нет. А кто это?
травой не поделишься?
Нет. А кто это?препод, просто у него есть курс про RTOS и он там про циски риски рассказывал
Нет, просто подумал, что в общем случае написать компилятор в RISC архитектуру гораздо проще, чем в CISC.
внутреннее устройство процессора тебе никто не расскажет.что-то не верится
Скорее всего это корпоративный секрет Интела или АМД.
За такое могут и замочить, наверно, даже на западе
чего тут такого скрывать то?
Нет Языка кроме C, и GCC — компилятор его!
=)
=)
> Нет, просто подумал, что в общем случае написать компилятор в
> RISC архитектуру гораздо проще, чем в CISC.
Сколько раз ты сам, лично писал компиляторы?
---
...Я работаю антинаучным аферистом...
> RISC архитектуру гораздо проще, чем в CISC.
Сколько раз ты сам, лично писал компиляторы?
---
...Я работаю антинаучным аферистом...
Я вот, например, только недавно узнал, что, оказывается, Майкрософт раздаёт исходники ядра Win2k3 по академической программеЭто кто тебе такое рассказал?
сс это симлиньк =)
Теоретически обойти преобразование можно. Практически для этого нужно выкрасть документацию по RISC командам, алгоритму шифрования патчей для проца, и, возможно, секретный ключ для этого алгоритма шифрования. Причем доступ ко всей этой информации имеет очень небольшое число человек во всей компании.
На данный момент раздобыть эту информацию никому не удалось ни для intel-процессоров, ни для amd.
На данный момент раздобыть эту информацию никому не удалось ни для intel-процессоров, ни для amd.
Какие вы видите причины для сокрытия информации о том, какой формат имеют микрооперации в процессорах?
С другой стороны мне кажется, что разработчики сих девайсов наверняка имели возможность использовать их в обход блока декодировки инструкций. Только тогда не понятно, почему они это не документировали.
С другой стороны мне кажется, что разработчики сих девайсов наверняка имели возможность использовать их в обход блока декодировки инструкций. Только тогда не понятно, почему они это не документировали.
Только тогда не понятно, почему они это не документировали.Чтоб иметь преимущество над третьепартийными компиляторами.
не совсем понимаю что ты хочешь получить в итоге? научиться засовывать команды в середину конвейера? ничего не выйдет — даже чисто теоретически никаких преимуществ не получится. итаниум из говёного п4 не выйдет никогда хоть ты запачься его микрокод — серийные процессор это тебе не тестовый эмулирующий макет где софтом сделано всё.
Понятно, что процессоры поддерживают CISC набор инструкций из-за необходимости совместимости со старыми моделями. Непонятно, почему не доступен напрямую RISC набор.
О преимуществах я уже писал. Мне кажется, что компилировать в RISC команды проще.
О преимуществах я уже писал. Мне кажется, что компилировать в RISC команды проще.
Мне кажется, что компилировать в RISC команды проще.это не самая сложная часть в современных компиляторах, по сути бакэнд ерунда.
для RISC просто чуть поменьше кода.
Непонятно, почему не доступен напрямую RISC набор.проблема в документировании, поддержке, сопровождении, совместимости
все это очень и очень дорогие вещи.
со смыслом кстати тоже проблемы =)
А со смыслом-то почему проблемы? Имхо, гораздо лучше один раз преобразовать программу в микроопы, чем делать это при каждом выполнении. Тем более тогда можно будет ничего не менять в процессоре, чтобы поменять алгоритм оптимизации.
> Имхо, гораздо лучше один раз преобразовать программу в микроопы, чем делать это при каждом выполнении
кто компиляцию будет делать? разработчик? т.е. ему придется поставлять прогу под каждый вид процессора?
> Тем более тогда можно будет ничего не менять в процессоре, чтобы поменять алгоритм оптимизации
опять же вопрос тот же, кто и когда будет проводить компиляцию?
возьмем тот же winxp, там большинству dll-ен уже лет 5-10, за это время успело смениться не одно поколение процов.
то, что ты хочешь - возможно при повсеместном внедрении промежуточного byte-кода.
кто компиляцию будет делать? разработчик? т.е. ему придется поставлять прогу под каждый вид процессора?
> Тем более тогда можно будет ничего не менять в процессоре, чтобы поменять алгоритм оптимизации
опять же вопрос тот же, кто и когда будет проводить компиляцию?
возьмем тот же winxp, там большинству dll-ен уже лет 5-10, за это время успело смениться не одно поколение процов.
то, что ты хочешь - возможно при повсеместном внедрении промежуточного byte-кода.
Я-то как раз за повсеместное внедрение...
О твоём вопросе по поводу компиляции. Не думаю, что сделать переключение "на лету" между режимом с декодером операций и без него слишком уж сложно. Это раз.
Два. Алгоритм преобразования CISC кода в RISC потенциально известен (по крайней мере компаниям-производителям процессоров). Не думаю, что его сложно реализовать программно и прикрутить к существующим компиляторам.
О твоём вопросе по поводу компиляции. Не думаю, что сделать переключение "на лету" между режимом с декодером операций и без него слишком уж сложно. Это раз.
Два. Алгоритм преобразования CISC кода в RISC потенциально известен (по крайней мере компаниям-производителям процессоров). Не думаю, что его сложно реализовать программно и прикрутить к существующим компиляторам.
ты на какой-то другой вопрос ответил.
вопрос был - компиляции где проводится? на стороне разработчика или пользователя?
если на стороне разработчика? то сколько копий поставляется пользователю?
если на стороне пользователя? то каким образом проводится компиляция (кто и каким образом настраивает окружение для компиляции)?
вопрос был - компиляции где проводится? на стороне разработчика или пользователя?
если на стороне разработчика? то сколько копий поставляется пользователю?
если на стороне пользователя? то каким образом проводится компиляция (кто и каким образом настраивает окружение для компиляции)?
Ты не понял. Я к тому, что не нужно проводить перекомпиляцию. Просто сделать режим работы, когда блок декодирования инструкций не работает. Старые программы исполняются в старом режиме, новые в новом.
Хотя можно и перекомпилировать. Имхо, лучше на стороне пользователя. Компиляцию можно проводить фактически просто эмулировав декодер инструкций. Чего там настраивать-то?
Хотя можно и перекомпилировать. Имхо, лучше на стороне пользователя. Компиляцию можно проводить фактически просто эмулировав декодер инструкций. Чего там настраивать-то?
Чувак, не страдай хуйней.
Если бы это было просто или доступно - то кто-то бы уже сделал это давно.
Раз это не сделано - значит это не так то и просто.
Фантазер бля нашелся.
Мурзилку почитай лучше или подрочи.
Если бы это было просто или доступно - то кто-то бы уже сделал это давно.
Раз это не сделано - значит это не так то и просто.
Фантазер бля нашелся.
Мурзилку почитай лучше или подрочи.
+1
подрочиСамый дельный совет в треде.
Чтоб иметь преимущество над третьепартийными компиляторами.Лолнег. Сколько денег заработала Интел на продаже бесплатного интеловского компайлера? Ващеее лолнег. Чуваки продают процессоры, любой более эффективный компилятор для них повышает продаваемость процессоров, точка.
По теме: хоть кто-нибудь в этом треде, кроме КОНТРЫ, вообще видел глазами RISK и CISK инструкции? Ну, так, чиста ознакомиться? Если да, то не пришло ли вам в голову, что риски типа в разы более объёмные, невзирая на меньшую длину команды? Ну, там, команда mov eax, [ebp*8 + esi] замечательно пакуется, это же зип практически. Не пришло ли вам в голову ВНЕЗАПНО, что процессор исполняет команды опять же в разы быстрее, чем они забираются из памяти, даже с учётом кешей? И что преобразователь CISK -> RISK реализуется параллельно (то есть практически бесплатно с точки зрения быстродействия и является по сути деархиватором, позволяя хоть как-то обойти медленную шину?
Ваши идеи, Шариков, космические как по масштабу, так и по глупости.
"Выйдем, поговорим, да?"
> Если да, то не пришло ли вам в голову, что
> риски типа в разы более объёмные,
> невзирая на меньшую длину команды?
По меньшей мере --- спорно.
Замечание Танненбаума заключается именно в том, что вместо
средней длины литерала в 13 разрядов на CISC отводится полное
слово. И это кроме того, что большинство видов адресации не
используется и что несколько простых команд оказываются быстрее
одной сложной, предназначенной для решения определённой задачи.
> Ну, там, команда mov eax, [ebp*8 + esi] замечательно пакуется,
Если учесть, что "ebp*8+esi" уже могло быть вычислено и
храниться в каком-нибудь r13, выигрыш сомнителен.
> Не пришло ли вам в голову ВНЕЗАПНО, что процессор исполняет
> команды опять же в разы быстрее, чем они забираются из памяти,
> даже с учётом кешей?
Процессор совсем не обязательно исполняет команды быстрее, чем
они забираются из памяти. Исходно, RISC именно потому и
появился, что исполнение команды требовало много тактов,
предоставляемых на отработку адресации памяти. Это приводило к
странным случаям, когда 6502 работал наравне с 8085 и даже Z80
только из-за однотактового доступа к памяти. Ладно, это было
очень давно и уже неправда.
> позволяя хоть как-то обойти медленную шину?
Основная мысль RISC заключается именно в том,
чтобы обойти медленную шину.
Слова "гарвардская архитектура" что-нибудь говорят?
За счёт упрощения логики память хотя бы частично может быть
размещена на процессоре, это то, что ты называешь "кеш",
так что выборка команд может производиться на частоте внутренней
шины процессора, что, как бы, чуточку быстрее выборки из памяти.
Ты можешь сказать, что оно и так есть, но в случае RISC "кеш"
может быть значительно больше, чем у гибридной архитектуры Intel
или AMD, да и команд там может помещаться чуть больше, чем в
соответствующем количестве памяти упомянутого гибрида.
> RISK
"K" is for "Komputer".
---
...Я работаю антинаучным аферистом...
> Если да, то не пришло ли вам в голову, что
> риски типа в разы более объёмные,
> невзирая на меньшую длину команды?
По меньшей мере --- спорно.
Замечание Танненбаума заключается именно в том, что вместо
средней длины литерала в 13 разрядов на CISC отводится полное
слово. И это кроме того, что большинство видов адресации не
используется и что несколько простых команд оказываются быстрее
одной сложной, предназначенной для решения определённой задачи.
> Ну, там, команда mov eax, [ebp*8 + esi] замечательно пакуется,
Если учесть, что "ebp*8+esi" уже могло быть вычислено и
храниться в каком-нибудь r13, выигрыш сомнителен.
> Не пришло ли вам в голову ВНЕЗАПНО, что процессор исполняет
> команды опять же в разы быстрее, чем они забираются из памяти,
> даже с учётом кешей?
Процессор совсем не обязательно исполняет команды быстрее, чем
они забираются из памяти. Исходно, RISC именно потому и
появился, что исполнение команды требовало много тактов,
предоставляемых на отработку адресации памяти. Это приводило к
странным случаям, когда 6502 работал наравне с 8085 и даже Z80
только из-за однотактового доступа к памяти. Ладно, это было
очень давно и уже неправда.
> позволяя хоть как-то обойти медленную шину?
Основная мысль RISC заключается именно в том,
чтобы обойти медленную шину.
Слова "гарвардская архитектура" что-нибудь говорят?
За счёт упрощения логики память хотя бы частично может быть
размещена на процессоре, это то, что ты называешь "кеш",
так что выборка команд может производиться на частоте внутренней
шины процессора, что, как бы, чуточку быстрее выборки из памяти.
Ты можешь сказать, что оно и так есть, но в случае RISC "кеш"
может быть значительно больше, чем у гибридной архитектуры Intel
или AMD, да и команд там может помещаться чуть больше, чем в
соответствующем количестве памяти упомянутого гибрида.
> RISK
"K" is for "Komputer".
---
...Я работаю антинаучным аферистом...
Могу даже дополнить твой пост. В современных x86 процессорах кэшируются вовсе не CISC-команды, а уже декодированные последовательности инструкций.
Могу даже дополнить твой пост. В современных x86 процессорах кэшируются вовсе не CISC-команды, а уже декодированные последовательности инструкций.
У тебя есть какая-то инсайдерская информация типа спиженной документации ?
Если есть - делись, почитаем.
Если нет - то нехуй сплетничать как последняя сука.
Ты не видишь разницы между мемоизацией, т.н. "кешем"
и быстрой памятью.
---
...Я работаю антинаучным аферистом...
и быстрой памятью.
---
...Я работаю антинаучным аферистом...
это только в p4
остальные такой фигнёй не страдают.
остальные такой фигнёй не страдают.
Сколько денег заработала Интел на продаже бесплатного интеловского компайлера?какой такой бесплатный компайлер?
Intel C++ Compiler 9.1 = $399 за лицензию + $160 в год
это для коммерческого использования, и по сути копейки.
Пока читал плакал...
Но тоже скажу пару слов.
RISС основаны на пачке команд одинаковой длины.
CISC развивалась и пошла в народ быстрее потому что для работы требовала меньше памяти в те времена когда память ещё была дорогая.
Но тоже скажу пару слов.
RISС основаны на пачке команд одинаковой длины.
CISC развивалась и пошла в народ быстрее потому что для работы требовала меньше памяти в те времена когда память ещё была дорогая.
Ну вы все и фрики 
Может быть имеется в виду не компилятор, а лишь такая его часть как "генератор кода"?
По идее под RISC он попроще, но чем чёрт не шутит...)
По идее под RISC он попроще, но чем чёрт не шутит...)
> По идее под RISC он попроще
Хоть раз писал генератор кода?
---
...Я работаю антинаучным аферистом...
Хоть раз писал генератор кода?
---
...Я работаю антинаучным аферистом...
RISC - вычисления с сокращённым набором команд
основная идея: более компактные и простые инструкции выполняются быстрее.
Характерные особенности RISC-процессоров:
Фиксированная длина машинных инструкций (например, 32 бита) и простой формат команды.
Одна инструкция выполняет только одну операцию с памятью — чтение или запись. Операции вида «прочитать-изменить-записать» отсутствуют.
Большое количество регистров общего назначения (32 и более).
CISC характеризуется следующим набором свойств:
Нефиксированным значением длины команды.
Исполнение операций, таких как загрузка в память, арифметические действия кодируется в одной инструкции
Взято с:
http://ru.wikipedia.org/wiki/RISC
http://ru.wikipedia.org/wiki/CISC
Следствие RISC архитектуры:
малый набор команд и простота команд => сложнее писать компилятор, проще реализовать в железе
команды фиксированной длинны => простота разбора(если вообще требуется) потока команд для внутреннего представления
Основной на мой взгляд минус, сложнее оптимизировать исполнение команд (если в cisc уже есть какая-то группировка за счет команд состоящих из нескольких моп то реализовать хотя бы внеочередное исполнение команд мне кажется сложнее(могу ошибаться)
CISC:
достаточно большой набор команд их разнообразие => сложнее реализовать в железе, проще писать компилятор
неоднородность длинны команд => невозможно сказать наперед, где начинается следующая команда. Для работы с несколькими командами надо разобрать все предедущие(возникает необходимость в достаточно большом кеше команд)
У каждого подхода свои плюсы и минусы. Современные x86 процы гибридные. Внешне они из себя представляют cisc архитектуру, но внутри (судя по прочитанной мной информации) реализуют risc ядро. Преобразование из x86 команд в мопы происходит в декодере, который(скорее всего) не является узким местом. Создавать доступ к внутренним мопам - это лишнии транзисторы, а самое главное затраты на реализацию(как определить через какой из интерфейсов приходят команды, насколько декодер связан с другими частями процессора) и никаких значительных бонусов. То что ты напишешь risc код - не означает, что ты в конечном итоге получишь более быструю программу(современные компиляторы создаю достаточно хорошо оптимизированный код, не факт что ты в конечном итоге получишь нечто отличное от декодера в 90% кода). Еще Идея интересная, но практических бонусов у нее нет.
основная идея: более компактные и простые инструкции выполняются быстрее.
Характерные особенности RISC-процессоров:
Фиксированная длина машинных инструкций (например, 32 бита) и простой формат команды.
Одна инструкция выполняет только одну операцию с памятью — чтение или запись. Операции вида «прочитать-изменить-записать» отсутствуют.
Большое количество регистров общего назначения (32 и более).
CISC характеризуется следующим набором свойств:
Нефиксированным значением длины команды.
Исполнение операций, таких как загрузка в память, арифметические действия кодируется в одной инструкции
Взято с:
http://ru.wikipedia.org/wiki/RISC
http://ru.wikipedia.org/wiki/CISC
Следствие RISC архитектуры:
малый набор команд и простота команд => сложнее писать компилятор, проще реализовать в железе
команды фиксированной длинны => простота разбора(если вообще требуется) потока команд для внутреннего представления
Основной на мой взгляд минус, сложнее оптимизировать исполнение команд (если в cisc уже есть какая-то группировка за счет команд состоящих из нескольких моп то реализовать хотя бы внеочередное исполнение команд мне кажется сложнее(могу ошибаться)
CISC:
достаточно большой набор команд их разнообразие => сложнее реализовать в железе, проще писать компилятор
неоднородность длинны команд => невозможно сказать наперед, где начинается следующая команда. Для работы с несколькими командами надо разобрать все предедущие(возникает необходимость в достаточно большом кеше команд)
У каждого подхода свои плюсы и минусы. Современные x86 процы гибридные. Внешне они из себя представляют cisc архитектуру, но внутри (судя по прочитанной мной информации) реализуют risc ядро. Преобразование из x86 команд в мопы происходит в декодере, который(скорее всего) не является узким местом. Создавать доступ к внутренним мопам - это лишнии транзисторы, а самое главное затраты на реализацию(как определить через какой из интерфейсов приходят команды, насколько декодер связан с другими частями процессора) и никаких значительных бонусов. То что ты напишешь risc код - не означает, что ты в конечном итоге получишь более быструю программу(современные компиляторы создаю достаточно хорошо оптимизированный код, не факт что ты в конечном итоге получишь нечто отличное от декодера в 90% кода). Еще Идея интересная, но практических бонусов у нее нет.
Основной на мой взгляд минус, сложнее оптимизировать исполнение команд (если в cisc уже есть какая-то группировка за счет команд состоящих из нескольких моп то реализовать хотя бы внеочередное исполнение команд мне кажется сложнее(могу ошибаться)Наоборот в RISC из-за простоты комманд, их проще переставлять, параллелить и тому подобное. Думаю, что это одна из причин того, что современные x86 содержат внутри RISC-ядро.
Наоборот в RISC из-за простоты комманд, их проще переставлять, параллелить и тому подобное.имхо, дело обстоит так:
если писать мощный оптимизирующий компилятор (вкладывая много сил) - то удобнее работать с risc, т.к. проще применить математику, оптимизирующий перебор и т.д.
если же писать компилятор со слабой/средней оптимизацией (вкладывая на разработку мало сил то проще работать с Cisc.
Имхо, можно для оптимизации применить уже существующие жёстко закодированные в CISC процессоры алгоритмы разбора CISC команд. Это позволит выполнять часть операций статически ещё на этапе компиляции программы. Очевидный же плюс.
На самом деле тут уже упоминался очевидный минус - программа в CISC командах в общем случае длиннее и требует больше обращений к ОЗУ для считывания. Хотя, имхо, кэширование должно решать эту проблему.
На самом деле тут уже упоминался очевидный минус - программа в CISC командах в общем случае длиннее и требует больше обращений к ОЗУ для считывания. Хотя, имхо, кэширование должно решать эту проблему.
> программа в CISC командах в общем случае длиннее
Я не знаю, что такое "общий случай", показывай на примере
известных тебе процессоров.
> Хотя, имхо, кэширование должно решать эту проблему.
А другую проблему?
Кроме той, что кеш тоже надо как-то заполнять из основной памяти.
---
...Я работаю антинаучным аферистом...
Я не знаю, что такое "общий случай", показывай на примере
известных тебе процессоров.
> Хотя, имхо, кэширование должно решать эту проблему.
А другую проблему?
Кроме той, что кеш тоже надо как-то заполнять из основной памяти.
---
...Я работаю антинаучным аферистом...
> Думаю, что это одна из причин того, что современные
Слово "микропрограммирование" кому-нибудь известно?
> x86 содержат внутри RISC-ядро.
---
...Я работаю антинаучным аферистом...
Слово "микропрограммирование" кому-нибудь известно?
> x86 содержат внутри RISC-ядро.
---
...Я работаю антинаучным аферистом...
> Одна инструкция выполняет только одну операцию с памятью —
> чтение или запись.
Линейка 8080--8085--Z80 --- это RISC.
Чудо, а ты пытался прочитать хотя бы ту же "Википедию", но на аглицком?
> малый набор команд и простота команд => сложнее писать компилятор
Хоть раз пробовал написать компилятор?
> неоднородность длинны команд => невозможно сказать наперед,
> где начинается следующая команда.
А дизассемблер?
> Современные x86 процы гибридные.
Слово "микропрограммирование" тебе тоже неизвестно.
Офигеть. Технология 60-х.
> Преобразование из x86 команд в мопы происходит в декодере,
> который (скорее всего) не является узким местом.
На чём основано "скорее всего"? Правда ли это вообще?
Ты об этом хотя бы подумал?
---
"Первое дело разума --- отличать истинное от ложного."
Альбер Камю
> чтение или запись.
Линейка 8080--8085--Z80 --- это RISC.
Чудо, а ты пытался прочитать хотя бы ту же "Википедию", но на аглицком?
> малый набор команд и простота команд => сложнее писать компилятор
Хоть раз пробовал написать компилятор?
> неоднородность длинны команд => невозможно сказать наперед,
> где начинается следующая команда.
А дизассемблер?
> Современные x86 процы гибридные.
Слово "микропрограммирование" тебе тоже неизвестно.
Офигеть. Технология 60-х.
> Преобразование из x86 команд в мопы происходит в декодере,
> который (скорее всего) не является узким местом.
На чём основано "скорее всего"? Правда ли это вообще?
Ты об этом хотя бы подумал?
---
"Первое дело разума --- отличать истинное от ложного."
Альбер Камю
>> Думаю, что это одна из причин того, что современные
> Слово "микропрограммирование" кому-нибудь известно?
А выражение "одна из"?
> Слово "микропрограммирование" кому-нибудь известно?
А выражение "одна из"?
Про длину команды - это предположение незнающего человека. Если этого недостатка у RISC'ов нет - что мне доказывать?
Какая проблема другая?
Какая проблема другая?
>>> Думаю, что это одна из причин того, что современные
>> Слово "микропрограммирование" кому-нибудь известно?
> А выражение "одна из"?
Для того, чтобы было справедливо "одна из", нужно, чтобы было
справедливо "вообще", а это не так.
---
...Я работаю антинаучным аферистом...
>> Слово "микропрограммирование" кому-нибудь известно?
> А выражение "одна из"?
Для того, чтобы было справедливо "одна из", нужно, чтобы было
справедливо "вообще", а это не так.
---
...Я работаю антинаучным аферистом...
> Про длину команды - это предположение незнающего человека.
> Если этого недостатка у RISC'ов нет - что мне доказывать?
Ты разберись про длину чего ты говоришь: команды или программы.
Подумай насчёт колмогоровского определения сложности. Может,
даже додумаешься до чего-нибудь.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Если этого недостатка у RISC'ов нет - что мне доказывать?
Ты разберись про длину чего ты говоришь: команды или программы.
Подумай насчёт колмогоровского определения сложности. Может,
даже додумаешься до чего-нибудь.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Длину программы
При чём тут сложность? Я не понимаю, какую вторую проблему ты имеешь ввиду.
При чём тут сложность? Я не понимаю, какую вторую проблему ты имеешь ввиду.
> Длину программы
> При чём тут сложность?
При том.
Иди, учи определение по Колмогорову.
> Я не понимаю, какую вторую проблему ты имеешь ввиду.
Не вопрос.
---
...Я работаю антинаучным аферистом...
> При чём тут сложность?
При том.
Иди, учи определение по Колмогорову.
> Я не понимаю, какую вторую проблему ты имеешь ввиду.
Не вопрос.
---
...Я работаю антинаучным аферистом...
> Для того, чтобы было справедливо "одна из", нужно, чтобы было
> справедливо "вообще", а это не так.
Доказательства есть?
> справедливо "вообще", а это не так.
Доказательства есть?
Ты тоже не смог даже аглицкой статьи из "Википедии" осилить?
---
"Первое дело разума --- отличать истинное от ложного."
---
"Первое дело разума --- отличать истинное от ложного."
Читал. Там есть такое выражение: "... although RISC was indeed able to scale up in performance quite quickly and cheaply, Intel took advantage ...". Примерно то, что я и имел в виду. Про необходимость "микропрограммирования", кстати, не нашёл. Где опровержения моего заявления о том, что это могло быть одной и причин? У тебя есть инсайдерская информация?
Кстати не встречал инфы о том, что на современных x86 от AMD и Intel можно поменять набор команд посредством их перепрограммирования. Я думал, что только Transmeta что-то подобное делала. Хотя, признаюсь, этим вопросом и не интересовался. Если есть ссылки, то было бы интересно.
Кстати не встречал инфы о том, что на современных x86 от AMD и Intel можно поменять набор команд посредством их перепрограммирования. Я думал, что только Transmeta что-то подобное делала. Хотя, признаюсь, этим вопросом и не интересовался. Если есть ссылки, то было бы интересно.
Кстати не встречал инфы о том, что на современных x86 от AMD и Intel можно поменять набор команд посредством их перепрограммирования.Можно, но не сильно. Там загружаемый микрокод. Некоторые баги так исправляют через BIOS или ОС.
Про микрокод я слышал. Но что именно с его помощью можно изменить - не в курсе.
Можно новые команды добавлять, но немного, так как этого микрокода совсем мало туда вмещается. Сам не пробовал, рассказывали.
А баги как фиксят? Не новыми же командами. И какого типа баги можно пофиксить?
И какого типа баги можно пофиксить?> Про необходимость "микропрограммирования", кстати, не нашёл.
А подумать?
Или история-таки ничему не учит?
> Где опровержения моего заявления о том, что это могло быть одной и причин?
Любое введение иерархии происходит не для того, чтобы
получить какую-то особую выгоду, а для упрощения.
Не знаю, как тебе, а мне очевидно, что быстрее перемещаться
по полносвязному графу, чем по дереву.
---
...Я работаю антинаучным аферистом...
А подумать?
Или история-таки ничему не учит?
> Где опровержения моего заявления о том, что это могло быть одной и причин?
Любое введение иерархии происходит не для того, чтобы
получить какую-то особую выгоду, а для упрощения.
Не знаю, как тебе, а мне очевидно, что быстрее перемещаться
по полносвязному графу, чем по дереву.
---
...Я работаю антинаучным аферистом...
> И какого типа баги можно пофиксить?
Например, ошибки в действиях над числами с плавающей запятой.
---
...Я работаю антинаучным аферистом...
Например, ошибки в действиях над числами с плавающей запятой.
---
...Я работаю антинаучным аферистом...
Точно не знаю. Думаю, переопределяют имеющиеся команды, которые уже микрокодом реализованы. Собственно, под это всё место и уходит, поэтому на новые ничего не остаётся.
> > Про необходимость "микропрограммирования", кстати, не нашёл.
> А подумать?
> Или история-таки ничему не учит?
Ну научи хотя бы сам тогда?
> > Где опровержения моего заявления о том, что это могло быть одной и причин?
>Любое введение иерархии происходит не для того, чтобы
> получить какую-то особую выгоду, а для упрощения.
> Не знаю, как тебе, а мне очевидно, что быстрее перемещаться
> по полносвязному графу, чем по дереву.
Вот мне почему-то кажется, что я тоже про упрощение говорил.
А более простые системы легче масштабируются.
> А подумать?
> Или история-таки ничему не учит?
Ну научи хотя бы сам тогда?
> > Где опровержения моего заявления о том, что это могло быть одной и причин?
>Любое введение иерархии происходит не для того, чтобы
> получить какую-то особую выгоду, а для упрощения.
> Не знаю, как тебе, а мне очевидно, что быстрее перемещаться
> по полносвязному графу, чем по дереву.
Вот мне почему-то кажется, что я тоже про упрощение говорил.
А более простые системы легче масштабируются.
на каком-то из IDF'ов чуваки рассказывали как с помощью новых инструкций, загружаемых через firmware на itanium2, можно получить аналог hyperthreading
ключевые слова можно отсюда надёргать
ключевые слова можно отсюда надёргать
Дык насколько тот итаниум дороже нормального проца, на котором hyperthreading уже есть?
ну фишка же не в "дороже", а в том, что набор инструкций менять можно, причём для этого есть стандартный метод
ibm db2 нормальным людям тоже ведь не надо
ibm db2 нормальным людям тоже ведь не надо
да кому нужен стандартный метод на каких-то странных процах
тут ведь про нормальные процы спрашивают
тут ведь про нормальные процы спрашивают
> тут ведь про нормальные процы спрашивают
тут уже много всякой хуйни вспомнили, так что не надо
тут уже много всякой хуйни вспомнили, так что не надо
> Вот мне почему-то кажется, что я тоже про упрощение говорил.
Attention span?
g> их проще переставлять, параллелить и тому подобное.
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
---
"...Нужно только поднять верхний пласт."
Attention span?
g> их проще переставлять, параллелить и тому подобное.
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
---
"...Нужно только поднять верхний пласт."
>> Вот мне почему-то кажется, что я тоже про упрощение говорил.
> Attention span?
Поясни мысль. На всякий случай, чтобы не возникло лишних вопросов - как переводится эта фраза, я посмотрел, но не понял что ты хотел этим сказать.
g> их проще переставлять, параллелить и тому подобное.
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
Прости меня, был немногословен, перепутал причину со следствием, неверно сформулировал мысль и т.д. Тебе теперь легче? Я думал о том, что система команд проще, следовательно она легче масштабируется, а написал за счёт чего это достигается в частности. Я дал примеры "интенсивного" масштабирования, но я не исключаю, что и для "экстенсивного" развития тоже бонусы есть и вообще есть и другие, примеры, наверное. А может и мои не совсем верные, но общая мысль была такая.
Вот писал я всё это и думал - почему ты хочешь, чтобы я тебе свою мысль разжевал, но когда сам отвечаешь, то предлагаешь "пожевать" самостоятельно, причём умышленно? Ты ведь, наверное считаешь, что если я подумаю, то я тебя пойму. Так вот я когда ту фразу писал, то тоже думал, что если читатель подумает, то он меня поймёт и не будет доёбываться. Вот.
> Attention span?
Поясни мысль. На всякий случай, чтобы не возникло лишних вопросов - как переводится эта фраза, я посмотрел, но не понял что ты хотел этим сказать.
g> их проще переставлять, параллелить и тому подобное.
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
Прости меня, был немногословен, перепутал причину со следствием, неверно сформулировал мысль и т.д. Тебе теперь легче? Я думал о том, что система команд проще, следовательно она легче масштабируется, а написал за счёт чего это достигается в частности. Я дал примеры "интенсивного" масштабирования, но я не исключаю, что и для "экстенсивного" развития тоже бонусы есть и вообще есть и другие, примеры, наверное. А может и мои не совсем верные, но общая мысль была такая.
Вот писал я всё это и думал - почему ты хочешь, чтобы я тебе свою мысль разжевал, но когда сам отвечаешь, то предлагаешь "пожевать" самостоятельно, причём умышленно? Ты ведь, наверное считаешь, что если я подумаю, то я тебя пойму. Так вот я когда ту фразу писал, то тоже думал, что если читатель подумает, то он меня поймёт и не будет доёбываться. Вот.
g> их проще переставлять, параллелить и тому подобное.
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
> Прости меня, был немногословен, перепутал причину
> со следствием, неверно сформулировал мысль и т.д.
> Тебе теперь легче?
Теперь правильно.
---
"Всю цепь силлогизмов не читал. <...> Ты наверно единственный на форуме,
кто отвечает в 100-процентном соответствии с правилами формальной логики."
FTP
g> Думаю, что это одна из причин того, что современные x86
g> содержат внутри RISC-ядро.
> Прости меня, был немногословен, перепутал причину
> со следствием, неверно сформулировал мысль и т.д.
> Тебе теперь легче?
Теперь правильно.
---
"Всю цепь силлогизмов не читал. <...> Ты наверно единственный на форуме,
кто отвечает в 100-процентном соответствии с правилами формальной логики."
FTP
Оставить комментарий
agaaaa
Вот заинтересовался вопросом, а можно ли обойти преобразователь CISC инструкций в RISC на современных процессорах и писать сразу код для RISC-ядра?