[juvf 10]

const нужен только чтобы уберечь программиста от самого себя, а никак не указание компилятору что и как размещать.

Да, согласен, но тоже не понятно почему тогда во всех случаях по разному.

 

Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать. Почему со статиком размещаются данные в др месте?

 

[DASM 0]

еще как указание. статик в теле фции размещается не на стеке, а в общей куче (не путать с кучей malloc). ну и плюс ограничение видимости одной единицей трансляции, если не в теле функции

 

А почему глобальный конст во флеше, локальный в озу?

? это самодеятельность компилера на его страх и риск.

 

собственно если точнее static тоже не говорит где размещать, но определяет время жизни. А уж размещение статик не на стеке - прросто вытекает из этого

[juvf 10]

еще как указание. статик в теле фции размещается не на стеке, а в общей куче (не путать с кучей malloc).

пф.... утверждение осталось, только дополню...

 

Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать, я имел в виду, указание не про кучу и стек, а указание про озу/флешь/еепром/внешнюю память и т.п.

 

это самодеятельность компилера на его страх и риск.

Согласен. В Си/С++ нет ни каких указаний на этот счет. Поэтому разработчики компиляторов на своё усмотрение делают реализацию. И поэтому, если важна область размещения, нужно компиллер контролировать и давать явные указания для размещения данных в нужную память.

 

А уж размещение статик не на стеке - прросто вытекает из этого

Ни чего не вытекает. Статик можно разместить в ОЗУ, а можно разместить в флеше. Конст можно разместить в озу, а можно в флеше. Компилятор волен сам - где и что размещать (в озу или во флешь), и его размещения не поддаются логике.

 

[Kabdim 0]

его размещения не поддаются логике.

Вполне поддаются и даже описаны в документации.

[DASM 0]

пф.... утверждение осталось, только дополню...

 

Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать, я имел в виду, указание не про кучу и стек, а указание про озу/флешь/еепром/внешнюю память и т.п.

 

Согласен. В Си/С++ нет ни каких указаний на этот счет. Поэтому разработчики компиляторов на своё усмотрение делают реализацию. И поэтому, если важна область размещения, нужно компиллер контролировать и давать явные указания для размещения данных в нужную память.

 

Ни чего не вытекает. Статик можно разместить в ОЗУ, а можно разместить в флеше. Конст можно разместить в озу, а можно в флеше. Компилятор волен сам - где и что размещать (в озу или во флешь), и его размещения не поддаются логике.

вытекает что не на стеке

[juvf 10]

вытекает что не на стеке

Причем тут стек? вопрос ТС не про стек, а про флешь vs озу.

[inventor 0]

наверное в следующих стандартах Си это

можно было бы учесть. с const ИМЕю ввиду..

что бы я еще сделал: ввел бы модификатор переменных global

для чего это: предположим в заголовочном файле

мы перечисляем все переменные, которые использует программа

в сегодняшних компиляторах для этого нужно писать в заголовке перменнные с словом extern

и определять сами эти переменные в *.c файле

если в заголовке описать переменные static - то все файлы, которые этот

заголовок включают будут плодить копии этих переменных, что совсем неправильно.

слово global помогло бы этого избежать

[ViKo 1]

Все, что описал топикстартер в начале темы, верно. Нужно понять (и простить). Не хотите, чтобы const переменная переписывалась из ПЗУ в ОЗУ - сделайте ее глобальной. Не нравятся глобальные переменные - сделайте ее статической внутри функции.

[demiurg_spb 0]

Что такое "основное адресное пространство"? В Си нет такого. В Си нет адресных пространств одно адресное пространство.

 

ps и в вашем авр нет основного адр. простр. В авр гарвардская архитектура, там есть адресное пространство памяти программ и адресное пространство памяти данных. Но к стандарту Си это отношения не имеет, т.к. Си абстрагирован от архитектуры.

Если Вы не в теме, то это не означает, что этого нет.

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gc...-Address-Spaces

 

В настоящий момент в GCC именно на этой почве случился ступор.

Разработчики avr-gcc не могут сделать так, чтобы по возможности константные данные автоматом ложились во флэш именно из-за того, что стандарт в настоящее время этого не разрешает.

 

Если интересно - скачайте стандарт c11.

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

Вообще-то в GCC в режиме С (без плюсов) уже года два как поддерживаются разные адресные пространства, в том числе и __flash. А вот в стандарте плюсов их нет, поэтому нет их и в плюсах AVG-GCC, поэтому там ступор, да. А еще - бывают контроллеры вообще без набортного флеша, там и код и константы - все в ОЗУ живет. И к чему все эти споры?

[demiurg_spb 0]

Я не про плюсы и говорю. И ступор не в плюсах.

const char __flash* const __flash names[] =
{
    "aaa",
    "bbb",
    "ccc"
};

не работает, а по всей здравой логике должно.

но народ упёрся и говорит, что нарушать стандарт не будем.

[inventor 0]

А еще - бывают контроллеры вообще без набортного флеша, там и код и константы - все в ОЗУ живет. И к чему все эти споры?

 

cc3200

но там все равно подрузамевается память только для чтения:

   45 190 bytes of readonly  code memory
6 072 bytes of readonly  data memory
 138 267 bytes of readwrite data memory

 

[juvf 10]

Согласно стандарту языка Си константные данные обязаны лечь в основное адресное пространство - всё.

Если Вы не в теме, то это не означает, что этого нет.

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gc...-Address-Spaces

 

В настоящий момент в GCC именно на этой почве случился ступор.

Разработчики avr-gcc не могут сделать так, чтобы по возможности константные данные автоматом ложились во флэш именно из-за того, что стандарт в настоящее время этого не разрешает.

 

Если интересно - скачайте стандарт c11.

И? Где в стандарте си основное адресное пространство?

Да даже в по вашей ссылке нет ни каких основных адресных пространств.

 

ps Это вы не в теме. При чем тут на какойт-о AVR Named Address Spaces? Вопрос не о авр, и даже не о gcc, а о Си.

 

pps

константные данные автоматом ложились во флэш именно из-за того, что стандарт в настоящее время этого не разрешает.

Навыдумывали. В стандарте Си нет даже слова flash. Если интересно - скачайте стандарт c11.

[demiurg_spb 0]

С вами бесполезно разговаривать - это Вы к AVR и flash привязались, не удосужившись прочесть представленные ссылки.

Всё о чём я написал напрямую относится к GCC в общем который, если Вы не в курсе, раньше всех коммерческих продуктов реализует новые возможности языка.

Мы используем в своих разработках GCC для множества архитектур, и по мере возможности делаем его и libc лучше. И мне очень странно слушать Ваши непонятные высказывания.

На этом с Вами разговор считаю законченным, пребывайте в осознании своего всезнания и далее.

As an extension, GNU C supports named address spaces as defined in the N1275 draft of ISO/IEC DTR 18037. Support for named address spaces in GCC will evolve as the draft technical report changes. Calling conventions for any target might also change. At present, only the AVR, SPU, M32C, RL78, and x86 targets support address spaces other than the generic address space.

 

Address space identifiers may be used exactly like any other C type qualifier (e.g., const or volatile). See the N1275 document for more details.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1005.pdf

 

Вдогонку: OpenCL основан на С99 и тоже использует схожие принципы что и Си для ембеда в части адресных пространств.

https://software.intel.com/en-us/articles/t...ce-in-opencl-20

[juvf 10]

написал всё что думаю о вас.... много букв.... удалил....

 

Вы видите/замечаете/понимаете разницу между "общий" и "основной", между "generic" и "general", между "Programming languages - C" и "Programming languages - C - Extensions to support embedded processors", между "gcc" и "си".

 

 

принципы что и Си для ембеда

Ого!!! Уже не "Си", а "Си для ембеда". Исправляетесь, значит есть смысл от общения. ;)