Знание об архитектуре компьютера

Анонимус с зашкаливающим ЧСВ не нужен.

Я говорю о самом простейшем и базовом знании. Те, у кого даже этого нет, те вообще мразь. О каком таком ЧСВ ты тут говоришь? Скоро уже требование знания таблицы умножения запишут в снобизм.

Вживую её можно ещё и потрогать

Зачем тебе трогать светодиоды? Ты извращенец?

От 180$.

Так я и говорю - копейки.

Да вы, батенька, мажор если

А вы, батенька, нищеброд, что ли? Почему-то я не удивлен.

Всё знать не получится.

Все знать и не надо. А вот самые базовые вещи знать обязан каждый программист. Не знает - в топку его!

переходят с па-рисков на ia64

кагбэ ia64 - VLIW там своя атмосфера.

Да что же ты на меня всё время стрелки переводишь. Возьми платку на интеловском камне и на арме с той же тактовой частотой, например, и продемонстрируй насколько быстрее линупс будет грузиться на АРМе. В результаты практического эксперимента я поверю чем в умоиспражнения какого-то слесаря.

школоло детектед. Меряться тактовыми частотами - на разных архитектурах это так мило. Есть важные характеристики MIPS/MHz, Watt/MHz. Так вот, если по первой характеристике интел армы уделывает без проблем, то по второй сосёт с причмоком. Там разница по бенчмаркам была если не в порядки, то в разы точно. Ещё интереснее смотреть на MIPS/Watt, тут это тоже интересно.

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

Ну да, всего-то в 21 раз.

Ты тупой? Тебе не сотни штук покупать надо, а одну. Один раз выложить 7 евро и 150 евро - без разницы, это одинаково незаметная часть бюджета будет для любого представителя среднего класса.

Образование вообще, знаешь ли, стоит намного дороже. Одни только книги идут по 50 евро каждая в среднем, а их надо много. Рядом с этими расходами какая-то железка вообще не будет заметна.

В чистой производительности армы проигрывают

С одинаковой памятью и кешем - выигрывают.

А вы, батенька, нищеброд, что ли? Почему-то я не удивлен.

Луговский тоже в своё время орал, что вы все нищеброды.

Не забудь, что я цены привожу для сравнения. хз кто там топикстартер, может студент без богатых родителей. Для него 180$(хорошо, academic licence 150$) вполне значительная сумма.

Ты извращенец?

Всем извращенцам извращенец. Завидуй.

С одинаковой памятью и кешем - выигрывают.

Мне в руки такого не попадало.

В виденых мной случаях, соотношение MIPS/MHz в сравнении армов с интелами у интела было лучше. Не всегда намного, но лучше.

Если ее убрать, то очевидно же, что производительность будет лучше.

Вот кстати, почему бы интелу не сделать чип только с RISC без x86 эмуляции в виде конкурента армам? Если уж X86 оно молотит шустро, то на родном коде будет гораздо интереснее.

может студент

Студент обычно где-то учится, иначе он не студент. И там, где он учится, все подобное барахло должно быть доступно вообще на халяву. А если не доступно, то обычно можно попросить, и вендоры, толкаясь локтями, сами побегут дарить подарки.

Всем извращенцам извращенец. Завидуй.

Ну купи себе ведро LED-ов по копейке штука и трогай всеми частями тела. Только какое это отношение к образовательному процессу имеет?

Студент обычно где-то учится, иначе он не студент. И там, где он учится, все подобное барахло должно быть доступно вообще на халяву. А если не доступно, то обычно можно попросить, и вендоры, толкаясь локтями, сами побегут дарить подарки.

Житель страны эльфов, выйди из сумрака. Может в странах развитого капитализма такое и есть, но в реалиях РФ с железячным образованием достаточно туго. Да, тяжёлое детство, аналоговые осциллографы, стрелочные тестеры и КТ315.

Вот кстати, почему бы интелу не сделать чип только с RISC без x86 эмуляции в виде конкурента армам?

