График битового поля не поддерживается процессором
Всем привет! Есть вот такая задача: Реализовать функцию для преобразования битовых полей. В решении необходимо использовать побитовые операции.
Примеры результатов вычислений:
f(0x5fdf629f) = 0xfde29f67
f(0x21eb958f) = 0x5e958f38
Проблема в том,что я понятия не имею как решить эту задачу.
Может кто-нибудь подсказать в какую сторону мне двигаться?
Реализовать функцию для преобразования десятичного числа в виде ASCII строки в многобитное двоичное число
Помогите, пожалуйста, подскажите с чего нужно начать или где можно посмотреть решенные подробного.
Реализовать функцию получения доступа для изменения всех полей
т.е. в main нужно вызвать эти функции, показать как они вызываются и изменяются.
Преобразования битовых данных в файл
Здравствуйте! Подскажите пожалуйста как преобразовать данные полученные через сокеты в файл вот.
Решение
В сторону битовых масок и сдвигов
Добавлено через 1 час 45 минут
Реализовать функцию преобразования матрицы согласно условию
Выполнить задания лабораторной работы №3 в виде функций с входными параметрами, таким образом.
Реализовать функцию "Отобразить / Скрыть пароль" для нескольких полей ввода.
Всем привет! У меня имеется необходимость разместить на сайте несколько форм авторизации.
Реализовать функцию преобразования строк с использованием рекурсивной процедуры
Прошу написать программный код по предоставленной задаче
Массив битовых полей
Добрый день! Из файла читается массив 4-битовых значений т.е. по два значения в каждом байте.
Типы битовых полей
Какие типы можно определять в битовых полях? Можно ли использовать битовые поля в чем-нибудь.
Использование битовых полей структуры
Многие не рекомендуют использовать битовые поля структуры. Нашел этому пока одно объяснение. "На.
В программе Chia написано:Разметка участков при включенной функции построения битовых полей почти всегда быстрее, так как имеет меньше операций записи примерно на 30%.С другой стороны, вы можете увидеть снижение требований к оперативной памяти при отключении функции построения битовых полей. Если ваш процессор разработан до 2010 года, возможно, вам придется отключить функцию построения битовых полей.👉🏻 На официальном сайте:Один k32 записывает 1,8 ТиБ в режиме без битового поля и 1,6 ТиБ с включенным битовым полем. Еще немного о поле.
Первоначально плоттер не использовал обратную сортировку битовых полей. Обратная сортировка битового поля теоретически быстрее, чем без использования битового поля, и мы уже знаем, что она экономит 12% от общего объема записи, но требует больше оперативной памяти. У нас есть предчувствие, что мы можем ускорить битовое поле на 10% и заставить его работать на большем количестве процессоров, но этого еще нет. Что мы действительно знаем, так это то, что, если вы согласны с увеличением общего количества операций записи на 12%, никакое битовое поле не будет работать быстрее, если SSD или быстрый SAS являются вашим временным каталогом. Если ваш временный каталог находится на обычном жестком диске, как у меня, битовое поле на 20% быстрее, чем без bitfield. Старые процессоры могут не видеть увеличения скорости так сильно, как указано выше.
Цифры в программе и на сайте немного разные, возможно из за того, что в процессе обновлений что то было изменено.Получается, отключение битового поля увеличит скорость плоттинга на SSD и других быстрых накопителях, например объединенных в RAID 0, но будет расходовать больше ресурса циклов перезаписей (TBW) на 8 — 12% Если вы используете для временных директорий обычные HDD, тогда отключать битовое поле не надо, без отключения скорость будет выше на 20 — 30% и будет расходовать меньше ресурса диска.
Битовые поля не поддерживаются в языке OpenCL. Что послужило причиной их не поддержать? В отличие от других пропущенных частей (рекурсия, указатели на функции. ), где есть очевидная причина не поддерживать их, я не вижу ни одной для битовых полей. Я уверен, что это не оплошность со стороны комитета, но в чем причина?
(Я храню некоторые биты, упакованные в целые числа, и код будет лучше читать с ними. Я понимаю битовые поля как удобный синтаксис для избежания битового сдвига и маскирования туда и обратно, что в любом случае они переводят в ассемблере.)
Я смог задать этот вопрос одному из участников рабочей группы. Вот что он должен был сказать:
Bit-fields are not portable -- so they could not be used in types used for kernel arguments.
The only place they could be used is for types for local variables declared inside a kernel.
The OpenCL working group was not convinced this was very useful. In addition, there were concerns that compilers may not generate efficient code when using bitfields. All of these led the working group to the decision not to support bit-fields in OpenCL C.
Важно помнить, что OpenCL допускает такие вещи, как хост с прямым порядком байтов и устройство с прямым порядком байтов. Разрешение битовых полей только еще больше усложнит поддержку смешанного порядка следования байтов.
Не переносимый . аргумент, что он работает только с тем же порядком байтов, слаб. Многие коды OpenCL (включая мой) будут написаны для конкретного оборудования. Программист должен лучше знать, что использовать, а что нет. (У меня есть фрагмент кода для доступа к группам битов внутри int; с битовыми полями было бы намного проще :-|)
В Википедии есть информация о недостатках битовых полей :
Bit members in structures as presented above have potential practical drawbacks. First, the ordering of bits in memory is CPU dependent and memory padding rules can vary between compilers. In addition, less well-optimized compilers sometimes generate poor quality code for reading and writing bit members and there are potentially thread safety issues relating to bit fields because most machines cannot manipulate arbitrary sets of bits in memory, but must instead load and store whole words.
Я думаю, что все эти недостатки актуальны в среде OpenCL.
Типы OpenCL имеют (в соответствующей реализации) одинаковую структуру памяти, иначе копирование буферов с хоста на устройство не имело бы смысла. Точка взята за порядок битов. В остальном (потокобезопасность, качество компиляции) ничем не отличается от процессоров. Я мог бы вставить свой код для битовых полей, упакованных в целые числа: это крайне неэлегантно.
Предположительно, порядок следования байтов влияет только на массивы длинных чисел и т.д.? Если мы храним/отправляем как массив беззнаковых символов, то гарантируется порядок байтов и порядок битов внутри байтов?
Я работаю над синтаксическим анализом сетевого потока данных, мне интересно, есть ли способ сопоставить поток данных непосредственно со структурой данных.
Например, я хочу определить структуру данных для протокола RTP следующим образом.
И используя это таким образом.
Но поскольку компилятор C ++ будет вставлять отступы между членами, есть ли способ контролировать это так, чтобы между членами (включая элементы битового поля) не добавлялось никаких отступов?
Этот вопрос НЕ является дубликатом того, как избавиться от байтов заполнения между элементами данных структуры, потому что в моем примере могут быть битовые поля.
Я считаю, что нет стандартного способа сделать это, но у вашего компилятора может быть какое-то расширение (например, оно есть в VS), которое позволяет вам управлять заполнением. Надеюсь, кто-то докажет, что я ошибаюсь.
Битовые поля в сумме кратны 8 (неудивительно). Если вы дадите указание компилятору упаковать класс / структуру, все будет в порядке.
Я не думаю, что между битовыми полями добавляется заполнение, не так ли? В противном случае это могло бы победить точку битовых полей.
@JonathanPotter, если сумма битовых полей не кратна 8, компилятор не будет разрезать последующие целые числа и т. Д. По границам байтов, поэтому он будет заполнять.
Если вы можете использовать C ++ 11, вы можете воспользоваться элементом управления выравниванием, реализованным с помощью alignof оператора.
Если вы выбрали вариант GCC, атрибут необходимо разместить в конце структуры:
Если вы выбрали вариант MSVC, прагма должна быть размещена перед структурой:
Если ваш код должен быть скомпилирован в обоих случаях, единственный способ (без alignof оператора C ++ 11 ) - это условная компиляция:
Чтобы избежать вставки заполненных байтов, вы можете использовать
У меня это сработало.
Также рассмотрите варианты компиляции для выравнивания элементов конструкции.
Но имейте в виду, что это повлияет на весь ваш проект.
Тем не менее, это расширение компилятора, зависящее от платформы (даже если gcc и VS используют для него один и тот же синтаксис, не знаю). И опция командной строки определенно только VS.
Если у вас нет требования, чтобы этот код «работал» на произвольных машинах - например, машинах, у которых есть ограничения относительно того, на каких границах байтов int находится объект (обычно это 4-байтовая граница), затем используйте
должен работать, и он поддерживается в GCC, а также в компиляторах Microsoft и Microsoft plug in совместимых (таких как компилятор Intel).
Но обратите внимание, что невыровненный доступ поддерживается не на всех процессорах, поэтому запуск блока с 16-битным значением, за которым следует 32-битное int , может вызвать проблемы.
Я бы также использовал целое число размера для порядкового номера, чтобы гарантировать, что оно 32-битное в КАЖДОМ компиляторе, а не внезапно 16 или 64-битное.
Также обратите внимание, что в стандарте C ++ ничего не говорится о порядке, в котором биты хранятся в битовом поле, или, если на то пошло, есть ли между ними промежутки или нет. Хотя вы можете ожидать, что битовые поля будут храниться в соответствии с порядком байтов (машины с обратным порядком байтов сначала начинают с младших битов, машины с прямым порядком байтов сначала начинают с битов самого высокого порядка), в стандарте ничего не говорится в этом отношении.
Я не понимаю, почему мы используем int , но не short или что-то меньшее, чем int .
- Насколько я понимаю, в памяти занят только 1 бит, а не все значение unsigned int. Это правильно?
Now I am curious, [are flags] the only way bit-fields are used practically?
Нет, флаги - не единственный способ использования битовых полей. Их также можно использовать для хранения значений размером более одного бита, хотя флаги встречаются чаще. Например:
Do we need to use bit fields to save space?
Битовые поля действительно экономят место. Они также позволяют упростить установку значений, не выровненных по байтам. Вместо битового сдвига и использования побитовых операций мы можем использовать тот же синтаксис, что и установка полей в файле struct . Это улучшает читаемость. С битовым полем вы могли бы написать
Однако для хранения нескольких независимых значений в пространстве одного int (или другого типа) без битовых полей вам нужно будет написать что-то вроде:
Улучшенная читаемость битовых полей, возможно, более важна, чем экономия нескольких байтов здесь и там.
Why do we use int? How much space is occupied?
Занято целое пространство int . Мы используем, int потому что во многих случаях это не имеет значения. Если для одного значения вы используете 4 байта вместо 1 или 2, ваш пользователь, вероятно, этого не заметит. Для некоторых платформ, размер имеет значение более, и вы можете использовать другие типы данных , которые занимают меньше места ( char , short , uint8_t , и т.д.).
As I understand only 1 bit is occupied in memory, but not the whole unsigned int value. Is it correct?
Нет, это не так. Все unsigned int будет существовать, даже если вы используете только 8 его бит.
@Willwsharp Я буду рад добавить больше деталей; можешь сказать мне, какую часть этого ты пытаешься понять?
Думаю, теперь я понимаю, что «делать это вручную» - значит пытаться извлечь данные без резервной структуры, поэтому вам придется выполнять манипуляции с битами самостоятельно. Верный?
@EricFinn Если пространство целого int занято , почему sizeof(directions) 4 байта (должно быть 8 байтов после того, что вы указали)? В моей машине sizeof(int) это 4 байта
Основная причина - уменьшить используемый размер. Например, если вы пишете:
Вы будете использовать не менее 3 * sizeof(unsigned int) или 12 байтов для представления 3 маленьких флагов, для которых потребуется всего 3 бита.
Итак, если вы напишете:
Это занимает то же пространство, что и один unsigned int , поэтому 4 байта. Вы можете добавить в структуру 32 однобитных поля, прежде чем ей понадобится больше места.
Это своего рода эквивалент классического битового поля для домашнего пивоварения:
Но синтаксис битового поля чище, сравните:
и, очевидно, меньше подвержены ошибкам.
Следующий вопрос: когда нужно экономить место? Больше никогда. Если вы не находитесь в очень ограниченном окружении, избегайте битовых полей.
В качестве дополнения: он ведет себя больше как логическое значение: вы можете писать flags.is_keyword == flags.is_extern (сравнивать с ((flags & IS_KEYWORD) == 0) == ((flags & IS_EXTERN) == 0) ). С другой стороны, с традиционными битовыми полями вы можете проверить несколько значений с помощью одного оператора сравнения: (flags & (IS_KEYWORD IS_EXTERN)) == IS_KEYWORD (это означает, IS_KEYWORD но не IS_EXTERN )
@Yawar Если структура непрозрачна, вы можете обрабатывать ее только с помощью указателя. В C тип указателя не имеет значения, а в C ++ он влияет только на изменение имени. Таким образом, короткий ответ - «Нет», длинный ответ - «Если он непрозрачен, он никогда не был частью ABI».
@rioki я имел в виду _Bool как тип в битовом поле: _Bool is_xyz : 1; . Может повлиять на статический анализ (в моем случае MISRA) или поведение _Generic.
Еще одно место, где часто встречаются битовые поля, - это аппаратные регистры. Если у вас есть 32-битный регистр, в котором каждый бит имеет определенное значение, вы можете элегантно описать его битовым полем.
Такое битовое поле по своей сути зависит от платформы. Переносимость в этом случае не имеет значения.
Переносимость касается не только оборудования. Различные компиляторы для одной и той же архитектуры могут не соглашаться по порядку битовых полей.
Хотя предостережение справедливо, я редко видел встроенные проекты, в которых использовалось несколько компиляторов. Обычно вы придерживаетесь одного для проекта.
Если аппаратный регистр находится в IP-блоке, а драйвер IP-блока используется в нескольких архитектурах, у вас будет несколько компиляторов. Т.е. это не такая уж редкость, как можно было бы подумать.
Мы используем битовые поля в основном (хотя и не исключительно) для структур флагов - байтов или слов (или, возможно, более крупных вещей), в которые мы пытаемся упаковать крошечные (часто с двумя состояниями) фрагменты (часто связанной) информации.
С другой стороны, мы не используем битовые поля для логических значений в других случаях, таких как обычное управление потоком программы, из-за того, как обычно работают компьютерные архитектуры. Наиболее распространенные процессоры не любят извлекать один бит из памяти - им нравятся байты или целые числа. Они также не любят обрабатывать биты - их инструкции часто работают с более крупными вещами, такими как целые числа, слова, адреса памяти и т. Д.
Итак, когда вы пытаетесь работать с битами, вы или компилятор (в зависимости от того, на каком языке вы пишете) должны выписать дополнительные операции, которые выполняют битовую маскировку и удаляют структуру всего, кроме информации, которую вы действительно хотите работать на. Если «упаковка» информации не дает никаких преимуществ (а в большинстве случаев их нет), то использование битовых полей для логических значений приведет только к накладным расходам и шуму в вашем коде.
Читайте также: