void const *argument, Что это? Опции

[ViKo]

В Keil CMSIS-RTOS RTX в параметрах задач указано:

Код

void job1 (void const *arg)

Что это, зачем? Писал, не задумываясь. Теперь хочу просветиться.

[Tarbal]

Вот документ.
На странице 5 есть информация о размещении констант в памяти.
http://netstorage.iar.com/SuppDB/Public/SU...memoryusage.pdf

Константы могут находиться в програмной памяти, оперативной памяти и внешней ЕПРОМ.

А здесь на странице 6 утверждают:
CONST Holds variables declared as const
.......
The CONST and CSTR should only be included in the XLINK file if there is an external
PROM in the system.

http://www.atmel.ca/Images/doc1079.pdf

Я уже не помню, а копаться лень. Для доступа ко внешней ЕПРОМ и для доступа ко внутренней ОЗУ используются одинаковые команды на ассемблере? Если разные, то это может объяснить многое в декларации функции с константным параметром.

Примечание: Я прекрасно знаю стандартное объяснение константного указателя как параметра функции, однако это всем известно. Разные способы адресации же это довольно неочевидное свойство.


Сообщение отредактировал Tarbal - Jan 14 2014, 13:38

[demiurg_spb]

Вот документ.

А теперь замените iar на avr-gcc...

[Tarbal]

А теперь замените iar на avr-gcc...

Простите, что вы имели ввиду?

[demiurg_spb]

Простите, что вы имели ввиду?

К тому что ваши ссылки, как собственно и измышления, исключительно для IAR. Но ведь есть и другие, более распространённые компиляторы, где const не гарантирует размещения данных в ПЗУ, что никак не противоречит стандарту. Об этом вам Сергей пытался намекнуть...

[Tarbal]

К тому что ваши ссылки, как собственно и измышления, исключительно для IAR. Но ведь есть и другие, более распространённые компиляторы, где const не гарантирует размещения данных в ПЗУ, что никак не противоречит стандарту. Об этом вам Сергей пытался намекнуть...

Я допускаю, что вы невнимательно читали то что я писал. Опять же ваши замечания о GCC мимо кассы, поскольку стартовый постинг был про Кейл.
О стандарте: Сколько я знаю компиляторов, у каждого есть свои особенности.

Если повесите свою параллельную ПЗУ на внешнюю шину как память данных - команды будут одинаковые. Но опять же, это не компилятор положит во флеш, а вы запихнете ПЗУ в адресное пространство ОЗУ, этакое чесание левого уха правой ногой. Обе эти памяти будут находиться в одном адресном пространстве.

Я это допускал, поэтому в предпоследнем постинге и написал:
"Я уже не помню, а копаться лень. Для доступа ко внешней ЕПРОМ и для доступа ко внутренней ОЗУ используются одинаковые команды на ассемблере? Если разные, то это может объяснить многое в декларации функции с константным параметром."

Обратите внимание на свой же документ:
Table comments:
(*) Each combination of processor option and memory model has a default memory type, and also one or more additionally available memory types. All constant and variable data which are put into the segments CCSTR, ECSTR, CSTR, CONST and CSTACK are always implicitly belonging to the default memory type.

Мне это ничего не говорит в контексте нашей дискуссии.

Дальше будете спорить?

Я не спорю, а ищу ответы.

[Сергей Борщ]

О стандарте: Сколько я знаю компиляторов, у каждого есть свои особенности.

Да, особенности есть. Но вам уже третью страницу объясняют, что к const это не относится. Требование стандарта к const одно - компилятор должен выдавать ошибку при попытке записи в такую переменную. Все. В остальном эта обычная переменная. Далее ход мыслей у всех компиляторописателей обычно одинаков: разместить переменные с похожими свойствами (обнуляемые, инициализируемые и т.д.) рядом, чтобы при старте (если нужно) подготовить каждую группу к работе одним махом в цикле. Отсюда группирование переменных в сегменты. Никаких требований на размещение во флеш/ОЗУ для const стандарт на компилятор не накладывает, но и не запрещает, если это не мешает выполнению остальных требований стандарта.
В случае разных адресных пространств (AVR) размещение констант в программной памяти (флеше) нарушает требование быть обычной переменной. Поэтому для размещения в других адресных пространствах (одно из которых - память кода) вводятся расширения - ключевые слова типа __flash, __eeprom, idata, xdata, far, huge и подобные. const совершенно перпендикулярен к этому.
Если же архитектура имеет только одно адресное пространство, то появляется возможность работать с константами прямо во флеш не нарушая требования стандарта без всяких дополнительных ключевых слов, сэкономив таким образом ОЗУ и немножко времени на копировании при старте. И тут уже все в руках программиста - использовать такую возможность или нет. const снова никоим образом на это не влияет. Я показывал, что изменением положения одной строки в скрипте линкера можно получить вариант с константами в ОЗУ и константами во флеше. Оба варианта будут работать. И оба не нарушают стандарт.

Мне это ничего не говорит в контексте нашей дискуссии.

default memory - ОЗУ. Содержимое всех указанных сегментов по умолчанию попадает в адресное прстранство ОЗУ. В том числе и сегмент CONST. Если это вам ни о чем не говорит - я не вижу смысла в дальнейшей дискуссии.