Есть мнение, что они считают свой микрокод страсть какой важной и опасной тайной. Не ясно, на каком основании. Так же есть мнение, что они защищают инвестиции (в первую очередь своих партнеров) в x86/x86_64 ISA.

Если уж X86 оно молотит шустро, то на родном коде будет гораздо интереснее.

Естественно. Их бы техпроцесс, да в хорошие руки! Да что там, те же ARM-ы бы по 22нм технологии делали бы. Но они даже свой собственный StrongARM прикрыли.

Есть мнение, что они считают свой микрокод страсть какой важной и опасной тайной.

Тот микрокод который исполняет x86 - это и есть их «самая главная военная тайна». Тут не поспоришь.

Естественно. Их бы техпроцесс, да в хорошие руки! Да что там, те же ARM-ы бы по 22нм технологии делали бы. Но они даже свой собственный StrongARM прикрыли.

Так интел же что-то говорил насчёт того, что он начинает делать микрухи по контракту на своих мощностях.

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

А ничего, что я с первыми своими ПЛИСками познакомился в задрипанном российском ВУЗе?

И, да, тестировал их с аналоговым осциллографом.

На уровне продвинутого пользователя.

Тот микрокод который исполняет x86 - это и есть их «самая главная военная тайна». Тут не поспоришь.

Не ясны причины такой паранойи. nVidia вон тоже ISA долго прятали, пока их полностью не среверсили, тогда уже и сами все опубликовали. Кому-то от этого стало хуже?

И к тебе вендоры бежали с распахнутыми руками и наперебой совали в руки свои отладки? сомнительно.

Я имею в виду не ISA ихнего RISC, а саму прошивку, которая исполняет x86.

Ну да, это были все подарки от вендоров. Еще там был класс вторых пней с NT, подаренных Microsoft-ом.

Аргументация на уровне школоло. Ты сравнивай RISC и x86, работающие на одинаковых частотах и выполненные по одинаковой технологии, идиот.

Ну так я тебе про это и говорю - давай ссылки на результаты тестов.

ARM на той же частоте всегда уделывает x86 и по производительности, и по энергопотреблению.

Это твои фантазии или есть результаты экспериментов?

Скорость загрузки лялиха никакого отношения к производительности CPU не имеет. Это скорее память и переферия. А по численным бенчмаркам ARM всегда уделывает x86 на той же частоте.

А кого волнуют синтетические тесты на абстрактных задачах когда ты рекомендуешь RISC или ARM как процессор общего назначения.

Идиот. Повторяю для тупых ничтожеств: доступ к регистровому файлу быстрее чем доступ к кешу.

Ну и что?

Ну и последнее: ты посмел проигнорировать тот факт, что все современные x86 - это RISC ядро, вокруг которого навешана тяжелая и тормозная обертка, единственная функция которой - обеспечение бинарной совместимости. Если ее убрать, то очевидно же, что производительность будет лучше.

Ты так говоришь, как будто внутри современного ia64-камня сидит RISC и интерпретирует машинные инструкции :)

В чистой производительности армы проигрывают

С одинаковой памятью и кешем - выигрывают.

Т.е. когда у обоих пайплайны одинаковой длины?

Ну и что?

Школоло такое школоло. Иди, уроки учи.

Ты так говоришь, как будто внутри современного ia64-камня сидит RISC и интерпретирует машинные инструкции :)

IA64 - это вообще VLIW. Там несколько RISC-пайплайнов. Да, эта архитектура еще более умная и правильная, чем RISC.

Но я так понимаю, ты, школоло тупое, вовсе не IA64 имеешь в виду, а x86_64? В таком случае - да, именно так. Там внутри чистый суперскалярный RISC, с load/store и прочими прелестями, а вокруг этого RISC аппаратный декодер из дебильных древних CISC-инструкций x86 в RISC.

Т.е. когда у обоих пайплайны одинаковой длины?

Нет. Когда одинаковый размер кешей и одинаковая архитектура и частота DDR-памяти. Ты, школоло, вообще понимаешь, что такое pipeline?

Ты сам-то понимаешь, что пайплайн - это кеш? Не?

