Ассемблер (ASM) для AVR в вопросах и ответах

[DimKra]

Вопрос знатокам: В AVR есть такой скрытный зверёк - регистр "PC", счётчик инструкций. Хотел узнать о нём поподробнее, как то например по какому физическому адреcу он сидит, можно ли его прочесть напрямую из программы ? Гугль молчит как партизан, неужели нигде нет подробной информации на этот счёт?

[WiseLord]

А зачем Вам знать это? Всё равно попытка прочитать этот регистр из программы давала бы как раз номер той инструкции, которой этот регистр читается. Что чуть менее чем бесполезно.

[DimKra]

WiseLord, думаю большей степени научное любопытство Ну может и пригодится для дебага, если будет возможность хотя бы читать.

[ПростоНуб]

DimKra, через CALL на следующую после него инструкцию и два (три для некоторых AVR) POP можете его значения получать. Но толку с него действительно немного.

[Demiurg]

Практического смысла нет. Смотрим описание этого регистра. Работает с командами rjmp, jmp, rcall, cal.

Код: Выделить всё

rjmp pc +\- x

Глухое зацикливание программы rjmp pc + 0.
Так как команды бывают двух и четырех байтные, заманаешься вручную высчитывать насколько команд нужно прыгнуть. Именно по этой причине крайне не рекомендуется работает вручную. Только по меткам.

Код: Выделить всё

Label_1:
bla-bla
rjmp +\- Label_x
bla-bla
Label_2:

[Alexeyslav]

Он-то регистр, но недоступен для чтения напрямую. Но с ним можно работать некоторыми командами - всевозможные команды перехода и возврата из подпрограммы.
Толку его читать? Он всегда указывать удет на ту инструкцию которой его прочитаешь, а это известно и так на этапе компиляции(переносимый по адресному пространству код под AVR я не видел).

[BOB51]

DimKra
Модификация содержимого PC производится "подстановкой адреса возврата через стек", командами call, jmp, коротких условных переходов и косвенных переходов ijmp, icall с подстановкой адреса из регистровой пары R31:R30 (она же Z).
Чтение... в принципе в некоторых случаях может иметь смысл (к вопросам отладки например) - тогда выполняем любой вызов call и считываем точку входа из верхушки стека.

[afz]

Вообще-то, это дело может оказаться полезным при организации сопрограмм. Применяется, например, в драйверах со сложными протоколами. Например, так (объясняю упрощенно): надо передать, допустим, что-то кому-то через нечто, вроде RS485. То есть получаем адрес абонента и блок данных, надо через UART достучаться до принимающего абонента и передать ему блок данных.

Так вот, пишем этот драйвер, как простую программу, которая делает эти действия, а когда, после выдачи байта в UART, надо подождать момента, когда можно будет передавать следующий байт, вызываем специальную подпрограмму ожидания, которая достает из стека и сохраняет в своей статической памяти адрес возврата, а также необходимые данные из регистров, восстанавливает из стека сохраненные регистры вызывавшей программы (той, которая выдала запрос на передачу по RS485) и возвращается в нее. Вызывавшая программа знает, что обмен только запущен, но еще не выполнен, она может заниматься чем-то другим.

Вторая половина программы ожидания запустится по прерыванию от UART'а, она сохранит нужные регистры, поднимет в них данные, сохраненные первой половиной и перейдет командой ijmp по адресу, добытому первой половиной из стека. Таким образом, драйвер продолжится с команды, следующей за вызовом специальной программы ожидания. Далее, готовим следующий байт, или готовим прием байта ответа (подтверждения от адресованного абонента) и снова вызываем ожидание. После очередного прерывания снова получит управление команда, следующая за последним вызовом ожидания, и т.д.

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

[Ivanoff-iv]

Подобное пытался делать на С, меня отругали за множественные выходы из подпрограммы... сделал запоминание точки выполнения и переход к концу подзадачи - отхватил за GOTO но чего хотел, того впринципе добился не знаю почему не нашел готового решения, идея то хороша...

[ARV]

Если вы хотите, чтобы вашим кодом мог пользоваться кто-то другой, или чтобы кто-то другой мог его модифицировать, если вы не хотите сломать голову при отладке своего кода и не желаете этого другим, никогда так не делайте!!!

Единственное допустимое применение подобного подхода - создание ядра ОСРВ.

никогда никому не посоветую так писать свои программы!

[ПростоНуб]

ARV, по сути, совершенно стандартные LIBC функции setjmp()/longjmp() этот механизм и обеспечивают. Или их тоже никогда нельзя использовать? А я то их неоднократно применял для организации кооперативной мультизадачности...

