удалил весь этот базар про С/С++ и про другие семейства МК.
господа, прекратить тут флудить на посторонние темы. считайте это предупреждением для всех участников темы.
второго предупреждения не будет. кто начнет флудить, того отправлю сразу в бан на 1 сутки.
Transformer-V, поскольку я удалил посты с флудом, кратко объясню тебе:
линейный код быстрее работает, чем компактный. и тут никого не волнует увеличение размера прошивки.

Я же объяснил ситуацию.
В новых МК аббревиатура GPR используется для обозначения 4 регистров ввода/вывода. Можете посмотреть даташит на МК AVR32DA32, раздел 9. РОН и РВВ – это всё таки разные регистры.
Даташит – это, фактически, стандарт, которого надо придерживаться.
В даташитах РОН называют General Purpose Working Registers или General Purpose Register File, но с аббревиатурой типа GPWR я не сталкивался, почему и возник вопрос.

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

Just_Fluffy, насчёт отладки. Можно точки остановки выбирать осознанно, но когда-нибудь и ошибёшься. А если в это время начался процесс накачки большой энергии или подача сильно ядовитого газа, который МК должен был вовремя остановить.
В этом плане отладку с остановкой МК никогда не использовал и даже не рассматривал варианты применения.
Насчёт внутрисхемной отладки.
На плате всегда ставлю разъём, через который производится программирование и отладка. В разъёме пару выводов используется для отладки. Через них МК по ходу выполнения программы выбрасывает в дебаггер (программатор+отладчик) номер точки и значение переменной в этой точке. Эти данные показываются на компьютере.
Алгоритм простой, в программе в нужных точках расставил команды, пару раз кликнул мышкой (компиляция и запуск программатора с отладкой). Это займёт несколько минут, МК начинает работать – и на экране компьютере появляются номера точек и значения выбранных переменных в этих точках, что и нужно для отладки в реальном времени.
Сразу много точек, никакой остановки МК, просто, удобно, дёшево, можно использовать с любым МК.
Наверно, это можно назвать внутрисхемной отладкой.
Как я понял, сейчас с АВР вы работаете без отладчика, это несерьёзно.

Здесь сравнение идёт с обычным ассемблером, а это прошлый век. Даже старенькая программа АБ раз в 5 лучше обычного ассемблера, а современная программа ещё в разы удобней.

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

AQ29, Я почему то так и подумала, что полноценной внутрисхемной отладкой вы не пользовались.
Те "два проводочка", в которые у вас выплевывается лог - это не полноценная отладка. А всего лишь лог.
И если вы где то в программе допустили ошибку, простую, но незаметную с первого раза - вы долго будете логами вылавливать свой косяк.
Касательно непрерываемых процессов - да, логи для этого годятся. А еще годятся измерительные приборы в виде осцилла, лог. анализатора и т.д.

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

Ну и я разочарована в вас. Неужели вы критичные секции работы с ядовитым газом отлаживаете вживую, по логам?
Где то ошиблись в знаке управления заслонкой или словили переполнение - и все, пи%%%ц, надышались газом?
Или спалили большой модный и дорогой мосфет.... И это прикиньте, да, в реалтайме... В логах потом, кашляя ядовитым газом, начинаете смотреть - а почему это у меня мосфет открылся на полную, вместо того что б закрыться....

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


Под простые АВРки у меня, увы, нету программатора, умеющего однопроводную отладку...
А под ЖТАГом в конторе доводилось отлаживать атмеги.
А серьезно это или несерьезно - давайте каждый будет решать за себя.

Да, кстати.
Назовите, пожалуйста, современную программу, которая лучше обычного ассемблера.
Про АБ не говорим, это тупиковая ветвь.

почти все

Martian, я про обычный ассемблер имела ввиду не командную строку, а IDE какую то... КМК, сейчас без среды нормальной с подсветкой синтаксиса, с автоподстановкой и другими плюшками работают редкие индивидуумы - фанаты командной строки и блокнота )))
Я хочу узнать, какую же программу AQ29 считает современной и удобной для себя..

Может я тоже перейду на эту удобную программу и производительность моя поднимется в 100500 раз... А то сижу, как дура, в Атмел Студии седьмой.....

"Лучше" - слишком общее и неконкретное. Протитвоположные требования: высокое быстродействие и компактность сгенерированного кода vs легкость написания, понимаемость и переносимость.

Спойлер

В одной мудрой старой книге прочитал: "Какой фотоаппарат самый лучший? Такового не существует. Иначе выпускали бы только его, зачем же нужны худшие?"

Вопрос не по теме топика.. Вы в студии Атмеги 1608 и 1609 не пробовали отлаживать?

Игорь_396, Нет.
Полноценная внутрисхемная отладка у меня ограничивалась двумя совместными проектами на 128 меге на одной из работ. Сейчас я под АВРки если пишу, то что то свое, совсем простое, что влазит в допотопную мега8 или вообще тиню 2313...
В основном сейчас приходится работать с другими платформами... не АВР.

Мы же сейчас про ассемблер говорим. Код генерируется в голове у программиста. И только излагается им в мнемонику в текстовом редакеторе.
И в этом ключе я и уточняю у AQ29, какую "современную программу" для написания программы на ассемблере он использует и считает лучшей.
Помнится мне, в соседней теме AQ29 с пеной у рта доказывал, что целочисленный логарифм круче и лучше float-овского... И он в своем ассемблере (!) вычисляет этот логарифм одной командой.
По факту там оказался АлгоритмБилдер и какая то сторонняя либа для приблизительного вычисления логарифма.
А этот АБ - это странное поделие, которое и не в ассемблер нормально не дает вникнуть, ни в нормальный ЯВУ.
Но да, цацка красивая - рисуешь блок-схему, а оно само там придумывает ассемблерный код.
Но куда то перенести эту "программу" - можно застрелиться
Здесь AQ29 утверждает, что есть программы еще более крутые, нежели АБ. Вот я и хочу узнать, что это за программы...

Индусы. Хотя это не программы...

Типовое решение при работе с ассемблером - обычный текстовой редактор.
(Гурманы используют понавороченнее редакторы различных авторов).
Далее компилятор следует...
Из типовых для АВРок это "родной" атмелевский avrasm2 (он же и микрощипом поддерживается на сегодня).
Собственно с ним в подавляющем большинстве и работают.
Однако посолиднее - компилятор от комплекта GСС, частью которого является обработка для AVR.
Штука избыточная и довольно слабо на радиолюбительском уровне используемая/изученная.

Касательно "аппаратной внутрисхемной отладки" - это вроде как ныне ИИ. Штука хорошая вроде, но думать своими мозами напрочь отучает.
И как это мы все времена ДО такого средства программы отлаживали?

Удивительно - но ведь работало же безо всяких сбоев и ошибок годами то, что "древними методами" отлаживаось (и по сей день работает).

BOB51, но когда есть полноценная отладка - то гораздо легче становится. И удобнее.
Обычно пошаговая отладка мне нужна в двух случаях:
1. найти какие то логические ошибки либо подлые опечатки, которые для компилятора не опечатки... Типа плюс на минус, или в условии if-а поставлено = вместо == (хотя в таком случае компилятор предупреждает)
Лично моя ошибка - могу вместо |= ляпнуть != , хотя эти символы совершенно в разных углах клавиатуры...
2. исследовать какую то периферию, напрямую играясь ее регистрами...

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

Когда я изучала платформу АВР на тине2313 - то моя отладка вообще был светодиодик на одном из портов.

Ранее МК имели в своем составе только ядро и минимальную периферию (большинство дополнительных модулей внешними микросхемами предоставлялись).
В том случае отладка только ядра касалась.
Далее нашпиговывать стали этой периферией сами МК...
Вот с тех пор и пошли в отладке всяческие "дополнительно-неучтенные нансы"...
причина - в работе программы участвует не только система команд с базовым ядром (обычно детально проработанные изготовителем), но и дополнительная периферия со СВОЕЙ аппаратной базой.
Тогда же и ерраты появляться стали с разделением выпущенных уже МК по группам, в коих те ерраты успели обнаружить.
Вот тут атмел одну бяку допустил - группы еррат вроде в документации есть, а вот как их по имеющемуся кристаллу определить - УВЫ... до сих пор "темный лес" (в отличии от тех же ПИКов к пример). Так что в большей степени окончательно определить работоспособность самоделки только реал-макет может.
Касательно "очепяток" - для ассемблера явление достаточно редкое (зависит от внимательности автора программы и принятой системы команд).
Вполне может быть устранено на уровне специализированного текстового редактора с "подсветкой синтаксиса".

Добрый вечер. Часто в исходниках на С++ встречаются такие ассемблерные вставки.
__asm__ __volatile__("nop" ::: "memory");
далее
__asm__ __volatile__("" ::: "memory");
С первой понятно - пропуск такта, нет операции. А вторая ?

Just_Fluffy, да…, мрачноватую картину вы описали с ядовитым газом.
Могу ещё подлить чёрной краски. А что, если это произошло с серийным дорогущим аппаратом в цехе. И сгорел не только мосфет, но гораздо более ценные вещи. А коллектив в цехе получает деньги после сдачи испытанного аппарата на склад. Сдали аппарат – получили деньги, не сдали – не получили.

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