Ты сам-то понимаешь, что пайплайн - это кеш? Не?

Ты что курил? И зачем после этого портвейном водку запивал?

Школоло такое школоло. Иди, уроки учи.

Т.е. ты не в состоянии ответить почему ты это приплёл? И не удивительно для барана, который так печётся о промахах в пайплайне и нисколько не заботится о том, что будет делать процессор с огромным регистровым файлом при переключении задач.

IA64 - это вообще VLIW. ... Да, эта архитектура еще более умная и правильная, чем RISC.

Ога. Продвинутая в сторону кладбища.

x86_64? В таком случае - да, именно так.

Т.е. т.н. «микрокоды» - это машинные инструкции для RISC-процессора, да?

Т.е. ты не в состоянии ответить почему ты это приплёл? И не удивительно для барана, который так печётся о промахах в пайплайне и нисколько не заботится о том, что будет делать процессор с огромным регистровым файлом при переключении задач.

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

Ога. Продвинутая в сторону кладбища.

Дебил. Большинство GPU - VLIW. Все современные DSP - VLIW. А что ламерье не осилило VLIW в системах «общего назначения», так это проблемы ламерья.

Т.е. т.н. «микрокоды» - это машинные инструкции для RISC-процессора, да?

Да, ламер.

Ты сам-то понимаешь, что пайплайн - это кеш? Не?

Охщи... путать кэш и конвеер - это 10.

Переключение задач вообще нерелевантно. Его стоимость мало влияет на производительность системы в целом.

Да ну?

Промахи при ветвлении на пару порядков важнее.

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

Дебил. Большинство GPU - VLIW. Все современные DSP - VLIW. А что ламерье не осилило VLIW в системах «общего назначения», так это проблемы ламерья.

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

Т.е. т.н. «микрокоды» - это машинные инструкции для RISC-процессора, да?

Да, ламер.

Замечательно. А можно теперь попросить у тебя пруф?

Охщи... путать кэш и конвеер - это 10.

Ещё один. Что такое конвейер? Просто кеш в быстрой памяти, куда предвыбираются инструкции из медленного ОЗУ, чтобы не образаться в ОЗУ на каждом шаге исполнения кода.

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

Школоло-троллоло, это должно быть очевидным для каждого, кто арифметику хотя бы на уровне третьего класса знает. Сравни, сколько ветвлений в секунду может происходить, и сколько переключений контекста. Учитывая наличие burst-доступа к регистровому файлу, кстати, разница между 8 и 32 регистрами абсолютно несущественная (не, я конечно же понимаю, что школоло и про burst ни хера не знает).

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

Ламерье - это те, кто пишет компиляторы и ОС. А не-ламерье умеет тот же Itanium употребять очень эффективно для числодробильных задач.

Замечательно. А можно теперь попросить у тебя пруф?

Ты вообще из какого мухосранска вылезло, ничтожное и тупое школоло?

Вот тут по-тупому, для ламеров объясняют:

http://sunnyeves.blogspot.co.uk/2009/07/intel-x86-processors-cisc-or-risc-or....

Ещё один. Что такое конвейер? Просто кеш в быстрой памяти, куда предвыбираются инструкции из медленного ОЗУ, чтобы не образаться в ОЗУ на каждом шаге исполнения кода.

Да... То, что ты школоло, видно было с самого начало, но настолько!!!

Конвейер, деточка, это data path, разделенный latch-ами. Соответственно, каждый коротенький элемент конвейера стабилизируется за один такт, и тактовая частота может быть сильно выше, чем если бы был один длинный data path. Но при этом, естественно, данные проходят через конвейер за несколько тактов: в лучшем случае - за столько тактов, насколько глубок конвейер, в худшем конвейер может или вовсе останавливаться, или пускать пузыри (инструкцию nop, грубо говоря). Если, например, неправильно пердсказано ветвление, то все, что после инструкции перехода было в конвейере, просто флашится, и исполнение начинается с начала. Стоимость этого дела - как минимум одна глубина конвейера.

