Могу ошибаться, но по-моему конкретно эти регистры 32-битные заложены в железе (а не просто отображены как 32-битные), по крайней мере обратное не указано явно.
регистры на железе могут быть и 8-, и 16-, и 32-, и, подозреваю, даже 64-битными
Абсолютно любыми, зависит от железа. И когда у меня, например, в контроллере были некоторые регистры 8-битные, а некоторые 16-битные, то я предпочитал 16-битные адресовать половинками, для уверенности (сей подход не рекламирую). Правда там все равно шина данных была 8-битная и регистры физически на ней стояли, так что своя кухня в некотором роде.
ISO/IEC TR 18037
Как интересно, ничего не знал об этом стандарте… Интересно, что в нем планируется внедрить, и как это увяжется с существующим развитием языка.
Вот и получается разной степени костыльные решения для того, чтобы сделать адреса 16-битных регистров правильно расположенными относительно базового адреса в ситуации, когда адреса регистра должны начинаться по границе 4 байт, а выравнивание 16-битного поля структуры по умолчанию — 2 байта
И это адище какое-то. Если вдруг вам понадобится 8-битный регистр среди кучи других регистров, то потребуется за ним гуськом расположить три таких же поля… И строго, очень строго следить за тем, чтобы кто-нибудь где-то в топе модуля не вписал pragma pack (2) например.
В этом смысле я считаю более консистентным подход с отдельным доступом к отдельным регистрам через указатели. Это правда требует больше работы с прямыми адресами, что само по себе не очень хорошо.
Что до переносимости, то сила C именно в том, что можно сделать непереносимые решения, там и когда это нужно
Поскольку я с этим языком не знаком в достаточной мере, то отчасти моя реакция вызвана банальным непониманием написанного. Но мне кажется также, что синтаксис у языка объективно вырвиглазный. Как и у шаблонизированного кода на плюсах с использованием стандартной библиотеки. Хотя с Растом все даже хуже. Не зная ничего о шаблонах С++, можно тем не менее по наитию понять, что же там написано. Глядя же на первый вариант растового кода (с генериком) я вообще не понимаю «что хотел сказать автор». Да, еще раз, дело в незнании языка, но кажется, что это положение дел весьма показательно.
Да, я понял, про то и пишу — воспринимать эту структуру как линейный массив (чего угодно, в том числе регистров) в общем случае нельзя. И хотя это очень распространенный прием (и от него трудно убежать — например я из-за лени использую STM HAL и пожинаю сопутствующие плоды), но мне он очень не нравится, поскольку опускает нас с уровня языка на уровень понимания его трансляции. Отсюда все эти сакральные знания про gcc aligned и ему подобное.
Добавлю, что дело не только в необходимости держать в голове выравнивание, нужно еще как-то защититься от случайных ошибок вида «вставили поле, не подумав про смещения». Я это встречал, и после такого вся красота использования структур для отображения регистров теряется.
Один мой вузовский препод говорил следующее: «Я знал старого одного программиста, он недавно умер, так вот он часто говорил, что Си скоро умрет. Но пока это не произошло — открываем редактор и пишем...»
Ну стоп, а в чем проблема-то? Ну оказались поля на самом деле по четыре байта, а не по два, кому от этого плохо? Аааа, кажется я догадываюсь… Наверное кто-то потом решил, что эта структура в памяти расположена сплошняком без промежутков между полями, и значит можно с ней работать как с массивом? Ну так ССЗБ, не?
Вообще пример конечно красивый, тут вам не откажешь, прямо руки тянутся… Но нет, слишком плохо я знаю плюсы. И я такой не один!
Я выше говорил о том, что находится промеж юнит-тестов и системных тестов — про интеграционные тесты. Фиксация на модульном тестировании, по личному наблюдению, развращает разработчика и полностью дистанцирует его от того, что потом будет твориться «в полях» (это помимо имманентно присущих такому виду тестирования проблем). Однако юнит-тестирование несколько более легко воспринимается мизантропами, проще формализуется и потому популярно в отрасли. А поскольку архитектура редко бывает идеальной (как и модульные спецификации), то мы потом и получаем ситуации, когда все отдельные модули прекрасны, крупные подсистемы никто не проверял, а все вместе работает как попало. Если же заставить себя подняться на уровень выше, до интеграционных тестов, то постепенно из-за деревьев проглядывается лес и становится понятно, чем будут жить те самые «операторы черных ящиков».
Возможно пример с датчиками всего лишь достаточно прост, и в его случае в принципе всего два уровня — юнит-тесты и системное тестирование. Я говорил про более общую ситуацию.
x86 — вполне себе полноценный байткод. И его поддерживают как в железе, так и в софте (тот же E2k). Только, как и следовало ожидать, поскольку он изначально под такую роль не затачивался — эту функцию он исполняет плохо.
Интересную позицию вы заняли. Ну, тут я прямо даже и возразить ничего не могу — по такому принципу можно утверждать почти что угодно.
А внутри, где-то в недрах, скрытых от глаз, да, там движуха, разные интересные ирхитектуры. nVidia, МЦСТ
Ну, я бы сказал, что эта движуха пока что мало производит помимо самой движухи.
«Благодаря» тому, что мы нормального, общего для достаточно большого процента программ, байткода так и не получили — все разработки ведутся «за закрытыми дверьми», в частных компаниях
А должны вестись где? В public schools и центрах взаимопомощи?
И, возвращаясь к основной нити, поскольку сделать ну совсем хороший байткод «на века» пока что маловероятно, то если бы вдруг подобный байткод ввел бы какой-нибудь регулятор, то новые процессорные технологии появлялись бы с большим скрипом.
НПЦАП вздохнул и вытер пот со лба, увидев себя в списке "непопаданцев". Даже и странно — такие ведь территории пропадают, в элитной части Москвы, на юго-западе...
И это — всем удалось с первого раза прочитать этот вот список справа вверху? Там, где "центр коллективного пользования сетевыми магистрами в инкубаторе диверсификации". Прямо аж убить хочется.
Для информации — сообщение выше разумеется не о том, что юнит-тесты не нужны. Оно о том, что не вполне ясен критерий — почему условному производителю датчиков очень нужны юнит-тесты, но про другие виды тестирования и их эффективность нет ни слова.
Может просто нужны нормальные интеграционные тесты? А то я вот систематически наблюдал (как у коллег, так и у сторонних организаций) довольно расслабленное отношение к тестированию полного комплекса "в полях" при постоянной демагогии на тему "смотрите, как у нас хорошо покрыт этот вот наш модуль". Последствия некоторых таких ситуаций разбираются иногда по десять лет (!), уже после окончания продажи комплекса.
Ну вы знаете… Если у вас отличная архитектура и "чистый код", то что вы будете проверять юнит-тестами? Там и интеграционные тесты не нужны… Теоретически...
Не неплохо, а необходимо. Либо можно просто отказаться от использования структур для доступа к группам регистров (но здесь есть свои минусы).
Могу ошибаться, но по-моему конкретно эти регистры 32-битные заложены в железе (а не просто отображены как 32-битные), по крайней мере обратное не указано явно.
Абсолютно любыми, зависит от железа. И когда у меня, например, в контроллере были некоторые регистры 8-битные, а некоторые 16-битные, то я предпочитал 16-битные адресовать половинками, для уверенности (сей подход не рекламирую). Правда там все равно шина данных была 8-битная и регистры физически на ней стояли, так что своя кухня в некотором роде.
Как интересно, ничего не знал об этом стандарте… Интересно, что в нем планируется внедрить, и как это увяжется с существующим развитием языка.
И это адище какое-то. Если вдруг вам понадобится 8-битный регистр среди кучи других регистров, то потребуется за ним гуськом расположить три таких же поля… И строго, очень строго следить за тем, чтобы кто-нибудь где-то в топе модуля не вписал pragma pack (2) например.
В этом смысле я считаю более консистентным подход с отдельным доступом к отдельным регистрам через указатели. Это правда требует больше работы с прямыми адресами, что само по себе не очень хорошо.
С этим не спорю.
Впрочем и это не снимает полностью вопрос переносимости.
Добавлю, что дело не только в необходимости держать в голове выравнивание, нужно еще как-то защититься от случайных ошибок вида «вставили поле, не подумав про смещения». Я это встречал, и после такого вся красота использования структур для отображения регистров теряется.
Что, внезапно, еще более общО и переносимо.
Вообще пример конечно красивый, тут вам не откажешь, прямо руки тянутся… Но нет, слишком плохо я знаю плюсы. И я такой не один!
Возможно пример с датчиками всего лишь достаточно прост, и в его случае в принципе всего два уровня — юнит-тесты и системное тестирование. Я говорил про более общую ситуацию.
UPD: Да, где были мои глаза — есть!
Интересную позицию вы заняли. Ну, тут я прямо даже и возразить ничего не могу — по такому принципу можно утверждать почти что угодно.
Ну, я бы сказал, что эта движуха пока что мало производит помимо самой движухи.
А должны вестись где? В public schools и центрах взаимопомощи?
И, возвращаясь к основной нити, поскольку сделать ну совсем хороший байткод «на века» пока что маловероятно, то если бы вдруг подобный байткод ввел бы какой-нибудь регулятор, то новые процессорные технологии появлялись бы с большим скрипом.
НПЦАП вздохнул и вытер пот со лба, увидев себя в списке "непопаданцев". Даже и странно — такие ведь территории пропадают, в элитной части Москвы, на юго-западе...
И это — всем удалось с первого раза прочитать этот вот список справа вверху? Там, где "центр коллективного пользования сетевыми магистрами в инкубаторе диверсификации". Прямо аж убить хочется.
Для информации — сообщение выше разумеется не о том, что юнит-тесты не нужны. Оно о том, что не вполне ясен критерий — почему условному производителю датчиков очень нужны юнит-тесты, но про другие виды тестирования и их эффективность нет ни слова.
На самом деле было бы интересно послушать ваши критерии разумности покрытия.
Может просто нужны нормальные интеграционные тесты? А то я вот систематически наблюдал (как у коллег, так и у сторонних организаций) довольно расслабленное отношение к тестированию полного комплекса "в полях" при постоянной демагогии на тему "смотрите, как у нас хорошо покрыт этот вот наш модуль". Последствия некоторых таких ситуаций разбираются иногда по десять лет (!), уже после окончания продажи комплекса.
Ну вы знаете… Если у вас отличная архитектура и "чистый код", то что вы будете проверять юнит-тестами? Там и интеграционные тесты не нужны… Теоретически...
Вот тут я не понял. Как смена языка (с Си на Раст например) спасет вас от грубых ошибок производителя в msp/bsp?