Арифметические операции над небольшими целыми числами в процессоре SPARC

Здравствуйте, форумчане!

Есть ли среди вас знатоки архитектуры SPARC? Если да, то просветите меня, пожалуйста, по такому вопросу.

Как в процессоре SPARC выполняются простые арифметические действия над целыми числами размера меньшего, чем стандартное машинное слово этого процессора (32 или 64 бит)? Допустим, нам надо выполнить какую-то простую операцию над байтом или 16-битным полусловом. Мне хотелось бы понять, каким набором машинных инструкций эта операция над байтом или полусловом длиной в 16 бит будет воплощена? Особенно мне интересно, как осуществляется контроль за переполнением разрядной сетки в этом случае.

В случае архитектуры x86 особых вопросов не возникает - как и в любой другой CISC-архитектуре код операции (поле КОП) в команде один и тот же независимо от размера данных, а собственно размер операндов задаётся специальными битами признаков внутри самой команды. Проблемы контроля переполнения данных в x86 (как, впрочем, и в других CISC-архитектурах) тоже нет. Фиксируется переполнение той разрядной сетки, которая указана в поле длины операндов. Т. е. если длина данных равняется одному байту - в регистре флагов фиксируется выход значения за границы одного байта, если операнды представляют собой 16-битные полуслова - фиксируется выход за пределы 16-битного представления целых чисел, если длина операндов равна 32-битному слову, результат должен помещаться в 32 бита (в противном случае будут установлены соответствующие флаги в регистре флагов). То же самое относится к 64-разрядным целым числам.

Хотелось бы понять, как те же самые проблемы (хранения небольших целых чисел размера меньшего длины машинного слова, манипулирования этими маленькими числами, контроля над переполнением данных при арифметических операциях с их участием) решаются в архитектуре SPARC. Для примера можно было бы рассмотреть какое-то простое арифметическое действие (например, сложение или вычитание) над двумя числами размером с байт или 16-битное полуслово и привести элементарную программку, которая его выполняет.

Был бы очень благодарен тем, кто мне ответит.

0

Сообщение от Evg Я тоже не утверждаю обратное, ибо этого не знаю. Я всего лишь предполагаю. Но я не разбираюсь в интеловской системе команд, у меня нет ни времени не желания проводить эксперимент, хотя посмотреть на результаты чужого эксперимента было бы интересно. Но, как я уже говорил, у меня нет полного понимания того, как эксперимент проводить правильно. И дело не в алгоритме, по которому должен работать софт, а в нехватке знаний о том, как работает конвейер. При незнании влёгкую можно поставить эксперимент, который как бы подтвердит идею, но окажется, что эксперимент был неправильный. Типа того, что проверяем утверждение "все числа чётные". Проверяем числа 2, 4, 6, 8, ..., убеждаемся, что все они чётные, распространяем результат эксперимента на всю вселенную и делаем (некорректный) вывод о том, что все числа чётные

Ну, написать правильный, грамотный тест задача не такая простая. Его ещё надо придумывать, на одно это времени уйдёт гораздо больше, чем на само программирование. Но написать маленькую вонючку (не тянущую на грамотный тест) можно.

ct - control transfer. Термин для операции передачи управления, я просто не знаю, как она на интеле называется. Переходы бывают статические (по заранее известному адресу) и динамические (по значений в регистре).

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