Так о какой такой «быстрой памяти» ты тут пищишь, школоло тупое?

Школоло-троллоло, это должно быть очевидным для каждого, кто арифметику хотя бы на уровне третьего класса знает. Сравни, сколько ветвлений в секунду может происходить, и сколько переключений контекста. Учитывая наличие burst-доступа к регистровому файлу, кстати, разница между 8 и 32 регистрами абсолютно несущественная (не, я конечно же понимаю, что школоло и про burst ни хера не знает).

Я всё-таки так и не начал тебя понимать. Вот ты сравниваешь регистры с пайплайнами и считаешь что регистры лучше. Хотя и те и риски и киски используют и то и другое, с единственной разницей, что чем больше регистров ты используешь - тем чаще ты будешь выплёвывать их в ОЗУ - ведь каждой библиотеке эти регистры нужны для своих целей. Я как-то не вижу смысла в твоих высказываниях, и уж конечно из всего словоблудия, что ты тут понаписал, никак не вытекает вывод об уродливости интеловской архитектуры. Мне бы хотелось услышать от тебя более чёткий и развёрнутый ответ что именно ты пытаешься до нас донести.

Ламерье - это те, кто пишет компиляторы

Да, и кто же их пишет?

Вот тут по-тупому, для ламеров объясняют

я по ссылке прочитал что во-первых описание принципа работы high performance substrate как конвертирование cisc команд в серии простых инструкций, напоминающих команды RISC-роцессора - поверхностно и неточно. А во-вторых, что современные интеловские архитектуры являются мощной комбинацией достоинств обоих типов процессоров. Мне кажется что твой пруф слегка тебя же и опровергает, не находишь?

Стоимость этого дела - как минимум одна глубина конвейера.
Так о какой такой «быстрой памяти» ты тут пищишь, школоло тупое?

Ты в самом деле не видишь логической связи между собственными высказываниями?

Вот ты сравниваешь регистры с пайплайнами и считаешь что регистры лучше.

Ляля, ты дебил? Тебя твоя мамка-наркоманка головой вниз часто роняла?!?

Во первых, это две совершенно разные темы. Длина пайплайна - следствие наличия сложного декодера. Количество регистров - следствие отсутствия мозгов у тех, кто когда-то проектировал x86 ISA.

В прошлом было полно хороших и правильных CISC-архитектур с большими регистровыми файлами (это и PDP/11, и VAX, и m68k). У них вообще никакого конвейера не было, они все были multi-cycle FSM.

Я как-то не вижу смысла в твоих высказываниях,

Это от того, что ты - безграмотное тупое школоло.

Да, и кто же их пишет?

Повторяю для шлюхиного отродья - их пишет ламерье. Доступно?

high performance substrate как конвертирование cisc команд в серии простых инструкций, напоминающих команды RISC-роцессора - поверхностно и неточно

Для данного уровня дискуссии - более чем точно. Главные характеристики RISC - это большие файлы регистров, отсутствие многотактовых инструкций и выделенные инструкции load и store. Микрокод во всех современных интелах именно так и устроен.

А во-вторых, что современные интеловские архитектуры являются мощной комбинацией достоинств обоих типов процессоров.

«Достоинство» этой комбинации ровно одно - бинарная совместимость. Никаких других достоинств у устаревшей ISA нет и быть не может по определению. Одни недостатки.

Ты в самом деле не видишь логической связи между собственными высказываниями?

Ты непроходимо туп. Сходи к врачу, проверься, может у тебя уже терминальная стадия фимоза головного мозга, а ты и не знаешь.

Еще раз, недоумок, какое отношение конвейер имеет к памяти?!? Кроме разве что того, что от архитектуры конвейера зависит минимально необходимое число портов этой самой памяти, и как результат - кеш получается неизбежно многократно медленнее чем регистровый файл, потому как для крошечного регистрового файла можно портов довольно много налепить.

Хотя, начинаю подозревать, ты и про то, что такое порт доступа к памяти, ни хера не понимаешь, школоло убогое.

