Привет знатокам ассемблера.
Нигде не нашел, но может все таки что и пропустил: нужна директива препроцессора позволяющая вставить в программу группу строк n раз.
Сейчас необходимо для разработки шаблона программ быстрого умножения/деления больших чисел. Проблема там в том, что при организации циклом очень большие накладные расходы на сохранение флага C (он используется в многобайтных ADC, SBC, CPC, ROL/ROR и т.д., но при этом портится в DEC), поэтому перед DEC его нужно куда то сохранять, а после - восстанавливать.
Поэтому пришел к мысли развернуть циклы - и время сэкономлю и от геморроя избавлюсь. Но затруднился с автоматизацией разворачивания (пока сделал 8 операций умножения для вариантов {1-8} байт на оператор), хочется написать что нибудь вроде
.macro zzz
LD R1,X
ROL R1
ST X+,R1
.endm
.cycle zzz(5)
чтобы сгенерить сдвиг для пяти байт.
Кто нибудь может подсказать: возможно ли такое?
Спасибо.
средствами avr-assembler из "студии" от Atmel такое невозможно.
а вот средствами GNU AS - легко, вот небольшая моя статья об этом: https://simple-devices.ru/articles/7-so ... ler-reviev (правда, по ссылке поменялся движок сайта и врезки кода стали уродскими... я не виноват)
работать с этим ассемблером посложнее будет, чем со "студийным"
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Угу, спасибо.
Вдогонку:
WinAVR это интегрированная среда разработки со своими отладчиком, симуляторами и т.д.?
Или после препроцессинга результат грузится в студию и допиливается там? Просто никогда дела с ним не имел.
студия версии 4.xx вполне себе дружит с WinAVR, позволяя делать отладку внутри себя без танцев с бубном.
WinAVR в голом виде - только компилятор. точнее, там есть и свой "отладчик" и "симулятор", но я пока не встречал героя, который бы ими пользовался
новые версии студии работают так же прозрачно с "тулчейном" avr-gcc, т.к. WinAVR - устарел и не поддерживается. WinAVR - это avr-gcc версии 3.3.2, в более свежих версиях есть интересные плюшки
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
[uquote="imerlin",url="/forum/viewtopic.php?p=3529356#p3529356"]...Проблема там в том, что при организации циклом очень большие накладные расходы на сохранение флага C (он используется в многобайтных ADC, SBC, CPC, ROL/ROR и т.д., но при этом портится в DEC), поэтому перед DEC его нужно куда то сохранять, а после - восстанавливать.[/uquote]Замечу, в AVR команды INC DEC флаг C не трогают, поэтому сохранять его не нужно. Мелочь, но приятно.
Замечу, в AVR команды INC DEC флаг C не трогают, поэтому сохранять его не нужно. Мелочь, но приятно.
Хм... И правда... Почему то засело в голове, что в таблице команд указано, что меняет... Помнится матерился из-за этого долго... Толи не на ту строчку посмотрел, толи что еще...
Может, в каком то из даташитов ошибка вкралась?
Спасибо, что сказали, а то так бы и пребывал в заблуждении...
Но в любом случае, для сравнения все равно танцы с бубном неизбежны - на Z то ведь по любому влияет.
Добавлено after 54 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=3529404#p3529404"]студия версии 4.xx вполне себе дружит с WinAVR, позволяя делать отладку внутри себя без танцев с бубном.[/uquote]
Спасибо, придется изучать...
Добавлено after 2 minutes 35 seconds:
[uquote="trofim2",url="/forum/viewtopic.php?p=3529431#p3529431"]типа так:
Так в том и вопрос был, чтобы не жестко задать, а произвольно: сколько надо, столько и задано, а не именно пять. А пока примерно так и вышел из положения: прописал 8 процедур для размеров операндов от 1 до 8-ми байт.
[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3529839#p3529839"]А стоит оно того? Разворачивать подобного рода циклы... экономия порядка 16 тактов на сдвиге 8 байт.... ценой потребления памяти в 8 раз?[/uquote]
Иногда да. Например, при небольшой длине операндов (2-3 байта) может баш на баш выйти по объему за счет удаления цикла. Ну и верно AVR заметил, что случаи разные бывают, а я предпочитаю, если уж однажды сделал, сделать так чтобы потом с полочки взять и с минимальными изменениями снова использовать. Ну лень мне снова вспоминать, например, как деление сделать. А скоро потребуется - давно хочу приборчик добить для регулировки зажигания и карбюратора: тахометр, УОЗ, УЗСК, стробоскоп... Там если точно мерить, то много тактов набегает за оборот на низких оборотах, сейчас не помню, но то ли на 4 то ли аж на 6 байт, и все это надо делить для вычисления частоты в об/мин. А умножения в любом ПИД регуляторе нужно.
Да и вообще, может я ошибаюсь конечно, но каждый проект индивидуален, где то по памяти лимит жестче, где то по скорости, лучше, если тяжелые базовые подпрограммы будут иметь возможность выбора: скорость за счет памяти или наоборот.
Да и вообще, я задал вопрос, находясь в заблуждении о том, что команды inc/dec изменяют флаг C, и циклы получались очень уж монструозными. Сейчас перепишу версию с циклами, посчитаю такты, может и решу что не надо так уж заморачиваться.
Добавлено after 6 minutes 44 seconds:
[uquote="trofim2",url="/forum/viewtopic.php?p=3529519#p3529519"]Тогда типа такого:
А через пару лет, когда уже основательно забудется как сделана эта программа, вдруг понадобится 11 байт. Не упустите, что программа может быть очень сложна, таких кусочков может быть не один десяток и с разными кратностями повторения. К тому же такой вариант слишком сложен для восприятия, не влезает целиком на экран для осмысления сути этого действия и вообще вместо облегчения работы приносит больше осложнений. Нет, судя по всему действительно, в классическом ASM для AVR эта задача не решается так как я хочу ее решить.
Формировать видеосигнал тяжелыми вычислениями? на АВР? Психушка плачет... Это несколько опрометчивые решения, там где надо каждый такт считать, нужно рассматривать другие решения - на ПЛИС например или DSP. Ведь больше времени потратите на отладку этих крох, а время дороже железа.
Такие алгоритмы вы с полочки не возьмёте, они слишком специфичны и аппаратно зависимы. Через год вы уже забудете про контроллер на котором делали эту оптимизацию, а на другом эти хаки уже не работают и т.п. взять современные ARM, там уже конвеер, разные частоты ядра и периферии и уже не столь очевидно сколько тактов уходит на конкретную конструкцию а иногда быстрее будет исполняться неказистая на вид конструкция.
За те циклы/подсчеты...
Я такую задачу делал когда WS2812 от АВРки запускал.
Все прекрасно контролируется и исполняется.
Причем с завидной стабильностью для случая программной широтной манипуляции
(это помимо основного генератора случайных чисел и прочей обработки).
Так что не надо "контейнер гнать" на 8-битники под ассемблером раньше времени.
Так кто гонит? Контролируется, да. Но задача для WS2812 по силам контроллеру, там не надо выжимать такты ибо не успеваешь - там такты считать надо чтобы обеспечить требуемые временные параметры импульсов, это совсем другое.
возьмите уже их и покиньте тему
Возьму, конечно, когда это надо будет - т.е. когда задача перерастёт возможности AVR или будет совсем впритык - именно для того чтобы не собирать крохи чтобы обеспечить менее 10% выигрыша по скорости.
