вместо того, чтобы «статически» избегать его, используя адреса, совместимые с рассматриваемыми типами.
Статически (во время компиляции) очень легко избежать когда-либо делать указатель с несмещение нескольких из 4 int*. Компиляторам не сложно с этим;в C вам придется привести к uintptr_t и обратно или выполнить другие трюки, чтобы выровнять int*.
Проверка выровненных адресов в HW очень дешевая (просто убедитесь, чтомладшие 3 бита равны нулю). Потенциальный сбой также дешев, если вам нужно только ускорить быстрый путь. Загрузка / хранение уже должны быть в состоянии вызвать сбой страницы для виртуальной памяти в любом случае.
Это не реальная проблема, требующая решения
only обратная сторона байта- адресная память с необходимыми для выравнивания нагрузками / хранилищами тратит эти младшие биты адреса. (Или, конечно, неэффективность, если у вас возникла проблема, когда было бы полезно выровнять нагрузки или хранилища, тогда невозможность их выполнить - это проблема, независимо от причины.)
В реальной жизни да, иногда мы имеемменьше выравнивания, чем хотелось бы, и обнаружение случаев, когда ваша программа работает медленно из-за этого, может быть полезным. У нас есть счетчики производительности для этого на современной x86. (И даже флаг проверки выравнивания, но он почти непригоден, потому что стандартные библиотеки и компиляторы предполагают, что он не установлен.)
Существует несколько машин с адресацией по словам, включая некоторые современные DSP. Но у них все еще есть только одна «шкала» для адресов, ни одна часть адресного пространства не может быть байтово-адресуемой.
Или есть серьезная причина предпочесть его таким образом (например, упрощающие компиляторы)?
Да, есть. Если вы хотите эффективно обнулить массив перед использованием его для массива bool или строки char, то обнуление может произойти с 8-байтовыми или даже более широкими хранилищами SIMD. Используя тот же адрес , который вы будете использовать для доступа байтов к тем же данным . Это только один пример.
Нередко хочется использовать более широкую загрузку или хранилище для копирования вокруг нескольких элементов struct. Говоря о том, как будет работать структура? Обычно у вас есть один адрес для базы структуры и вы можете получить доступ к любому члену с фиксированными смещениями. С вашей схемой, вам нужно будет сместить адрес вправо, чтобы отменить неявное смещение влево qld?
Кроме того, распределитель памяти, такой как malloc, может использовать один и тот же адрес независимо от того, каквызывающая сторона хочет использовать память. Нужно ли масштабировать адрес (смещая) обратно до некоторого стандартного масштаба до free, да?
Наличие нескольких адресов для одних и тех же ячеек памяти является "псевдонимом" и, как правило, вызывает проблемы.
Или вы представляете, что байтовое адресное пространство полностью не пересекается с адресным пространством qword? Если да, то как вы можете эффективно копировать данные с одного на другое, не имея возможности хранить более 1 байта за раз? Может быть, с SIMD-загрузками / хранилищами, доступными для каждого адресного пространства?
Или это 4 ГБ памяти, адресуемые байтами (а также слова, слова и слова), и выше 4–8 ГБдиапазон адресован только как 16-битные или более широкие фрагменты? И следующие 8GiB выше, которые можно использовать только как 32-битные блоки? (Верхняя половина диапазона адресов dstr). и т. д.
Если это так, у вас есть отдельный распределитель malloc для каждого размера, поэтому, если вам нужна память, к которой можно обращаться в байтах, она ограничена низкими 4 ГБ (32-битными bstr адресами)= младшие 29 бит 32-битного qstr адресного пространства?) Потому что у вас есть память, которая недоступна для использования в качестве байтов. Адресное пространство qstr можно представить как неявное смещение влево на 3, чтобы создать 35-битный адрес байта, выровненный на 8 байтов.
Это звучит очень сложно, или, по крайней мере, не соответствует стандартной модели, к которой привыкло программное обеспечение, и это закреплено в таких языках, как C. Было бы более нормально использовать такой механизм, как сегментация, для расширения вашего адреса. -пространство равномерно, чтобы вы могли использовать любой из них для строк, байтовых массивов и т. д.
Я думаю, виртуальная память все еще будет работать в терминах физических страниц фиксированного размера, а ОС может поддерживать любые виртуальныестраница в эффективно 35-битном виртуальном адресном пространстве с одной из этих страниц 4k. Но это означает, что граница страницы для qstr составляет всего 4096/8 = 512 больших адресов qword.
(Я предполагаю, что ширина регистра в этих примерах составляет 32 бита. Если у вас есть 64-битные регистры, вы неВам не нужны неудобные приемы для расширения адресного пространства, вы можете просто использовать байтовые адреса.)