Какие нужны знания об архитектуре компьютера для изучения ассемблера?

0. Вводное. Есть два пути: простой и правильный. см. http://www.williamspublishing.com/21-days.html

отсюда: «Приблизительные затраты времени при выполнении различных операций на типичном персональном компьютере с частотой 1 ГГц летом 2001 года»

=> вот примерно такие знания должны быть, чтобы иметь представление о порядке величин

1. ссылки «Что каждый программист должен знать о памяти»

http://rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory.html

Hi-level assembler (HLA, http://en.wikipedia.org/wiki/High_Level_Assembly ) содержит хорошую, подробную книжку «Art Of Assembler»

http://www.plantation-productions.com/Webster/www.artofasm.com/Linux/HTML/AoA... , PDF:

http://www.plantation-productions.com/Webster/www.artofasm.com/Linux/index.html

Вводная статься в HLA в LinuxJournal: http://www.linuxjournal.com/article/8408

Art Of Assembler — хорошая, подробная книжка страниц на 900, содержит всё, о чём нужно иметь представление на низком уровне для начала.

Дальше можно развиваться по ссылкам из списка литературы этой книжки.

Например, того же автора, «Write a Great Code» http://www.plantation-productions.com/Webster/www.writegreatcode.com/index.html

Или, изучить вопрос линковки и загрузки:

1. Linkers and loaders by J. Levine http://linker.iecc.com/ , в Gentoo eix linkers-and-loaders

2. How to write shared libraries, U. Drepper http://people.redhat.com/drepper/dsohowto. pdf

Да, и еще - наличие конвейера это как-бы тоже отличительная черта RISC. Для какой либо стековой архитектуры, или для архитектуры с малым числом регистров от конвейера было бы очень мало толку, он бы все время или простаивал, или был бы заполнен пузырями. Так что, ничтожество, никаких других способов увеличения тактовой частоты, кроме RISC-ядра с декодером и переименования регистров для такой убогой ISA как x86 просто не было.

Agner Fog, мануалы по оптимизации

http://www.agner.org/optimize/

см. например начиная с Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms, через Optimizing subroutines in assembly language: An optimization guide for x86 platforms и мануалы по конкретной архитектуре.

Чем хороши его мануалы, описывают процесс оптимизации в целом. То есть, профилирование: как определить узкие места, что именно нужно и что не нужно оптимизировать, как конкретно это делать.

cуть-то нихрена не изменится. x86 архитектура вообще и её асм в частности - адовое говно. Вагоны костылей, реальный режим, области памяти HI_MEM/DMA/..., сегментация и это только те костыли которые я вспомнил(

ещё calling conventions, описание ABI сюда же можно добавить. Их много, все разные, на уровне компилятора и ОС. Вот тут копья ломают по поводу микрооптимизаций на асме, а ведь на уровне ABI и calling conventions самой ОС --- тот ещё древний зоопарк, ограничивающий производительность в целом на какие-то полпроцента. А может быть и больше — кто её мерял, систему в целом-то.

Вот в AmigaOS / Motolora MC 680x0 были вменяемые ABI/calling conventions. Насколько это ускорило вызов сисколлов, сложный вопрос — никто ведь не мерял альтернативные варианты.

КолибриОС / МенуэтОС отакуэ, чего уж там.

Длина пайплайна - следствие наличия сложного декодера.

Обоснуй

Количество регистров - следствие отсутствия мозгов у тех, кто когда-то проектировал x86 ISA.

В прошлом было полно хороших и правильных CISC-архитектур с большими регистровыми файлами (это и PDP/11, и VAX, и m68k). У них вообще никакого конвейера не было, они все были multi-cycle FSM.

... и они остались в прошлом.

Это от того, что ты - безграмотное тупое школоло.

Есть альтернативная версия: возможно смысла в твоих высказываниях просто нет. Ты даже в качестве пруфов приводишь ссылки на документы, которые опровергают твои же слова.

Повторяю для шлюхиного отродья - их пишет ламерье. Доступно?

Ну так и процессоры делают они же. При чём хорошие процессоры, которые бьют всякие риски и армы.

Для данного уровня дискуссии - более чем точно.

Ты утверждал что там риск сидит и эмулиет машинные команды, а оказалось что это, мягко говоря, неправда. Следовательно, дальнейшие твои выводы так же не верны.

Главные характеристики RISC - это большие файлы регистров, отсутствие многотактовых инструкций и выделенные инструкции load и store. Микрокод во всех современных интелах именно так и устроен.

А по твоей сслыке весьма справедливо пишут, что такое сравнение - поверхностно и неточно.

«Достоинство» этой комбинации ровно одно - бинарная совместимость. Никаких других достоинств у устаревшей ISA нет и быть не может по определению. Одни недостатки.

да-да, оно и видно :)

Обоснуй

Ты совсем быдло, да?

Классический RISC pipeline: IF -> ID -> EX -> MEM - >WB; При наличии сложного декодера стадия ID раздувается на много дополнительных стадий, в последних интелах их чуть ли не 8 (!!!).

и они остались в прошлом.

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

возможно смысла в твоих высказываниях просто нет.

Просто ты, ничтожество, больше половины слов не понимаешь. Ты уже доказало, ничтожество, что вообще не понимаешь, что такое pipeline. Ты не понимаешь, ничтожество, что такое register file, чем он отличается от кеша, и что такое порты памяти. Ты не понимаешь, ничтожество, что такое burst. Так что у тебя нет и ни малейшейшего шанса даже приблизительно понять мои аргументы, ты слишком безграмотная мразь, ты вообще ни черта не знаешь про архитектуру процессоров.

Ты даже в качестве пруфов приводишь ссылки на документы, которые опровергают твои же слова.

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

А по твоей сслыке весьма справедливо пишут, что такое сравнение - поверхностно и неточно.

Повторяю для тупых - в контексте нашей дискуссии оно абсолютно точно. Да, там не 5 шагов в конвейере. Там, строго говоря, более одного конвейера (потому как суперскаляр). Да, это не классический RISC (а классических и не осталось в природе). Но в плане ISA это полноценный RISC.

да-да, оно и видно :)

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

Ты непроходимо туп. Сходи к врачу, проверься, может у тебя уже терминальная стадия фимоза головного мозга, а ты и не знаешь.

Еще раз, недоумок, какое отношение конвейер имеет к памяти?!?

Откуда по-твоему туда попадают команды? И почему они там целыми пачками лежат?

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

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

Хотя, начинаю подозревать, ты и про то, что такое порт доступа к памяти, ни хера не понимаешь, школоло убогое.

Да, пожалуй, расскажи поподробнее что ты под этим понимаешь в применении к регистровому файлу.

MIPS, ARM, m68k

Ну давай, продемунстрируй нам на примере популярного среди простолюдинов ARM - покажи нам чем он прямее интеловской архитектуры.

не скажу за ARM — там команды-предикаты смущают и MMU не очень прямое... но вот x86 vs. m68k, например:

* ортогональный набор команд. В любой команде можно использовать любой регистр, нет таких чудес как в Z80 djnz label; (неявный регистр B), или в x86: LOOP label; (неявный cx/ecx/rcx) * 8 регистров данных, 8 регистров адресных * косвенная адресация. двойная-тройная косвенная адресация в одной команде. В одной команде двойные-тройные скобки — за милое дело. * автоинкремент/автодекремент как в PDP 11 или в Си: MOVL (a1)+, -(a2) ; *(--a2)= *a1++ * да, MMU тоже не очень ровный (вообще отдельной микросхемой)

второй и третий пункт напрямую ложатся на Си, как в PDP11.

ортогональность + много регистров позволяет отвести на ABI для сисколлов свой отдельный набор регистров и не париться. Грубо говоря, у нас ABI использует один набор регистров для ядра и сисколлов, и второй набор для функций программы. В итоге не нужны в сисколлах трамплины в пространство ядра, и сохранение всех регистров, а нужен способ защитить один набор от другого.