К счастью, не всё так плохо с отладкой.
В моей отладке выброс переменной в дебаггер происходит быстро и в подавляющем большинстве случаев не влияет на основную работу. Скажем, для выброса 2-хбайтной переменной при частоте кварца 10 МГц понадобится около 5 мксек, совсем немного.
Кроме того, в таких аппаратах есть обработка аварийных ситуаций. Поскольку МК не остановлены, скорее всего, аппарат будет выключен.
А вот при вашей отладке при остановке МК всё плохо.
Есть ещё вариант безопасной отладки. Искомую переменную забросить в SRAM, это всего 6 тактов, а выкинуть её в дебаггер в безопасном свободном окне программы, где задержки по времени не влияют на работу.
На мой взгляд, в моей отладке существенные преимущества: нет остановки МК и анализ сразу во многих точках.
В моей отладке никаких «логов костылить» не надо. Подключил дебаггер к разъёму на плате – и можно работать. Кстати, что такое лог при отладке – не знаю.
Из плюсов у вас есть пошаговая отладка. На мой взгляд, это малосущественно. Ошибка может находиться на расстоянии, скажем, в 1000 строк от точки остановки, сколько времени вы будете туда шагать.
Почему считаете, что в моей отладке трудно найти простую ошибку?
Расставить команды выброса переменных и запрограммировать МК – это по времени минуты. Через несколько таких операций обычно выходишь на строку с ошибкой, и проблема решена.
В этом плане странная позиция у ВОВ51 по поводу аппаратной внутрисхемной отладки. «Думать мозгами» и тратить драгоценное время надо не при отладке, а при разработке программы, здесь есть где развернуться.

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

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

Starichok51, странная получается ситуация. Скажем, разработчик пишет программу для какого-нибудь устройства, в которой написал свою программу деления. Она может быть совсем неоптимальной, но проходит по параметрам. Разработчик её не оптимизирует, не тратит время, ни ему к чему, устройство хорошо работает. Это понятно.
Но с компилятором совсем другая ситуация. Перед разработчиком стоит задача написать как раз оптимальную программу деления, ведь ею будут пользоваться тысячи людей.
Возможно, там складывалась авральная ситуация из советских времён: к концу месяца надо выдать готовую программу. Главное, чтобы правильно работала, а то, что она не оптимальна, для СИ-шников сойдёт.

Приведу пример.
Пусть не про AVR, но это не существенно.
В ARM-ах нет EEPROM-а. Его эмулируют в программном флеше. Чтобы продлить жизнь флешу, делают скользящую запись массива EEPROM. То есть каждая новая запись ведет к смещению всего EEPROM на его величину. И так пока не будет полностью занята вся страница стирания флеша. Потом всю страницу стирают и начинают сначала. Таким образом, если EEPROM в 16 раз короче страницы, то нагрузка на флеш упадет в 16 раз.
Так вот, я допустил ошибку в условии определения конца страницы. Но я этого не знал. Просто вдруг как бы слетала прошивка при очередном сохранении в EEPROM НА КРАЮ СТАНИЦЫ. А происходило это потому, что поиск края текущего EEPROM из-за ошибки проскакивал мимо и улетал на хардфол по ошибке адреса.
Найти достаточно быстро я смог лишь тогда, когда ставил бряк на начало поиска и ПО ШАГАМ проходил всю процедуру поиска, наблюдая за указателем и содержимым по указателю.
Сделать это через порт, сами понимаете, принципиально невозможно, ибо ПРОГРАММА НЕ РАБОТОСПОСОБНА.
Да и нет у меня свободных УАРТов в этом проекте. Все заняты.

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

Для этого нужно правильно выбирать точку останова. Да и останов нужен, чтобы сориентироваться в значениях переменных, контекстов и прочей мути. И аналитическим мышлением вычислить причину бага.
Сами понимаете, что когда доступен весь МК с потрохами для наблюдения в ОПРЕДЕЛЕННОМ временнОм срезе (там где бряк), то это на порядки удобнее, чем последовательный вывод, где даже захват данных в буфер не может быть синхронным.

AQ29
Все зависит от поставленных задач и имеющихся средств для их решения.
Большинство случаев, когда при разработке устройств применяется "чистый ассемблер" имеют жестко заданные условия.
В этом случае разработка начинается еще на уровне схемотехники, детальной проработки документации и алгоритмов, которые должно отрабатывать устройство.
Возможные "точки нестабильности" уже на данном (начальном) уровне выявляются. Соответственно и методики контроля по ним заранее определяются - где аппаратно, где программно.
И лишь затем уже программа пишется с учетом всего, что предварительно получено было.
Причем исключительно для того устройства, что было задано в проекте (в некоторых случаях с учетом некоторых узких рамок "возможной дальнейшей модернизации").
С одной стороны вроде бы нерационально - каждый проект полностью "с нуля" и естественно программа никак не приспособлена к переносу на другую схему/аппаратную базу.
Но с другой - кому что требуется.

принципиально как раз таки возможно...

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

Как говорил МихалМихалыч - Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел.
Прошу прощения за оффтоп.

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

Но к сожалению, в модный современный алгоритм-билдер внутрисхемную отладку, увы, не завезли... Только команду логарифма....

И, кстати, название современной программы для написания программ на ассемблере для AVR нам так и не сказали....

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