Easyelectronics.ru

После упоминания макроассемблера некоторым нужно было еще вспомнить про фигню для авр, которая с квадратиками и стрелочками, забыл ее название))) Там еще у ее сторонников переменные назывались исключительно в стиле DenNedeli, а функции UvelichitDatu. И убедительно доказать, что без нее армы вообще нежизнеспособны, а с ней наступил бы программисткий рай)))

Да ладно... Global_Wayt, или SkanServChen, или Adr_Taim0 - сильно лучше? ;)

Да, там ассемблер был... с некоторой натяжкой даже макро.

Да я не ограничиваюсь, какие задачи возникают, такие и решаю. Пока максимальный объём был 32 кБ, в следующем проекте понадобится, наверно, 64 кБ.
Макроассемблер, правда, увеличивает объём, но не много, процентов десять, двадцать.
В одном проекте приходилось одновременно работать и с ATMega8, и с ATMega32. Как-то нет особой разницы. В любом случае непосредственно работа идёт с небольшим участком кода, а где этот участок расположен, в большой программе или малой, особого значения не имеет. Правда, большой МК дольше программируется, при отладке неудобство.


Про абсолютную характеристику не понял, что там плюс, что минус.
Передавал коллеге часть кода (следящая схема), вроде не было проблем.
У меня последний проект на ATMega16, думаю, в основу проекта вы «въедете» минут за двадцать.

Для меня основным инструментом при отладке является дебаггер. Когда при отладке в реальном режиме времени можно, практически, в любом месте просмотреть любую переменную, всё резко упрощается.
Про calling conventions даже не слышал, посмотрел по интернету. Наверно, при вызове функции у себя действую по-другому. При вызове функции регистры РОН (это AVR), используемые в этой функции, забрасываю в стек, по завершении функции возвращаю. А аргументы передаю через SRAM.

Calling conventions - это в основном для языков высокого уровня. Как передаются аргументы и результаты функций, кто отвечает за сохранение и восстановление регистров.
Впрочем, на асме вы тоже были вынуждены выработать для себя какую-то calling convention, это экономит время.

Ну а то, про что я говорил - что код на других языках (тот же C/C++) порой приходится отлаживать в виде асма - что требует некоторого знания асма для данной платформы (до сих пор не пойму, почему для x86 образовались два совершенно разных диалекта - собственно intel и gnu).

"Г-н Журден: Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой."(С)Мольер :)

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

А ещё встречается фигня, что отладчик сбрасывает флаги при пошаговом выполнении. Это к флагам, которые сбрасываются при чтении регистров. Я с этим, в своё время, ещё на stm8 сталкивался, когда I2C использовал. При обычной работе все хорошо, а при пошаговой висло на первой же проверки установки флага.

Для отладки в реальном времени нужен трассировщик, штука в наших краях редкая, хотя и очень полезная в таких случаях. Но это имеет мало отношения к архитектурам, те или иные возможности для трассировки есть почти во всех, и уж тем более во всех кортексах (встроено в ядро).

Отправлено с моего SM-N920C через Tapatalk

В упомянутых Атмегах - только ногодрыг свободными пинами, если они есть, и логический анализатор. В старших кортексах MTB тоже нету, и не знаю какие из бесплатных дебаггеров его поддерживают. Поэтому если есть комм. стеки то хорошо иметь ОСРВ с отдельной задачей дебага-логгинга и дополнительным контролем временных интервалов.

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

Не так всё плохо.
При отладке использую программную передачу одного байта в дебаггер через свободные выводы. В дебаггере свой МК, который обеспечивает отладку и программирование.
По времени это не так много, вроде как менее 150 тактов отлаживаемого МК.
Задержка небольшая, так что во многих местах программы можно посмотреть без проблем. Но, конечно, бывали случаи, когда даже такая задержка «ломала» программу.
Если всё же очень хочется в таком месте посмотреть переменную, то это можно сделать. Достаточно переменную «сбросить» в регистры РОН (это АВР), это займёт всего несколько тактов, а затем переменную посмотреть в другом месте программы, где нет «напряга» со временем.
Приходилось делать обмен данными (SPI, RS232), особых проблем с отладкой не было, хотя иногда приходилось придумывать специфические приёмы применения дебаггера.

Не знаю, что собой представляет трассировщик для макроассемблера, чем он лучше просмотра переменных с помощью дебаггера.
Скажем, в одном месте программы мне надо посмотреть переменную «а», в другом – «b». В этих местах программы поставил команды: Q (N1, a) и
Q (N2,b). N1 и N2 – маркеры точек программы. После программирования на экране компьютера появится:
N1 a
N2 b
Здесь a и b – конкретные числа.
Так можно просмотреть путь прохождения программы и переменные в нужных точках программы. Есть, конечно, выше указанное ограничение по времени, здесь ситуация похуже, приходится передавать ещё и маркерный байт, но, в большинстве случаев, это малосущественно.
В «напряженные» по времени точки программы лучше без особой нужды не «соваться».