Хотя такого способа конечно нет, и ABI AmigaOS например — это просто соглашение, в других ОС вроде A/UX (Amiga Unix, что-то BSD-подобное) или Linux на 680х0 — полноценный режим ядра/пользователя, с переключениями контекста, сохранением/восстановлением регистров, MMU и прочим.

Вот например если бы идею регистрового окна и ABI из SPARC доработать: разделить регистровый файл на 2 окна, регистры ядра и регистры юзермоде, и управлять там сходным ABI, было бы что-то подобное. И защитить юзермоде регистровый файл при работе в режиме ядра, и наоборот.

Откуда по-твоему туда попадают команды? И почему они там целыми пачками лежат?

Из instruction cache, естественно. Все современные процессоры в этом плане чисто Гарвардские.

Только непонятно зачем это делать, если в крошечный регистровый файл помещается лишь крошечный кусочек байтов,

Дебил... Редкостной незамутненности дебил!

Много регистров необходимо для того, чтобы конвейеры не пустовали. Если все вычисления проводятся только над регистрами, то можно нагрузить все стадии конвейера, вставляя пузыри только там, где невозможно разрулить зависимости между этими самыми регистрами. Когда регистров мало, промежуточные значения спиллятся в память, а это - инструкции load и store, которые, во первых, имеют тенденцию останавливать весь конвейер и ждать, а во вторых не позволяют вычислить зависимости между значениями и раскидать вычисления по параллельным конвейерам.

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

Где таких ничтожных идиотов делают?!? Там надо все напалмом выжечь, чтоб они дальше не размножались!

При наличии 32 регистров общего назначения даже весьма сложные выражения, типичные, например, для машинной графики, полностью помещаются в регистры и не требуют памяти. Совсем. Вместе со всеми необходимыми константами, не влезшими в immediate поля. Так о каком таком «постоянно перезагружать» ты тут пердишь?

Да, пожалуй, расскажи поподробнее что ты под этим понимаешь в применении к регистровому файлу.

Смотри - ID читает два значения из регистров. В один такт. В тот же такт WB пишет одно значение в регистр. Получается три порта только на один конвейер. Теперь умножь эти три порта на количество суперскалярных конвейеров. Ужаснись. Несчастный 32*32 регистровый файл занимает площади на кристалле до хрена, хватило бы на много килобайт SRAM кеша, потому как там сплошные crossbar switches.

А у кеша данных этих портов обычно только два, один на чтение, один на запись. У кеша инструкций (который поменьше размерами) может быть два-три порта чтения.

регистры ядра и регистры юзермоде,

В тумбе так и сделано.

Классический RISC pipeline: IF -> ID -> EX -> MEM - >WB; При наличии сложного декодера стадия ID раздувается на много дополнительных стадий, в последних интелах их чуть ли не 8 (!!!).

Ты количество и длину словами-синонимами считаешь чтоли, мой малообразованный друг?

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

В смысле??? Ты же сам писал, что огромные регистровые файлы - это благо, следующим постом написал что этот костыль отмер в процессе эволюции ВТ, а я почему-то должен отвечать за твой базар?

Мои ссылки подтверждают мои слова.

Почаще повторяй эту мантру - вдруг кроме тебя самого в неё поверит ещё какой-нибудь лошок, случайно забрёдший в этот тред.

Повторяю для тупых - в контексте нашей дискуссии оно абсолютно точно.

Только в твоём пруфе пишут что поверхностно и не точно, а так никаких претензий, конечно. Ты можешь иметь собственное оценочное суждение, только непонятно зачем тогда приводить текст, его опровергающий, в качестве пруфа :)

С какой целью ты пытаешься нас всех тут обмануть?

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

И не говори, самому противно от того, что ты постоянно макаешь меня в твоё невежество

Ты количество и длину словами-синонимами считаешь чтоли, мой малообразованный друг?

Это мне говорит тупая быдлятиа, которая вообще не знает, что такое конвейер?

Да, в данном случае это синонимы. Суперскалярность начинается там после ID - на уровне RISC-инструкций. А декодер полностью линейный.

