[Сергей Борщ 143]

Интересно, где именно происходит сложение "$Port + GPIO_BSRR" в данном случае $Port = 0x40001800, а GPIO_BSRR = 0x10.

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

 

Для такой операции тоже ведь нужно использовать регистры

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

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

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

[allsettingsdone 0]

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

 

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

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

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

Изменено 16 января, 2014 пользователем allsettingsdone

[Golikov 0]

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

 

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

 

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 через год вспомнит чего вы хотели, зачем и почему это должно изменится при смене клока.... :)?

 

 

 

 

[Сергей Борщ 143]

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

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

 

[jcxz 242]

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

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:

[Golikov 0]

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

 

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

 

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

 

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

[jcxz 242]

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

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

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

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

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

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

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

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

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

[_Pasha 0]

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

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

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

[Golikov 0]

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

 

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

 

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

 

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

 

 

 

 

[_Pasha 0]

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

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

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

[Golikov 0]

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

 

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

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

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

 

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

 

 

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

 

 

 

 

[SapegoAL 0]

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

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

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

 

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

 

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

[Сергей Борщ 143]

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

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

 

[_Pasha 0]

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

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

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

 

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

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

 

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

[mantech 53]

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

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

 

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

 

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