компилятор и порядковый номер

У меня есть ISA, который «отчасти» с прямым порядком байтов.
Основной блок памяти является целым числом, а не байтом. Например,

00000000: BEFC03FF 00008000

Представляет, что «низкое» целое число BEFC03FF и «высокое» целое число 00008000,
Мне нужно прочитать значение, представленное некоторыми битами. Например, биты с 31 по 47.
То, что я делаю в VS10 (c ++), генерирует uint64_t var = 0x00008000BEFC03FF
после этого используйте соответствующую маску и проверьте значение var & mask,
Законно ли это сделать? Я делаю некоторые предположения о расположении битов uint64_t — это законно?
Можно ли предположить, что для самого компилятора и для каждой ОС (без зависимости от hw) расположение битов в uint64_t будет таким?

1

Решение

Вы правы быть обеспокоены, Это делает иметь значение.

Однако, в этом конкретном случае, поскольку ISA имеет младший порядок байтов, то есть если он имеет AD [31: 0], младший значащий бит целого числа упакован в бит 0. Предполагая, что ваш процессор также имеет младший порядок байтов, тогда не о чем беспокоиться , когда данные записываются в память, они должны иметь правильный порядок байтов

0000  FF
0001  03
0002  ..

Предположим, если ваш протокол внешней шины с прямым порядком байтов и ваш процессор с прямым порядком байтов. затем 16-разрядное целое число в вашем процессоре, скажем, 0x1234 будет 0001_0010_0011_0100 в родном формате, но 0010_1100_0100_1000 в автобусе (при условии, что это 16 бит).

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

0000 0001_0010
0001 0011_0100

тогда это зависит от программного обеспечения, чтобы поменять порядок байтов

1

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector