За 44-битным ограничением адреса виртуальной памяти в Windows x64

Question

http://www.alex -ionescu.com /? Р = 50 .

Я прочитал вышеупомянутый пост.Автор объясняет, почему Windows x64 поддерживает только 44-битный адрес виртуальной памяти, на примере односвязного списка.

struct {  // 8-byte header
        ULONGLONG Depth:16;
        ULONGLONG Sequence:9;
        ULONGLONG NextEntry:39;
} Header8;

Первой жертвой было сокращение пространства для порядкового номера до 9 бит вместо 16 бит, уменьшая максимальный порядковый номер, которого может достичь список.Это все еще оставило 39 битов для указателя - посредственное улучшение по сравнению с 32 битами.При принудительном выравнивании структуры по 16 байт при выделении можно выиграть еще 4 бита, поскольку теперь можно всегда предполагать, что нижние биты равны 0.

---

О, я могу 'Т понять.

Что "При принудительном выравнивании структуры на 16 байтов при выделении можно выиграть еще 4 бита, поскольку теперь нижние биты всегда можно считать равными 0."средства?

Answer 1

16 is 0010000 in binary

32 is 0100000 in binary

64 is 1000000 in binary

и т. Д.

Вы можете видеть, что для всех чисел, кратных 16, последние четыре бита всегда равны нулю.Таким образом, вместо того, чтобы хранить эти биты, вы можете оставить их и добавить их обратно, когда пришло время использовать указатель.

Answer 2

Для 2 ^ N-байтового выровненного указателя его адрес всегда делится на 2 ^ N - это означает, что младшие N битов всегда равны нулю. В них вы можете хранить дополнительную информацию:

encode ptr payload = ptr | payload
decode_ptr data = data & ~mask
decode_payload data = data & mask

, где маска (1 << N) - 1 - то есть число с установленными младшими битами N.

Этот прием часто используется для экономии места в низкоуровневом коде (полезные данные могут быть флагами GC, тегом типа и т. Д.)

Фактически вы сохраняете не указатель, а число, из которого можно извлечь указатель. Конечно, следует позаботиться о том, чтобы не разыменовывать число в качестве указателя без декодирования.