Комментарии 33
Порадовал в свое время несказанно порядок байт на каком-то арме, для double: efghabcd.
В итоге для формата сохранения под разные архитектуры, написал что-то вроде QDataStream, только порядок байт более гибко задается.
uint8_t mask = (ORDER_LE | ORDER_LE << 1 | ORDER_BE << 2), вроде такого. и для float и int-ов отдельно. зато вычисляется такая маска один раз, и потом все довольно просто
dest[mask ^ 0] = src[0];
dest[mask ^ 1] = src[1];
dest[mask ^ 2] = src[2];
dest[mask ^ 3] = src[3];
В итоге для формата сохранения под разные архитектуры, написал что-то вроде QDataStream, только порядок байт более гибко задается.
uint8_t mask = (ORDER_LE | ORDER_LE << 1 | ORDER_BE << 2), вроде такого. и для float и int-ов отдельно. зато вычисляется такая маска один раз, и потом все довольно просто
dest[mask ^ 0] = src[0];
dest[mask ^ 1] = src[1];
dest[mask ^ 2] = src[2];
dest[mask ^ 3] = src[3];
Вспомнилась замечательная платформа C2000 от TI, где данные адресуются по 16 бит и sizeof(uint16) == 1. Очень весело отлаживать при первом знакомстве.
В статье, к сожалению, очень много неточностей я бы не рекомендовал ее для серьезного чтения (это претензия к автору, а не к переводчику).
Во-первых байт это не «последовательность из восьми бит» в которой «биты нумеруются справа налево», а минимальная адресуемая структура памяти и левых и правых битов или иной их нумерации или выделения битов внутри байта с точки зрения адресации нет, писать так совершенно некорректно. Выше упомянули платформу с размером байта в 16 бит. Байт, по определению он не разделяется логически с точки зрения адресации, биты в нем можно выделить исключительно по значению самого байта. То, что обычно при схематическом изображении на доске/бумаге/мониторе байт разделяют на биты и справа записывают младший бит — не более чем условность изображения. К байту следует относиться как к одному значению, чаще всего 256-ричному.
Последовательность из 8 бит называется октетом. В случае передачи по сети — всегда и в любом стандерте, писать о байтах в сети и измерять скорость передачи по сети в байтах в секунду является некорректным.
Маркер последовательности байтов фактически используется — при хранении текста в кодировке UTF-16 (т.к позволяет различать big endian и little endian только для 16-битных значений).
Необходимость конвертировать данные через ntoh*/hton* определяется не платформой получателя, а сетевым протоколом. Большая часть стандартизованных протоколов используется сетевой (прямой) порядок байт.
Это не так, например все последние версии платформ MIPS и ARM имеют возможность работать как в big endian так и в little endian режимах. Есть разные сборки Linux, например, под один и тот же процессор работающий в little endian или в bin endian режимах.
Во-первых байт это не «последовательность из восьми бит» в которой «биты нумеруются справа налево», а минимальная адресуемая структура памяти и левых и правых битов или иной их нумерации или выделения битов внутри байта с точки зрения адресации нет, писать так совершенно некорректно. Выше упомянули платформу с размером байта в 16 бит. Байт, по определению он не разделяется логически с точки зрения адресации, биты в нем можно выделить исключительно по значению самого байта. То, что обычно при схематическом изображении на доске/бумаге/мониторе байт разделяют на биты и справа записывают младший бит — не более чем условность изображения. К байту следует относиться как к одному значению, чаще всего 256-ричному.
Последовательность из 8 бит называется октетом. В случае передачи по сети — всегда и в любом стандерте, писать о байтах в сети и измерять скорость передачи по сети в байтах в секунду является некорректным.
Маркер последовательности байтов фактически используется — при хранении текста в кодировке UTF-16 (т.к позволяет различать big endian и little endian только для 16-битных значений).
Необходимость конвертировать данные через ntoh*/hton* определяется не платформой получателя, а сетевым протоколом. Большая часть стандартизованных протоколов используется сетевой (прямой) порядок байт.
Каждый компьютер одного типа имеет внутреннюю совместимость (он может считывать свои собственные данные), но нет никакой гарантии, как именно интерпретирует эти данные компьютер другого типа.
Это не так, например все последние версии платформ MIPS и ARM имеют возможность работать как в big endian так и в little endian режимах. Есть разные сборки Linux, например, под один и тот же процессор работающий в little endian или в bin endian режимах.
Какая-то слишком маленькая статья для объяснения, что одни байты идут 1234, другие — 4321. Не пробовали написать трёхтомник «Биты и байты — неизвестный мир компьютеров»?
Да и тестировать числа на четность тоже приходится слегка реже, чем через оператор. Да и у четного числа не последний байт ноль, а последний бит.
Левая статья. И слишком «полноводная» (много воды) для такой простой темы.
Левая статья. И слишком «полноводная» (много воды) для такой простой темы.
Пром. контроллеры, например.
позволяют делать даже побитовую выборку без работы с масками
И там данная проблема как раз актуальна: для того, чтобы обратиться, например, к биту 1.0 в ПЛК, в hmi приходится обращаться к биту 0.0.
позволяют делать даже побитовую выборку без работы с масками
И там данная проблема как раз актуальна: для того, чтобы обратиться, например, к биту 1.0 в ПЛК, в hmi приходится обращаться к биту 0.0.
Статья неплохая в качестве ликбеза, но требует вычитки — много мелких ляпов на русском языке.
Не статья, а вода. На вики и то больше информации.
является число нечетным или четным (последний байт 0)
госпади исусе!
Имхо, достаточно было пример с римскими цифрами IV и VI, к примеру, разобрать. Автор словно гнался за объемом текста.
Извините, но калькулятор в Windows с Вами не согласен :)
Ну давайте сверятся… Я выбрал режим Programmer. Переключил радиокнопку на hex. Набрал 12 и переключил радиокнопку на bin, что приводит к конвертации числа в другой тип. Согласно этому, Ваш вариант — это А или же 10…
Рекомендую bitbucket.org/arbv/ptypes/src
Хорошая статья, но на мой взгляд не хватает для пояснения элементарной вещи. Глядя на последовательность 00001001, которую обычно мы интерпретируем слева направо, нужно пояснить, где тут старший байт, а где младший. Я бы в перевод добавил картинку как эта https://uynguyen.github.io/2018/04/30/Big-Endian-vs-Little-Endian/
Машины с порядком хранения от старшего к младшему (прямой порядок) хранят старший байт первым. Если посмотреть на набор байтов, то первый байт (младший адрес) считается старшим.
Машины с порядком хранения от младшего к старшему (обратный порядок) хранят младший байт первым. Если посмотреть на набор байт, то первый байт будет наименьшим.
Мне кажется тут и далее в статье перепутаны термины "прямой порядок" и "обратный порядок". Должно быть наоборот: прямой порядок - это little-endian, обратный порядок - big-endian
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разбираемся с прямым и обратным порядком байтов