Так вот для безусловного динамического перехода (или call'а) не имеет смысл строить какие-то технологии, аналогичные предсказателю перехода, потому что невозможно заранее попытаться исполнить код, адрес которого ещё не известен. И вот динамический переход может быть естественным барьером против механизма out-of-order, который обеспечит то, что сначала самомодифицируемый код окажется в памяти гарантированно раньше того момента, когда он попадёт в конвейер. И именно этот момент отличает код работы с вложенными функциями от варианта N1-N2. Опять-таки это размышления, а не факт

Рассуждения в общем-то логичны. Но тут вот в чём дело. Перед тем как будет выполнена команда косвенного перехода через регистр какая-то другая команда, предшествующая косвенному переходу, должна занести адрес перехода в этот регистр. Это может быть команда mov (в твоём примере с вложенной функцией и кодом-обёрткой над ней, трамплином, как ты его называешь, наверняка так оно и есть). Это может быть в общем-то любая арифметическая операция — add, sub и т. д. Так вот, умный процессор может досчитаться до этой команды записи в регистр, ну, вернее говоря, он просто поймёт, что команда jmp register просто связана с этой командой mov, а других зависимостей (от других команд) у неё нет, и исполнить сначала mov register, register2, а потом этот jmp register. И исполнить он может эту пару команд последовательно, без промежутков, допустим, на одном из своих конвейеров. И не дожидаться, пока будет сформирован другими mov'ами весь код трамплина. Т. е. этот косвенный переход будет для процессора почти как прямой с заранее известным адресом перехода. Тут даже никакого механизма предсказания переходов не потребуется, если это будет так. Ты мысль мою понял, наверное. Тут дело в другом — пока процессор вычислит эту зависимость, выполнит обе команды и решит, по какому адресу ему продолжить загружать код, пройдёт немало времени. За это время возможно уже код "трамплина" будет готов и загружено в буфер будет то, что надо.

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

0

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

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

Сообщение от JohnyWalker Поэтому когда ты говоришь о невозможности применения принципов программирования 50-ых — 60-ых годов (особенно на машинном уровне), я с этим не согласен. Принципы-то в общих чертах сохранились прежними

На этих принципах ты не построишь программу размером в миллионы строк программного кода. Это и следует считать "невозможностью"

Сообщение от JohnyWalker Но если такая возможность предусмотрена логикой вычислительной машины и принципами, заложенными в неё ещё во времена фон Неймана

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

Сообщение от JohnyWalker Потом этот приём — вставка кода через переполнение буфера, — как мне кажется, отнюдь не единственный и не основной в арсенале хакера. Мы ведь всегда можем средствами ОС запретить страницы с кодом изменять, а страницы с данными исполнять. И если мы вдруг вообще запретим всякую самомодификацию кода средствами процессора или операционной системы, вряд ли это отпугнёт хакеров

Пока динамическое связывание работает через модификацию исполняемых сегментов кода, запретить не получится. Хотя в QNX уже по умолчанию запрещено это делать. Хакеров это не отпугнёт, но жизнь у них станет сложнее, причём бесплатно (с точки зрения "нормального" пользователя). Ещё раз повторю, никто не запрещает модифицировать код. Но все было бы хорошо, если бы процессор не поддерживал специальных возможностей по автоматическому детектированию модификации кода, т.к. это и облегчит процессор, и удешевит его. Там, где модификация кода является необходимостью - пожалуйста, используйте, но используйте специальные команды процессора (как iflush на sparc'е).

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

Сообщение от JohnyWalker У тебя есть примеры программ или их фрагментов, написанных этими стариками?

Есть. К сожалению показать их не могу, т.к. за это на мне будет висеть ответственность. Но на пальцах могу привести один из примеров, с которым я в своё время долго разбирался. Текст программы был чуть ли не сотню страниц размером. В некоторой переменной с плохим именем (типа "a") условно было записано "количество шариков". В какую-то ветку программы мы должны были зайти при сложной комбинации условий, из которых очень неявно вытекало, что количество шариков равно двум. Внутри этой ветки потребовалось понятие условно "высота здания", которая равна трём. Вместо того, чтобы явно воткнуть константу 3, было использовано выражение "a + 1" (поскольку постфактум его значение должно было равняться трём). И вот когда сидишь вникаешь в эту многокилометровую портянку, то в какой-то момент код с трудом, но понимаешь, и оно плавно переходит в состояние, когда теряешь всякую логику. Сначала я думал, что человек попросту идиот, но его коллега (из той же возрастной категории) мне рассказал, что такой маразм лезет из многолетнего стажа программирования на ассемблере, когда константы рожать слишком дорого, быстрее работать со значениями на регистрах. Для меня период одновременного программирования на языке и на ассемблере был в школьном возрасте, а потому мозг легко адаптируется и переключается с одного варианта на другой, а вот когда человек всю жизнь программировал на ассемблере или около того, а в 40 лет перешёл на язык программирования, то мозг уже не переключается

Сообщение от JohnyWalker В ходе всех этих сложных и хитроумных оптимизаций возникнет куча побочных эффектов. Один из них (и я чувствую, далеко не единственный) мы с тобой обсуждали. Так вот задача создателей процессора все эти побочные эффекты вычислить, понять и устранить

Это не так. Уже давно прошли времена, когда создатели процессоров варились в собственном соку и делали вещь в себе. Железо уже давно создаётся в тесном сотрудничестве с разработчиками операционных систем, компиляторов, библиотек. Теперь единицей абстракции является не процессор, а машинный комплекс. Т.е. для программиста создают иллюзию идеальной машины не только процессор, но и система программирования (за которой прячется ОС, компилятор, библиотеки). Но закон дырявых абстракций никто не отменял, а потому полной иллюзии идеальной машины никогда не будет. Но для человека, занимающегося программированием с этапа самого начала пройдёт очень много времени, прежде, чем он увидит дыры в абстракции

Добавлено через 5 минут

Сообщение от JohnyWalker Хотя ты мне нашёл пример, когда даже создатели компилятора gcc, вполне серьёзной софтины, почему-то прибегли к этому приёму (к генерации кода во время выполнения).

Про "почему-то" ответ довольно логичен. Потому что афторы (точнее, создатели) gcc - ещё те гавнокодеры. Вложенные функции в виде расширения у них появились давно. Но вложенные функции в общем-то противоречат философии языка Си (уж не знаю, каким другим словом это назвать). Это противоестественное расширение, поэтому ни в какие более поздние стандарты языка Си вложенные функции не вошли, в отличие от других расширений, которые изначально появились в GNU C, а потом попали в официальные стандарты. И опять здесь остаётся весьма идиотская причина, по которой всё это до сих пор живёт - совместимость. На том же самом QNX этот приём не будет работать

Сообщение от JohnyWalker Но если такая возможность следует из логики работы вычислительной машины (принципа хранимой программы), значит она должна быть реализована в полном объёме и безо всяких ограничений. А уж пользоваться этим или нет — это воля программиста, как ему заблагорассудится

Не из "логики", а "из возможности, которая постфактум". Много лет назад люди что-то попробовали сделать, опираясь на те возможности, которые были в настоящий момент, но не думали о том, что в будущем это всё создаст массу проблем

Добавлено через 4 минуты

Сообщение от JohnyWalker Но написать маленькую вонючку (не тянущую на грамотный тест) можно.

Естественно речь идёт о вонючке. Но её надо правильно написать

Сообщение от JohnyWalker Перед тем как будет выполнена команда косвенного перехода через регистр какая-то другая команда, предшествующая косвенному переходу, должна занести адрес перехода в этот регистр. Это может быть команда mov (в твоём примере с вложенной функцией и кодом-обёрткой над ней, трамплином, как ты его называешь, наверняка так оно и есть). Это может быть в общем-то любая арифметическая операция — add, sub и т. д. Так вот, умный процессор может досчитаться до этой команды записи в регистр, ну, вернее говоря, он просто поймёт, что команда jmp register просто связана с этой командой mov, а других зависимостей (от других команд) у неё нет, и исполнить сначала mov register, register2, а потом этот jmp register. И исполнить он может эту пару команд последовательно, без промежутков, допустим, на одном из своих конвейеров. И не дожидаться, пока будет сформирован другими mov'ами весь код трамплина. Т. е. этот косвенный переход будет для процессора почти как прямой с заранее известным адресом перехода

Я имел в виду то, что конвейер, увидев кодировку команды с косвенным переходом, будет трактовать её как барьер, т.е. механизм, при котором out-of-order НЕ будет переставлять операции, идущие до точки косвенного перехода и после неё. Так оно, или не так - я не знаю, это вопрос далеко выходит за рамки знаний среднего программиста на ассемблере, а потому тут и спросить не у кого. Тут нужно читать сложные спецификации по процессору, а их тоже надо уметь читать, эта задача не для слабонервных

1

Вот вся разница между тобой и мной в нашей дискуссии в том, что я смотрю на компьютер и процессор, как на интересную и умную машину. Она не стесняет и не ограничивает моих возможностей, она обладает высокой степенью гибкости, а самоизменяющийся код как раз и являет собой пример именно такой высокой гибкости, и её язык при этом строго соответствует своей спецификации. Т. е. команды можно сочетать друг с другом любым возможным способом, каждая команда выполнит ровно то, что написано в справочнике по системе команд — никаких сюрпризов и побочных эффектов от команды ждать не придётся. Это действительно научно-инженерный подход. Для тебя же процессор и компьютер — это всего лишь инструмент для заработка денег кучкой алчных и вёртких барыг. Есть рынок, есть текущие задачи и стиль программирования, востребованный временем, значит, надо ему всячески угождать, выпуская продукт, соответствующий этим запросам. Выпустить быстрее, больше, слупить поболее бабла за предельно короткий срок. Это гнилой подход на самом деле, ни к какому прогрессу не ведущий. Этим принципом руководствуется Голливуд, выпуская свои идиотские фильмы, им же в ещё большей степени руководствуется российский кинематограф, создавая кино, непригодное к просмотру, наши замечательные соотечественницы-писательницы — Донцова, Устинова, Маринина — или такой же замечательный писатель — Акунин — действуют в том же русле (живут все они, кстати, припеваючи). Этот же подход — "Всё во имя коммерции!" — исповедует и компания Microsoft. При этом нельзя сказать, что рождённая этой фирмой ОС Windows действительно качественная, надёжная и красивая система, скорее, наоборот. Так что не стоит бранить учёных, называя их паразитами, проедающими бюджет, от них, скорее, больше пользы.

Да, мне нравится идея самомодификации кода, я нахожу её плодотворной. А ещё мне нравится оператор goto в ЯВУ, преданный анафеме блюстителями стиля, я уважаю указатели в C. С Лиспом и Хаскеллем поработать не приходилось. И я не вижу никакого резона всё это запрещать.

Сообщение от Evg Процессор - это не вещь в себе. Так же, как и программа. Компьютер нужен для того, чтобы решать какие-то задачи. А потому его устройство в конечном итоге диктуется требованиями, которые нужны для задачи. От требований к задачам идут требования к системе программирования, от возможностей и потребностей системы программирования идут требования к железу. И ниоткуда нет требований самомодификации кода, кроме как от всяких вредоносных и шпионских программ

По идее, самомодификация — это забавная игрушка, имеющая больше теоретический интерес. Да, на обычном языке программирования, будь то C/C++/Java, не напишешь нормальным путём самомодифицирующейся программы. Но вот представь себе такой пример. У тебя есть какой-то сложный численный расчёт (допустим, что-то считается методом конечных разностей). И в этом расчёте изначально неизвестна формула, по которой необходимо выполнить вычисление, формулу предстоит ввести пользователю после запуска программы. Формула, очевидно, имеет текстовую форму и непосредственно исполниться не может. Как решить задачу? Я вижу только один вариант. Встроить в нашу программу небольшой компилятор, скомпилировать им нашу формулу, после чего полученный код поместить в какую-то часть программы (в кодовую зону или в зону данных — не важно) и передавать ему управление (например, вызывать этот код из цикла, если у нас численные методы). Можно было бы, конечно, подойти по-другому. Компилировать нашу формулу, порождать для полученного кода целую dll/so и помещать в неё нашу функцию. А потом эту so, естественно, динамически компоновать с основной программой. Но ведь это более громоздко и противоестественно. Так что самоизменяющийся или самопорождающийся код может быть востребован на практике в некоторых случаях. И не только хакерами и вирусописателями. Более простое решение - это, конечно, встроить в нашу программу вычислений маленький интерпретатор (вместо компилятора), но тогда скорость работы упадёт в лучшем случае раз в 10 - 20.

Вообще можно было бы придумать язык, в котором была бы предусмотрена возможность самогенерации кода в процессе выполнения. Для таких случаев годился бы тот же самый подход. Сейчас это способны делать только интерперетаторы. Универсально, но довольно медленно. Интересно, а как там в Лиспе и Хаскеле? Может, там тоже есть встроенный компилятор вроде того, о котором я говорил?

И неизвестно, где ещё самомодифицируемый код может пригодиться. Боюсь, мой пример не единственный.

На этих принципах ты не построишь программу размером в миллионы строк программного кода. Это и следует считать "невозможностью"

Ты опять, в который уже раз, путаешь принципы технологии (которые достаточно фундаментальны и меняются нечасто) и технику исполнения (которая меняется с годами, к тому же подвержена влиянию моды). Программа в 10 млн. строк кода (а примерно столько имеет, допустим, ядро Линукс), написанная на Си, по своим принципам ничем не отличается от такой же программы середины 1960-ых годов, написанной, допустим, на Фортране или Алголе. Те же if, else, while, do, break, continue, такие же переменные и т. д. Такие же функции и процедуры. Всё отличие в размере, а как следствие, в большей модульности исходников, в лучшей продуманности общей структуры программы. Но это не новые принципы программирования, а всего лишь более проработанный подход к планированию. А твердить "На этих принципах ты не построишь программу размером в миллионы строк программного кода" можно до бесконечности. Но C (я про плюсы даже не говорю) очень простой язык, а на нём создают гигантов вроде ядра Линукс или X Window.

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

Да в том-то и дело, что архитектурно все базовые принципы сохранились (назови мне фундаментальные отличия, если считаешь, что это не так). Всё отличие в основном в огромном усложнении машин. И нет смысла приносить в жертву принцип фон Неймана, принцип, согласно которому программа и данные хранятся в одной памяти, а как следствие, код может быть подвергнут модификации самим же кодом.

Пока динамическое связывание работает через модификацию исполняемых сегментов кода, запретить не получится. Хотя в QNX уже по умолчанию запрещено это делать. Хакеров это не отпугнёт, но жизнь у них станет сложнее, причём бесплатно (с точки зрения "нормального" пользователя). Ещё раз повторю, никто не запрещает модифицировать код. Но все было бы хорошо, если бы процессор не поддерживал специальных возможностей по автоматическому детектированию модификации кода, т.к. это и облегчит процессор, и удешевит его. Там, где модификация кода является необходимостью - пожалуйста, используйте, но используйте специальные команды процессора (как iflush на sparc'е).

Не-а, сразу ложные выводы.
Первое заблуждение. Не облегчит это сколько-нибудь серьёзно процессор. В нём столько всякой разнообразной аппаратуры и по детектированию зависимостей между командами, и по переименованию регистров, и по определению всяких нестандартных ситуаций, когда разрешить конфликт можно только, приостановив на время нижние ступени конвейера, и дождавшись выполнения впереди идущих команд (pipe interlocks). Всякие статистические предсказатели ветвлений (фирма AMD для их предсказания додумалась уже использовать нейронные сети) очень сложно устроены. Кэш тоже сложный с опережающей (интеллектуальной, спекулятивной) загрузкой данных. Так что автоматическое детектирование модификации кода — это далеко не самое сложное, что есть в процессоре. Это капля в море. Выкинуть эту функцию — и процессор упростится не более, чем на 1 - 2%. Ровно на столько же он станет дешевле (а то и меньше). И заплатить вместо 400 долларов, допустим, 392, чтобы получить сильно изуродованную архитектуру — а оно мне надо?

Второе заблуждение. Если сохранить возможность самомодификации кода, но не отслеживать её аппаратурой процессора, хакерам, как ты думаешь, это нисколько не усложнит жизнь. Просто между модификацией/генерацией некоторой команды и её исполнением надо будет выждать некоторое количество тактов. Т. е. нельзя будет модифицировать одной командой код другой рядом с ней стоящей команды. Ну так хакер сообразит вставить между модифицирующей и модифицируемой командой N штук nop (штук 20 - 30, больше и не надо). Если и это не поможет (так как nop'ы будут просто пропущены процессором и это не займёт у него ни одного такта), хакер вставит просто кучу бессмысленных арифметических и пересылочных действий — mov, xchg, add, sub, mul, div (последняя выполняется дольше всего), and, or, xor. После того как весь этот мусор выполнится, нужная команда или группа команд будет готова к загрузке в буфер. Так что такой наплевательский подход на устройство процессора усложнит жизнь приличному программисту, но совсем не хакеру.

Но на пальцах могу привести один из примеров, с которым я в своё время долго разбирался. Текст программы был чуть ли не сотню страниц размером. В некоторой переменной с плохим именем (типа "a") условно было записано "количество шариков". В какую-то ветку программы мы должны были зайти при сложной комбинации условий, из которых очень неявно вытекало, что количество шариков равно двум...

Ну, уж это совсем идиотский пример. Да я и с трудом представляю себе ассемблер, в котором сделать, допустим,
mov ax, 3
намного сложнее, чем
inc ax
Я выбрал интелловский ассемблер, но это, скорее, псевдокод. Я так программировать не призываю. Хотя над вашими программёрскими стандартами я смеюсь.

Это не так. Уже давно прошли времена, когда создатели процессоров варились в собственном соку и делали вещь в себе. Железо уже давно создаётся в тесном сотрудничестве с разработчиками операционных систем, компиляторов, библиотек. Теперь единицей абстракции является не процессор, а машинный комплекс. Т.е. для программиста создают иллюзию идеальной машины не только процессор, но и система программирования (за которой прячется ОС, компилятор, библиотеки). Но закон дырявых абстракций никто не отменял, а потому полной иллюзии идеальной машины никогда не будет. Но для человека, занимающегося программированием с этапа самого начала пройдёт очень много времени, прежде, чем он увидит дыры в абстракции

Железо, положим, и тогда делалось в тесном сотрудничестве с разработчиками ОС и трансляторов, у тебя неверное представление об истории вычислительной техники. Возьми, к примеру, фирму DEC или IBM — крупнейшие и лучшие производители железа своего времени. Обе фирмы выпускали не только компьютеры, но и полный набор программного обеспечения к нему. Возьми, к примеру, PDP-11. DEC снабжала его операционной системой, у них их было даже 2 на выбор — RSX-11 и RT-11. RSX-11 была маленькой многозадачной операционной системой с командной строкой. К ней шёл компилятор того же Фортрана (он был обязательным тогда) и возможно даже C, какой-нибудь простенький примитивный редактор (вполне приличный по меркам своего времени), ассемблер PDP-11 обязательно присутствовал в системе и обязательно шли с системой библиотеки ввода-вывода для языков программирования и системных вызовов ядра RSX-11. Плюс полный комплект документации. RSX-11 - нормальная ОС своего времени для мини ЭВМ, кому она не нравилась, мог купить у AT&T Unix.

Другой пример. Фирма IBM, разработавшая к началу 70-ых (а может, чуть раньше) своего великого монстра. Назывался монстр IBM System/360, он вообще шёл с операционной системой OS/360 (очень сложной для своего времени) и обширнейшим набором программ. Ассемблер, компиляторы, Фортран, PL/1, Cobol, все необходимые базовые библиотеки, — всё это присутствовало в системе безоговорочно. И полный комплект документации.

Третий пример. СССР. ЭВМ БЭСМ-6, середина 60-ых годов. Там тоже была простенькая операционная система, какой-нибудь пакетный исполнитель заданий, обязательно присутствовал транслятор Фортрана или Алгола-60 (или обоих вместе). Наверняка простенькая библиотека ввода-вывода тоже была, иначе как этим всем пользоваться. И разработаны все эти программы были скорее всего тем же самым институтом, который проектировал аппаратуру.

Четвёртый пример. ЭВМ МИР. Маленькая вычислительная машинка примерно тех же лет, имевшая небольшие габариты. Тоже весь базовый набор программ имела от производителя, а как же без них.


Так что производители железа того времени не просто сотрудничали с создателями программ, а они сами же и создавали эти программы. Это были два подразделения, работавшие в одной фирме (или в одном институте в СССР). А так, выпустить голое железо. Кто бы для него стал базовое ПО писать? Кому бы оно нужно было? В США это всё просто покупать бы не стали, и фирмы-производители это всё прекрасно понимали. Так что представление о том, что производители компьютеров варились тогда в собственном соку и делали вещь в себе, оно абсурдно. Это такая вымышленная реальность у тебя в голове. Сейчас произошло, скорее, разделение труда между производителями процессоров и фирмами, разрабатывающими программы, хотя они и плотно общаются.

А про то, что теперь для программиста теперь единицей абстракции является не процессор, а машинный комплекс, и что недостатки процессора можно исправить компилятором, библиотеками, ОС и пр. и пр. — это всё фигня чистой воды. Процессор настолько фундаментальная и важная здесь единица, что его недостатки не выправишь ничем, они будут все вылезать наружу. Если команды будут иметь кучу побочных эффектов при исполнении, связанных с другими рядом стоящими командами, исправить это компилятором будет очень сложно, да и неразумно. Самое страшное будет, что разработчикам компилятора будет очень сложно, почти невозможно, все эти побочные эффекты просчитать. И ошибки нет-нет, да и будут иногда вылезать. Примеры таких побочных эффектов в MIPS и SPARC, не самые страшные, — это слоты задержки ветвления, в ранних MIPS'ах слоты задержки загрузки. Всё это мог учесть компилятор, хотя хорошего в этом было мало. Если же постараться так облегчить и упростить суперскалярник, будет вообще белиберда на выходе.

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

0

Про "почему-то" ответ довольно логичен. Потому что афторы (точнее, создатели) gcc - ещё те гавнокодеры. Вложенные функции в виде расширения у них появились давно. Но вложенные функции в общем-то противоречат философии языка Си (уж не знаю, каким другим словом это назвать). Это противоестественное расширение, поэтому ни в какие более поздние стандарты языка Си вложенные функции не вошли, в отличие от других расширений, которые изначально появились в GNU C, а потом попали в официальные стандарты. И опять здесь остаётся весьма идиотская причина, по которой всё это до сих пор живёт - совместимость. На том же самом QNX этот приём не будет работать

Не знаю ничего про аффторов gcc, говнокодеры они или хорошие программисты. Но против вложенных функций в C ничего не имею. Паскаль же с ними как-то живёт, там тоже они есть. Я совсем другое имел в виду. Код-трамплин необходим, т. к. вложенная функция, вопреки заявленному, принимает лишний параметр — адрес стека функции-"хозяйки". Вопрос в другом, нужно ли было код этого трамплина формировать в стеке. Может быть, его можно было создать в области кода во время компиляции (а не исполнения). Но тогда непонятно, как ему передавать этот доп. параметр. Через глобальную переменную? А если там многократный вызов, рекурсия, многопоточность. Эта глобальная переменная, т. к. она в одном экземпляре, будет затёрта. В общем, возникает вопрос повторной входимости. Как это противоречие разрешить-то. Сложная задача. Может, авторы gcc тут не говнокодеры, а наоборот, молодцы, и выбрали они самое простое и надёжное решение.

Я имел в виду то, что конвейер, увидев кодировку команды с косвенным переходом, будет трактовать её как барьер, т.е. механизм, при котором out-of-order НЕ будет переставлять операции, идущие до точки косвенного перехода и после неё.

А будет ли оно так? Ещё большой вопрос.

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

0

Сообщение от JohnyWalker каждая команда выполнит ровно то, что написано в справочнике по системе команд — никаких сюрпризов и побочных эффектов от команды ждать не придётся

Ты когда-нибудь читал реальное описание системы команд? Не книжку из разряда "ассемблер за 21 день", а реальное полное описание каждой команды (т.е. полная растактовка по конвейеру). Вот это и есть полноценное описание. А то, что для тебя может стать сюрпризом какое-то для тебя неочевидное свойство - это всего лишь следствие того, что ты на систему команд смотришь так, как тебе больше нравится, а не на то, как реально работает процессор

Сообщение от JohnyWalker Для тебя же процессор и компьютер — это всего лишь инструмент для заработка денег кучкой алчных и вёртких барыг

Не "для меня". Это то, что имеет место быть в реальном мире. Просто я на устройство мира смотрю без фантазий

Сообщение от JohnyWalker Это гнилой подход на самом деле, ни к какому прогрессу не ведущий

Вот когда выпустишь свой процессор, хотя бы самый простой и хотя бы на бумаге (в виде описания на Verilog'е), тогда и будешь иметь моральное право давать оценку действий тем людям, которые выпускают микросхему с плотностью в сотни миллионов транзисторов на квадратном сантиметре. Жизнь устроена так, что судят и критикуют в основном те, кто сам ничего не сделал

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

Есть ли польза от учёных, которые тратят огромные деньги на телескопы и изучают просторы вселенной? Пока неивестно. Вклад в нашу жизнь людей, которые в своё время изучали электричество (явление, непонятное для непосвящённых), в наши дни вполне ощутим. Если бы компьютер остался дорогой игрушкой для избранных, то вполне могло оказаться так, что основным его пользователем были бы военные. Так что всякие товарищи типа Билла Гейтса внесли немалый вклад в то, какими компьютеры являются сейчас. А так же и в то, что ты можешь себе позволить проводить эксперименты N1-N2 в домашних условиях. Можно сколько угодно поливать дерьмом коммерсантов, торгашей и прочих, но в первую очередь они являются теми винтиками прогресса, которые переносят этот самый прогресс из научных лабораторий в бытовую жизнь

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

Немного тебя расстрою, но тут уже всё украдено до нас и давно всё работает. Это технология JIT-компиляции. Но то, что ты описал (и то, чем является JIT) - это НЕ самомодификация кода, это появление нового кода в процессе работы (без его дальнейшей мутации). Нужно оно в жизни или нет - вопрос сложный и философский. Изначально JAVA появилась как переносимый код для встраиваемых систем. Разработчикам JAVA'ы даже в страшном сне не могло привидеться то, что её будут использовать для написания серверов. Это ещё один уровень абстракции в той системе, о которой я писал выше (процессор + система программирования). Думается, причина популярности в основе так же имела коммерческий характер, а не научный. Как я уже говорил - никто не запрещает создавать код на лету (потому что процессору начхать, в какой момент код родился), просто нужно уметь делать это правильно

Сообщение от JohnyWalker Вообще можно было бы придумать язык, в котором была бы предусмотрена возможность самогенерации кода в процессе выполнения.

Придумай Но при изобретении нового языка нужно понимать, что он должен хоть в чём-то иметь преимущество перед "обычными" языками

Сообщение от JohnyWalker Интересно, а как там в Лиспе и Хаскеле? Может, там тоже есть встроенный компилятор вроде того, о котором я говорил?

Нет, компилятор генерирует обычный код, там нет никакой самомодификации или генерации кода на лету

Добавлено через 17 минут

Сообщение от JohnyWalker Программа в 10 млн. строк кода (а примерно столько имеет, допустим, ядро Линукс), написанная на Си, по своим принципам ничем не отличается от такой же программы середины 1960-ых годов, написанной, допустим, на Фортране или Алголе. Те же if, else, while, do, break, continue, такие же переменные и т. д. Такие же функции и процедуры

А при чём тут Алгол и Фортран? Мы же говорили о программах на ассемблере, которые собственный код модифицируют

Сообщение от JohnyWalker Выкинуть эту функцию — и процессор упростится не более, чем на 1 - 2%. Ровно на столько же он станет дешевле (а то и меньше). И заплатить вместо 400 долларов, допустим, 392, чтобы получить сильно изуродованную архитектуру — а оно мне надо?

Это неправильное предположение, думать, что если транзисторов стало на 1% меньше, то и процессор станет на 1% дешевле. Здесь не учтена стоимость разработки и отладки сложного механизма. В модуле памяти транзисторов на много больше, но память представляет собой регулярно повторяющуюся структуру, а потому её разработка намного дешевле, чем разработка процессора с эквивалентным количеством транзисторов

Сообщение от JohnyWalker Если сохранить возможность самомодификации кода, но не отслеживать её аппаратурой процессора, хакерам, как ты думаешь, это нисколько не усложнит жизнь

Я не говорил "усложнить", я говорил "не облегчать" - это разные вещи (хотя где-то могли и пальцы заплестись от такой длинной писанины). Разработчик процессора не должен включать в аппаратуру то, что нужно только хакерам. Здесь нет цели усложнить хакерам жизнь. Здесь цель - не делать специально чего-то, что облегчило бы им жизнь, не давая при этом никаких других преимуществ

Сообщение от JohnyWalker Да я и с трудом представляю себе ассемблер, в котором сделать, допустим, mov ax, 3 намного сложнее, чем inc ax

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

Сообщение от JohnyWalker и что недостатки процессора можно исправить компилятором, библиотеками, ОС и пр. и пр. — это всё фигня чистой воды

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

Сообщение от JohnyWalker Если команды будут иметь кучу побочных эффектов при исполнении, связанных с другими рядом стоящими командами, исправить это компилятором будет очень сложно, да и неразумно

Опять-таки я интелом не занимаюсь. Но слышал, что есть довольно толстые описания того, какие последовательности команд могут приводить к непредсказуемым результатам. Есть всякие errata'ы. В задачу компилятора входит в том числе и следить за тем, чтобы всё это проблемное хозяйство не появилось в итоговом коде

Сообщение от JohnyWalker Примеры таких побочных эффектов в MIPS и SPARC, не самые страшные, — это слоты задержки ветвления

Если речь идёт о delay-slot, то это не побочное явление, а свойство процессора, которое компилятор успешно учитывает

Сообщение от JohnyWalker Это ты предлагаешь примерно, как построить дом из гнилых досок и брёвен. Доски и брёвна у него рассыпаются в руках, зато гвозди из отличной нержавейки. И пластиковые окна от лучшего производители, даже система кондиционирования самая лучшая в мире стоит. И потому они выправляют все недостатки дома

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

Добавлено через 6 минут

Сообщение от JohnyWalker Паскаль же с ними как-то живёт, там тоже они есть

Там нету возможности взятия адреса на вложенную функцию

Сообщение от JohnyWalker Вопрос в другом, нужно ли было код этого трамплина формировать в стеке. Может быть, его можно было создать в области кода во время компиляции (а не исполнения)

При рекурсивном вызове охватывающей функции такое не проканает

Сообщение от JohnyWalker Может, авторы gcc тут не говнокодеры, а наоборот, молодцы, и выбрали они самое простое и надёжное решение

Они гавнокодеры не потому, что выбрали такое решение, а потому, что ввели в язык вложенные функции. Они среди прочего ввели ещё одну конструкцию, достойную гавнокодеров - VLAIS (VLA in structures), правда официально оно в документации нигде не присутствует, но в ядре линукса было задействовано. clang на эту конструкцию русским языком сообщаем "в clang'е VLAIS никогда не будет поддержано"

Сообщение от JohnyWalker А будет ли оно так? Ещё большой вопрос

Я не знаю. А потому и говорю, что опираться в качестве доказательства на код реализации вложенных функций в gcc нельзя. Ситуация там может отличаться от ситуации N1-N2 этим самым неявным барьером

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

Может и может. Технической невозможности тут нет. Всё упирается в вопрос "а нужно ли это". Если честно, я уже и забыл, с какой целью мы хотели это выяснить. Спор уже превратился в переливание из пустого в порожнее. Времени на него уходит много, а пользы (в том числе и тем, кто вдруг это читает) как-то не видно

0

Сообщение от Evg Ты когда-нибудь читал реальное описание системы команд? Не книжку из разряда "ассемблер за 21 день", а реальное полное описание каждой команды (т.е. полная растактовка по конвейеру). Вот это и есть полноценное описание. А то, что для тебя может стать сюрпризом какое-то для тебя неочевидное свойство - это всего лишь следствие того, что ты на систему команд смотришь так, как тебе больше нравится, а не на то, как реально работает процессор

1. Я читал не книжку "ассемблер за 21 день", а книжки Юрова и Зубкова. Первую более подробно, вторую отрывками. Для средних знаний и представлений о предмете этого достаточно, если не заниматься программированием на ассемблере профессионально. А растактовка по конвейеру нужна инженерам, создающим процессор, или программистам, занимающимся очень глубокой низкоуровневой оптимизацией (типа Агнера Фога). Мне такие глубокие знания действительно не нужны, ибо этим надо заниматься всю жизнь.
2. Но смею тебя уверить, что любой нормальный процессор (а не сферический процессор в вакууме, придуманный тобой для нашего спора) при всех своих сложных механизмах работы (конвейеры, 4 АЛУ и 2 FPU, 3-уровневый кэш, спекулятивное предсказание переходов и мн. др.) стремится у программиста создать иллюзию нормального ПОСЛЕДОВАТЕЛЬНОГО исполнения. Любой разработчик цифровой электроники или человек, близко связанный с этой отраслью, тебе вне всякого сомнения это подтвердит. И только сумасшедший будет утверждать обратное. И этот принцип (иллюзии последовательного выполнения потока команд так, как они записаны в программе) справедлив и для Intel'а, и для SPARC'а, и для Power'а, и для ARM'а, и для любого другого нормального процессора. Бывают небольшие отклонения от него (тот же delay branch slot, он имеет, скорее, исторические причины), но они легко и однозначно учитываются программистом на ассемблере или разработчиком компилятора. Или будешь опять спорить с этим очевидным утверждением?

Добавлено через 1 час 20 минут
Далее...

Сообщение от Evg Опять-таки я интелом не занимаюсь. Но слышал, что есть довольно толстые описания того, какие последовательности команд могут приводить к непредсказуемым результатам. Есть всякие errata'ы. В задачу компилятора входит в том числе и следить за тем, чтобы всё это проблемное хозяйство не появилось в итоговом коде Нет, я этого не предлагаю. Это мир так устроен. Те же самые интеловские процессоры построены на базе микрокодной прошивки. Т.е. внутри процессора есть ещё один маленький процессор, который помимо прочего ещё и занимается программным обходом ошибок основного процессора

Видишь ли, ошибки в процессорах есть, т. к. делают их люди. В том же Интеле несколько раз находили ошибки (мелкие и крупные) в операции вещественного умножения и деления. Ошибок этих в любом процессоре немало, хотя их значительно меньше, чем в софте. И да, производитель процессора, заметив эти ошибки, когда процессор уже поставлен в серию и ничего на схемотехническом уровне уже изменить нельзя (т. к. это займёт много времени) старается выпустить заплатки к нему в виде изменений в микрокоде (который "зашивается" программатором). Но никто этими ошибками не гордится, никто не объявляет их неотъемлемой особенностью процессора, тем свойством, которое должно быть сохранено во всех будущих поколениях процессора. Это дефект, от которого стараются в следующих моделях избавиться и избавиться не заплатками микрокода, а по возможности исправлением ошибок, допущенных в схемотехнике (пусть схемотехнику сейчас пишут на Verilog'е, сути это не меняет).

Так что в идеале процессор по-прежнему остаётся аппаратом, последовательно исполняющим свои команды, без каких-либо побочных эффектов и трудно учитываемых странностей в поведении. Он полностью соответствует своему каноническому описанию, даваемому в массовых учебниках и в ISA Manual (на важно, справочник это по системе команд Intel, Sparc, Power или Arm). Так что всё, что пишут по этому поводу в книжках (учебниках или официальных руководствах), оно совершенно правильно и это не какой-то там выдуманный компьютер. Ошибки же, перечень которых имеется в errata'х, — это дефекты, подлежащие в дальнейшем исправлению подобно тому, как стараются избавиться от всяких глюков в gcc или каком-либо другом компиляторе. Ты же, напротив, специально для нашего спора стараешься придумать какой-то "грязный" процессор и доказать, что это и есть единственно правильный вариант. Поверь мне, это не так, и ты этому не найдёшь никакого подтверждения.

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

Добавлено через 32 минуты

Сообщение от Evg Это неправильное предположение, думать, что если транзисторов стало на 1% меньше, то и процессор станет на 1% дешевле. Здесь не учтена стоимость разработки и отладки сложного механизма. В модуле памяти транзисторов на много больше, но память представляет собой регулярно повторяющуюся структуру, а потому её разработка намного дешевле, чем разработка процессора с эквивалентным количеством транзисторов

А вот тут ты просто искажаешь смысл моих слов и приписываешь мне то, чего я не говорил. Я нигде не утверждал, что сложность и дороговизна процессора измеряется напрямую количеством транзисторов в нём. А говорил я следующее (можешь перечитать тот пост и убедиться). Что в современном процессоре механизмов и узлов, оптимизирующих выполнение команд, позволяющих выполнять различные команды параллельно на нескольких АЛУ и разрешающих всякие противоречивые ситуации, огромное количество. К ним я отнёс и вычисление зависимостей между командами, и спекулятивное исполнение ветвей кода, и возврат к прежнему состоянию, если предсказание оказалось ошибочным, и много всякой всячины. И механизм, детектирующий модификацию одной командой кода другой, лишь ничтожно малая часть всего этого, к тому же далеко не самая сложная. Если этот механизм выкинуть из процессора, сложность разработки его, а как следствие и цена, сократится ничтожно. Выгоды от этого потребитель просто не почувствует. Ты же мне приписал какую-то несусветную глупость, мол, цена процессора напрямую определяется количеством транзисторов в нём, и зачем-то стал её опровергать.

Я не говорил "усложнить", я говорил "не облегчать" - это разные вещи (хотя где-то могли и пальцы заплестись от такой длинной писанины). Разработчик процессора не должен включать в аппаратуру то, что нужно только хакерам. Здесь нет цели усложнить хакерам жизнь. Здесь цель - не делать специально чего-то, что облегчило бы им жизнь, не давая при этом никаких других преимуществ

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

Добавлено через 2 минуты
Далее... Я сам устал от этого спора

Добавлено через 36 минут

Сообщение от Evg Есть ли польза от учёных, которые тратят огромные деньги на телескопы и изучают просторы вселенной? Пока неивестно. Вклад в нашу жизнь людей, которые в своё время изучали электричество (явление, непонятное для непосвящённых), в наши дни вполне ощутим. Если бы компьютер остался дорогой игрушкой для избранных, то вполне могло оказаться так, что основным его пользователем были бы военные. Так что всякие товарищи типа Билла Гейтса внесли немалый вклад в то, какими компьютеры являются сейчас. А так же и в то, что ты можешь себе позволить проводить эксперименты N1-N2 в домашних условиях. Можно сколько угодно поливать дерьмом коммерсантов, торгашей и прочих, но в первую очередь они являются теми винтиками прогресса, которые переносят этот самый прогресс из научных лабораторий в бытовую жизнь

А я всех коммерсантов грязью и не поливаю. Среди коммерческих фирм немало всякого дерьма (вроде M$), но много и очень достойных компаний. Intel, IBM, ARM, я что-то ради имею против? Разорение DEC и Sun Microsystems — большая потеря для мира IT, как мне кажется. Я лишь выступаю против принципа "Прибыль всё, результат работы ничто", ибо он приводит к гниению. Ты же его как бы защищаешь. Кстати, все действительно хорошие компании стараются создать качественный продукт, а не тухлятину. И в Intel, и в ARM, и в той же Oracle даже, работают образованные квалифицированные инженеры. Они используют в своей работе вполне научный подход, академические знания, полученные в университетах на факультетах компьютерных наук. И они стараются (по крайней мере, лучшие из них), чтобы их подходы и решения были красивыми. Я не вижу здесь никакого глубокого противоречия между наукой и бизнесом. Вряд ли среди них найдётся много идиотов, которые будут утверждать, что undefined behaviour, ошибки и побочные эффекты в работе процессора — это норма.

От учёных же пользы ничуть не меньше, без них коммерческие технологии были бы просто невозможны. Как было возможно создать диод или транзистор без знания о pn-переходе и знания основ квантовой механики? А ведь квантовая механика выходит далеко за пределы электроники, пока она всё равно имеет больше теоретическое, чем практическое применение. Как без знаний химии получить сверхчистый кремний? А ведь без этого всего компьютерные технологии невозможны были бы в принципе. Как без очень глубоких знаний органической химии и биологии развивать фармацевтику? Это просто невозможно. Таких примеров масса. Технологии и производство — следствие и применение научных знаний. Есть, разумеется, и обратная связь, она тоже очень важна. Все успешные и богатые страны — это страны с развитой фундаментальной (в т. ч. отвлечённой и оторванной от практики) наукой. У кого науки нет (или они её забросили), те торгуют кофе, какао, нефтью и газом.

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

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

0

Сообщение от JohnyWalker что любой нормальный процессор (а не сферический процессор в вакууме, придуманный тобой для нашего спора) при всех своих сложных механизмах работы (конвейеры, 4 АЛУ и 2 FPU, 3-уровневый кэш, спекулятивное предсказание переходов и мн. др.) стремится у программиста создать иллюзию нормального ПОСЛЕДОВАТЕЛЬНОГО исполнения

Наличие операции iflush на sparc'е, очевидно, говорит об обратном. На sparc'е физически невозможно "правильно" исполнить наш код N1-N2, тупо потому, что там нет никакой возможности обеспечить, требуемое исполнение команд. Потому что в аппаратуре нет никаких средств для автосинхронизации памяти, кэша и конвейера. Только через специальную явно поставленную в код операцию, против которой ты так выступаешь

(Тут я вспомнил, с чего всё началось)

Я не знаю тонкостей работы других процессоров, но очень сомневаюсь в том, что там устроено так же как на интеле (т.е. аппаратура автоматически распознаёт запись в код). Но всё это можно посмотреть в исходниках gcc. У меня под руками оказался gcc-4.8. Арх-зависимые фрагменты находятся в каталоге gcc-4.8.0/gcc/config. Далее в нужном подкаталоге ищешь макрос TARGET_TRAMPOLINE_INIT и растущий от него код. На sparc'е этот код заканчивается вызовом gen_flush, на arm'е вызовом функции __clear_cache, на mips'е - gen_clear_cache. Ради интереса можешь посмотреть на других. Твой изначальный вопрос был о том, можно ли делать самомодификацию кода. Так вот ответ остался прежним - можно, но нужно делать это правильно

1

Сообщение от Evg Они гавнокодеры не потому, что выбрали такое решение, а потому, что ввели в язык вложенные функции. Они среди прочего ввели ещё одну конструкцию, достойную гавнокодеров - VLAIS (VLA in structures), правда официально оно в документации нигде не присутствует, но в ядре линукса было задействовано. clang на эту конструкцию русским языком сообщаем "в clang'е VLAIS никогда не будет поддержано"

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

Вложение функций друг в друга есть в очень многих языках. Есть оно совершенно точно в Паскале. Не уверен точно, но наверняка оно есть и в Аде. Цель этих вложенных процедур и функций очень проста — сделать программы более модульными и структурными, а как следствие, более понятными. Модульность в языке Си (да и в плюсах в общем-то тоже) недоразвита. Поэтому я не понимаю, почему вложенных функций не должно быть в C, раз они есть в Паскале и Аде. Насколько они сочетаются со стилем и эстетикой языка C, вопрос непростой. Но он спорный и очень субъективный.

По поводу массивов переменной длины. Эта возможность появилась ещё в стандарте C99, я это знал. А авторы gcc эту возможность расширили, допустив вкладывать такие массивы в структуры (об этом я узнал сейчас от тебя). Кстати, с чего ты взял, что эта конструкция отсутствует в их документации? Она гуглится на 1, 2, 3. Вот
http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

Массивы переменной длины сами по себе довольно удобны, они нужны особенно тем, кто программирует численные методы. В противном случае остаётся использовать традиционное решение через malloc(). Ну а если разработчики gcc решили расширить область применения этих массивов и позволили их включать в структуры — почему бы и нет? Если это технически реализовать несложно, если это не входит в противоречие с другими конструкциями языка, я не вижу в том ничего плохого.

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

Добавлено через 39 минут

Сообщение от Evg Немного тебя расстрою, но тут уже всё украдено до нас и давно всё работает. Это технология JIT-компиляции. Но то, что ты описал (и то, чем является JIT) - это НЕ самомодификация кода, это появление нового кода в процессе работы (без его дальнейшей мутации). Нужно оно в жизни или нет - вопрос сложный и философский. Изначально JAVA появилась как переносимый код для встраиваемых систем. Разработчикам JAVA'ы даже в страшном сне не могло привидеться то, что её будут использовать для написания серверов. Это ещё один уровень абстракции в той системе, о которой я писал выше (процессор + система программирования). Думается, причина популярности в основе так же имела коммерческий характер, а не научный. Как я уже говорил - никто не запрещает создавать код на лету (потому что процессору начхать, в какой момент код родился), просто нужно уметь делать это правильно

Я тут на новизну и не претендовал Про то что Java использует этот подход, я конечно же знал, как ещё иначе ускорить работу JVM. По поводу того, что это, как ты пишешь, "НЕ самомодификация кода, это появление нового кода в процессе работы (без его дальнейшей мутации)", это правильно. Но по-моему, два подхода достаточно близки, они лежат где-то рядом. Кстати, проблема двух команд N1-N2 может и тут проявиться точно так же. Допустим, один код внутреннего компилятора сгенерировал другой крошечный код в одну, две или три команды (а кто его знает, теоретически такое возможно), после чего передал управление на этот маленький код. Если код оказался считан процессором раньше, чем он был окончательно сгенерирован, то случится то же противоречие, что и в нашем случае N1-N2. Генерация трамплина для того, чтобы передать указатель на вложенную функцию другой внешней функции, тот же самый случай. Там нет настоящей самомодификации кода, но есть тот же риск.

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

0

Сообщение от JohnyWalker По поводу массивов переменной длины. Эта возможность появилась ещё в стандарте C99, я это знал

В Си99 невозможно сделать массив переменной длины полем структуры. В отличие от GNU C. VLA и VLAIS - это разные вещи. По поводу остального спорить не буду, ибо надоело уже

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

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

Добавлено через 55 секунд
Пока ты писал длинный текст, появился пост #47 (мало ли вдруг не заметил) с информацией о том, как получить ответ на изначально интересовавший тебя вопрос

0

Спор-то у нас чисто демагогическое направление принял. Хорошо это или плохо писать самомодифицирующийся код. Даже на самом деле нет. Спор о другом шёл. Должен ли процессор поддерживать эту возможность или нет на уровне своей аппаратуры. Я утверждал, что да, поскольку это фундаментальное свойство вычислительной машины, ты же успорял, что это хлам, мусор, это всё давно предано анафеме и нужно только хакерам для их антиобщественной деятельности И после этого каждый из нас доказывал, что он умнее другого. А в общем-то это вопрос стиля, вкуса и взглядов на вычислительную машину. Пользы от таких споров немного. Лучше обсуждать разные архитектуры, сравнивать их особенности, возможности и заложенные в них ограничения.

Пост твой видел, спасибо. У меня как раз оказался исходник gcc-6.2.0.

Щас смотрю указанный тобой макрос и функции. Лучше расскажи, как ты вычислил, что генератор этого трамплина скрыт в этом файле и под этим макросом. Как ты к этому пришёл?

0

Сообщение от JohnyWalker Лучше расскажи, как ты вычислил, что генератор этого трамплина скрыт в этом файле и под этим макросом. Как ты к этому пришёл?

Лет 15 назад была необходимость ковыряться в этом месте в исходниках gcc

0

Почитал и не пойму, о чем вы спорите ?
Существовал когда-то алгоритм как отличить 80286 от 80386. А по глубине конвейера.
У первого она была 8 байт, у второго 16. Алгоритм состоял в том, чтобы модифицировать
команду впереди текущей и смотреть увидит процессор эту модификацию или нет.
Т.е. в понятиях одного из спорщиков эти процессоры самомодификацию кода не поддерживали.
Ну и кому это мешало ? Если ты модифицируешь код, который не дальше 16-и байт от текущего,
то после модификации сделай
jmp $+2
и конвейер сбросится. Во всяком случае именно у этих процессоров он сбросится.
Т.е. спор ни о чем. Даже когда проблема была, она никому не мешала.

Добавлено через 11 минут
P.S.
Можно даже сказать парадоксальное.
Не поддержка процессором самомодификации кода помогала писать самомодицикацию кода !
Например, некий код хочет положить поверх себя другой код и передать ему управление в некоторую точку. Делаем (на Пнях и далее работать не будет) :
rep movsb
ret
где ret сработает только потому, что она в конвейере, в памяти она уже убита.
Ну и ret неизбежно сбросит конвейер и вуаля.

2

Сообщение от Ethereal Почитал и не пойму, о чем вы спорите ?

Да нет, я просто поинтересовался, поддерживает ли процессор SPARC самомодификацию кода. В ответ на это многоуважаемый Evg заявил, что это какая-то страшная гадость, которая и в страшном сне не приснится и о которой и упоминать-то неприлично. Я с ним не согласился по этому поводу. Да, я согласен, что практической пользы от использования самомодификации кода сейчас немного, но ничего плохого в этой возможности нет. И приятно было бы её сохранить в процессоре. Ну а уж пользоваться этим приёмом или нет, как мне кажется, личное право программиста на ассемблере. На этой почве у нас и завязался длительный спор. Хотя я не ставлю под сомнение квалификацию Evg как программиста, просто я с ним не согласен.

Существовал когда-то алгоритм как отличить 80286 от 80386. А по глубине конвейера. У первого она была 8 байт, у второго 16. Алгоритм состоял в том, чтобы модифицировать команду впереди текущей и смотреть увидит процессор эту модификацию или нет.

Т. е. все ранние процессоры от Intel от 8086 до 80486 включительно самомодификации кода не поддерживали как раз по причине наличия в них конвейера.

Т.е. в понятиях одного из спорщиков эти процессоры самомодификацию кода не поддерживали. Ну и кому это мешало ? Если ты модифицируешь код, который не дальше 16-и байт от текущего, то после модификации сделай jmp $+2 и конвейер сбросится. Во всяком случае именно у этих процессоров он сбросится. Т.е. спор ни о чем. Даже когда проблема была, она никому не мешала. P.S. Можно даже сказать парадоксальное. Не поддержка процессором самомодификации кода помогала писать самомодицикацию кода ! Например, некий код хочет положить поверх себя другой код и передать ему управление в некоторую точку. Делаем (на Пнях и далее работать не будет) : rep movsb ret где ret сработает только потому, что она в конвейере, в памяти она уже убита. Ну и ret неизбежно сбросит конвейер и вуаля.

Но любая команда перехода (безусловный jmp, условный jxxx, вызов call, возврат ret) в любом из этих процессоров обязательно приводила к полному сбросу и очистке конвейера с последующим считыванием и загрузкой команд в конвейер по новой, а значит, позволяла увидеть модификацию кода любой впереди идущей команды даже в пределах глубины конвейера. Правильно понял?

А почему любой переход, даже безусловный, приводил в этих процессорах к сбросу и полной очистке конвейера? Может, это делалось для того, чтобы избежать всяких побочных эффектов и странностей поведения вроде delay branch slot у ранних RISC (эффект, неизбежный у простенького конвейера, если против него не предпринять специальных мер)?

(на Пнях и далее работать не будет)

Т. е. Pentium (начиная с самой первой его модели) и выше уже поддерживает самомодификацию кода? Он её отслеживает и детектирует своей аппаратурой, и, если она случилась, выполняет синхронизацию кэша первого уровня кода с кэшем первого уровня данных, сбрасывает конвейер и начинает работу "с чистого листа"? Интересно, насколько в полном объёме Пентиум и выше поддерживает самомодификацию кода? Возможна ли такая ситуация, что самомодификация окажется настолько хитрой и нетривиальной, что суперскалярник Intel запутается и примет неправильное решение? Допустим, он где-то её не увидит или увидит, но неправильно обработает, нарушит порядок действий, ну или что-то в этом роде?

0

Добавлено через 3 минуты


Добавлено через 13 минут

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

Собственно, пример Ethereal наглядно показывает, что твоя хотелка в реальной жизни не работает. Тот факт, что одна и та же последовательность команд отработает по разному на разных версиях процессора, говорит о том, что нельзя на процессор смотреть как на абстракцию, которая работает согласно книжкам, которые ты читал (этот класс книг я и назвал термином "ассемблер за 21 день"). Т.е. попытка смотреть на абстракцию именно как на абстракцию, и не видеть, где именно она протекает - это и есть основной момент, который отличает профессионального программиста от любителя. А хотелка не работает, потому что есть миллион прочих факторов, в том числе и финансовых, и эти факторы оказываются перевешивающими в вопросе "абстрактный математический процессор vs процессор в суровой реальности". Ну а на процессорах, отличных от интела, реальность оказывается ещё более суровой (по сравнению с придуманным миром, в котором есть идеальный процессор, работа которого полностью соответствует абстракции)

Добавлено через 20 минут

Сообщение от Evg это и есть основной момент, который отличает профессионального программиста от любителя

Наверное слишком категорично выражено. Имелся в виду профессионал в рассматриваемой области программирования (той, к которой относится абстракция)

0

Сообщение от JohnyWalker Но любая команда перехода (безусловный jmp, условный jxxx, вызов call, возврат ret) в любом из этих процессоров обязательно приводила к полному сбросу и очистке конвейера с последующим считыванием и загрузкой команд в конвейер по новой, а значит, позволяла увидеть модификацию кода любой впереди идущей команды даже в пределах глубины конвейера. Правильно понял?

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

Добавлено через 28 минут

Сообщение от JohnyWalker Т. е. Pentium (начиная с самой первой его модели) и выше уже поддерживает самомодификацию кода?

Вот о чем создатели Пней меньше всего думали, так это о поддержке самомодификации кода. Они думали о том, чтобы камень быстрее разогнать и больше ни о чем. Что у них получилось, то получилось.
Появление посредника между памятью и процессором в виде кеша привело к тому, что программно работа конвейера уже не видна. Вроде бы так. Так-что если поддержка самомодификации кода (в том смысле, в какой вкладываешь в это дело ты) и появилась, то только нечаянно, исключительно нечаянно.

Добавлено через 9 минут

Сообщение от JohnyWalker А почему любой переход, даже безусловный, приводил в этих процессорах к сбросу и полной очистке конвейера?

Не понял почему "даже" безусловный. В первую голову безусловный.
Безусловный переход сбрасывал конвейер именно потому, что байты, расположенные за командой безусловного перехода, исполнять не нужно. Они уже выгреблись и тут вдруг оказалось, что исполнять их не нужно. Значит вон их с конвейера. И заполняем конвейер с нуля по адресу перехода.
Предсказание переходов и предвыборка кода по адресу перехода появились только в каком-то из Пней.

Добавлено через 15 минут

Сообщение от Evg нельзя на процессор смотреть как на абстракцию, которая работает согласно книжкам,

Достаточно представлять себе ограничения абстракции. То есть вот абстракция, а вот ее краевые эффекты. Такие как конвейер, команда PUSH SP (которая может класть на стек значение указателя стека до ее исполнения, а может и после, зависит от того кто процессор делал) и ... чего-то пока не вспоминается еще примеров.

Добавлено через 5 минут
Идти на поводу абстракции до конца - это вызовы подпрограмм по наименованию в Algol 60 и трюк Йенсена. Вот уж асбтракция так абстракция. Чистая, абсолютная и черезвычайно сложно реализуемая. Но в конце-концов ведь одумались и отказались от нее.

1

Сообщение от Ethereal Достаточно представлять себе ограничения абстракции. То есть вот абстракция, а вот ее краевые эффекты. Такие как конвейер, команда PUSH SP (которая может класть на стек значение указателя стека до ее исполнения, а может и после, зависит от того кто процессор делал) и ... чего-то пока не вспоминается еще примеров.

Это было сказано в догонку к статье http://russian.joelonsoftware.... tions.html в контексте нашего давешнего срача. JohnyWalker'у очень хотелось смотреть на процессор абстрактно, чтобы он мог модифицировать код (в том числе и тот, который уже попал в конвейер), а все растущие из этого проблемы переложить на инженеров (создателей процессора), а не на программиста. Собственно, срач вокруг этого у нас и начался, просто потом ещё и в ширину пошёл

0

Собственно, пример Ethereal наглядно показывает, что твоя хотелка в реальной жизни не работает. Тот факт, что одна и та же последовательность команд отработает по разному на разных версиях процессора, говорит о том, что нельзя на процессор смотреть как на абстракцию, которая работает согласно книжкам, которые ты читал (этот класс книг я и назвал термином "ассемблер за 21 день"). Т.е. попытка смотреть на абстракцию именно как на абстракцию, и не видеть, где именно она протекает - это и есть основной момент, который отличает профессионального программиста от любителя. А хотелка не работает, потому что есть миллион прочих факторов, в том числе и финансовых, и эти факторы оказываются перевешивающими в вопросе "абстрактный математический процессор vs процессор в суровой реальности". Ну а на процессорах, отличных от интела, реальность оказывается ещё более суровой (по сравнению с придуманным миром, в котором есть идеальный процессор, работа которого полностью соответствует абстракции)

Evg, вот смотри, ты вот сейчас занимаешься самой настоящей демагогией. Ты приводишь кучу всяких чисто демагогических доводов. То у тебя виноваты книжки, которые ты презрительно именуешь "ассемблер за 21 день", то у тебя выступают в качестве аргумента суровые жизненные реалии, отличные от придуманного идеального мира. То сказываются финансы, то злокозненные хакеры, с которыми нужно бороться, у тебя главный аргумент. То ты мне ссылаешься на опубликованные списки ошибок, допущенных при проектировании процессора, которые стараются худо-бедно залатать заплатками в микрокоде. И всё это у тебя свалено в одну кучу. Поверь мне, все твои доводы в данном случае — это сотрясание воздуха, причём бОльшая их часть довольно просто отметается, а остальные настолько малоконкретны, что просто и не знаешь, о чём спорить.

Смотри, ты говоришь, что абстракция не работает. В качестве примера ты как раз приводишь мой случай самомодификации кода в границах "видимости" конвейера. Да, здесь она не работает, поскольку самомодифицирующийся код — это всё-таки очень редкий приём, больше сейчас относящийся к хакерским трюкам (но оттого, что это "хакерский" приём, не следует, что он не имеет права быть). Поэтому производители современных процессоров не стали заботиться о полной поддержке этого приёма, а без специального учёта он входит в противоречие с принципом конвейера.

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

Т. е. попытка смотреть на абстракцию именно как на абстракцию, и не видеть, где именно она протекает - это и есть основной момент, который отличает профессионального программиста от любителя. А хотелка не работает, потому что есть миллион прочих факторов, в том числе и финансовых, и эти факторы оказываются перевешивающими в вопросе "абстрактный математический процессор vs процессор в суровой реальности". Ну а на процессорах, отличных от интела, реальность оказывается ещё более суровой (по сравнению с придуманным миром, в котором есть идеальный процессор, работа которого полностью соответствует абстракции)

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

Я, не являясь конечно же профессионалом по части машинного программирования (я на это и не претендую), пока могу назвать лишь несколько примеров такого специфического поведения:

1. delay branch slot у старых RISC-процессоров. Эта особенность связана с принципом работы простого классического конвейера, это неизбежное следствие принципа конвейеризации. С ней можно было искусственно бороться, заставив конвейер сбрасываться после любой команды перехода, условного и безусловного. Почему-то создатели ранних RISC, такие люди как Хеннесси и Паттерсон, пошли по другому пути, видимо они решили, что delay branch slot — дополнительное средство оптимизации быстродействия, позволяющее поднять производительность на 10 - 15 процентов (вместо того чтобы ждать, пока загрузится команда, на которую должно быть передано управление, и терять впустую 1 такт, способствуя образованию в конвейере пустого места, в этот слот можно воткнуть какую-то другую команду из тех, что должны были выполниться до точки ветвления). В более сложных суперскалярных процессорах, как пишут источники, этот оптимизирующих трюк оказался малоэффективен. Слот задержки ветвления легко учитывается и, насколько мне известно, не приводит НИ К КАКИМ неоднозначностям в поведении процессора, хотя и несколько затрудняет чтение и написание программы на ассемблере. Его также без проблем учитывают все компиляторы.

2. Проблема модификации одной командой кода других близлежащих команд, связанная с тем, что близлежащие команды могли уже быть загружены в конвейер (плюс, на это ещё накладывается возможность внеочередного исполнения). То что мы с тобой обсуждали. Да, эта проблема также следует из конвейерной организации процессора, она в случае простого классического конвейера (каких уже почти и не делают) очень похожа на проблему слотов задержки. Если процессор не поддерживает самомодификацию кода на уровне своей электроники, программист или хакер, написавший такой код, должен как-то позаботиться о сбросе кэша или конвейера. В случае SPARC'а, возможно, достаточно команды iflush, в случае старых Интелов было необходимо искусственно вводить команду безусловного перехода, и с ней всё прекрасно работало. В принципе, самомодифицирующийся код — редко использующаяся возможность, поэтому её развитой поддержки в процессоре, похоже, и нет. Но если знать, как ею пользоваться, наверное, реализовать можно.

3. Третий пример нарушения принципа идеального процессора — то что привёл Ethereal. Это команда PUSH SP. Но тут даже на абстрактном идеализированном уровне есть противоречие. Команда и модифицирует значение регистра, и его же записывает по адресу, хранящемуся в этом регистре. В самой формулировке есть противоречие. Значит, каждый процессор может обработать этот случай по-своему. Один поместит в стек SP до модификации, а другой поместит в стек уже модифицированное значение (уменьшенное на 2, 4 или 8). Это примерно как в C следующий код

Вот что тут будет согласно правилам C и его стандарту? Оно как-то регламентируется или это undefined behaviour?

Но это вообще какой-то достаточно противоречивый случай. Он к случаю последовательного атомарного исполнения процессором команд отношения не имеет, тут совсем другое.

Вот я тебе привёл три случая отклонения от модели идеального процессора (мы их все рассматривали). Все их несложно запомнить и учесть при программировании. Ты говоришь, что в RISC-процессорах таких нарушений гораздо больше. Из твоих слов следует, что их вообще огромное количество, они очень тяжело поддаются учёту и чтобы их все знать и учитывать, надо читать не учебники по ассемблеру вроде этого https://www.ozon.ru/context/detail/id/97652/ или этого https://www.amazon.com/Second-... 0120884216, а сложнейшие мануалы на много тысяч страниц, содержащие чуть ли ни растактовку каждой команды по конвейеру. Иначе серьёзной большой и надёжной программы на ассемблере и не написать, ибо модель процессора как последовательного исполнителя команд не состоятельна, между командами в конвейере возникают сложнейшие корреляции, приводящие к неожиданным и непредсказуемым результатам в их поведении и пр. и пр. Я иначе твои слова охарактеризовать, чем бред, не могу. Если это не так, приводи конкретные примеры. Их у тебя должно быть ОЧЕНЬ много. А так, у тебя и учебники по asm'у несостоятельны, и мануалы с растактовкой просто необходимы, без них будут ошибки. В общем, всё как в сумасшедшем доме.

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

Добавлено через 2 минуты
P.S.
Я вопрос задавал ради того чтобы узнать что-то новое, обогатиться какими-то знаниями, а того, что оно выльется в такую фигню, я даже не предполагал.

Добавлено через 8 минут
И извини, если был резок в каких-то своих словах. Цели оскорбить у меня не было никакой. Просто это очень тяжело участвовать в таких спорах.

0

Команда CPUID появилась только на 80486. Но Дос-оские утилитки типа CheckIt определяли тип процессора и тогда, когда никакой CPUID еще не было. И все эти определения строились исключительно на отличиях реальных процессоров от абстрактных. Соответствуй реальные процессоры абстрактным моделям такое определение было бы совершенно невозможно.
В конце концов алгоритм определения модели процессора из семейства 80x86 устаканился, когда был найден его кратчайший вариант. Надо бы его найти, наверняка в Интернете он где-нибудь есть. Но ранние варианты такого алгоритма были другими и они просто кладезь знаний по ограничениям абстракций, двусмысленностям дефиниций, и остроумия.
На память помню что использовались
- различия в глубине конвейера и влияние этой глубины на самомодификацию кода
- различия в исполнении push SP
- многократный сдвиг словного регистра на 16 бит - слово занулится или ни одного сдвига вовсе не произойдет ? То есть число сдвигов берется как оно есть или все же по модулю 16 ?
Еще что-то ... вот забыл.

Добавлено через 30 минут

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

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

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

Очень напоминает шарахания к крайностям времен Перестройки - поскольку имеют место некоторые отклонения от идеала равенства (привелегии партноменклатуры, ага), давайте похерим идеал полностью, как несостоятельный, и другого пути нетЪ. Или таки Нина Андреева, ибо ТРУ ? Одно из двух и иного не дано.

0