Там же дело не в видимых результатах выполнения инструкций (которые определены документацией), а в деталях реализации и времени исполнения (замеряя которое и вытаскивается теоретически недоступная информация). По времени чёткой документации нет - есть таблички с latency/throughput для инструкций, но в общем случае их недостаточно для предсказания времени работы произвольного куска кода.
Особенностью архитектуры ARM64 является то, что при определенных условиях эти манипуляции со стеком раскладывались компилятором на две команды
Точнее особенностью кодогенератора Go под ARM64 (уже пофикшенной). Так то в типичном коде под DOS или Win32 (именно 32битный) для "обычных" интеловских процессоров постоянно используются push/pop при вызовах функций или просто когда регистров под временные переменные не хватает, так что в произвольный момент указатель стека указывает на какие то промежуточные данные.
Скорее рантайм с кодогеном не договорились. Как написал выше, по идее и такие стеки раскручиваются - но возможно в рантайме Go для оптимизации обрабатывают только простые случаи, а в компиляторной команде это не до всех донесли.
Погуглил - пишут, что для LFN в MS DOS 7 нужен отдельный резидент (работающий и в других версиях DOS). Я в те годы его не видел. И в любом случае нужно использовать отдельное API (семейство функций 71h для int 21h).
По идее отдельные изменения указателя стека должны явно прописываться в .eh_frame и учитываться в процессе раскрутки. Но не знаю, как конкретно работает раскрутчик в рантайме Go.
Насколько помню, LFN для досовских программ был доступен только в дос окне из под винды (и то если сама прога использовала соответствующие расширения), при загрузке в режиме DOS только короткие.
под SVE хочется писать «длино‑агностичный» код. std::simd частично закрывает эту историю: native<T> подбирает «правильную» ширину под флаги компилятора
Идеология SVE - скомпилировать один раз бинарный код, который автоматом использует ширину вектора на том процессоре, на котором запускается. Для std::simd размер нужен во время компиляции.
Программирование тогда было не столько наукой, сколько ремеслом
Но к тому времени уже были придуманы машина Тьюринга и лямбда исчисление, так что научная работа над алгоритмами и программированием шла параллельно с перещёлкиванием тумблеров на реальном железе.
Никто не мещает хранить состояние на внешних ресурсах и подключать новые в процессе работы программы.
Так как в нынешнем C++ правильно работать с отдельными битами double/float?
По хорошему либо выполняется документированная команда, либо генерируется соответствующее исключение. Но да, далеко не везде это так.
Писать код через db не так уж и странно (скажем, если надо использовать новые инструкции, которые ещё не завезли в тулчейн).
Так это именно bug, а не feature )
Там же дело не в видимых результатах выполнения инструкций (которые определены документацией), а в деталях реализации и времени исполнения (замеряя которое и вытаскивается теоретически недоступная информация). По времени чёткой документации нет - есть таблички с latency/throughput для инструкций, но в общем случае их недостаточно для предсказания времени работы произвольного куска кода.
Точнее особенностью кодогенератора Go под ARM64 (уже пофикшенной). Так то в типичном коде под DOS или Win32 (именно 32битный) для "обычных" интеловских процессоров постоянно используются push/pop при вызовах функций или просто когда регистров под временные переменные не хватает, так что в произвольный момент указатель стека указывает на какие то промежуточные данные.
Скорее рантайм с кодогеном не договорились. Как написал выше, по идее и такие стеки раскручиваются - но возможно в рантайме Go для оптимизации обрабатывают только простые случаи, а в компиляторной команде это не до всех донесли.
Погуглил - пишут, что для LFN в MS DOS 7 нужен отдельный резидент (работающий и в других версиях DOS). Я в те годы его не видел. И в любом случае нужно использовать отдельное API (семейство функций 71h для int 21h).
По идее отдельные изменения указателя стека должны явно прописываться в .eh_frame и учитываться в процессе раскрутки. Но не знаю, как конкретно работает раскрутчик в рантайме Go.
Насколько помню, LFN для досовских программ был доступен только в дос окне из под винды (и то если сама прога использовала соответствующие расширения), при загрузке в режиме DOS только короткие.
Это уже ближе к концу 90х.
Я что-то пропустил и во времена Windows 95 действительно была Win32 версия дюка?
В больших проектах разделение на разбирающихся во внутренней логике и в пользовательском интерфейсе всё таки было.
У меня от Turbo C осталась привычка к F2, так и перенавешивал на неё сохранение в разных редакторах.
На каком железе проверяли? Есть мнение, что с поддержкой настоящих процессоров стало не очень.
Прочитайте сообщения выше )
Речь шла об эмуляции одной инструкции процессора, какие ещё блендеры/скейлеры?
Идеология SVE - скомпилировать один раз бинарный код, который автоматом использует ширину вектора на том процессоре, на котором запускается. Для std::simd размер нужен во время компиляции.
TP был заметно быстрее TC (как минимум сам язык делает возможной однопроходную компиляцию).
Верю что быстрее, но реализовать эмуляцию произвольной инструкции, скажем, на x86 или ARM с разнообразными расширениями - задачка весьма серьёзная.
Но к тому времени уже были придуманы машина Тьюринга и лямбда исчисление, так что научная работа над алгоритмами и программированием шла параллельно с перещёлкиванием тумблеров на реальном железе.