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

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

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

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

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

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

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

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

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

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

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

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