> Какая разница,Большая. Во первых всего несколько записей и несколько циклов. Во вторых их делает железо без разбавки этого инструкциями для нескольких регистров. Так что через несколько циклов обработчик IRQ получает контроль и это к тому же будет стандартное сишное ABI, так то, прикольно придумано.
> если каждая запись в RAM все равно машинный цикл,
Этих машинных циклов довольно скромно может быть, если надо именно это. А на reentry когда зашивалиись и не успели состояние восстановить - и того меньше, железо достаточно сообразительно чтобы стопнуть восстанов на середине, и проскипать сохранение, т.к. не успели же снести сохраненное с прошлого раза еще.
> даже если он один такт? Тот же STM32 25 слов (при наличии FP)
> хреначит в стек и столько же потом вытаскивает. А это, простите, уже 50 тактов.
Простите но вы не в теме.
Во первых лично я пользуюсь M0/M3 где FP нет, в т.ч. и потому: мне больше предсказуемость надо чем bulk performance. Более мелкая и простая система проще в осознании и понимании worst case. А самые жесткие сертификаты для критичных применений у STMок у M0/M0+ вообще: там проще всего надежность и предсказуемость системы от и до изучить было, потому и.
Во вторых насколько я помню, плавучка в M4 опциональна, даже в M4F. Можно и не сохранять.
В третьих даже если сохранять - они сделали там какой-то забавный чит, когда большая часть регистров плавучки может быть сохранена в фоне, ПОСЛЕ того как IRQ handler получил управление. Они это как-то типа фонового сохранения обозвали. Я не особо интересовался, т.к. предпочитаю не создавать себе проблем и использую M0/M3.
> Во-первых, по разному бывает. На том же STM32 порой нужно выполнять код из RAM.
Это несколько экзотика. И там еще флеха не обязана поспевать за ядром на всем ходу, есть wait states, а префетчер и 64-бит шина это аннулирует только частично, и вносит небольной но все же джиттер. Но все же, interleaving шин есть и латенси в целом довольно умеренный может быть.
Для большей предсказуемости можно флеху с 0 wait states гонять - но тогда 24МГц максимум.
> Во-вторых, ко времени выполнения обработчика прерываний это имеет очень
> косвенное отношение.
И тем не менее, латенси у упомянутых культурная и близко не стояла с ужастиками про которые вы вещали.
> Если просто в вызываемой функции, то только в соответствии с ABI.
Если мы про IRQ то там сохраняет само железо, пойнт в том что мы скипаем явные команды push/pop разгружая I-bus для более полезных вещей. Это и латенси улучшает в том числе. А бонусом обработчик IRQ - просто сишная функция. То что ему ABI железо cделало он не знает.
Если мы про основной код, у современных оптимизеров могут быть свои идеи на этот счет. Они могут вообще заинлайнить маленький кусочек актуальный в именно ЭТОМ контексте от всей функции, просчитав что это выгоднее, что тут всегда вот так, и вообще заскипав call функции как таковой, и все пляски, вместо этого врезав тот кусочек который бы в этом кейсе выполнялся как несколько команд. Особенно LTO это дело любит.
> Но в обработчике прерываний, уж простите, как минимум все регистры, которые будут
> в этом обработчике использованы. Вне зависимости от ABI.
При том их еще до входа железка сама пушнула за считанные такты, входных параметров у (void) точно нету, и что-то пушить именно в коде хэндлера придется только если ему ABIшных регистров мало окажется. И если это сильно актуально можно и на асмовый код посмотреть. А если совсем уж приперло, играем мизера, запасу нет, можно и на асме хэндлер выписать, тогда уже точно с гарантиями.
> По сравнению с программно доступными регистрами - копейки.
Однако компилер так то в курсе правил ABI и первым делом упихивается в него. Но можно и на асме выписать если совсем приспичило. Я не развалюсь, право - обработчики IRQ обычно простые и быстрые так то стараются делать.
> Причем речь уже о частном случае.
Если мы полезли такты считать, мы всяко конкретную систему анализируем - в другой железке это может быть иным прямо на уровне их железа, там надо изучать уже их систему и их особенности и лимиты.
> Векторов прерываний у МК не так уж много.
У STM32F0/1xx - около 80 штук бывает. Я б сказал, нормальненько так. Кстати там еще и можно более приоритетным менее приоритетного задвигать, и кстати сохранение контекста при этом уже не потребуется, уже сделано для менее приоритетного так то.
> Даже в STM32 - по одному вектору на 8 GPIO.
Описание EXTI этот сэр явно не читал. Все не так: есть эн обработчиков для именно 1 лапки, куда можно приаттачить именно 1 лапку, а есть shared, общие для сразу нескольких, но опять же, никто не запрещает с собой договориться что там только 1 лапку разруливаем. А другие - на другие обработчики. Ну да, у меня бонус: я "фулстэк". Могу гибридные решения: если становится неудобно софту, переделаю роутинг печатки. Если неудобно железу/разводке, я могу пересмотреть конфигурацию в софте. У фулстэка есть преимущества, более плотный контроль над системой и возможность сделать себе удобно и логично - среди них.
> Мы же про время выполнения обработчика прерываний говорим. А так да, сам
> бывало на критические задачи STM8 или ATTINY ставил в таком монопольном режиме.
Да я и на STM32F1 так пару раз делал. А чего б ему.
> До Paduk так до сих пор и не добрался, хотя подобные задачи - уж точно для них.
> При цене то в 2-3 цента за корпус.
Я не гоняю масспрод миллионами юнитов имеючи интерес больше к кастом деву и подобному, так что мне всякая китайская пакость не особо сдалась. С атмелками я немного могу поразвлечься по старой памяти но смысла в них когда STM32 есть я честно говоря почти не вижу. "Bang per buck" у атмелов какой-то не спортивный уж очень на фоне вон тех. А если кому мелочь надо то G0 в 8 лапом корпусе появился. Вот так вот можно в SO-8 чип с DMA получить :)
> Это редкость. У ST только в STM32G4/L4.
Кто посмел с314ть опамп в моих L15x?!
> требовали сотню-другую ОУ. А уж серийные - свыше тысячи.
Кошмар какой, парад антитехнологичности. Теперь я понимаю почему Маск в своем старлинке кастомные чипы beamformer от STM поставил. Их там полсотни всего чтоли, по 1 на свой патч вроде.