«… если они есть…» - фраза мало подходит разработчику.
В большинстве случаев разработчик сам выбирает МК, поэтому он должен выбрать МК побольше, чтобы свободные пины были. Свободные пины могут пригодиться и в дальнейшем при развитии проекта.
Кстати, много пинов для дебаггера не надо. У дебаггера два сигнала: тактовый сигнал C и сигнал данных D. Запись данных в дебаггер идёт по сигналу С, поэтому под сигнал D можно использовать и занятый пин, лишь бы он был «на выход». Для сигнала С также можно использовать занятый пин, если на время отладки его можно выключить в программе (например, пин используется для зажигания несущественного светодиода и т.д.).
В принципе, для сигнала С можно использовать и занятый пин без отключения в программе, но тут надо аккуратнее.

В макроассемблере с помощью дебаггера в реальном времени можно без ОСРВ измерять временные интервалы с точностью до долей микросекунд.
Достаточно в программе поставить команды старта и стопа. Эти команды – простой переброс сигнала пина, поэтому их можно использовать, практически, без ограничения в любом месте программы.

А почему передача через стек будет лучше и быстрее?
Мне кажется, что в идеале проще, надежнее и быстрее иметь все переменные глобальными (с ограничением области видимости). Отказаться от манипуляций с указателем стека и возможных проблем с выходом за пределы стека.

А gcc и не знает)))) Они передают параметры через регистры, по возможности))))

Надежнее в каких случаях? Ассемблер?

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




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

Если интересно: https://www.terraelectronica.ru/news_company.php?ID=569

В кортексах как раз есть, в ARMv7 и ARMv9 нет, но это и не кортексы. У старших ядер слишком высокая производительность, встроить трассировку сложно, и трассировщик получится очень дорогой.

Я имел в виду старшые по возрасту :). ЕМНИП МТВ появился в Кортехе-М0 только в поколении "М0+".
Обидно что китайцы еще не освоили копирование трассировщиков. Но т.к. китайцы вообще не умеют в софт то ждать бесплатной иде с поддержкой трассировки еще долго.

В общем случае отвлеченного языка высокого уровня...
Можно предположить, что использование стека для данных придумали в те времена, когда память стоила дорого и ее было мало.
Для ассемблера кмк это неоптимальный нудный метод.

PS: еще интересно, можно ли заменить стек возвратов эдаким заранее построенным деревом возвратов? Т.е. полностью отказаться от устаревшей технологии стеков :)

Довольно забавно читать гипотезы человека, который в теме ни в зуб ногой :-).
1. Рекурсия. Передайте параметры через глобальные переменные, ага-ага.
2. 100500 функций. Заведёте 100500*n переменных или будете использовать одни и те же? Если одни и те же - где будете сохранять старое значение переменной, когда она понадобится для "внутренней" функции? Учтите, что внешняя и внутренняя функция могут быть в разных модулях - т.е. компилиться по отдельности, не зная в этот момент друг о друге.

В общем, геморроя много, толку мало (а на современных процах - вообще может быть вред от cache misses).

Впрочем, я знаю один компилятор паскаля, который таки передавал через переменные в фиксированных адресах RAM. Дело было под CP/M-80, и рекурсия в этом компиляторе по умолчанию была запрещена.

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



Использование регистров для передачи тоже имеет те же недостатки, но все же используется.
Тут хуже что велосипед понятен только тому, кто его собрал, а прочим уже неясно, что куда передается и почему такие вот пляски с бубном. Хотя если кто помнит, то даже при передаче через стек есть поле для маневра, типа кто очищает стек и порядок передачи переменных :)



Там просто памяти мало было и компайлер не шибко интеллектуальный, чтобы рекурсию в цикл развернуть.

fr0ster, ну да, в ту эпоху с оптимизирующими компиляторами было не особо... Плюс проц 8080 - у него не особо много режимов адресации, и заточенного под использование стек фреймов (типа ADD AX,[BP+07]) тупо нету.

Кстати, в том компиляторе, если пометить функцию, как рекурсивную - насколько я помню, он реализовывал перекладывание переменных в стек (т.е. проседала производительность)

А "рекурсию в цикл развернуть" - разверните обход дерева, когда при обработке узла есть свои переменные, нужные и до, и после обработки children. Получите аккурат стек - и, как вы понимаете, делать второй стек параллельно со стеком вызовов в большинстве случаев будет куда хуже, чем пихать всё в стек вызовов.

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

Ну дык не всякую рекурсию можно распараллелить. В некоторых языках указание, что рекурсия хвостовая налагает допограничеия на функцию, выход за которые чреват расстрелом.



Ну стек это не только ценный мех, а еще и компромис между производительностью и безопасностью.
Либо анально огораживаете стек и тратите процессорное время на проверку, что у вас переполнение стека не выполнит какой нить эксплойт, либо имеете лоторею.. но правда вряд ли кто эксплойт для тиньки будет использовать :)

А если не эксплойт, а просто размер стека неправильно задан. Например, иар для авр не умеет во время компиляции определять макс размер стека.

А вот у иар для авр как раз два стека - вызовов и переменных.

100-500 функций это не так уж много переменных. Грубо говоря, несколько кБайт - практически несущественная величина.

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

Существуют ли компиляторы, которые постоянно контролируют стек от переполнения? И на этапе компиляции автоматически определяют размер стека (или стеков)?

Да. Нет.
Первое реализуется прописыванием некоего кода между кадрами стека и проверкой этого кода после возврата из функции, не сошлось, генерится ошибка насчет порчи стека. А второе фантастика пока, слишком много потребуется знать компилятору, что бы подобное реализовать. ИМХО. Хотя могу и ошибаться.