Эх,
когда то юзал этот дебагер.
Не скажу зачем
Потом дорога пошла в другом направлении и забыл.
Но было весело.
Разработана для управления процессами на низком уровне Windows, причём таким образом, чтобы операционная система не распознавала работу отладчика. В отличие от прикладного отладчика, SoftICE способен приостановить все операции в Windows, что очень важно для отладки драйверов.
Сейчас с учетом объёма кода и кучи интерпретируемого кода,
уже сомнительна его полезность.
Но просто для само развития:
Есть современные аналоги?
И да, в мире linux есть современные аналоги?
Здравствуйте, opfor, Вы писали:
O>Здравствуйте, wl., Вы писали:
wl.>>Ghidra. от NSA wl.>>https://hexrays.su/ida92/ida92.torrent — вот там можно скачать
O>вы бы погуглили отличие дизассемблера от дебаггера...
opfor, ну куда ты лезешь со своими никчемными советами и Гидра,и IDA идут в комплекте со своими отладчиками. Ну изучи матчасть
Здравствуйте, yoyozhik, Вы писали:
Y>Есть современные аналоги?
Нет, и не планируется. SoftICE был придуман "от бедности", когда дополнительный компьютер считался роскошью, а с ограниченными возможностями отладки соглашались мириться. Уже в начале 2000-х нормой стала удаленная отладка — сперва по UART, потом по FireWire/Ethernet, потом еще и по USB. Виртуальные машины так и вовсе удобно отлаживать — хоть с хоста, хоть из другой VM.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нет, и не планируется. SoftICE был придуман "от бедности", когда дополнительный компьютер считался роскошью, а с ограниченными возможностями отладки соглашались мириться. Уже в начале 2000-х нормой стала удаленная отладка — сперва по UART, потом по FireWire/Ethernet, потом еще и по USB. Виртуальные машины так и вовсе удобно отлаживать — хоть с хоста, хоть из другой VM.
Здравствуйте, yoyozhik, Вы писали:
Y>Есть современные аналоги?
Да, есть. Сыроватые, правда. Например, HyperDbg.
Как уже отметил Евгений, то можно отлаживать и через VM + WinDbg. В IDA были заявления по поводу поддержки ядреной отладки, но в рабочем виде я никогда таковой не видел.
Y>И да, в мире linux есть современные аналоги?
Для юзермода я использовал IDA+Remote. Вполне себе работало. А вот для ядра я аналогов не знаю.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, пассажир, Вы писали:
П>>прям в режиме ядра?
ЕМ>Что именно "прям"?
это значит что отладчик работает на голом железе до загрузки ОС и может отлаживать ОС в режиме ядра
обычным отладчиком вглубину можно отлаживать только до системного вызова ОС
Здравствуйте, pva, Вы писали:
pva>Сыроватые, правда.
У них нет шансов выйти из разряда сыроватых, ибо это все чисто любительские поделки.
pva>можно отлаживать и через VM + WinDbg.
Это единственно правильный технически способ отладки ядерного кода. Все остальное — костыли и полумеры, в том числе SoftICE.
pva>В IDA были заявления по поводу поддержки ядреной отладки, но в рабочем виде я никогда таковой не видел.
И не надо, ибо незачем и неудобно, а старый/подержанный компьютер/ноутбук стоит копейки.
Здравствуйте, пассажир, Вы писали:
П>отладчик работает на голом железе до загрузки ОС и может отлаживать ОС в режиме ядра
Второе верно, первое — нет. Отладочный модуль ядра в винде (kdXXX.dll) загружается на раннем этапе загрузки системы, так что самые первые этапы загрузки он отлаживать не может, для этого применяются специальные аппаратные модули, подключаемые к системной плате. SoftICE вроде бы умел отлаживать загрузку Win9x, поскольку она грузилась из-под DOS, а вот загрузку NT, насколько я знаю, он отлаживать не умел (да и не надо это никому, кроме разработчиков NT и малвари под нее).
Здравствуйте, Евгений Музыченко, Вы писали:
pva>>Сыроватые, правда. ЕМ>У них нет шансов выйти из разряда сыроватых, ибо это все чисто любительские поделки.
Оно работает и поддается кастомизации. Этого достаточно.
pva>>можно отлаживать и через VM + WinDbg. ЕМ>Это единственно правильный технически способ отладки ядерного кода. Все остальное — костыли и полумеры, в том числе SoftICE.
Евгений, оставь свой снобизм. Можно, конечно, везде использовать молоток, но зачем? Некоторая малварь использует специальную антиотладку, которая блокирует возможность предлагаемого тобой "единственно правильного".
pva>>В IDA были заявления по поводу поддержки ядреной отладки, но в рабочем виде я никогда таковой не видел. ЕМ>И не надо, ибо незачем и неудобно, а старый/подержанный компьютер/ноутбук стоит копейки.
Тебе неудобно. IDA по юзабилити один из лучших инструментов как для статического анализа, так и для отладки (если нет доступа к исходникам). В том числе мультиплатформенной.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Второе верно, первое — нет. Отладочный модуль ядра в винде (kdXXX.dll) загружается на раннем этапе загрузки системы, так что самые первые этапы загрузки он отлаживать не может,
Здравствуйте, pva, Вы писали:
pva>Некоторая малварь использует специальную антиотладку, которая блокирует возможность предлагаемого тобой "единственно правильного".
Такая малварь без труда заблокирует и любой отладчик-надстройку (и SoftICE не был исключением). Если не блокирует — это всего лишь везение. Для таких случаев единственно правильный вариант — аппаратный отладчик. Все остальное — баловство и лотерея по определению.
pva>IDA по юзабилити один из лучших инструментов как для статического анализа, так и для отладки
Именно поэтому IDA, по понятным причинам, никогда не будет работать так же, как SoftICE, а исключительно через модуль удаленной отладки, и один из возможных интерфейсов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нет, и не планируется. SoftICE был придуман "от бедности", когда дополнительный компьютер считался роскошью, а с ограниченными возможностями отладки соглашались мириться. Уже в начале 2000-х нормой стала удаленная отладка — сперва по UART, потом по FireWire/Ethernet, потом еще и по USB. Виртуальные машины так и вовсе удобно отлаживать — хоть с хоста, хоть из другой VM.
кстати, а насколько в таком режиме удобно (и вообще возможно?) отлаживать юзермодные процессы? Там можно шагать по запущенному юзермодному потоку так, чтоб те не догадались об отладке?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, wl., Вы писали:
wl.>>куда ты лезешь со своими никчемными советами
ЕМ>К сожалению, как раз Ваши советы в данной теме совершенно никчемны, ибо Вы абсолютно не понимаете, в чем состоит уникальность SoftICE.
не понял, отлаживать виртуальную машину с виндой можно уже давно, и инструменты те же самые
Здравствуйте, opfor, Вы писали:
O>насколько в таком режиме удобно (и вообще возможно?) отлаживать юзермодные процессы?
Возможно (такому отладчику без разницы, какой код отлаживать), но чертовски неудобно. В режиме прерывания он не сможет загрузить символьную информацию (нужно озаботиться этим заранее), не даст открыть страницу в интернете или локальный файл (например, с документацией), запустить параллельный процесс и т.п.
Поэтому такие отладчики востребованы исключительно на безрыбье.
Здравствуйте, wl., Вы писали:
wl.>отлаживать виртуальную машину с виндой можно уже давно
Что значит "давно"? Ее всегда можно было отлаживать, с момента появления первого полноценного виртуализатора (вроде как VirtualPC).
wl.>инструменты те же самые
Чем, по-Вашему, "те же самые инструменты" отличаются от SoftICE?
Здравствуйте, pva, Вы писали:
pva>В IDA были заявления по поводу поддержки ядреной отладки, но в рабочем виде я никогда таковой не видел.
в IDA отладчик работает по GDB протоколу. Поэтому любой GDB stub — и можно отлаживаться.
(При желании можно свой стаб для винды написать, знаю когда такой делали чтобы ранние этапы бута винды отлаживать.)
Я из IDA отлаживал Cortex-M, через OpenOCD. Прямо по голому железу.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Для таких случаев единственно правильный вариант — аппаратный отладчик. Все остальное — баловство и лотерея по определению.
Аппаратный, сам-по-себе, тоже не панацея. Вспомни, как детектили BluePill.
Кстати, аппаратная виртуализация и есть аппаратный отладчик.
Здравствуйте, IID, Вы писали:
IID>в IDA отладчик работает по GDB протоколу. Поэтому любой GDB stub — и можно отлаживаться. IID>(При желании можно свой стаб для винды написать, знаю когда такой делали чтобы ранние этапы бута винды отлаживать.)
Я про
и вероятность того что оно умеет вместо kddbg аттачится. Хотя, выше уже указали на отличное комбо с qemu. Про него я совсем забыл.
Здравствуйте, IID, Вы писали:
IID>Аппаратный, сам-по-себе, тоже не панацея.
Сам по себе он только дает интерфейс для отладки, как и виндовые ядерные отладочные модули. А там уже все определяется софтом, который им управляет.
IID>Вспомни, как детектили BluePill.
Я не вдавался, в чем там были сложности?
IID>аппаратная виртуализация и есть аппаратный отладчик.
Ее, во-первых, нужно как-то настроить (например, запустить отдельный загрузчик), а как в таком случае отлаживать штатную работу того же BIOS? Во-вторых, ее реализация должна позволять полностью воспроизвести исходную конфигурацию (то есть — возможность неограниченной вложенности), а такого, насколько я знаю, ни один процессор не поддерживает.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, undo75, Вы писали:
U>>на больших эвм с перволентой и перфокартами как бы вы отлаживались? ЕМ>Возможно, Вы удивитесь, но средства отладки (как аппаратные, так и программные) были и там.
Как я видел на фоточках тех больших машин, там можно было буквально с большого пульта-консоли сделать дохрена низкоуровневых операций.
В т.ч. считать/записать байты в память. Посмотреть содержимое регистров. Остановить и выполнять программу по шагам.
Вот это — подлинный аппаратный отладчик.
А ещё раньше, в самых первых ЭВМ, даже ассемблера никакого не было. Программы нужно было составлять прямо в машинных кодах с помощью ручки и бумажки. Потом как-то загонять её в ЭВМ, и только затем запускать.
Но программы тех лет были куда как проще нынешних.
Здравствуйте, jamesq, Вы писали:
J>можно было буквально с большого пульта-консоли сделать дохрена низкоуровневых операций.
Да, именно так и работали в однозадачном режиме. Там, где поддерживалась многозадачность, были и средства программной отладки, в том числе символьной.
J>в самых первых ЭВМ, даже ассемблера никакого не было. Программы нужно было составлять прямо в машинных кодах с помощью ручки и бумажки.
Самое смешное, что так нередко делалось на PDP-11 (СМ-4, Электроника-100, Электроника-60 и т.п.). Там была принята восьмеричная система счисления для отображения кодов и команд, а система команд была "ортогональной", где в качестве источника и приемника данных фигурировали пары из метода адресации (три бита) и используемого регистра (еще три бита) — по две восьмеричные цифры. Остальные разряды отводились под код операции, так что и читать, и составлять такие команды было очень легко.
Эта система команд была чертовски компактной и одновременно мощной и удобной, до сих пор по ней ностальгия. Когда нужно было набросать программку из пары десятков команд, и было лень возиться с ассемблером, мы так и забивали машинные коды по абсолютным адресам. Все описание базовой архитектуры и системы команд помещалось на складную картонную карту формата A5, у меня где-то валяется такая.
Еще были забавные компьютеры-калькуляторы Электроника Д3-28, содранные с какого-то Wang'а и творчески доработанные в СССР. Там система счисления уже использовалась псевдо-шестнадцатеричная (пары вида 1215 вместо CF), а система команд организована так, что кнопки ввода цифр и математических операций генерировали соответствующие машинные команды. Их мы тоже программировали прямо в кодах.
J>Но программы тех лет были куда как проще нынешних.
И тогда были очень сложные программы. Порой даже сложнее многих нынешних, поскольку памяти было мало, скорости были низкими, толковых оптимизаторов не было, приходилось оптимизировать вручную и проявлять чудеса изобретательности.
Но даже без извращений можно было сделать довольно много. Я, например, на той же Д3-28 за пару месяцев наколотил в машинных кодах визуальный текстовый редактор с форматированием, печатью, сохранением на ленту и чтением с нее. Когда под рукой нет ничего, кроме голой железки с кнопками, такое не кажется чрезмерно сложным.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И тогда были очень сложные программы. Порой даже сложнее многих нынешних, поскольку памяти было мало, скорости были низкими, толковых оптимизаторов не было, приходилось оптимизировать вручную и проявлять чудеса изобретательности.
Да уж. Сейчас в порядке развлечения ковыряюсь во всяких древностях. Пытаюсь что-нибудь попрограммировать.
Что у процессора только один регистр аккумулятора для вычислительных операций — к этому я уже привык. Что оперативки только 2 килобайта — это тоже бывает. Что нету операций умножения и деления — так даже интереснее.
Но вот что операция побитового сдвига выполняется только на 1 разряд — это уж слишком.
Здравствуйте, jamesq, Вы писали:
J>операция побитового сдвига выполняется только на 1 разряд — это уж слишком.
"Это вы слишком много кушать". Чтобы команда могла двигать на произвольное количество разрядов, нужно либо микрокод крутить в цикле (и тогда это ничем не лучше обычного цикла), либо иметь в АЛУ до хренища аппаратных мультиплексоров, с помощью которых можно отобразить любую часть слова на любую другую, а это дорого.
J>Я хочу на таком железе sha256 посчитать
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, jamesq, Вы писали:
J>>операция побитового сдвига выполняется только на 1 разряд — это уж слишком.
ЕМ>"Это вы слишком много кушать".
... либо иметь в АЛУ до хренища аппаратных мультиплексоров, с помощью которых можно отобразить любую часть слова на любую другую, а это дорого.
Нынешние владельцы EPYC Genoa с 64 ядрами и терабайтом ОЗУ откровенно зажратые типы по сравнению с подобным. У которых одних транзисторов на чипе в 15 миллионов раз больше.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но даже без извращений можно было сделать довольно много. Я, например, на той же Д3-28 за пару месяцев наколотил в машинных кодах визуальный текстовый редактор с форматированием, печатью, сохранением на ленту и чтением с нее. Когда под рукой нет ничего, кроме голой железки с кнопками, такое не кажется чрезмерно сложным.
Вот видишь, какой ты способный. Мог бы наколотить и плюсовый компилятор со своими макросами где-нибудь за полгода
Здравствуйте, Евгений Музыченко, Вы писали:
IID>>Вспомни, как детектили BluePill.
ЕМ>Я не вдавался, в чем там были сложности?
Вложенная виртуализация. До Bluepill наивно считалось, что если ты не смог перейти в режим гипервизора — значит он уже запущен. И детект тривиальный.
Bluepill был софтовой реализацией вложенной виртуализации.
И когда у тебя, потенциально, завиртуализировано ВСЁ. Как НАДЕЖНО и в общем случае понять, на реальном железе ты исполняешься, или под виртуалкой.
Напомню, это было время, когда только-только вышли первые платы с AMD виртуализацией, а Intel ещё только обещал выпустить свою.
IID>>аппаратная виртуализация и есть аппаратный отладчик.
ЕМ>ее реализация должна позволять полностью воспроизвести исходную конфигурацию (то есть — возможность неограниченной вложенности), а такого, насколько я знаю, ни один процессор не поддерживает.
И опять напомню про BluePill — там сделали вложенную виртуализацию "руками". Задолго, до появления железной поддержки вложенности.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Самое смешное, что так нередко делалось на PDP-11 (СМ-4, Электроника-100, Электроника-60 и т.п.). Там была принята восьмеричная система счисления для отображения кодов и команд, а система команд была "ортогональной", где в качестве источника и приемника данных фигурировали пары из метода адресации (три бита) и используемого регистра (еще три бита) — по две восьмеричные цифры. Остальные разряды отводились под код операции, так что и читать, и составлять такие команды было очень легко. Эта система команд была чертовски компактной и одновременно мощной и удобной, до сих пор по ней ностальгия.
У S/360 тоже предельно простая как для человека система команд, легко читается и пишется и в дампе, и на пульте. И потомок в виде SystemZ сохранил большую часть этих свойств (хоть ему и не нужно).
ЕМ>Но даже без извращений можно было сделать довольно много. Я, например, на той же Д3-28 за пару месяцев наколотил в машинных кодах визуальный текстовый редактор с форматированием, печатью, сохранением на ленту и чтением с нее. Когда под рукой нет ничего, кроме голой железки с кнопками, такое не кажется чрезмерно сложным.
Хотелось бы услышать подробности о структурах данных и трюках
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>"Это вы слишком много кушать". Чтобы команда могла двигать на произвольное количество разрядов, нужно либо микрокод крутить в цикле (и тогда это ничем не лучше обычного цикла),
Лучше — тем, что на уровне микрокода можно выбрать, как именно удобнее исполнять операцию.
Грубо говоря, в модели 1000 только сдвиг по биту в цикле, в 2000 и 3000 добавлен уровень мультиплексирования, который двигает по 4 бита за такт, а в 5000 и далее — полная бочка.
EM> либо иметь в АЛУ до хренища аппаратных мультиплексоров, с помощью которых можно отобразить любую часть слова на любую другую, а это дорого.
Сейчас уже копейки. Прикольно наблюдать, конечно, мучения народа на 8051, но уже нефункционально.
Здравствуйте, IID, Вы писали:
IID>И когда у тебя, потенциально, завиртуализировано ВСЁ. Как НАДЕЖНО и в общем случае понять, на реальном железе ты исполняешься, или под виртуалкой.
Это больше теория, чем практика. Чтоб виртуализовать "ВСЁ", в составе этого "всего" должны быть все без исключения аппаратные средства, встречающиеся в типовой системе, а их уже в конце 90-х было немало, со всеми их особенностями и неявными багами. Если тщательно сэмулировать систему определенной конфигурации, то "неузнаваемой" она пробудет недолго, а потом ее начнут детектить тупо по аппаратной сигнатуре. Эмулировать же достаточное количество различных конфигураций — адская работа, за которую взялись бы только с целью какой-нибудь грандиозной масштабной аферы. Ну, или какие-нибудь безумцы, одержимые сверхцелью.
Здравствуйте, IID, Вы писали:
IID>>>Вспомни, как детектили BluePill.
ЕМ>>Я не вдавался, в чем там были сложности?
IID>Вложенная виртуализация. До Bluepill наивно считалось, что если ты не смог перейти в режим гипервизора — значит он уже запущен. И детект тривиальный.
В стиле Википедии тут после "наивно считалось" должна стоять верхняя плашка "[кем?]" Отдельными представителями мира x86? В VM/370 такая вложенная виртуализация поддерживалась ещё в конце 1970-х. К тому же уровень вложенности в VM/370 был уже неограниченным (реально, начиная с 3-го, по доступным мне отзывам, начинались заметные тормоза, с 4-го уже они не давали нормально работать). Это при том, что в SystemZ до сих пор нет nested paging! (или я не так читаю?)
Рутковская, безусловно, гений, но для осознания принципиальной возможности было достаточно знаний за пределами мирка PC/Wintel. Подробнейшая документация к VM/370 была тогда точно доступна. Код — возможно, я не знаю, когда его открыли, но уже по документации можно было понять не только, что это возможно, но и методы.
Аппаратная вложенность в современном x86 в виде VMCS/VMCB shadowing и аналог в AArch64 дают только два уровня, дальше тоже надо софтово.
Это не к основной теме, просто некоторые детали в вашем комментарии таки хотелось уточнить.
ЕМ>>ее реализация должна позволять полностью воспроизвести исходную конфигурацию (то есть — возможность неограниченной вложенности), а такого, насколько я знаю, ни один процессор не поддерживает.
IID>И опять напомню про BluePill — там сделали вложенную виртуализацию "руками". Задолго, до появления железной поддержки вложенности.
Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа. В задачах Евгения (звуковые драйвера) это может быть критично.
Здравствуйте, netch80, Вы писали:
N>Уложить в мелкие ресурсы крупную задачу это наверняка много хитростей
Ну, мы с коллегами никогда не доходили до того, чтоб заниматься самомодификацией, передачей управления "внутрь" команд и подобными трюками, которые вынуждены использовать авторы конкурсных программ с жестким ограничением на ресурсы. Как-то всегда хватало традиционного. Не хватает адресного пространства — используются переключаемые страницы/банки (если они есть на платформе), не хватает оперативной памяти — перекрытия/оверлеи, не хватает скорости вычислений — приближения, предвычисления, табличные функции и подобное.
Поскольку "узкие" по ресурсам задачи тогда решались преимущественно на ассемблерах, всегда было достаточно четкое представление о реально потребных для конкретной задачи объемах ресурсов. Современные представления об этих объемах, как правило, завышены на несколько порядков. Многое из того, что типичный современный программист едва сумеет втиснуть в возможности среднего железа выпуска 2008-2012, тогдашний программист реализовал бы на каком-нибудь 486, а то и 386, разве что не так красиво и развесисто. Исключая, понятное дело, объективно тяжелые вычисления, и столь же объективно тяжелые данные (например, видеопотоки), вытекающие непосредственно из задачи, а не из наиболее типовых и удобных методов ее решения.
Здравствуйте, netch80, Вы писали:
N>Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа.
Можно накосячить и куда проще. Я до сих пор не перехожу с VMware Workstation 12, поскольку в старших версиях поломали виртуализацию асинхронного обмена с дисковыми устройствами. Наверное, разработчики уже тогда накупили себе SSD и решили, что асинхронный обмен себя изжил, пора переходить к синхронному, дабы выиграть сотни микросекунд любой ценой. В итоге, даже если и хост, и VM работают только с SSD, синхронная операция чтения/записи все равно блокирует VM на те самые сотни микросекунд, и лаги обработки прерываний/DPC и прочих асинхронных событий становятся несуразно большими. Звуковые потоки с небольшими буферами это ломает в первую очередь, но эти ребята проверяли, скорее всего, на вычислениях и видео, а там оно совершенно незаметно.
Пытался по этому поводу бодаться с VMware — они сперва стали жевать сопли, а потом написали, что единственный Support Case, входивший в мою подписку, они исчерпали, и предложили купить новый. Я их послал и забил, благо версия 12 до сих пор вполне годится для отладки.
Здравствуйте, jamesq, Вы писали:
J>Нынешние владельцы EPYC Genoa с 64 ядрами и терабайтом ОЗУ откровенно зажратые типы по сравнению с подобным. У которых одних транзисторов на чипе в 15 миллионов раз больше.
Эх, помню времена, когда наличие barrel shifter было конкурентным преимуществом и оговаривалось отдельно Часто он появлялся из-за надобности плавучки, но не обязательно.
Здравствуйте, andyp, Вы писали:
A>Эх, помню времена, когда наличие barrel shifter было конкурентным преимуществом и оговаривалось отдельно Часто он появлялся из-за надобности плавучки, но не обязательно.
Те времена я не застал вообще. Про barrel shifter узнал только сейчас от тебя.
Я только сейчас, в 2025 в подробностях выясняю, насколько ограничены были процессоры 70-х и 80-х. Ну может кое-что знал про 8086. Само собой, уже четверть века знаю про 16-битный реальный режим, но не суть.
Хочу сказать, что сверху всех ограниченных возможностей 8-битных процессоров идёт то, что:
1. Они работали на частоте в единицы мегагерц
2. А впридачу, команды не выполнялись за один такт. Дай бог за 4 — самые быстрые. А то и по 10-20 тактов.
В общем, все эти процессоры откровенно убоги.
Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком.
То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit.
Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Здравствуйте, jamesq, Вы писали:
J>Я только сейчас, в 2025 в подробностях выясняю, насколько ограничены были процессоры 70-х и 80-х. Ну может кое-что знал про 8086. Само собой, уже четверть века знаю про 16-битный реальный режим, но не суть. J>Хочу сказать, что сверху всех ограниченных возможностей 8-битных процессоров идёт то, что: J>1. Они работали на частоте в единицы мегагерц J>2. А впридачу, команды не выполнялись за один такт. Дай бог за 4 — самые быстрые. А то и по 10-20 тактов.
Я всё-таки попридерусь к деталям, они существенны для понимания:
1. В самом современном процессоре команды не выполняются за один такт! Вместо этого выполняется, например, 30 команд за 10 тактов, если оптимально налажен код на это. Или 10 команд за 40 тактов, если в коде сплошные кросс-зависимости и нет заранее подкачанных данных. Но одна команда выполняется всё равно за несколько тактов. Минимум — два, среднее — от 5 до 10. Потому что собственно длина такта обычно рассчитывается так, чтобы соответствовать где-то двум операциям сложения значения длиной в слово. (Схемотехники скажут, что это слишком грубая оценка, но для старта сойдёт.)
А вот out-of-order — то, что позволяет достичь суммарной скорости повыше за счёт параллельной обработки. Но и ресурсов на это надо дохрена. Считаем, от миллионов вентилей.
(Бывают замедленные контроллеры, в которых даже деление выполняется за 1 такт. Но это намеренное дизайнерское решение.)
2. Почему в 8080 обычный NOP тратил 4 такта — не знаю, но в 6502 он тратил 2 такта. Фактически у него скорость была одинакова (2 мкс в обоих, за счёт того, что первые 8080 шли под 2MHz, 6502 — под 1MHz). Если бы 8080 был сделан чуть умнее, вероятно, и он бы быстрее работал. Но он был чуть раньше.
Всё равно расчёт шёл на финальную скорость выполнения программы, а она постепенно повышалась и процессоры одного ценового класса были примерно одинаковы в этом.
(Цена — отдельный вопрос. Когда 6800 и 8080 продавались за 175$, 6502 пошёл за 25$... и это была чудовищная подстава. Неудивительно, что на его создателей взъелись.)
J>В общем, все эти процессоры откровенно убоги. J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit.
Ну а если ты в современном x86 выполнишь задачу отрицания (negating) 256-битного числа, тебе придётся прогонять его порциями по 64 бита через регистры, "инвертируя разряды и добавляя carry bit". И о чём это говорит, кроме того, какой тебе доступен размер операций и какой нужен? А зачем на таком процессоре тебе отрицание 32-битного числа? Это там нетипичная операция.
Я тебе больше скажу — даже 8-битное отрицание таким образом на Z80 выполнялось в два приёма, потому что его АЛУ было 4-битным. То есть реально на нём это было 8 шагов.
А какая-нибудь S/360 Model 30, за десять лет до того, тоже выполняла операции побайтно, потому что у неё 8-битный АЛУ, но команда была одна, потому что все эти детали были спрятаны в микрокоде (говоря современным термином). А Model 50 имела 32-битный АЛУ, но и стоила она от полутора миллионов тогдашних долларов.
J>Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Выполняется дольше, если ты про 8080. 4 такта это NOP. "ADC M" — 7 тактов. "INX H" — 5 тактов. "XRI" — 7 тактов. Тайминги открыты, подсчитай сам.
Да. Закон Мура и аналогичные про удвоение ресурсов, скорости и пр. за полтора-два года — придумали не зря. С, условно, 1971 (год Intel 4004) до 2005 (когда рост тактовой точно остановился и начали думать и об оптимизации внутренней логики) это рост от 2↑17 = 131072 до 2↑25.5 = 47млн только формально по Муру. Реальные цифры где-то посредине. Но и сейчас есть что выжимать из технологии.
Здравствуйте, jamesq, Вы писали:
J>В общем, все эти процессоры откровенно убоги.
Если учесть, что проектировались они практически вручную и сравнивать с тем, что было до них — это просто чудо. HDL появились в середине 80х. А так — нарисуй схемку, разведи, размести, создай масочки, напыли, вытрави... Ошибся — выкинь и начни сначала. Ну и если сравнить с тем, что было, а не с тем, что стало через 30 лет, они открывали охренительные новые горизонты во многих вещах.
J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт, здесь мне пришлось прогонять всё это число побайтово через аккумулятор, инвертируя разряды и добавляя carry bit. J>Вся история заняла аж 16 инструкций, и выполняется наверное 64 такта. И это на 2 МГц процессоре, ага.
Ну да. Простейшие вещи стоили много труда, а неправильно организованные вычисления приводили к невозможности вычислить то что надо. Поэтому код и наработки были настолько ценны. Сейчас — это мусор.
Здравствуйте, jamesq, Вы писали:
J>команды не выполнялись за один такт.
Выполнялись даже во многих машинах 60-70-х. Но это касалось, понятное дело, именно выполнения самой операции, после загрузки всех операндов в регистры, и до записи результатов в память (если было запрошено).
А известная БЭСМ-6 вообще не имела команды сдвига. Вместо этого у нее были две команды — "битовая разборка" и "битовая сборка". Первая раскидывала идущие подряд разряды сумматора по позициям, указанным единичными разрядами операнда, а вторая, наоборот, собирала с этих позиций в "плотную" группу. Всё это, как и большинство команд, выполнялось за один такт, а машина была транзисторная. У нее было всего 38 команд, включая несколько служебных (недоступных прикладному программисту), но писать под нее на ассемблере было весьма удобно.
J>В общем, все эти процессоры откровенно убоги.
Понятное дело — это ж были, по большому счету, обрубки нормальных "больших" процессоров, изначально предназначенные сугубо для частных, ограниченных задач. БОльшая часть усовершенствований в сфере микропроцессоров — это отнюдь не новшества, а воспроизведение уже существовавших когда-то решений, как в исходном виде, так и с изменениями под новые обстоятельства.
J>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт
В нормальных процессорах это делалось за один такт еще в 50-х.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А известная БЭСМ-6 вообще не имела команды сдвига. Вместо этого у нее были две команды — "битовая разборка" и "битовая сборка". Первая раскидывала идущие подряд разряды сумматора по позициям, указанным единичными разрядами операнда, а вторая, наоборот, собирала с этих позиций в "плотную" группу. Всё это, как и большинство команд, выполнялось за один такт, а машина была транзисторная.
Вот тут очень интересно — точно за один такт? Потому что сборка и разборка (то, что в x86 сейчас называется pext и pdep соответственно) это крайне сложные в реализации, если без цикла, команды, для них специально для скорости работы придумывали специальные сети вентилей, которые окупаются, IMHO, ну как минимум от технологии 1990-го, не раньше.
Если есть источник на это утверждение, прошу его указать.
Кстати, тут приводится некоторая shift immediate, которая однозначно сдвиг. Так что утверждение про "вообще не имела" как-то сомнительно.
EM> У нее было всего 38 команд, включая несколько служебных (недоступных прикладному программисту), но писать под нее на ассемблере было весьма удобно.
Я почитал описание... как-то совершенно неровно в размерах, за этим надо постоянно следить. В код эмулятора не лез.
J>>Я вчера писал процедурку взятия противоположного от 32-х битного числа со знаком. J>>То, что в нормальном процессоре уже в 1990-х делалось одной инструкцией, выполняющейся за 1 такт
ЕМ>В нормальных процессорах это делалось за один такт еще в 50-х.
Ну если "нормальный" это ценой от миллиона тогдашних $, то согласен
Здравствуйте, netch80, Вы писали:
N>Рутковская, безусловно, гений
Она (а может быть и он) больше гений пиара. А ещё ппц высоченная(-ный).
Реальную работу, кстати, сделал Александр Терешкин (ник 90210). но его постепенно подчистили из истории, заменив поляком.
IID>>И опять напомню про BluePill — там сделали вложенную виртуализацию "руками". Задолго, до появления железной поддержки вложенности.
N>Всё равно есть проблема потери скорости (неравномерной, зависимой от вида действий) и неточного воспроизведения поведения железа.
Конечно есть потеря скорости. Но как её измерить, без внешнего наблюдателя, и когда нет доверия к локальным источникам данных.
N>В задачах Евгения (звуковые драйвера) это может быть критично.
Каких ещё драйверов ?
я думал мы жвачку для мозгов жуём, с подачи ТС, размышляем о вариантах реализации отладчиков.
Здравствуйте, netch80, Вы писали:
N>точно за один такт?
Не, наврал — в документации на АЛУ указано 53 такта. Я и сам сомневался, что они на голых транзисторах нагородили сложных матриц для произвольной коммутации разрядов.
N>Кстати, тут приводится некоторая shift immediate, которая однозначно сдвиг.
Это сдвиг не данных, а адреса памяти (смещение относительно адреса). Ну вот назвали почему-то так. Там вместо сложных методов адресации были специальные команды прибавления адреса из регистра или ячейки памяти ко внутреннему регистру-модификатору адреса (РМА). Можно было подряд выполнить несколько таких команд, последовательно сдвигая адрес к нужной базе, а адрес в поле команды или индексном регистре затем использовался, как смещение относительно этой базы.
N>Так что утверждение про "вообще не имела" как-то сомнительно.
Битового сдвига действительно не было. Двигали или сборкой/разборкой, или умножением/делением на степень двойки.
N>как-то совершенно неровно в размерах, за этим надо постоянно следить.
А привычка очень быстро вырабатывалась. Мы программы часто даже не писали, сразу набирали в редактор из головы. В основном же работа с данными идет вокруг объектов в памяти, а в БЭСМ-6 как раз был специальный разряд в поле команды, обозначающий смещение вверх или вниз от адреса в индексном регистре. А для сложных способов адресации были как раз те самые адресные сдвиги.
N>Ну если "нормальный" это ценой от миллиона тогдашних $, то согласен
Так те процессоры вполне отрабатывали свои миллионы, разумно распределяя свои ресурсы, а не разбазаривая, как сейчас.
Здравствуйте, IID, Вы писали:
IID>Конечно есть потеря скорости. Но как её измерить, без внешнего наблюдателя, и когда нет доверия к локальным источникам данных.
Например, посчитать статистику скорости срабатывания различных операций разных устройств — MMU, APIC, North/South Bridges, PCI, USB и т.п. Виртуализовать все это так, чтоб до наносекунд соблюсти все времянки реального железа, адски сложно (и столь же дорого).
Здравствуйте, yoyozhik, Вы писали:
Y>Но просто для само развития:
Y>Есть современные аналоги? x64dbg
Y>И да, в мире linux есть современные аналоги? gdb
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Например, посчитать статистику скорости срабатывания различных операций разных устройств — MMU, APIC, North/South Bridges, PCI, USB и т.п. Виртуализовать все это так, чтоб до наносекунд соблюсти все времянки реального железа, адски
сложно (и столь же дорого).
а наносекунды ты чем будешь засекать ? таймером, которому доверия нет
кстати, на ARM давно намечена тенденция выносить работу с железом в Secure World. Чтобы после компрометации ядра HLOS ты не мог устроить армагеддон, напримев занизив напряжение питания или неприлично разогнав камень. Также Secure World может перехватывать события от устройств, и даже быть третьим этапом трансляции страниц (второй — гипервизор). И что-то там замерять дело неблагодарное. Мало того что оно сильно от устройств будет отличаться, так ещё и от профилей питания, и, конечно, всякой фоновой загрузки во всех этих дополнительных операционках.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А привычка очень быстро вырабатывалась. Мы программы часто даже не писали, сразу набирали в редактор из головы.
Боюсь спросить, сколько вам лет? Наверное такое даже не в 80-х было, а не позже 70-х.
Здравствуйте, IID, Вы писали:
IID>а наносекунды ты чем будешь засекать ? таймером, которому доверия нет
А ему и не нужно доверия. Задача в том, чтобы определить, соблюдаются ли в системе все известные временнЫе соотношения, характерные для определенных моделей железа. Еще можно проверить наличие недокументированных особенностей (состояние резервных регистров/разрядов и т.п.). Нарушение каких-то из этих соотношений будет означать, что в системе что-то не так — или неисправная физическая, или не полностью виртуализованная. А что именно в виртуализованной системе работает не так — таймер, контроллер или шина — уже не столь важно.
Здравствуйте, jamesq, Вы писали:
J>сколько вам лет?
Не столь и много — 57.
J>Наверное такое даже не в 80-х было, а не позже 70-х.
Я начинал в 80-м. А сотрудники нашей кафедры работали на БЭСМ-6 в одном из НИИ где-то до середины 90-х. Примерно до тех же времен в другом НИИ, с которым я сотрудничал, работали на какой-то из ЕС ЭВМ, пока не заменили ее на несколько PC AT. Основная проблема с заменой была даже не в деньгах, а в программах — для БЭСМ-6 было много программ на экзотических языках или местных диалектах Fortran/Algol, для ЕС — на PL/1 и COBOL. Переносить их на PC было то еще удовольствие.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, IID, Вы писали:
IID>>а наносекунды ты чем будешь засекать ? таймером, которому доверия нет
ЕМ>А ему и не нужно доверия. Задача в том, чтобы определить, соблюдаются ли в системе все известные временнЫе соотношения, характерные для определенных моделей железа. Еще можно проверить наличие недокументированных особенностей (состояние резервных регистров/разрядов и т.п.). Нарушение каких-то из этих соотношений будет означать, что в системе что-то не так — или неисправная физическая, или не полностью виртуализованная. А что именно в виртуализованной системе работает не так — таймер, контроллер или шина — уже не столь важно.
Это всё хрень. Которая может отвалиться как через 10 лет, так и через 48 часов.
Для вирусни и прочих наколенных поделий такое можно заюзать, но не для серьезного софта с миллионами инсталлов.
Часто он появлялся из-за надобности плавучки, но не обязательно.
