caxapa.ru :: По идее, не сработает. Если my_handler определить как простую функцию, то в конце у неё сработает обычный return и нарушит выполнение кода неподходящим возвратом. Может получиться так:

Nikolay_Po (24.04.2025 09:09, просмотров: 104) ответил SciFi на Вот пример, как надо: __attribute__((naked)) void my_handler_hpe(){ asm("call my_handler; mret"); }

По идее, не сработает. Если my_handler определить как простую функцию, то в конце у неё сработает обычный return и нарушит выполнение кода неподходящим возвратом. Может получиться так:

__attribute__((naked)) void my_handler_hpe(){ goto my_handler: }

При этом, my_handler() определить как функцию-прерывание. Тогда и штатный пролог будет обеспечен компилятором, и mret сработает как надо. Как думаете, взлетит?

Ответить

- Ничего не понял. Что не сработает? "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)
        
        Нет, HPE не включён. Просто повезло. Но что А5 портится - верно подмечено. В общем, не рабочее, если опять таки, вручну в стек не сохранять/извлекать. - Nikolay_Po(24.04.2025 13:33)
        
        Если работает, почему бы и нет? Просто "ни строчки на ассемблере" звучит как странноватый фетиш. Но в каждой избушке свои погремушки. У меня они тоже есть, но я стараюсь о них не рассказывать :-) - 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)

ARM, RISC-V контроллеры