Codavr (10.02.2019 15:02 - 15:44, просмотров: 35307) MBedderДолой империалистический интернационал!
-
- Возьми dsPIC33Cx "и делай с ним что хошь" - их ядро имеет команды операций с битовыми полями. Кстати, вроде в Кортексах М3 вроде тоже нечто подобное есть - MBedder(11.02.2019 15:09)
- Для операций с битовыми полями не нужны спец. инструкции процессора в общем случае... - fk0(11.02.2019 23:37)
- В общем случае нет, но когда спешишь, бывают полезны. - Крок(12.02.2019 10:40)
- Да для того, чтобы жевать сопли, вообще никакие инструкции не нужны - подумаешь, каких-то лишних 100500 тактов займет - у нас их теперь много, а уж гавнокодеров и подавно - MBedder(12.02.2019 10:36)
- A = A & B или A = A | ~B. Здесь нет 100500 тактов, на типичном RISC процессоре это вообще делается за одну (между регистрами) или три (1 - загрузка из памяти, 2 - операция, 3 - запись в память) операции. Есть ньюансы с атомарным доступом, но они fk0(117 знак., 12.02.2019 12:13)
- Да нахер твою запись в твою память - МК работают через SFR, в которые напиханы 100500 битовых полей, и если этими полями можно рулить АППАРАТНО - то сила в этом великая есть. А в память свою можешь писать чем угодно, хоть прокладками Always - MBedder(12.02.2019 12:53)
- Сколько тактов потребуется RISC процессору, чтобы узнать кол-во отличных от нуля разрядов в 32-битном регистре? - Хаос(12.02.2019 12:25,
)
- В общем случае проблема описана в "Алгоритмических трюках для программистов" Г. Уоррена. По ссылке (другой источник, но есть в онлайне) много деталей, практически же код выглядит так: fk0(1535 знак., 12.02.2019 12:52, ссылка)
- Пожалуй, все же тыкну "ими всех налево и направо". :) Хаос(924 знак., 12.02.2019 13:09, )
- Пожалуй, все же тыкну "ими всех налево и направо". :) Хаос(924 знак., 12.02.2019 13:09,
- В общем случае проблема описана в "Алгоритмических трюках для программистов" Г. Уоррена. По ссылке (другой источник, но есть в онлайне) много деталей, практически же код выглядит так: fk0(1535 знак., 12.02.2019 12:52, ссылка)
- Зря ты так. Не всем повезло как тебе быть сам себе хозяин и иметь высокомаржинальное устройство. Мне вот в массовке сказали PIC32 дешевле PIC24. И теперь приходится "говнокодить". Чтоб байт отправить в spi драйвер гармонии используется очередь, abivan(224 знак., 12.02.2019 11:03)
- Ах какой у него чудесный уарт , вот уже лет 10. - PlainUser(12.02.2019 11:49)
- По мне так очередь и мьютекс - не плохо. Как-то попробовал код I2C из MCC Microchip. Мой чип MCC не поддерживал, но код легко адаптировался. Nikolay_Po(509 знак., 12.02.2019 11:37)
- A = A & B или A = A | ~B. Здесь нет 100500 тактов, на типичном RISC процессоре это вообще делается за одну (между регистрами) или три (1 - загрузка из памяти, 2 - операция, 3 - запись в память) операции. Есть ньюансы с атомарным доступом, но они fk0(117 знак., 12.02.2019 12:13)
- Вот щаз все брошу и углублюсь в изучение поделий мелкочипа, затем перейду к штудированию свежих еррат, потом начну месяцами переписываться с ихней службой поддержки. Нет уж, наелся досыта. Одного раза хватило. - Codavr(11.02.2019 20:57)
- Это ты какой-то несвежий PIC зажевал. Я за больше чем 10 лет сделал на dsPIC/PIC24 ряд успешных и удачных проектов и ни разу не теребил саппорт - MBedder(11.02.2019 21:06)
- ПИК 18-й. Мне он приглянулся тем что имел наименьший по количеству ног корпус из всех контроллеров с CAN на борту среди всех производителей и к тому же у мелкочипа под него были примеры на SAE J1939. Я тогда приблуду для NMEA2000 мастерил. - Codavr(11.02.2019 21:13)
- Я с 8-битными PIC'ами серьезно никогда не работал - так, мелочевку всякую иногда делал. 16-битные dsPIC/PIC24 - это небо и земля по сравнению с их 8-битными - по удобству, изяществу, многообразии периферии и т.д. - MBedder(11.02.2019 21:18)
- 18-е 16/8 битные. Если склероз не врет, то это был 18F2580 - Codavr(11.02.2019 21:18 - 21:35)
- 8-битные. Это разрядность ALU, а не ширина трусов обкуренной разработчицы этого трэша - MBedder(11.02.2019 22:24)
- Ну они тогда их рекламировали именно как 16/8, типа 16 бит инструкция, 8 бит данных. причем с упором на инструкцию :) - Codavr(11.02.2019 22:27 - 22:30)
- чистые 8 бит, пох на размер инструкций. Кстати в те времена (2580) уже были at90can128 чего их не заюзали ?? - Aleksey_75(11.02.2019 22:32)
- Я же выше объяснил. - Codavr(11.02.2019 22:42)
- чистые 8 бит, пох на размер инструкций. Кстати в те времена (2580) уже были at90can128 чего их не заюзали ?? - Aleksey_75(11.02.2019 22:32)
- Ну они тогда их рекламировали именно как 16/8, типа 16 бит инструкция, 8 бит данных. причем с упором на инструкцию :) - Codavr(11.02.2019 22:27 - 22:30)
- pic18f2580/pic18f25K80 просто сказка, до сих пор пользую, нареканий ноль, кан как часики ) - Aleksey_75(11.02.2019 21:40)
- Мне нужен был режим listen only, и не допускалась потеря данных, а у них как раз про этот режим еррата. В исправлении предлагалось преинициализизировать CAN. Вот спасибочки, пока я его презапускаю теряю критически важные сообщения. Прочие косяки Codavr(397 знак., 11.02.2019 21:49 - 21:56)
- 8-битные. Это разрядность ALU, а не ширина трусов обкуренной разработчицы этого трэша - MBedder(11.02.2019 22:24)
- 18-е 16/8 битные. Если склероз не врет, то это был 18F2580 - Codavr(11.02.2019 21:18 - 21:35)
- Я с 8-битными PIC'ами серьезно никогда не работал - так, мелочевку всякую иногда делал. 16-битные dsPIC/PIC24 - это небо и земля по сравнению с их 8-битными - по удобству, изяществу, многообразии периферии и т.д. - MBedder(11.02.2019 21:18)
- ПИК 18-й. Мне он приглянулся тем что имел наименьший по количеству ног корпус из всех контроллеров с CAN на борту среди всех производителей и к тому же у мелкочипа под него были примеры на SAE J1939. Я тогда приблуду для NMEA2000 мастерил. - Codavr(11.02.2019 21:13)
- Это ты какой-то несвежий PIC зажевал. Я за больше чем 10 лет сделал на dsPIC/PIC24 ряд успешных и удачных проектов и ни разу не теребил саппорт - MBedder(11.02.2019 21:06)
- Если бы Codavr бросил свои АВР и перешёл на кортекс, ему бы и битфилды не понадобились, памяти бы и так хватало. - йцукен(11.02.2019 15:46, ссылка)
- Вопрос - а насколько компиляторы умеют эффективно это использовать? Или все на intrinsic надо писать? - Evgeny_CD(11.02.2019 21:22)
- Вот код из "уточнённого вопроса", скомпилированный ИАРом (medium optimization). Видно, что ИАР использует UBFX и BFI. йцукен(1690 знак., 11.02.2019 23:02)
- Спасибо! - Evgeny_CD(12.02.2019 01:06)
- Битовый доступ к памяти - это аппаратная фишка кортеха, которая банально мапится на адресное пространство. Работа, правда, сильно быстрее не становится, процессор все равно делает read-modify-write, хоть и непрозрачно для погромиста. lloyd(348 знак., 11.02.2019 21:29)
- Вот код из "уточнённого вопроса", скомпилированный ИАРом (medium optimization). Видно, что ИАР использует UBFX и BFI. йцукен(1690 знак., 11.02.2019 23:02)
- Ух ты, какой шустрый! А если надо упаковывать битовые структуры для экономии спутникового канала связи - тогда на что переходить? А в Inmarsat биты на вес золота в буквальном смысле. - Evgeny_CD(11.02.2019 21:12)
- Зачем мне на него переходить? Я его пользую там где он нужен (лет 5 уже), где хватает тиньки я ставлю тиньку. Ну давай щаз начнем во все приблуды вкорячивать андроид шоб "и так хватило". Не стану я гвозди забивать отбойным молотком. - Codavr(11.02.2019 20:50 - 21:07)
- Вопрос - а насколько компиляторы умеют эффективно это использовать? Или все на intrinsic надо писать? - Evgeny_CD(11.02.2019 21:22)
- Для операций с битовыми полями не нужны спец. инструкции процессора в общем случае... - fk0(11.02.2019 23:37)
- Мне понравилось, как делает этот чувак Sergey_N(69 знак., 11.02.2019 12:56)
- Терпеть не могу, когда типы объявляют макросами, совершенно уродская, хоть и распространённая практика. - =AlexD=(11.02.2019 14:18)
- В богомерзком ГЦЦ mse homjak(336 знак., 11.02.2019 11:00)
- Объясни, на кой хер тебе понадобилась data? Что мешает адресовать сам R0container. Говнокодом попахивает. - fk0(11.02.2019 23:39)
- Патамушта я готовлю массив из генерённых Р0контейнеров. Ну, не только их. Массив из структур с интами. Когда я формирую контейнер, я заполняю поля всяко-разными вычислениями. А в массив кладу как "Р0контейнер.дата", т.е. ИНТ. Я, потом, и работаю с mse homjak(18 знак., 12.02.2019 00:00)
- Да это понятно, что ты с ними как с интами работаешь. Но почему не сразу как с флоатами, а? Откуда ты знаешь, что там в этих интах на какой позиции лежит, а? Вот в этом проблема. Там не только ендианность, там ещё разные компиляторы по-разному fk0(39 знак., 12.02.2019 00:02)
- Ну, сами ГЦЦшники не стесняются имана так формировать битовые поля для настройки процессора. Чо мне бояться? Я чо, рыжий? Или крайний? - mse homjak(12.02.2019 00:06)
- И работает оно только в этой версии GCC и только на этом процессоре. А ты небось начнёшь через сеть сейчас пересылать. - fk0(12.02.2019 00:14)
- Не, не начну. Это умрёт вместе с этим процессором. Я переползаю на новую архитектуру раз в 10-15 лет. - mse homjak(12.02.2019 00:19)
- До того как оно умрёт, существует 100500 причин, почему код может быть собран на другой архитектуре. Начиная от юнит-тестов. - fk0(12.02.2019 01:14)
- Нет таких причин. - mse homjak(12.02.2019 09:47)
- До того как оно умрёт, существует 100500 причин, почему код может быть собран на другой архитектуре. Начиная от юнит-тестов. - fk0(12.02.2019 01:14)
- Не, не начну. Это умрёт вместе с этим процессором. Я переползаю на новую архитектуру раз в 10-15 лет. - mse homjak(12.02.2019 00:19)
- И работает оно только в этой версии GCC и только на этом процессоре. А ты небось начнёшь через сеть сейчас пересылать. - fk0(12.02.2019 00:14)
- Ну, сами ГЦЦшники не стесняются имана так формировать битовые поля для настройки процессора. Чо мне бояться? Я чо, рыжий? Или крайний? - mse homjak(12.02.2019 00:06)
- Да это понятно, что ты с ними как с интами работаешь. Но почему не сразу как с флоатами, а? Откуда ты знаешь, что там в этих интах на какой позиции лежит, а? Вот в этом проблема. Там не только ендианность, там ещё разные компиляторы по-разному fk0(39 знак., 12.02.2019 00:02)
- Да ладно. Вот надо, например, все поля обнулить быстро. - s_h_e(11.02.2019 23:52)
- memset(R0container, 0, sizeof(R0container)). Ещё примеры? Скопировать? Я уже писал: R0container a = b... А ему эта data нужна чтоб своими грязными руками туда лазать и писать говнокод который говном полным ендианности обмажет всё вокруг. - fk0(11.02.2019 23:59)
- С memset оно сразу делается нечитаемо. Если нужно обфусцировать код - ок. - s_h_e(12.02.2019 00:15)
- А у тебя просто говнокод. В юнион data меньшего размера, случайно, чем битовое поле -- что-то не инициализируется и ты этого никогда не узнаешь. - fk0(12.02.2019 01:13)
- Такое в любом юнионе может быть. Не использовать юнионы? Не нужно тогда на сишечке писать, надо брать другой язык. - s_h_e(12.02.2019 09:50)
- Юнионы служат не для замены reinterpet_cast (в конечном счёте, у тебя для memcpy и memset), а для возможности размещения в одной области памяти одного из вариантов типа данных, ну и для ручного (не)вызова конструкторов. Скоро введут сплошной fk0(81 знак., 12.02.2019 12:17)
- Я бы не драматизировал. Юнион - вполне удобный способ для грязных хаков, очевиднее, чем через указатель на байт. Боисся и себе не доверяешь - напиши static_assert. - VLLV(12.02.2019 12:28)
- Чего там грязного? Как иначе пропихнуть слово 32разряда через 8разрядную внешнюю шину? Особенно, если запись определённого байта фиксирует 32р слово в приёмнике. - mse homjak(12.02.2019 13:49 - 13:54)
- Сейчас буденновец или назовет волшебные слова "сериализация-десериализация", ну или шашкой покрошит. - VLLV(12.02.2019 14:51)
- Чего там грязного? Как иначе пропихнуть слово 32разряда через 8разрядную внешнюю шину? Особенно, если запись определённого байта фиксирует 32р слово в приёмнике. - mse homjak(12.02.2019 13:49 - 13:54)
- Я бы не драматизировал. Юнион - вполне удобный способ для грязных хаков, очевиднее, чем через указатель на байт. Боисся и себе не доверяешь - напиши static_assert. - VLLV(12.02.2019 12:28)
- Юнионы служат не для замены reinterpet_cast (в конечном счёте, у тебя для memcpy и memset), а для возможности размещения в одной области памяти одного из вариантов типа данных, ну и для ручного (не)вызова конструкторов. Скоро введут сплошной fk0(81 знак., 12.02.2019 12:17)
- Такое в любом юнионе может быть. Не использовать юнионы? Не нужно тогда на сишечке писать, надо брать другой язык. - s_h_e(12.02.2019 09:50)
- А у тебя просто говнокод. В юнион data меньшего размера, случайно, чем битовое поле -- что-то не инициализируется и ты этого никогда не узнаешь. - fk0(12.02.2019 01:13)
- С memset оно сразу делается нечитаемо. Если нужно обфусцировать код - ок. - s_h_e(12.02.2019 00:15)
- memset(R0container, 0, sizeof(R0container)). Ещё примеры? Скопировать? Я уже писал: R0container a = b... А ему эта data нужна чтоб своими грязными руками туда лазать и писать говнокод который говном полным ендианности обмажет всё вокруг. - fk0(11.02.2019 23:59)
- Патамушта я готовлю массив из генерённых Р0контейнеров. Ну, не только их. Массив из структур с интами. Когда я формирую контейнер, я заполняю поля всяко-разными вычислениями. А в массив кладу как "Р0контейнер.дата", т.е. ИНТ. Я, потом, и работаю с mse homjak(18 знак., 12.02.2019 00:00)
- Объясни, на кой хер тебе понадобилась data? Что мешает адресовать сам R0container. Говнокодом попахивает. - fk0(11.02.2019 23:39)
- Плюнь и забудь (ну если не приперло так что больше никак).Сам себя проклянешь через пару лет вернувшись к своим-же исходникам.Лучше взять uint и просто работать с его битами. - PlainUser(11.02.2019 09:23)
- Оказалось всё не так просто. Для битовых полей есть исключение. ЫЫукпу(455 знак., 11.02.2019 00:21)
- Это из стандарта вынуто или народ уже в процессе юзания компилеров находит такие веселухи? - Codavr(11.02.2019 09:17)
- Это из INCITS/ISO/IEC 9899-2011[2012], раздел 6.7.2 Type specifiers, пункт 5. ЫЫукпу(546 знак., 11.02.2019 11:40 - 12:14)
- Спасибо. - Codavr(11.02.2019 11:44)
- Это из INCITS/ISO/IEC 9899-2011[2012], раздел 6.7.2 Type specifiers, пункт 5. ЫЫукпу(546 знак., 11.02.2019 11:40 - 12:14)
- А еще в MS Visual Studio сдвиг unsigned long long вправо на 64 бита дает в результате всякую х.йню. - Хаос(11.02.2019 08:18, )
- Чем мотивируют? - Codavr(11.02.2019 09:45)
- Ничем не мотивируют. Вот цитата из хелпа к MS VS: Хаос(265 знак., 11.02.2019 11:14, )
- Могли бы и на стандарт сослаться, в 6.5.7 Bitwise shift operators (С) и 5.8 Shift operators (С++) именно так и сказано. А ещё сдвиг вправо implementation-defined для знаковых если значение отрицательно. - ЫЫукпу(11.02.2019 13:22)
- Я сейчас пишу в основном на Verilog'e, поэтому стандарта С++ под рукой просто нет. А хелп, вот он, рядом. :) - Хаос(11.02.2019 14:31, )
- Во во, еще немного и стандарт можно будет заменить одной фразой implementation-defined. - Codavr(11.02.2019 14:18)
- Я сейчас пишу в основном на Verilog'e, поэтому стандарта С++ под рукой просто нет. А хелп, вот он, рядом. :) - Хаос(11.02.2019 14:31,
- Звыняйте хлопцы, так получилось :( - Codavr(11.02.2019 11:57)
- Есть большое подозрение, что это особенность процессоров Intel, а не компилятора MS VS. Операция сдвига слишком проста и там нет места для творчества криворукого программиста. - Хаос(11.02.2019 12:18, )
- Скорее всего. Если бы дело было в софте, то поправили бы моментально. - Codavr(11.02.2019 12:29)
- Компилятор IAR не сдвигает влево больше чем на 32 бита и никто его не рвется править. - VLLV(11.02.2019 12:32)
- Вопрос не в "больше чем 32 бита", а вопрос в "равно 32-м битам". Хаос(404 знак., 11.02.2019 13:04, )
- Ограничение 32/64 (длина машинного слова ARM/Intel) в общем то логично, или компилятор, или пользователь (неважно кто) должен проверять аргумент, от того, кто это делает, замедление алгоритма не зависит. Или? - VLLV(11.02.2019 13:18)
- Как бы привычно и логично, что при сдвиге беззнакового вправо в старший задвигается нолик. Логично предполагать что скока ни сдвигай он туда и будет писаться. Если бы не предупредили, то у меня и мысли бы не возникло проверять так ли это. - Codavr(11.02.2019 14:09 - 14:14)
- У меня тоже "и мысли не возникало проверять так ли это", пока не стал делить полиномы 4095-ой степени над полем Галуа друг на друга. Вот тут то все и началось.. Пол дня искал причину, почему декодер БЧХ не хочет декодировать пакеты. :) - Хаос(11.02.2019 14:29, )
- Могу себе представить как ты матерился, когда разобрался :))) - Codavr(11.02.2019 14:36)
- Аццки!!! - Хаос(11.02.2019 14:38, )
- Аццки!!! - Хаос(11.02.2019 14:38,
- Могу себе представить как ты матерился, когда разобрался :))) - Codavr(11.02.2019 14:36)
- У меня тоже "и мысли не возникало проверять так ли это", пока не стал делить полиномы 4095-ой степени над полем Галуа друг на друга. Вот тут то все и началось.. Пол дня искал причину, почему декодер БЧХ не хочет декодировать пакеты. :) - Хаос(11.02.2019 14:29,
- Ну, например, в сигнальных процессорах ADI это никому не нужно делать. Результат сдвига на ширину машинного слова всегда нулевой, так зачем тогда тратить время на эту проверку? - Хаос(11.02.2019 13:23, )
- Как бы привычно и логично, что при сдвиге беззнакового вправо в старший задвигается нолик. Логично предполагать что скока ни сдвигай он туда и будет писаться. Если бы не предупредили, то у меня и мысли бы не возникло проверять так ли это. - Codavr(11.02.2019 14:09 - 14:14)
- Ограничение 32/64 (длина машинного слова ARM/Intel) в общем то логично, или компилятор, или пользователь (неважно кто) должен проверять аргумент, от того, кто это делает, замедление алгоритма не зависит. Или? - VLLV(11.02.2019 13:18)
- Вопрос не в "больше чем 32 бита", а вопрос в "равно 32-м битам". Хаос(404 знак., 11.02.2019 13:04,
- Компилятор IAR не сдвигает влево больше чем на 32 бита и никто его не рвется править. - VLLV(11.02.2019 12:32)
- Скорее всего. Если бы дело было в софте, то поправили бы моментально. - Codavr(11.02.2019 12:29)
- Есть большое подозрение, что это особенность процессоров Intel, а не компилятора MS VS. Операция сдвига слишком проста и там нет места для творчества криворукого программиста. - Хаос(11.02.2019 12:18,
- Могли бы и на стандарт сослаться, в 6.5.7 Bitwise shift operators (С) и 5.8 Shift operators (С++) именно так и сказано. А ещё сдвиг вправо implementation-defined для знаковых если значение отрицательно. - ЫЫукпу(11.02.2019 13:22)
- Ничем не мотивируют. Вот цитата из хелпа к MS VS: Хаос(265 знак., 11.02.2019 11:14,
- Чем мотивируют? - Codavr(11.02.2019 09:45)
- Это из стандарта вынуто или народ уже в процессе юзания компилеров находит такие веселухи? - Codavr(11.02.2019 09:17)
- Расширяются как минимум к (беззнаковому) инту, производятся операции, приводятся обратно. По-моему всё достаточно прозрачно. - fk0(10.02.2019 18:55)
- Да я собственно так и предполагал, но на всякий случай решил уточнить. - Codavr(10.02.2019 19:52)
- Всю половою жизнь пользуюсь. Хотя говорят - вредно. Только некоторых платформах обязательно использовать опцию упаковки структур, иначе начнется по настоящему. - IBAH(10.02.2019 18:09, ссылка)
- =)) я тут несколько лет назад наступил... отладил прогу на ПК, всё отлично...полез в DSP, охреневаю от поведения... разобрался, нумерация битов не с той стороны =))) а так, всё хорошо =)) - sav6622(11.02.2019 00:45)
- Не нужно смешивать всё в одну кучу. Упаковка нужна для другого и люди которые про неё так много говорят не понимают, что на самом деле она не нужна вовсе и у них руки из жопы (или мозги, не знаю). - fk0(10.02.2019 18:57)
- Уточню вопрос Codavr(322 знак., 10.02.2019 15:49 - 15:56)
- Повторяю ещё раз, для всех вычислений в C действует правило integer promotion - fk0(10.02.2019 18:59, ссылка)
- Я тоже загадку могу загадать: int a6:1; - fk0(10.02.2019 18:58)
- Допустимо. Но переполнение нужно отслеживать самому. - Скрипач(10.02.2019 15:50)
- Ради такого дела готов отслеживать. Так все же, при операциях оно к uint их переобразует? - Codavr(10.02.2019 15:53)
- Там вначале пытается в int, если не получается, всовывает в unsigned (если типы разные, ибо если одинаковые то и делать нечего): fk0(934 знак., 10.02.2019 19:03)
- Ну то есть все те же правила что и при неявном преобразовании типов? Спасибо. - Codavr(10.02.2019 19:27)
- Там вначале пытается в int, если не получается, всовывает в unsigned (если типы разные, ибо если одинаковые то и делать нечего): fk0(934 знак., 10.02.2019 19:03)
- Ради такого дела готов отслеживать. Так все же, при операциях оно к uint их переобразует? - Codavr(10.02.2019 15:53)
- Никаких извращений не помню. По крайней мере, накладывание маски и получение отдельных битов ведет себя как с любой другой переменной. Скрипач(328 знак., 10.02.2019 15:38 - 15:45)
- Производить битовые операции с битами битовых полей - это и есть извращение ;) - VLLV(11.02.2019 09:47)
- Я использую union, в котором комбинируют битовое поле и соответствующую ему по размеру беззнаковую переменную. evgeniy1294(256 знак., 10.02.2019 15:35)
- В этом никакого особого смыла нет вообще. Вместо smth1.val = smth2.val можно писать smth1 = smth2. Или memcpy. A других применений "альтернативного" представления -- нет. За залезание руками в val -- нужно руки отрубать, ибо говнокодище. - fk0(10.02.2019 19:07)
- Да ну. А если мне нужно задать значение всем ногам порта GPIO, причем одновременно? smth.val = mask, и все. Это просто пример. evgeniy1294(280 знак., 10.02.2019 21:40)
- Интересуют операции не с самими полями, а с их элементами. - Codavr(10.02.2019 15:42)
- До дома доберусь, скину листинг ассемблерный. Там прекрасно видна работа с элементами поля. - evgeniy1294(10.02.2019 15:48)
- В этом никакого особого смыла нет вообще. Вместо smth1.val = smth2.val можно писать smth1 = smth2. Или memcpy. A других применений "альтернативного" представления -- нет. За залезание руками в val -- нужно руки отрубать, ибо говнокодище. - fk0(10.02.2019 19:07)
- Возьми dsPIC33Cx "и делай с ним что хошь" - их ядро имеет команды операций с битовыми полями. Кстати, вроде в Кортексах М3 вроде тоже нечто подобное есть - MBedder(11.02.2019 15:09)