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

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

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

Сообщение отредактировал allsettingsdone - Jan 16 2014, 13:36

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

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

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

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

Вы не правы. Все современные ассемблеры точно так же умеют вычислять значения константных выражений. И даже 10 лет назад уже умели.
И даже более того - средства макроязыка в ассемблерах как правило более мощные чем препроцессор си.
Мне часто очень не хватает макро-возможностей асма в си, когда вспоминаю что мог позволить себе в асме...
Но си скован стандартом, а ассемблер - нет.
Хотя я совсем не поддерживаю ТС в его утопическом стремлении к чистому ассемблеру - жизнь его научит и отрезвит (в лице работодателя например)
(если он конечно будет профессионально заниматься программированием, а не как любитель).

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

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

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

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

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

На TI C55xx если мне не изменяет память 6-тактный конвеер и переходы (не внутри RPT) 4-5-6 тактов.
Там я применял много способов оптимизации в том числе и конвееризацию вычислений внутри циклов, когда одновременно выполнялась голова цепочки команд обработки сэмпла в одном АЛУ в то время как
в те же самые такты выполнялся хвост этой цепочки команд для предыдущего сэмпла в другом АЛУ.
Что уж говорить про параллельные чтения/сохранения в ОЗУ.
И зря зареклись. Никогда ещё ни до ни после я по эффективности кода так не превосходил си-компилятор как тогда - мой код на асм получался в РАЗЫ меньше и быстрее.
Оптимизировав инструкции по размеру, спарив их, убрав все штрафы (stall-ы), раскидав выполнение по разным шагам конвеера, загнав цикл в RPTBLOCAL, использовав разные фичи типа циклической адресации и т.п. можно было в разы уделать компилятор
А вот на ARM выигрыш от такой оптимизации будет значительно меньше и смысл в ней значительно меньше.
Изредка, когда приходится что-то написать на асм для ARM/Cortex-M с оптимизацией времени выполнения, с тоской вспоминаю C55xx....

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

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

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



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

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

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

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

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


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

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

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

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

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

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

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

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