Перейти к содержанию
    

STM32 Ассемблер. Идеи и приёмы написания

Интересно, где именно происходит сложение "$Port + GPIO_BSRR" в данном случае $Port = 0x40001800, а GPIO_BSRR = 0x10.
А где бы вы сделали это сложение? Еще раз оглашу ваши условия: "оба слагаемых константы и известны до начала выполнения программы".

 

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

И где вообще хранится константы когда мы используем их в виде "mov R0,#4" - вот число 4 здесь, процессор же должен от куда нибудь его взять?
Это описано в разделе "About the instruction descriptions" прямо в начале описания ассемблерных команд. Часто бывает полезно один раз прочитать документацию с самого начала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А где бы вы сделали это сложение? Еще раз оглашу ваши условия: "оба слагаемых константы и известны до начала выполнения программы".

 

Простите, но все ассемблеры такие действия выполняют в уме.

Это описано в разделе "About the instruction descriptions" прямо в начале описания ассемблерных команд. Часто бывает полезно один раз прочитать документацию с самого начала.

Это макрос и от пользователя может прийти что угодно (просто в этом случае я сразу прописал), вот скажем я с юарта буду посылать имя порта, в конечном итоге отправляя его в аргумент этого макроса, тогда получается что приплюсовывать "GPIO_BSRR" к имени порта (у которых код тоже задефайнен, у каждого свой) микроконтроллер будет на лету? Он же не будет знать какой порт будет следующим. Как же так?

Изменено пользователем allsettingsdone

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так вам про это и долдонят битый час:)

 

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

 

UART -> DR = Data;

 

а в ассемблере берется адрес + смещение этого регистра как константа, и в нее пихается содержимое регистра отвечающего за data.

 

Меняем процессор, меняем данные, меняем уарт, нажимаем откомпилировать код и все поехали дальше.

 

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

 

Может утрированно, но смысл именно такой. Ассемблерный код чтобы он был эффективный должен быть крайне порезан.

 

в С мы можем себе позволить

Data = (int)126/24*432/12.5;

 

но после компиляции в адрес даты будут пихать константу, и если допустим конструкция

TimeInHour = Tic/CPU_FREQ * 60 * 60; - понятно

 

то в асме будет деленный регистр в котором лежат данные Tic на константу, значение который фиг разгадаешь глядя на нее...

2.1428571428571428571428571428571e-5

а по уму должно быть не деление а умножение на

46 666.666666666666666666666666667

для клока 168 МГц.

 

И вот как по 46 667 через год вспомнит чего вы хотели, зачем и почему это должно изменится при смене клока.... :)?

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

тогда получается что приплюсовывать "GPIO_BSRR" к имени порта (у которых код тоже задефайнен, у каждого свой) микроконтроллер будет на лету?
Нет, не получится. Если вы почитаете описание команды mov то увидите, что вторым операндом должна быть константа. Хотите вычислять на лету - надо будет писать кусок кода из нескольких команд. Чтобы убедиться - напишите желаемое на Си, скомпилите и посмотрите листинг. При желании можете взять его за основу и попытаться соптимизировать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

в С мы можем себе позволить

Data = (int)126/24*432/12.5;

но после компиляции в адрес даты будут пихать константу, и если допустим конструкция

TimeInHour = Tic/CPU_FREQ * 60 * 60; - понятно

то в асме будет деленный регистр в котором лежат данные Tic на константу, значение который фиг разгадаешь глядя на нее...

2.1428571428571428571428571428571e-5

Вы не правы. Все современные ассемблеры точно так же умеют вычислять значения константных выражений. И даже 10 лет назад уже умели.

И даже более того - средства макроязыка в ассемблерах как правило более мощные чем препроцессор си.

Мне часто очень не хватает макро-возможностей асма в си, когда вспоминаю что мог позволить себе в асме... :crying:

Но си скован стандартом, а ассемблер - нет.

Хотя я совсем не поддерживаю ТС в его утопическом стремлении к чистому ассемблеру - жизнь его научит и отрезвит (в лице работодателя например) :twak:

(если он конечно будет профессионально заниматься программированием, а не как любитель).

 

PS: Кстати - совсем не согласен с тем кто тут писал что ассемблер ARM - сложный. Из всех асмов что я когда-либо изучал, этот - самый простой.

Достаточно хотя-бы взглянуть на асм TI DSP 5000-ного семейства. :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ага или на асм ДСПешника со сдвоенным АЛУ,

 

помню там было много приколов с тем что branch делался 3 такта, и часто эти 3 такта шли на доп вычисления, типа 1 такт бранч, а потом еще 2 команды которые выполнялись до бранча. Или когда ффт на 2 алу раскидывалось в параллель. Примерно тогда я зарекся соревноваться в компилятором.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

