вряд ли инлайн-асм в C/C++-коде обрабатывается компилятором так
Инлайн асм в 64битном cl.exe вообще вырубили, как раз из за невозможности нормально генерировать SEH правила.
Ради того, чтобы сэкономить восемь шестнадцать байт на стеке?
Скорее ради нескольких тактов процессора при каждом заходе в try блок, в каких то ситуациях может быть критично. Идея в том, что при отсутствии исключений try должен быть вообще бесплатным - то есть использовать его можно сколько угодно, лишь бы сами исключения не падали. Генерация правил в компиляторе дело наживное (в Юниксах .eh_frame секция давно использовалась), об усложнениях пишущих на ассемблере, видимо, не особо думали - директивы дали и ладно.
И SEH тоже испортили, убрав цепочку фреймов с стека. Чем руководствовались — загадка.
Тут то всё понятно - убрали дополнительный оверхед в прологе/эпилоге на работу с этой цепочкой. Раскрутка стека при исключениях стала заметно дороже - но предполагается, что исключения - это действительно исключения и случаются крайне редко.
все нововведения нужны только, если ваш код вызывает код из посторонних библиотек (банальный пример — WinAPI) или наоборот, посторонний код вызывает ваш
В этих случаях ещё неплохо правила для SEH прописать(см. здесь, "Unwind helpers for MASM").
Это соответствует варианту "мы знаем, что старший ребёнок девочка". Эквивалент оригинальной задачи - монетку подбрасывали два раза, и мы знаем что как минимум один раз (не факт, что при первом подбросе) выпадал орёл. Соответственно, вероятности второго орла/девочки в разных вариантах разные.
А если говорить о классических профилировщиках (perf, VTune), данным на небольшой кусок кода можно доверять только если это внутренний цикл с большим числом итераций - иначе статистические ошибки сильно испортят картину.
IACA и его "потомки" (OSACA, llvm-mca, uica) не профилировщики, а статические анализаторы - с одной стороны, они дают полную картину с точностью до работы отдельных инструкций и не подвержены погрешностям измерения, с другой - точность ограничена заложенной моделью и параметрами процессора, на железе они анализируемый код не запускают.
В смысле с Altair 8800? Да, результат сравнения очевиден. Больше известного западного на 8080 не припомню, как то больше на 6502 и Z80, причём ещё c 70х
так это претензии не к тем, кто делал, а к партии и правительству.
Статья же именно об этом - отсутствие рынка и т.д. Конструкторский талант разработчиков Микроши или Суры не обсуждается.
Да, если компилировать C код в tiny модели (код и данные живут в одном общем сегменте, используются только ближние указатели), exe2bin стабильно отрабатывал.
Какой то странный переход от ограничения ближних указателей к оверлеям. Код или данные в EXE могли быть больше 64k, при этом всё грузилось в память, но при необходимости использовались дальние указатели (в C компиляторах в связи с этим были разные модели памяти от tiny до huge с разными дефолтными типами указателей). Оверлеи нужны если программа не влезает в 640k.
Как то всё сложно. Я к такому примеру - сначала создали конкретный класс, который используется в куче мест (естественно, никакого прямого доступа к полям объектов, только чётко документированный интерфейс - но создаётся везде просто через конструктор с аргументами). Потом получилось, что для какого то набора аргументов реализация заметно отличается - сделали отдельный класс, в конструкторе первоначального класса при необходимости возвращаем его объект; код пользователей менять не надо - они продолжают считать, что работают с одним конкретным классом.
Я это и имел в виду, неточно выразился.
Инлайн асм в 64битном cl.exe вообще вырубили, как раз из за невозможности нормально генерировать SEH правила.
Скорее ради нескольких тактов процессора при каждом заходе в try блок, в каких то ситуациях может быть критично. Идея в том, что при отсутствии исключений try должен быть вообще бесплатным - то есть использовать его можно сколько угодно, лишь бы сами исключения не падали. Генерация правил в компиляторе дело наживное (в Юниксах .eh_frame секция давно использовалась), об усложнениях пишущих на ассемблере, видимо, не особо думали - директивы дали и ладно.
Не раскрыта тема проверки корректности адресов возврата/перехода в железе (Intel CET, ARM PAC/BTI).
Практика программирования (Керниган/Пайк) - не только про C, но большая часть кода на нём.
Тут то всё понятно - убрали дополнительный оверхед в прологе/эпилоге на работу с этой цепочкой. Раскрутка стека при исключениях стала заметно дороже - но предполагается, что исключения - это действительно исключения и случаются крайне редко.
В этих случаях ещё неплохо правила для SEH прописать(см. здесь, "Unwind helpers for MASM").
Это соответствует варианту "мы знаем, что старший ребёнок девочка". Эквивалент оригинальной задачи - монетку подбрасывали два раза, и мы знаем что как минимум один раз (не факт, что при первом подбросе) выпадал орёл. Соответственно, вероятности второго орла/девочки в разных вариантах разные.
А если говорить о классических профилировщиках (perf, VTune), данным на небольшой кусок кода можно доверять только если это внутренний цикл с большим числом итераций - иначе статистические ошибки сильно испортят картину.
IACA и его "потомки" (OSACA, llvm-mca, uica) не профилировщики, а статические анализаторы - с одной стороны, они дают полную картину с точностью до работы отдельных инструкций и не подвержены погрешностям измерения, с другой - точность ограничена заложенной моделью и параметрами процессора, на железе они анализируемый код не запускают.
В смысле с Altair 8800? Да, результат сравнения очевиден. Больше известного западного на 8080 не припомню, как то больше на 6502 и Z80, причём ещё c 70х
Статья же именно об этом - отсутствие рынка и т.д. Конструкторский талант разработчиков Микроши или Суры не обсуждается.
А на других счётных кодах проблема не воспроизводится?
Альтернатива - пилить такой же код самим с нуля.
Вопрос в ресурсах на эту работу. В американском минобороны должны найтись.
Никто не мешает периодически подтягивать в свой форк изменения из основной ветки (с пристальным code review).
А стандартный аудит не подходит?
Такое подойдёт?
Да, если компилировать C код в tiny модели (код и данные живут в одном общем сегменте, используются только ближние указатели), exe2bin стабильно отрабатывал.
Какой то странный переход от ограничения ближних указателей к оверлеям. Код или данные в EXE могли быть больше 64k, при этом всё грузилось в память, но при необходимости использовались дальние указатели (в C компиляторах в связи с этим были разные модели памяти от tiny до huge с разными дефолтными типами указателей). Оверлеи нужны если программа не влезает в 640k.
На уровне языка нет, но можно в рамках проекта договориться, что с таким то объектами работает только через такие то методы с такими то параметрами.
Как то всё сложно. Я к такому примеру - сначала создали конкретный класс, который используется в куче мест (естественно, никакого прямого доступа к полям объектов, только чётко документированный интерфейс - но создаётся везде просто через конструктор с аргументами). Потом получилось, что для какого то набора аргументов реализация заметно отличается - сделали отдельный класс, в конструкторе первоначального класса при необходимости возвращаем его объект; код пользователей менять не надо - они продолжают считать, что работают с одним конкретным классом.
В JS же вроде duck typing - можно возвращать объекты никак не связанных классов, достаточно чтобы они реализовывали общие интерфейсы.