ищу исходники intrinsic-функций IAR EW430, __bic_SR_register и __bic_SR_register_on_exit Опции

[sensor_ua]

сабж.
остальные, думаю, аналогичны.
поискал в инклюдах полеченной EV-версии - не нашёл, гагль кучу мусора выдал, ну и варианты якобы аналогичных функций от mspgcc, CW. Хотелось бы посмотреть на вариант от IAR

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

Мое мнение: на то они и intrinsic, что их результирующий код генерится компилятором в процессе работы и может различаться в зависимости от остального кода. Поэтому исходника их нет. Может быть исходник для какого-то конкретного случая, когда функцию встраивать нецелесообразно. Например memcpy для пересылки одного-нескольких байт с известными на этапе компиляции адресами будет заменен на несколько mov, а для большего количества или в случае параметров-переменных будет вставлен вызов библитечной реализации. Ваши функции требуют в качестве параметра адрес сохраненного на стеке SR, который знает компилятор в процессе генерации кода (и, если я правильно помню, вырождаются в одну команду, операнды которой компилятор подставляет на лету) или доступа к самому SR, что на голом С невозможно, а асмовые вставки у ИАРа хромают. К тому же эти команды могут изменить флаги условий, которые компилятор может ожидать от предыдущих команд. При генерации intrinsic - реализации компилятор может оценить влияние передаваемого вами параметра на эти флаги. Могу ошибаться.

[sensor_ua]

Дело в том, что уже приходилось рихтовать некоторые особенности творчества от IAR. Вспомните хотя бы работу с EEPROM AVR.
Делаю проектик и напоролся на алогичный случай - повторяющееся ненормальное поведение программы при засыпаниях (без засыпания функциональность соответствует ожидаемой) грешу пока на криворукость, но есть и предположение о проблемах с использованием и/или кривой реализацией этих самых функций. Отладчик, к сожалению, не позволяет пройтись пошагово именно там, где возникают проблемы (eZ430-RF2500)

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

Делаю проектик и напоролся на алогичный случай - повторяющееся ненормальное поведение программы при засыпаниях

А что говорит в местах засыпания/просыпания листинг?

[sensor_ua]

Завтра попробую высмотреть чего там. Конечно нужно посмотреть. Просто ситуация следующая - в проекте есть только одно место засыпания и несколько обработчиков прерываний, где делается "побудка". Предыдущий проект с теми же обработчиками прерываний и тем же единственным местом засыпания благополучно работает, хотя какое-то время были похожие проблемы, но после разбирательств как-будто криворукость нашлась (совсем не в обработчиках) и проблемы якобы ушли.

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

Сказать нечего, зато есть очень подходящий смайлик:

[sensor_ua]

Пока до кода не добрался, но скажу ещё почему сомнения закрались - в обработчике прерывания таймера (на него в первую очередь и грешу) у меня под конец обработчика есть простенькая конструкция
if(use_delay){ __bic_SR_register_on_exit(SCG1 | SCG0 | OSCOFF | CPUOFF); }//Active All
т.е. выход из обработчика делается с "побудкой" не во всех случаях. Как в таком случае компилятор должен себя вести - не очень себе представляю

[sensor_ua]

Криворукость нашлась. Но всё-равно хотелось бы хотя бы знать следующее - __bic_SR_register() делается с тупым запрещением/разрешением прерываний или через сохранение статуса, ну а __bic_SR_register_on_exit() просто не трогает GIE или как, "встраивается" в эпилог и её нужно использовать перед самым выходом или может вызываться в любом месте обработчика прерывания, или просто в любой критической секции (при уже запрещённых прерываниях)

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

__bic_SR_register() делается с тупым запрещением/разрешением прерываний или через сохранение статуса

Как вы себе это представляете? GIE живет в этом же регистре SR. Если я понимаю правильно, то __bic_SR_register(x) компилится в (к сожалению, проверить сейчас не на чем):

Код

    bic #x, SR;если х - константа

    mov &val, Rx
    bic Rx, SR; если х - переменная.

Где тут запрещать прерывания?

, ну а __bic_SR_register_on_exit() просто не трогает GIE или как, "встраивается" в эпилог и её нужно использовать перед самым выходом или может вызываться в любом месте обработчика прерывания, или просто в любой критической секции (при уже запрещённых прерываниях)

А разве она встраивается не в точку использования? В точке использования компилятор знает, сколько байтов он положил на стек в процессе выполнения обработчика. Например, 4. Тогда __bic_SR_register_on_exit(х) выливается в bic #x, 4(SP). При выходе из прерывания на исполнении RETI это "подправленное" значение будет загружено в SR. Тут тоже запрещать прерывания негде.

[sensor_ua]

Где тут запрещать прерывания?

Я надеюсь что так, но сомнения есть. А так как нет исходников, то сомнения остаются, потому как даже если один раз оно будет скомпилировано так, как Вы написали, то второй раз (так как может рулить сам компилятор) это может быть не так.

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

Спасибо, это похоже оно и врятли можно сделать иначе