Следует ли использовать именованные адресные пространства там, где они доступны? - PullRequest
0 голосов
/ 14 мая 2018

Есть некоторые архитектуры, которые имеют несколько адресных пространств, известные примеры - истинные гарвардские, но, например, OpenCL также имеет это свойство.

Компиляторы C могут предоставить некоторые решения для этого, одним из них является Именованный адресПробелы, поддерживающие специальные квалификаторы указателя для обозначения адресного пространства указателя, но могут также присутствовать другие решения.

Я не знал о них, и в архитектуре, которую я использую (8-битный AVR), есть другое решение для этой проблемы, специальноеized макросы (pgmspace.h) для работы с данными в ПЗУ.Но нет никаких проверок типов на них, и они (на мой взгляд) делают код некрасивым, поэтому мне кажется, что использование именованных адресных пространств является превосходным и, возможно, даже более портативным способом решения проблемы (переносимым в том, чтоможно легко перенести такое программное обеспечение на цель, имеющую одно адресное пространство, предоставив пустые определения для классификаторов адресного пространства).

Однако в предыдущем вопросе, в котором я узнал об их доступности, решения, предлагающие использоватьИменованные адресные пространства получили серьезное отрицание, здесь: Как сделать два в противном случае идентичных типа указателей несовместимыми

Downvoters не предоставили никакого объяснения, и я тоже не нашел ничего, для меня это выглядит какИменованные адресные пространства - хороший и совершенно функциональный способ решения проблемы.

Кто-нибудь может дать объяснение?Почему именованные адресные пространства, вероятно, не следует использовать?(предпочитая любой другой метод, доступный на цели, имеющей несколько различных адресных пространств)

Ответы [ 2 ]

0 голосов
/ 25 мая 2018

Другой подход - украсть технику, используемую в таких вещах, как ядро ​​Linux, и такие инструменты, как smatch.

Linux имеет определение как

# define __user

, что означает, что код может произносить такие вещи, как int foo (const __user char * p). Компилятор игнорирует __user, но затем используются такие инструменты, как smatch, чтобы убедиться, что указатели не случайно попадают между пространствами имен.

0 голосов
/ 14 мая 2018

Проблема с ними очевидна: они работают только на компиляторе gcc.

А в отрасли встроенных систем существует множество различных компиляторов, каждый из которых предлагает свой уникальный, непереносимый способ сделать это. Иногда это хорошо (большинство встроенных проектов никогда не переносятся на разные компиляторы), но с общей точки зрения это не так.

(Та же проблема существует и с расширенными адресами - если вы, например, используете 8 или 16-битный MCU с более чем 64-килобайтной адресуемой памятью. Компиляторы затем используют различные нестандартные расширения, такие как near и far .)

Одним из решений этих проблем является создание «обертки» вокруг поведения, специфичного для компилятора, путем создания уровня аппаратной абстракции (HAL), где вы указываете, что тип, используемый для хранения данных во флэш-памяти, равен flash_byte_t или некоторому другому затем из вашего HAL включите специфичный для компилятора заголовочный файл, содержащий фактическую typedef, такую ​​как typedef const __flash uint8_t flash_byte_t;. Например, приложение включает в себя «compiler.h», а это, в свою очередь, включает «gcc.h». Таким образом, вам нужно переписать только один маленький заголовочный файл при переключении компилятора.

Также, как выясняется, C позволяет const flash_byte_t очень хорошо, хотя это уже было typedef'd как const. В C есть специальное странное правило, гласящее, что вы можете добавлять в объявление столько раз, сколько захотите. Так что const const int x эквивалентно const int x. Это означает, что если пользователь получит дополнительную const-квалификацию, это нормально.


Обратите внимание, что это в основном AVR, являющееся здесь особым исключением из-за его странной гарвардской модели.

В противном случае, существует большинство отраслевых стандартов, используемых большинством компиляторов: все const квалифицированные переменные со статической продолжительностью хранения должны быть размещены во флэш-памяти. Конечно, стандарт C не дает никаких гарантий (это выходит за рамки стандарта), но большинство встроенных компиляторов ведут себя так.

...