-
- А этот GCC при влёте в прерывание сохраняет весь набор регистров,
или только используемые (изменяемые) в данном прерывании? Я про
программный режим в CH32V, разумеется, не про аппаратный. - vpv.vpv(24.04.2025 11:51)
- Я мечтаю, что сохраняет только используемые. Вроде, при обсуждении
аппаратного механизма, проскакивало, что для маленьких
обработчиков, где затрагивается мало регистров, программное
сохранение контекста может выиграть, но только если делать пролог и
эпилог вручную. Компилятор не оптимизирует количество сохраняемых
регистров. - Nikolay_Po(24.04.2025 11:53)
- Что ж, неважнецкий какой-то компилятор, значит. )) IAR AVR чётко
сохраняет только те, которые меняются. Но! Стоит внутри П/П сделать
ещё один вызов - всё. IAR сохраняет все регистры. Хотя вызов (я
делал косвенные, т.е. через указатели) очень простой. Вот там я
применял "__raw", т.е. указание IAR'у не сохранять ничего. Я сам
сохранял что нужно (особенно эффективна пересылка пары регистров в
другую пару за 1 такт), отчего реакция и отработка П/П
увеличивалась в разы. - vpv.vpv(25.04.2025 07:45)
- Попробовал заинлайнить в прерывании все вызовы. Заинлайнилось. Ни одного вызова подпрограммы. Но как было 22 инструкции пролога, так и осталось. Не оптимизирует сборка GCC 12 от WCH. - Nikolay_Po(25.04.2025 22:57)
- Спасибо. У меня точно есть вызовы из прерывания. И много коротких. Попробую заинлайнить - вдруг догадатется посокращать сохранение. - Nikolay_Po(25.04.2025 09:58)
- Мечта сбылась. Утверждается, что LLVM умеет IPRA. Но если
посмотреть на цифры, то реальная "польза" весьма скромная. Когда в
дизассемблере видишь сохранение кучи регистров, это немного
расстраивает, конечно. SciFi(1 знак., 24.04.2025 12:01, ссылка)
- В какой версии GCC оно заработает? Интересно. - Nikolay_Po(24.04.2025 12:27)
- Не знаю. Но могу дать ссылку на рабочий тулчейн. Я попробовал,
работает. SciFi(1 знак., 24.04.2025 12:28, ссылка)
- Что-то вроде 19.1.7. У меня пока в комплекте с IDE версия 12. - Nikolay_Po(24.04.2025 12:30)
- Если что, LLVM и GCC - это совсем не одно и то же. - SciFi(24.04.2025 12:30)
- Я думал, что GCC - это типа обёртки для LLVM. - Nikolay_Po(24.04.2025 12:32)
- Если что, LLVM и GCC - это совсем не одно и то же. - SciFi(24.04.2025 12:30)
- Что-то вроде 19.1.7. У меня пока в комплекте с IDE версия 12. - Nikolay_Po(24.04.2025 12:30)
- Не знаю. Но могу дать ссылку на рабочий тулчейн. Я попробовал,
работает. SciFi(1 знак., 24.04.2025 12:28, ссылка)
- В какой версии GCC оно заработает? Интересно. - Nikolay_Po(24.04.2025 12:27)
- Что ж, неважнецкий какой-то компилятор, значит. )) IAR AVR чётко
сохраняет только те, которые меняются. Но! Стоит внутри П/П сделать
ещё один вызов - всё. IAR сохраняет все регистры. Хотя вызов (я
делал косвенные, т.е. через указатели) очень простой. Вот там я
применял "__raw", т.е. указание IAR'у не сохранять ничего. Я сам
сохранял что нужно (особенно эффективна пересылка пары регистров в
другую пару за 1 такт), отчего реакция и отработка П/П
увеличивалась в разы. - vpv.vpv(25.04.2025 07:45)
- Я мечтаю, что сохраняет только используемые. Вроде, при обсуждении
аппаратного механизма, проскакивало, что для маленьких
обработчиков, где затрагивается мало регистров, программное
сохранение контекста может выиграть, но только если делать пролог и
эпилог вручную. Компилятор не оптимизирует количество сохраняемых
регистров. - Nikolay_Po(24.04.2025 11:53)
- Вот пример, как надо: __attribute__((naked)) void my_handler_hpe(){
asm("call my_handler; mret"); } - SciFi(24.04.2025 08:13)
- По идее, не сработает. Если my_handler определить как простую
функцию, то в конце у неё сработает обычный return и нарушит
выполнение кода неподходящим возвратом. Может получиться так: Nikolay_Po(223 знак., 24.04.2025 09:09)
- Ничего не понял. Что не сработает? "asm("пролог; call my_func;
эпилог") - что тут может не сработать? - SciFi(24.04.2025 09:11)
- Ну, так сработает. Если в эпилоге не забыть mret. Но, во-первых, я
не хочу лишний call/ret, во-вторых, я не хочу вручную писать часть
пролога, которая необходима для сохранения контекста перед
выполнением кода прерывания. - Nikolay_Po(24.04.2025 09:23)
- Я не настаиваю. Сомневаюсь, что найдёте вариант лучше, я уже
немного изучал этот вопрос. А лишний call/ret - это такая мелочь.
Жизнь слишком коротка, чтобы зацикливаться на такой ерунде. - SciFi(24.04.2025 09:25)
- Как вам мой свежий взгляд на проблему? Ни строчки на ассемблере! И
заработало в железе. Nikolay_Po(3023 знак., 24.04.2025 10:48)
- Так у тебя же портится регистр A5 в USART1_IRQHandler !!! А работает все нормально из-за включенного HPE ???!!! Ну - я иначе никак не могу это объяснить. il-2(169 знак., 24.04.2025 13:14)
- Если работает, почему бы и нет? Просто "ни строчки на ассемблере"
звучит как странноватый фетиш. Но в каждой избушке свои погремушки.
У меня они тоже есть, но я стараюсь о них не рассказывать :-) - SciFi(24.04.2025 10:48)
- Оно перестаёт быть странным, когда этот код нужно передать дальше в
разработку другим людям. А с ассемблером они пугаются. Ассемблер
более аппаратно-зависим. А мой код пойдёт практически на любых МК,
поддерживаемых GCC. - Nikolay_Po(24.04.2025 10:51)
- "Любой МК" в данном случае - это фикция, эта штука привязана к
конкретному RISC-V. Погоня за "переносимостью" тоже может быть
чрезмерной. - SciFi(24.04.2025 10:53)
- Покажите, где здесь непереносимость? Nikolay_Po(314 знак., 24.04.2025 10:58)
- На скольких разных МК вы запускали этот код? - SciFi(24.04.2025 10:59)
- А на скольких он у вас не пошёл? Достаточно того, что этот код
поддерживается GCC. Навскидку не нашёл исчерпывающего перечня
архитектур с поддержкой naked. Но вот сообщение 2011г: Nikolay_Po(786 знак., 24.04.2025 11:10)
- Я не настаиваю. Мой тезис - разница между "теоретически" и
"практически". Вроде бы об одном и том же, но есть нюанс. - SciFi(24.04.2025 11:17)
- Пока все наши утверждения взаимно голословны, кроме того, что у
меня
заработалов CH32V203. - Nikolay_Po(25.04.2025 16:28)
- Пока все наши утверждения взаимно голословны, кроме того, что у
меня
- Я не настаиваю. Мой тезис - разница между "теоретически" и
"практически". Вроде бы об одном и том же, но есть нюанс. - SciFi(24.04.2025 11:17)
- А на скольких он у вас не пошёл? Достаточно того, что этот код
поддерживается GCC. Навскидку не нашёл исчерпывающего перечня
архитектур с поддержкой naked. Но вот сообщение 2011г: Nikolay_Po(786 знак., 24.04.2025 11:10)
- На скольких разных МК вы запускали этот код? - SciFi(24.04.2025 10:59)
- Покажите, где здесь непереносимость? Nikolay_Po(314 знак., 24.04.2025 10:58)
- "Любой МК" в данном случае - это фикция, эта штука привязана к
конкретному RISC-V. Погоня за "переносимостью" тоже может быть
чрезмерной. - SciFi(24.04.2025 10:53)
- Оно перестаёт быть странным, когда этот код нужно передать дальше в
разработку другим людям. А с ассемблером они пугаются. Ассемблер
более аппаратно-зависим. А мой код пойдёт практически на любых МК,
поддерживаемых GCC. - Nikolay_Po(24.04.2025 10:51)
- Как вам мой свежий взгляд на проблему? Ни строчки на ассемблере! И
заработало в железе. Nikolay_Po(3023 знак., 24.04.2025 10:48)
- Я не настаиваю. Сомневаюсь, что найдёте вариант лучше, я уже
немного изучал этот вопрос. А лишний call/ret - это такая мелочь.
Жизнь слишком коротка, чтобы зацикливаться на такой ерунде. - SciFi(24.04.2025 09:25)
- Ну, так сработает. Если в эпилоге не забыть mret. Но, во-первых, я
не хочу лишний call/ret, во-вторых, я не хочу вручную писать часть
пролога, которая необходима для сохранения контекста перед
выполнением кода прерывания. - Nikolay_Po(24.04.2025 09:23)
- Ничего не понял. Что не сработает? "asm("пролог; call my_func;
эпилог") - что тут может не сработать? - SciFi(24.04.2025 09:11)
- По идее, не сработает. Если my_handler определить как простую
функцию, то в конце у неё сработает обычный return и нарушит
выполнение кода неподходящим возвратом. Может получиться так: Nikolay_Po(223 знак., 24.04.2025 09:09)
- А зачем? Пишешь свою функцию пре-пролог, ее указываешь в таблице
векторов прерывания. А уже из нее делаешь вызов "настоящей"
функции-обработчика прерывания. Только вызов надо делать через JMP - il-2(24.04.2025 05:15)
- А если просто "goto Label:" ? - Nikolay_Po(24.04.2025 09:09)
- У тебя же пролог - ассемблерный. Вот и пиши на ассемблере - буква J - il-2(24.04.2025 09:56)
- Нет, не мой стиль. На Си - так на Си! См. выше. Nikolay_Po(1 знак., 24.04.2025 10:48, ссылка)
- У тебя же пролог - ассемблерный. Вот и пиши на ассемблере - буква J - il-2(24.04.2025 09:56)
- JMP - это тонкая тема. RISC-V имеет особенности. Там обычно branch
with link, а возврат из прерывания mret, и ему этот link по
барабану. - SciFi(24.04.2025 08:27)
- А не надо "with link". Надо "without link" :-) Если уж писать на
асме, то все под твоим контролем - il-2(24.04.2025 08:36)
- Золотые слова. А чтобы этим контролем не выстрелить себе в ногу,
надо для начала разобраться, как надо и как не надо :-) - SciFi(24.04.2025 08:45)
- Ты от меня что-то скрываешь :-) Я не вижу проблемы - написать
пролог на асме, а в конце командой J (без всяких L) перескочить на
обработчик прерывания. А там он сам выйдет по MRET куда положено. И
никаких дополнительных JL / RET. Мне мой вариант больше нравится
:-) - il-2(24.04.2025 10:01)
- Только надо иметь ввиду, что прыжок по J это 20 бит или в пределах 1 Мб. Может и не дотянуться. petrd(293 знак., 25.04.2025 16:16)
- Так и сделал. Только без Асма. Мне мой вариант больше нравится. - Nikolay_Po(24.04.2025 10:52)
- Ты от меня что-то скрываешь :-) Я не вижу проблемы - написать
пролог на асме, а в конце командой J (без всяких L) перескочить на
обработчик прерывания. А там он сам выйдет по MRET куда положено. И
никаких дополнительных JL / RET. Мне мой вариант больше нравится
:-) - il-2(24.04.2025 10:01)
- Золотые слова. А чтобы этим контролем не выстрелить себе в ногу,
надо для начала разобраться, как надо и как не надо :-) - SciFi(24.04.2025 08:45)
- А не надо "with link". Надо "without link" :-) Если уж писать на
асме, то все под твоим контролем - il-2(24.04.2025 08:36)
- А если просто "goto Label:" ? - Nikolay_Po(24.04.2025 09:09)
- А этот GCC при влёте в прерывание сохраняет весь набор регистров,
или только используемые (изменяемые) в данном прерывании? Я про
программный режим в CH32V, разумеется, не про аппаратный. - vpv.vpv(24.04.2025 11:51)