juvf 17 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба const нужен только чтобы уберечь программиста от самого себя, а никак не указание компилятору что и как размещать. Да, согласен, но тоже не понятно почему тогда во всех случаях по разному. Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать. Почему со статиком размещаются данные в др месте? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба еще как указание. статик в теле фции размещается не на стеке, а в общей куче (не путать с кучей malloc). ну и плюс ограничение видимости одной единицей трансляции, если не в теле функции А почему глобальный конст во флеше, локальный в озу? ? это самодеятельность компилера на его страх и риск. собственно если точнее static тоже не говорит где размещать, но определяет время жизни. А уж размещение статик не на стеке - прросто вытекает из этого Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба еще как указание. статик в теле фции размещается не на стеке, а в общей куче (не путать с кучей malloc). пф.... утверждение осталось, только дополню... Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать, я имел в виду, указание не про кучу и стек, а указание про озу/флешь/еепром/внешнюю память и т.п. это самодеятельность компилера на его страх и риск.Согласен. В Си/С++ нет ни каких указаний на этот счет. Поэтому разработчики компиляторов на своё усмотрение делают реализацию. И поэтому, если важна область размещения, нужно компиллер контролировать и давать явные указания для размещения данных в нужную память. А уж размещение статик не на стеке - прросто вытекает из этогоНи чего не вытекает. Статик можно разместить в ОЗУ, а можно разместить в флеше. Конст можно разместить в озу, а можно в флеше. Компилятор волен сам - где и что размещать (в озу или во флешь), и его размещения не поддаются логике. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба его размещения не поддаются логике. Вполне поддаются и даже описаны в документации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба пф.... утверждение осталось, только дополню... Более того, static - это всего лишь указание компилятору, что данные статические, а никак не указание компилятору что и как размещать, я имел в виду, указание не про кучу и стек, а указание про озу/флешь/еепром/внешнюю память и т.п. Согласен. В Си/С++ нет ни каких указаний на этот счет. Поэтому разработчики компиляторов на своё усмотрение делают реализацию. И поэтому, если важна область размещения, нужно компиллер контролировать и давать явные указания для размещения данных в нужную память. Ни чего не вытекает. Статик можно разместить в ОЗУ, а можно разместить в флеше. Конст можно разместить в озу, а можно в флеше. Компилятор волен сам - где и что размещать (в озу или во флешь), и его размещения не поддаются логике. вытекает что не на стеке Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба вытекает что не на стеке Причем тут стек? вопрос ТС не про стек, а про флешь vs озу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
inventor 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба наверное в следующих стандартах Си это можно было бы учесть. с const ИМЕю ввиду.. что бы я еще сделал: ввел бы модификатор переменных global для чего это: предположим в заголовочном файле мы перечисляем все переменные, которые использует программа в сегодняшних компиляторах для этого нужно писать в заголовке перменнные с словом extern и определять сами эти переменные в *.c файле если в заголовке описать переменные static - то все файлы, которые этот заголовок включают будут плодить копии этих переменных, что совсем неправильно. слово global помогло бы этого избежать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба Все, что описал топикстартер в начале темы, верно. Нужно понять (и простить). Не хотите, чтобы const переменная переписывалась из ПЗУ в ОЗУ - сделайте ее глобальной. Не нравятся глобальные переменные - сделайте ее статической внутри функции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба Что такое "основное адресное пространство"? В Си нет такого. В Си нет адресных пространств одно адресное пространство. ps и в вашем авр нет основного адр. простр. В авр гарвардская архитектура, там есть адресное пространство памяти программ и адресное пространство памяти данных. Но к стандарту Си это отношения не имеет, т.к. Си абстрагирован от архитектуры. Если Вы не в теме, то это не означает, что этого нет. https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gc...-Address-Spaces В настоящий момент в GCC именно на этой почве случился ступор. Разработчики avr-gcc не могут сделать так, чтобы по возможности константные данные автоматом ложились во флэш именно из-за того, что стандарт в настоящее время этого не разрешает. Если интересно - скачайте стандарт c11. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 141 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба Вообще-то в GCC в режиме С (без плюсов) уже года два как поддерживаются разные адресные пространства, в том числе и __flash. А вот в стандарте плюсов их нет, поэтому нет их и в плюсах AVG-GCC, поэтому там ступор, да. А еще - бывают контроллеры вообще без набортного флеша, там и код и константы - все в ОЗУ живет. И к чему все эти споры? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба Я не про плюсы и говорю. И ступор не в плюсах. const char __flash* const __flash names[] = { "aaa", "bbb", "ccc" }; не работает, а по всей здравой логике должно. но народ упёрся и говорит, что нарушать стандарт не будем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
inventor 0 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба А еще - бывают контроллеры вообще без набортного флеша, там и код и константы - все в ОЗУ живет. И к чему все эти споры? cc3200 но там все равно подрузамевается память только для чтения: 45 190 bytes of readonly code memory 6 072 bytes of readonly data memory 138 267 bytes of readwrite data memory Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 25 декабря, 2017 Опубликовано 25 декабря, 2017 · Жалоба Согласно стандарту языка Си константные данные обязаны лечь в основное адресное пространство - всё. Если Вы не в теме, то это не означает, что этого нет. 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 26 декабря, 2017 Опубликовано 26 декабря, 2017 · Жалоба С вами бесполезно разговаривать - это Вы к 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 17 27 декабря, 2017 Опубликовано 27 декабря, 2017 · Жалоба написал всё что думаю о вас.... много букв.... удалил.... Вы видите/замечаете/понимаете разницу между "общий" и "основной", между "generic" и "general", между "Programming languages - C" и "Programming languages - C - Extensions to support embedded processors", между "gcc" и "си". принципы что и Си для ембеда Ого!!! Уже не "Си", а "Си для ембеда". Исправляетесь, значит есть смысл от общения. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться