caxapa.ru :: Я вот что-то не пойму, почему у IAR нет в стандартной либе функи alloca? Немодно что-ли?

LightElf (05.11.2015 19:31, просмотров: 34525)

Я вот что-то не пойму, почему у IAR нет в стандартной либе функи alloca? Немодно что-ли?

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- Длинный срач в этой теме напомнил армейскую мудрость о рукопашном бое. Скрипач(356 знак., 06.11.2015 20:07)
  - :) - Shatun_(06.11.2015 22:54)
- Стремная она -> --> Можно недеццких багов поиметь - Evgeny_CD(05.11.2015 19:48, ссылка, ссылка)
  - Не читай больше всякой ерунды. Ты окончательно превратился в менагера. - fk0(06.11.2015 00:41)
  - С malloc можно поиметь в сто раз больше недетских багов - LightElf(05.11.2015 19:55)
    - Для malloc существуют шикарнейшие отладчики, для выявления недетских багов. В этом его гигантский плюс. А засор стека толком никто ловить не умеет. - fk0(06.11.2015 00:42)
      - Пример отладчика в варианте ARM FreeRTOS|uCOS, пожалуйста. - Evgeny_CD(06.11.2015 01:54)
        
        Кстати могу тебе сказать, для очень больших проектов в области (почти)embedded, как ни странно, есть тоже "синтетический порт" и много вещей можно отладить на PC, а потом тащить на железяку. Ибо её программировать 20 минут с какими-то матерями и fk0(93 знак., 06.11.2015 12:12)
        
        Синтетический порт - это очень хорошо, но не все он поможет отладить. Всякие тонкие вещи с аппаратурой и DMA, например. Всякий "невыровненный доступ" и прочее... Если в аппаратуре осталось хоть чуть-чуть ресурсов, то штука класса "монитор" хорошо Evgeny_CD(12 знак., 07.11.2015 00:20)
        
        Ну да, ты умеешь говорить очевидные вещи... Только с мест оно видней, что и как лучше. - fk0(07.11.2015 00:28)
        
        Дык эта. Если железяка сделана так, что "её программировать 20 минут с какими-то матерями и отладчика там вообще никакого нет", то нужно железячнику руки оторвать. Или нет? - SciFi(06.11.2015 12:18)
        
        Железяки не свои и их очень много. А то бы кто и зачем платил программистам. - fk0(06.11.2015 12:39)
        
        Обсуждать слишком глубокие ньюансы с непрофессионалами -- бесполезная трата времени. Ибо ты даже не понимаешь о чём говоришь. Дело не в ОС. Могу только сказать, что даже на PIC18 лучше маллок, чем стек. Баги ловятся легче. - fk0(06.11.2015 12:01)
        
        PIC18 с 31 ячейкой стека адресов возврата? Можно зажечь :) Вообще-то мы вроде бы обсуждали (мое мнение), что лучше не использовать alloca - так о чем мы спорим? - Evgeny_CD(07.11.2015 00:46)
        
        Да, PIC18. malloc лучше контролируемым нарушением границ и понятным сроком жизни выделенного сегмента памяти, против автоматических переменных. - fk0(07.11.2015 02:55)
    - Нет, методологически alloca куда стремнее. Получается принципиальная зависимость существования области памяти по полученному указателю от потока управления. Феерический источник багов. - Evgeny_CD(05.11.2015 19:58)
      - Попробуй объяснить, чем это отличается от маллока? - fk0(06.11.2015 00:42)
        
        Вызвал на alloca на одном уровне вложенности (от main() ), указатель сохранил, вернулся на уровень верх, потом снова вошел на прежний уровень вложенности, операция по заботливо сохраненному указателю - вуаля! - Evgeny_CD(06.11.2015 01:34)
        
        Ты часто сохраняешь указатель на локальные переменные? Это и есть alloca(). С дуру конечно можно лоб расшибить... - fk0(06.11.2015 12:02)
