Это не так работает. Компилятор делает оптимизации исходя из того, что код написан правильно и UB не может возникнуть ни при каких входных данных.
То есть если написан memset локальной переменной, которая потом не читается, а размер приходит извне, то такой memset можно удалить.
Но неоптимизированный код за время своей работы изменит регистры и память, а оптимизированный может по-другому распределить регистры и данные в памяти. Видимо нужны какие-то точки, в которые возможно переключение, и ограничения оптимизаций.
Кому интересно как всё было на самом деле, рекомендую www.folklore.org или в виде книги « Revolution in The Valley: The Insanely Great Story of How the Mac Was Made».
функция использует DSO-идентификатор, который известен только компилятору
Мне стало интересно как генерится этот __dso_handle. Например, если это случайное число, выбранное в момент компиляции, то оно может совпасть у двух библиотек, в таком случае их atexit'ы перепутаются.
Всё оказалось проще и хитрее: __dso_handle — это объект с релокацией, которая подставляется в момент загрузки библиотеки. А так как адреса библиотек в процессе не могут пересекаться, то и хэндлы от разных библиотек всегда будут разные.
Но ведь Newton OS с самого начала работала на ARM.
То есть если написан memset локальной переменной, которая потом не читается, а размер приходит извне, то такой memset можно удалить.
Хотя в C это валидный код.
А вот в виртуалке будет работать, только если она поддерживает виртуализацию PMU.
Мне стало интересно как генерится этот __dso_handle. Например, если это случайное число, выбранное в момент компиляции, то оно может совпасть у двух библиотек, в таком случае их atexit'ы перепутаются.
Всё оказалось проще и хитрее: __dso_handle — это объект с релокацией, которая подставляется в момент загрузки библиотеки. А так как адреса библиотек в процессе не могут пересекаться, то и хэндлы от разных библиотек всегда будут разные.
x87 в 2017 году?