Ты же сам писал, что огромные регистровые файлы - это благо, следующим постом написал что этот костыль отмер в процессе эволюции ВТ, а я почему-то должен отвечать за твой базар?

Быдло ты, быдло. Они не отмерли, а перекочевали в RISC. Умерли multi-cycle процессоры. Просто некоторые (тот же x86), превратившись в конвейерные RISC, унаследовали за каким-то лысым хреном бинарную совместимость с древним говном, в том числе и ничтожное количество регистров. Серьезные процессоры всегда были с большим числом регистров, а x86 - это всего лишь жалкие писюки. Сейчас, в x86_64 это немного исправили, теперь значительно больше регистров общего назначения доступно, но родовой травмы x86 это не отменяет.

Только в твоём пруфе пишут что поверхностно и не точно, а так никаких претензий, конечно.

Начинаю догадываться. Читать ты не умеешь вообще. Совсем. Смотришь в текст, а видишь фигу. Предложения длиннее трех слов у тебя в связный текст вообще не складываются.

Итак, сын гулящей сучки, рассказывай, чем ядро x86 не RISC? Раз уж, по твоему гомосяцкому мнению, «сравнение не точно»?

Вот, читай тут про конкретное устройство декодера: http://users.utcluj.ro/~baruch/book_ssce/SSCE-Intel-Pipeline.pdf

И сравни это со сложностью декодера, например, той же тумбы.

Из instruction cache, естественно. Все современные процессоры в этом плане чисто Гарвардские.

Так, а он не память, нет? А откуда берётся стоимость промаха?

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

Много - это сколько конкретно?

Когда регистров мало, промежуточные значения спиллятся в память, а это - инструкции load и store, которые, во первых, имеют тенденцию останавливать весь конвейер и ждать, а во вторых не позволяют вычислить зависимости между значениями и раскидать вычисления по параллельным конвейерам.

И как это сказывается на исполнении типичных задач процессором общего назначения?

При наличии 32 регистров общего назначения даже весьма сложные выражения, типичные, например, для машинной графики, полностью помещаются в регистры и не требуют памяти. Совсем. Вместе со всеми необходимыми константами, не влезшими в immediate поля. Так о каком таком «постоянно перезагружать» ты тут пердишь?

И сколько времени займёт загрузка всех регистров данными для следующего «весьма сложного выражения»? Да, и являются ли эти «весьма сложные выражения» типичной задачей для процессоров общего назначения?

Смотри - ID читает два значения из регистров. В один такт. В тот же такт WB пишет одно значение в регистр. Получается три порта только на один конвейер. Теперь умножь эти три порта на количество суперскалярных конвейеров. Ужаснись. Несчастный 32*32 регистровый файл занимает площади на кристалле до хрена, хватило бы на много килобайт SRAM кеша, потому как там сплошные crossbar switches.

Т.е. получается, что большое количество регистров не только бессмыссленно, но ещё и вызывает дикое увеличение сложности кристалла?

Да, в данном случае это синонимы.

Ну-ну

Они не отмерли, а перекочевали в RISC

Который, как белко писал выше, по производительности сосёт у интела.

Итак, сын гулящей сучки, рассказывай, чем ядро x86 не RISC?

Хм, а начинал ты с бодрых утверждений о том, что интеловская архитектура кривая, а RISC - прямая :)

Ну-ну

Ты конченный дебил. Вообще ни хера из дискуссии не усвоил.

Который, как белко писал выше, по производительности сосёт у интела.

Кем отмечено, мразь? Если уж говорить про те же частоты и аналогичную память и кеш, то тот же IA64 уделывает x86_64 в хвост и в гриву.

Хм, а начинал ты с бодрых утверждений о том, что интеловская архитектура кривая, а RISC - прямая :)

Именно. x86 - это декодер кривой и уродливой древней ISA, вокруг прямого и правильного RISC. И оно было бы намного быстрее, если декодер выкинуть и оставить только RISC. Ты совсем тупое дерьмо, что даже этого не догоняешь?