- Почему нет? В stdlib.h есть calloc и malloc. Чем не устраивают? - Ксения(05.11.2015 19:44)
  - Ксения, принципиально alloca != malloc - LightElf(05.11.2015 19:47)
    - Тогда я просто не знаю, что такое alloca :) - Ксения(05.11.2015 19:48)
      - Это выделение памяти на стеке. - LightElf(05.11.2015 19:49)
        
        А вы закажите среди локальных переменных массив - вот и будет вам память на стеке :) - Ксения(05.11.2015 19:54)
        
        так и придется делать, но это не позволяет задавать размер стека динамически. У всех задач будет стек одинакового размера, что неаккуратненько. - LightElf(06.11.2015 19:45)
        
        А стоит ли делать "динамизм" в этой фемтоОСи? Это даст выигрыш? - Evgeny_CD(07.11.2015 00:55)
        
        Я некорректно выразился. Не динамически, в смысле "в рантайме". А в смысле, чтоб каждой задаче выделять стек своего размера. В общем тоже решаемо, но обвязка получается мутная. LightElf(76 знак., 07.11.2015 02:15)
        
        Рекурсивная функция с автоматической переменной-массивом размером с минимальный размер стека (байт 256 эдак) спасёт в общем-то. Хуже другое, я смысла в кооперативной RTOS практически не вижу. Нужна скорей некая (а-ля libevent хотя бы) библиотека fk0(106 знак., 06.11.2015 23:59)
        
        Что-то типа такого? - LightElf(09.11.2015 12:27, ссылка)
        
        Дело хозяйское. Мне так вот часто хочется раскидать код по отдельным задачам. - LightElf(07.11.2015 02:19)
        
        Желание неправильное, глупое, и ничем не обоснованное. Лучше б тебе хотелось уйти от необходимости ручного задания последовательности исполнения команд, от императивного программирования к декларативному. - fk0(07.11.2015 02:58)
        
        Это в C99 только. - fk0(06.11.2015 00:44)
        
        Все еще хуже - variable length array не обязан выделяться на стеке, и конкретно в IAR он создается на куче (в конец функции компилятор втыкает free). - LightElf(06.11.2015 19:47)
        
        Гонишь. За такие подляны пожизненный эцих без права на интернет. - ASDFS(06.11.2015 20:03)
        
        Пруф в студию! - LightElf(06.11.2015 20:50)
        
        !? Пруф на мое мнение - мое слово ))))) - ASDFS(07.11.2015 01:09)
        
        Принимается! :) А серьезно - в стандарте не сказано жестко, где именно должны создаваться массивы. - LightElf(07.11.2015 02:20 - 02:37)
- В стандарте нет, поэтому кагбэ не обязаны. - SciFi(05.11.2015 19:35)
  - Блин, грустно. Придется думать, как бы ее заменить. LightElf(115 знак., 05.11.2015 19:47)
    - Т.е. он делает "RTOS" из текущего потока? А ссылочку можно? - Evgeny_CD(05.11.2015 19:49)
      - Вот здесь идея описана. Оно косячное, но важна идея. - LightElf(06.11.2015 19:48, ссылка)
        
        Прикольно. Я вчера по alloca setjmp longjmp несколько материалов нагуглил, этот в том числе. Но вот что меня смушает.... Evgeny_CD(539 знак., 07.11.2015 00:32)
        
        1) Вытесняющие оси требуют больше стека. Задача может быть прервана в любой момент, потому шедулер вынужден сохранять все регистры. В кооперативной осе задача переключается только в определенные моменты, компилятор знает о них и может правильно LightElf(305 знак., 07.11.2015 02:29)
        
        Кооперативная ОС нужна только для одного -- планировщик (большие биг-луп программы слишком много времени тратят на проверку условий в цикле). Но он легко заменяется чем-то вроде libevent. Если срок разработки ПО менее года и работает пара человек fk0(202 знак., 07.11.2015 03:06)
        
        Ты несёшь полнейшую чушь. Вытесняющая ОС стека больше аж на три десятка байт требует? Да у тебя недетерменированное дерево вызовов заставит сходу полкилобайта на каждый стек отдать. - fk0(07.11.2015 03:03)
        
        8 килобайт стека хватит каждому - Linus kernel(07.11.2015 15:19, )
        
        qsort() неудачно вызови... - fk0(07.11.2015 15:22)
        
        Это который? - qsortk :)(07.11.2015 15:29, )
        
        не фантазируй. 10 задачек жрут от 100 до 200 байт стека. больше всех толстая матзадача с тучей вызовов матфункций (операции с кватернионами) и много локальных структур (кватернионов и матриц). есть и такиие задачи, что в сотню байт вкладываются. - Mahagam(07.11.2015 13:59)
        
        Ты ещё объясни как ты в 20-байтном стеке прерывание обрабатывать будешь, бугага. - fk0(07.11.2015 14:46)
        
        Прерывание в своем стеке, это правильно в любом случае. - Evgeny_CD(07.11.2015 14:49)
        
        Это ты не фантазируй. Первая попавшаяся функция 200 байт сожрать может и ещё попросить. Это просто у тебя задачки такие, отдалённые от реалий современного программирования. - fk0(07.11.2015 14:38)
        
        а реалии современного программирования какие? сячкать говнокод жрущий память? я тебе привёл данные по реальному проекту вообще-то. - Mahagam(07.11.2015 16:10)
        
        20 байт стека на задачу? Всё ясно с твоими проектами. - fk0(07.11.2015 16:45)
        
        я такого не писал. 100-200 на задачу. две задачки (математическая задача, и сетевая часть с ftp и файловой системой) жрут сильно больше остальных. и у них стеки выделены раза в два больше остальных. - Mahagam(07.11.2015 17:17)
        
        Тебе информация для справки: в средней программе на linux 16кБайт стека не хватает, похрену какие там задачки, это просто некий усреднённый стек для усреднённой задачи, с нормальным программированием (никто не говорит "мы не используем fk0(30 знак., 07.11.2015 14:40)
      - Завтра, оно дома. Там setjmp + alloca. Исходный стек (на котором main вызвана) нарезается на куски и раздается потокам. - LightElf(05.11.2015 19:52 - 19:54)
        
        Все равно с переносимостью будут проблемы. setjmp не является универсальной на всех платформах. Т.е. не намного лучше асмового кода. - Evgeny_CD(05.11.2015 20:05)
        
        Не говори о чём не знаешь с высоты менагерского полёта. Я как проф. программист тебе скажу, что alloca() и setjmp() как раз и являются кросплатформенным способом выкрутиться из ситуации без знания регистров и ассемблера. Будь там операционка (т.е. fk0(283 знак., 06.11.2015 00:47)
        
        Скажи мне, профессиональный программист, WinAVR -> PIC24 -> PIC32 -> GCC ARM Cortex | IAR ARM Cortex alloca() и setjmp() точно ли есть, и одинаково ли работают? - Evgeny_CD(06.11.2015 01:37)
        
        alloca нет, потому как оно оказывается не входит в стандарт. setjmp есть везде, потому что стандарт. Поведение опять-таки описано в стандарте. - LightElf(06.11.2015 19:50)
        
        Не важно одинаково ли они работают, но они должны быть и типично есть в любом C компиляторе после 1989 года. Другое дело, что на PIC24, могу сказать, оно жрёт неадекватно (порядка 256 байт) памяти. Но это уже детали. - fk0(06.11.2015 12:03)
        
        Как пример -> - Evgeny_CD(06.11.2015 01:44, ссылка)
        
        Осталось понять, причём здесь setjmp. Он то как раз сохранит "временные переменные" компилятора в целостности (как и весь кусок вышележащего стека). - fk0(06.11.2015 12:05)
        
        Не понимаю, чем память в куче хуже чем на стеке? - =AlexD=(05.11.2015 19:59)
        
        Наверное, задумка создателей этой функции была автоматическое освобождение памяти, но реальность оказалась мрачнее мечтаний :( - Evgeny_CD(05.11.2015 20:01)
        
        1) Выделение памяти на стеке потокобезопасно сразу, без всяких выкрутасов LightElf(57 знак., 07.11.2015 02:35)
        
        Задумка создателей в том, что C не предоставляет другого способа именить $SP. - fk0(06.11.2015 00:48)
        
        Не видел требований что бы это было сделано через изменение $SP. Честно говоря не представляю как можно менять $SP, там же все локальные переменные относительно него адресуются, вся адресация нарушится. Либо надо выделять еще один регистр, которых AlexBi(13 знак., 06.11.2015 11:32)
        
        Это проблема автора компилятора и рантайма. - LightElf(06.11.2015 19:53)
        
        Для отдельного потока, треда, задачи, процесса, нужен свой стек, значит нужно переключать стеки и менять $SP. Что тут непонятного? - fk0(06.11.2015 12:06)
        
        Вот например кусок кода: AlexBi(240 знак., 06.11.2015 12:37)
        
        Локальные переменные адресуются относительно специального регистра frame pointer потому. Компилятор конечно может и относительно SP нраоптимизировать, но он знает что делает и учитывает смещение SP. - fk0(06.11.2015 13:06)
        
        Ксения права -> - Evgeny_CD(05.11.2015 19:56, ссылка)
        
        Ответил. Это вариант, но не совсем. Локальный массив (тем более VLA) не обязан создаваться на стеке (и по факту часто создается на куче, пример можно посмотреть в либах IAR). - LightElf(06.11.2015 19:57)

Средства и методы разработки