помню там было много приколов с тем что branch делался 3 такта, и часто эти 3 такта шли на доп вычисления, типа 1 такт бранч, а потом еще 2 команды которые выполнялись до бранча. Или когда ффт на 2 алу раскидывалось в параллель. Примерно тогда я зарекся соревноваться в компилятором.

На TI C55xx если мне не изменяет память 6-тактный конвеер и переходы (не внутри RPT) 4-5-6 тактов.

Там я применял много способов оптимизации в том числе и конвееризацию вычислений внутри циклов, когда одновременно выполнялась голова цепочки команд обработки сэмпла в одном АЛУ в то время как

в те же самые такты выполнялся хвост этой цепочки команд для предыдущего сэмпла в другом АЛУ.

Что уж говорить про параллельные чтения/сохранения в ОЗУ.

И зря зареклись. Никогда ещё ни до ни после я по эффективности кода так не превосходил си-компилятор как тогда - мой код на асм получался в РАЗЫ меньше и быстрее. :rolleyes:

Оптимизировав инструкции по размеру, спарив их, убрав все штрафы (stall-ы), раскидав выполнение по разным шагам конвеера, загнав цикл в RPTBLOCAL, использовав разные фичи типа циклической адресации и т.п. можно было в разы уделать компилятор :biggrin:

А вот на ARM выигрыш от такой оптимизации будет значительно меньше и смысл в ней значительно меньше.

Изредка, когда приходится что-то написать на асм для ARM/Cortex-M с оптимизацией времени выполнения, с тоской вспоминаю C55xx....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы если бы так упорно писал бы на ассемблере(бы),

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

Если Вы не пишете на Си, Вы придете к интерпретаторам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вам видать плохой компилятор достался:) ну или у вас ооочень большая голова.

 

я разглядывая полученные коды находя крайне странно-нелогичные конструкции длительное время втыкая в них понимал что они настолько хитро упакованы, что я бы даже не поглядел бы в эту сторону. Хотя может если набраться опыта то за пару лет сам начнешь так мыслить... но где теперь этот проц и тот код? Стоил бы он нескольких лет упорных втыканий в АСМ? Все течет все меняется...

 

побивающее компиляторы как по скорости так и по размеру.

 

а это не нарушает закон сохранения энергии?

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а это не нарушает закон сохранения энергии?

Подозрительным образом сообщество мгновенно накидывается на человека, который только намекнул на то, что хочет заниматься асмом. :biggrin:

И это довольно давно продолжается. В данном случае закон сохранения энергии нарушается действительно, поскольку например мне лично все равно, развивается компиляторостроение Си или нет и дивидендов от этого процесса как будучи агентом влияния я не получу никаких.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

не я про другое.

 

иногда интерпритатор работает медленнее, но код становиться меньше

иногда он работает быстрее, но требует больших команд и код становится больше

иногда он работает и медленнее и код больше

 

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

 

 

П.С. Я как представитель общества считаю что когда кто-то как ТС начинает изучать ассемблер, то он очевидно заблуждается, и заблуждение настолько очевидно, что нет никаких сил не попытаться его спасти%)... Подозреваю что всеми движет примерно похожее чувство.

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подозрительным образом сообщество мгновенно накидывается на человека

Да никто не накидывается. :rolleyes:

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

 

Я, например, даже при вылизывании, сначала всё пишу на Си, убеждаюсь в работоспособности и только потом переписываю узкие места. Убеждаясь, что всё продолжает работать.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

иногда интерпритатор работает медленнее, но код становиться меньше

иногда он работает быстрее, но требует больших команд и код становится больше

иногда он работает и медленнее и код больше

 

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

Если у вас есть объяснения как такое получает мне правда интересно, без иронии...

 

Надо какое-то пространство обсуждения принять. Потому что, скажем, в случае JIT-компиляции, - это нарушение закона сохранения или расширение множества свойств наблюдаемой системы? А то мы так быстро заблудимся :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хотя я совсем не поддерживаю ТС в его утопическом стремлении к чистому ассемблеру - жизнь его научит и отрезвит (в лице работодателя например)

(если он конечно будет профессионально заниматься программированием, а не как любитель).

 

Если ТС уж так хочет сравнить си и асм, то пусть попробует написать поддержку файловой системы через УСБ флешку :biggrin: И потом еще попробует перенести все это счастье на другой проц... А мы посмотрим, сколь лет ему на это понадобится :wacko:

 

ЗЫ. Мы все стремимся, используя более высокоуровневые языки, облегчить себе жизнь, потому что у заказчиков требования тоже растут неплохо. Если 5-10 лет назад им было достаточно настройки устройства через простейшую менюшку с кнопками вниз\вверх, то теперь подавай удаленный доступ, желательно через инет, обновление прошивки по 1 тычку кнопки и т.д. Идите в ногу со временем, а не занимайтесь глупостями в виде чистого асма!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...