Добавлено after 5 minutes 42 seconds:
[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=3704504#p3704504"]не нашел готового решения[/uquote]
setjmp()/longjmp()

[Demiurg]

[uquote="afz",url="/forum/viewtopic.php?p=3704382#p3704382"]...[/uquote]
Хотелось бы увидеть вашу реализацию.

[uquote="ARV",url="/forum/viewtopic.php?p=3704560#p3704560"]Если вы хотите, чтобы вашим кодом мог пользоваться кто-то другой, или чтобы кто-то другой мог его модифицировать, если вы не хотите сломать голову при отладке своего кода и не желаете этого другим, никогда так не делайте!!! Единственное допустимое применение подобного подхода - создание ядра ОСРВ. никогда никому не посоветую так писать свои программы![/uquote]
Здесь два конца одной палки. 1 - Прогнуться под "всех" и писать свои проекты с этой позиции. 2 - Если вы знаете, что делаете, и уверены, что именно такой ваш подход решает ВАШИ задачи, значит так и делаете. Отладка проекта - автоматом - вы точно знаете, что делаете, как работает ваша программа. Если нет нужного инструмента, значит создайте его. Я про тестовые программные закладки.

Другое дело, если заранее известно, что ваш проект кто-то будет повторять, править, совместные проекты. Здесь на ваше усмотрение. Пишите как для "всех", либо документируете ваши подходы.

[ПростоНуб]

[uquote="Demiurg",url="/forum/viewtopic.php?p=3704595#p3704595"]Если вы знаете, что делаете, и уверены, что именно такой ваш подход решает ВАШИ задачи, значит так и делаете.[/uquote]
Каждый второй специалист, увольнение которого происходит по моей инициативе, расстается с проектом имеено из-за такого подхода. Потому что даже если, кроме этого специалиста, никто этот код на проекте трогать не будет, то код все равно надо поддерживать, а специалист может заболеть, уволиться, уйти в декрет и т.п. На такие риски я никогда не подпишусь.

Иными словами, или вообще исключите такой подход у себя в голове, или принимайте бесповоротное решение в том, что никогда в будущем программированием зарабатывать не будете.

[Demiurg]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3704601#p3704601"]...[/uquote]
Мне приходилось разные чужие проекты разбирать. Если проект писал специалист, гораздо проще разобраться. Правда тут навык и опыт разбора чужих проектов нужен. Некоторые проекты писали мои "учителя", спецы, участники профильных форумов. Я неоднократно мозги себе наизнанку выворачивал, чтобы понять реализации их проектов. И некоторые наработки в дальнейшем я стал сам использовать. Принципы программирования. Если проект писал начинающий, практика показывает, что проект дешевле по всем параметрам переписать заново. При условии, что проектом будет заниматься специалист.

Повторю еще раз, если мои личные наработки решают специфичные задачи проекта, я ни под кого прогибаться не буду. Это означает, что мне виднее, когда подход под "всех" не решает задач.

[BOB51]

ГЫММ...
Это ж вроде ветка про АССЕМБЛЕР....
В Си ассемблер всего лишь ВСПОМОГАТЕЛЬНОЕ звено.
Выше рамок компилятора выходить крайне опасно по многим вышеуказанным КОТАМИ причинам.
А вот "в чистом виде" пишем как пожелаем, не забывая про документирование.

[Demiurg]

[uquote="BOB51",url="/forum/viewtopic.php?p=3704614#p3704614"]ГЫММ...
Это ж вроде ветка про АССЕМБЛЕР....[/uquote]
Совершенно верно. На ассемблере специалист сам решает, как реализовать проекты.

[ПростоНуб]

BOB51, если документирование так же подразумевает, например, отступление от принятой ранее конвенции по использованию регистров, и это отступление действительно обосновано, то почему бы и нет? Но мне сложно представить себе причины, по которым 16-битные переменные передаются не в регистрах-спарках, а 8-битные - наоборот )

[ARV]

А вот "в чистом виде" пишем как пожелаем, не забывая про документирование

никакое документирование не поможет разобраться в коде, который произвольно меняет точки исполнения! ассемблер позволяет сделать что угодно, не нарушая парадигму программирования низкого уровня, но МОЖНО не означает НУЖНО. редкие исключения, как я уже говорил, только подтверждают общее правило.

стандартные LIBC функции setjmp()/longjmp() этот механизм и обеспечивают

во-первых, тема про ассемблер, и говорить о LIBC тут неуместно.
во-вторых, если многие считают goto злом, то setjmp/longjmp - это просто адское зло, открывающее врата ада.
в-третьих, я еще раз повторяю: в некоторых узкоспециализированных случаях типа разработки ядра ОСРВ это допустимо, но только в виде исключения и с условием, что всякого, кто посмеет к этому потом прикоснуться, либо сожгут на костре, как еретика, либо вознесут до уровня ангела

[ПростоНуб]

ARV, Вы действительно считаете, что на ассемблере недопустимо использовать конструкции, которые в ассемблером коде формируются компилятором ЯВУ? И Вы никогда из ассемблера не вызываете функции, написанные на ЯВУ? Объясните причины, пожалуйста. Я так часто пользуюсь и первым, и вторым. Причем пользовался ещё на ассемблере IBM/370, и с тех пор не прекращаю )

Добавлено after 8 minutes 50 seconds:
BOB51, возможно, у нас разные подходы, но, в подавляющем большинстве случаев, у меня в проектах С и ассемблер взаимодействуют в тесной связке. То есть, как в С используются ассемблерных вставки и вызываются функции на ассемблере, так и из ассемблера вызываются функции на С, включая библиотечные. Это очень экономит время, почти не влияя на производительность программы и размер кода

[ARV]

Вы действительно считаете, что на ассемблере недопустимо использовать конструкции, которые в ассемблером коде формируются компилятором ЯВУ?

при чем тут конструкции? вы не видите разницу между командой ret или jmp и алгоритмом, в котором эти команды перемещают программный счетчик в неожиданное место, не отслеживаемое "разумом"? вы никогда не сможете предсказать, в каком состоянии находится программа, написанная при таком подходе, просто взглянув на её текущий "снимок" РОН и PC - вам придется долго и скрупулезно исследовать содержимое стека и листинга, чтобы понять, где программа окажется спустя 100 следующих тактов...