LINUX.ORG.RU
ФорумTalks

C или ASM

 


0

2

на микроконтроллерах?

Сколько ни пишут, что компиляторы умеют оптимизировать лучше человека, но факты говорят за себя: код на асме получается короче, чем сгенерированный avr-gcc, даже с -Os. Раза в полтора-два.

Это существенно вызвано тем, что там, где я могу хранить переменную в отдельном регистре под нее, avr-gcc предпочитает хранить ее в памяти, подгружая в регистры для использования, а затем выгружая обратно.

★★★★★

Последнее исправление: cvs-255 (всего исправлений: 1)

если из любви к искусству - то ассемблер

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

Harald ★★★★★
()

если хорошо знаешь целевой ASM - конечно пиши на нём, в чём проблема?

зы. ни разу кстати не слышал эквивалента «быдлокод» в отношении asm. то-ли изрыгатели неосилили, то ли по смыслу не подходит :-)

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

ни разу кстати не слышал эквивалента «быдлокод» в отношении asm. то-ли изрыгатели неосилили, то ли по смыслу не подходит :-)

Пример: для выравнивании количества тактов в 2-х ветвях программы жёсткого реального времени я иногда использовал пакеты [NOP, NOP, ..., NOP] — задержка просто считается «на пальцах» и думать «не нужно» © :)

quickquest ★★★★★
()

где я могу хранить переменную в отдельном регистре под нее, avr-gcc предпочитает хранить ее в памяти

Ключевое слово register? Ну или патчить GCC, чтобы он лучше дружил с avr. А то под те же итаниумы пару лет назад у GCC были серьёзные проблемы с разворачиванием циклов.

kim-roader ★★
()

Си конечно, если делом заниматься, а не для искусства.

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

Для ARM GCC генерит нормальный код и ситуация постоянно улучшается. Для AVR GCC генерит что генерит и все только хуже становится с новыми версиями. Но смысла возиться с AVR особого нет.

alexru ★★★★
()
Последнее исправление: alexru (всего исправлений: 1)

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

ilovewindows ★★★★★
()
Ответ на: комментарий от cvs-255

Ассемблерные вставочки могут помочь. Это компромисс. Да и на Си по-разному писать можно. Чего там такого избыточного, чтоб не влезло ?

frugurt
()
Ответ на: комментарий от Harald

Да, и? Я что должен везде пихать Atmel и AVR, даже если в этом нет смысла?

У Atmel-а полно хороших МК на ARM и все идет к тому, что их будет больше и больше. Все хотят ARM и никто не хочет vendor lock-in.

alexru ★★★★
()
Ответ на: комментарий от cvs-255

Хотя да, если говнокодить, то никуда не влезет )

frugurt
()
Ответ на: комментарий от Lincor

Тут меня убеждали что ваш XOR AX,AX используют сейчас только ламеры и пенсионеры

ilovewindows ★★★★★
()
Ответ на: комментарий от cvs-255

На современных процессорах - ничем, но Ъ хакиров это не останавливает.

alexru ★★★★
()
Ответ на: комментарий от Harald

Как такие кощунственные вещи говорить можно! :)

Я тут не для рекламы, рекламой пусть маркетологи занимаются.

Да и ARM для многих вещей избыточен

Согласен, но с каждым днем разница все меньше и меньше. Начинать с AVR точно смысла нет. Это подтверждает и то, что Atmel University Program переехала с AVR на ARM с этого года.

alexru ★★★★
()
Ответ на: комментарий от quickquest

иногда использовал пакеты [NOP, NOP, ..., NOP] — задержка просто считается «на пальцах» и думать «не нужно» © :)

это-же фича, наглухо отсутствующая в ближайшем С.

MKuznetsov ★★★★★
()
Ответ на: комментарий от alexru

Согласен, но с каждым днем разница все меньше и меньше. Начинать с AVR точно смысла нет.

А вот как насчёт таких соображений? Я не знаю, как оно по факту, но по идее AVR-ки, как более примитивные, наверное производятся по более дубовому техпроцессу, и соответственно должны быть более надёжными в плане устойчивости к радиации, колебаниям напряжения, помехам и прочей фигне. Т.е. в плане надёжности они должны быть лучше ARM

Harald ★★★★★
()
Ответ на: комментарий от Harald

Почти все последние изменения в семействе AVR - это die shrink уже существующих МК, так что тех процесс близок.

И даже если и нет, то радиационная устойчивость для бытовых МК не гарантируется, так что без разницы, все-равно применять нельзя. В плане помех они тоже почти одинаковы, за исключением того, что большинство AVR может работать от 5 В, что потенциально может немного помочь с помехами.

Но если схемотехника настолько плоха, что помехи реально мешают МК, то в любом случае нужно переделывать.

alexru ★★★★
()
Ответ на: комментарий от alexru

И да, были случаи когда устройство работало на более дубовой версии МК и не работает на новой, хотя они 100% совместимы по параметрам. Но во всех этих случаях Abslute Maximum Ratings были нарушены, просто старые чипы менее чувствительны.

alexru ★★★★
()
Ответ на: комментарий от Harald

ARM для многих вещей избыточен

Для мыргания светодиодом и AVR избыточен. А на более серьёзных приложениях ARM-ы удобнее в разы, что на сях, что на ассемблере.

one_more_hokum ★★★
()

Не, нафиг ASM. Работа замедляется значительно, увеличивается цена разработки, ухудшается сопровождаемость. Если очень надо, то лучше писать на Си, а какие-то критические куски оптимизировать на ассемблере.

Zubok ★★★★★
()
Ответ на: комментарий от kim-roader

Ну или патчить GCC

Да там весь register allocator с нуля переписать надо!

Pythagoras ★★
()
Ответ на: комментарий от cvs-255

Инструкция получается короче как минимум (1 байт против 3 в 16-битном режиме и 5 в 32-битном).

KivApple ★★★★★
()
Ответ на: комментарий от Harald

А если железка уже выпущена и это доработка прошивки?

KivApple ★★★★★
()
Ответ на: комментарий от alexru

Начинать с AVR точно смысла нет.

Спорное мнение. На AVR в отличии от ARM нет кучи режимов тактирования, периферия попроще и т. д. При использовании AVR можно вообще использовать только 1 даташит, ничего не гуглить, настроить нужный периферийный модуль в пару строчек в виде присваивания регистрам и работать.

Как помигать светодиодом на AVR?

DDRB |= _BV(1);
while (1) {
PORTB ^= _BV(1);
_delay_ms(500);
}

Как помигать светодиодом на ARM?

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
GPIO_InitTypeDef gpio;
gpio.GPIO_Pin = GPIO_Pin_12;
gpio.GPIO_Mode = GPIO_Mode_Out_PP;
gpio.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOA, &gpio);
while (1) {
GPIO_SetBits(GPIOA, GPIO_Pin_12);
delay(500);
GPIO_ResetBits(GPIOA, GPIO_Pin_12);
delay(500);
}

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

В результате для новичка таки будет проще AVR, с его скромной, зато очень простой и понятной периферией, которая настраивается в пару строчек.

Я до сих пор не могу до конца разобраться с работой с I2C на STM32, хотя на AVR всё заводилось с пол-пинка. То ли я где-то косячу, то ли ошибка в стандартной библиотеке. Самое интересно, что частично оно работает, а через пару секунд чтений зависает.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)

Зависит от задачи. Что-то примитивное можно и на асме, можно и на C. А вот большой проект на асме писать тяжко. Сишечка берёт своим количеством готовых функций. Недавно написал человеку для авр на с программку, которая получала два uint16_t и находила логарифм их отношения (децибелятор я делал). Этот мужичок хороший электронщик, но с не знает, всю жизнь писал на асме под pic. Реализовывать эту арифметику на асме он просто замахался бы. Так что вывод очевиден.

ramon13666 ★★★
()

C
Плюсом будет то, что не только мк, но и другой код читать/писать можно. Ну и портирование и прочее легче

sehellion ★★★★★
()

Просто у avr-gcc плохой кодогенератор. Коммерческие компиляторы для AVR генерят куда оптимальнее.

oneliner
()
Ответ на: комментарий от KivApple

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

n_play
()

Сколько ни пишут, что компиляторы умеют оптимизировать лучше человека, но факты говорят за себя: код на асме получается короче, чем сгенерированный avr-gcc, даже с -Os. Раза в полтора-два.

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

какие ещё флажки юзал кроме Os?

n_play
()
Ответ на: комментарий от n_play

Не совсем. Разница в том, что у AVR более простая периферия. Так за порт ввода-вывода отвечает всего три регистра DDRx, PORTx и PINx (направление ввода-вывода, запись в порт/включения подтяжки в режиме входа, чтение из порта), у которых каждый бит тупо соответствует нужной ножке. В случае использования периферии типа USART или I2C ножки автоматически переключаются из режима GPIO в нужный режим. И много ещё такого.

Да, на ARM больше всяких функций и режимов работы периферии, но новичку они обычно не нужны, зато инициализация простейших вещей отнимает кучу строчек, что может запутать и отпугнуть. Для не сложных проектов AVR хватает за глаза, а дальше уже можно делать выбор.

KivApple ★★★★★
()
Ответ на: комментарий от n_play

Когда я последний раз смотрел на avr-gcc, он не умел использовать индексные регистры в качестве стека данных, отчего все аргументы функций и локальные переменные адресовались через манипуляции с SP, это серьёзно раздувало прологи/эпилоги функций и код в целом.

oneliner
()

C, ясен пень!

gcc давным-давно отлично оптимизирует. Правда, есть проблема с STM8: для них кроме sdcc нет компилятора, а sdcc нихрена не умеет оптимизацию.

Ну и еще: как ты будешь, скажем, TCP/IP реализовывать на ассемблере? Или USB?

А еще сейчас такие офигенные МК появились, что на них вполне можно даже считать float'ы и double'ы (а всего-то лет пять назад на человека, который в коде под МК писал float, тыкали пальцем и крутили у виска).

И да: оптимизация оптимизации рознь! Все на свете не соптимизируешь.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от MKuznetsov

Оно элементарно втыкается как ассемблерная вставка. Изредка эта хрень нужна (например, чтобы при старте main() выдержать паузу, необходимую для инициализации USB).

Понятно, что в основной программе только идиот будет nop'ами задержки на фиксированный промежуток времени выставлять: во-первых, для этого есть таймеры; а во-вторых, первое же прерывание эту фиксированную задержку сделает неопределенной.

Eddy_Em ☆☆☆☆☆
()

P.S.

И да, выкидывай нафиг эти атмели. STM32 рвет их по всем направлениям!

Eddy_Em ☆☆☆☆☆
()
23 января 2016 г.
Ответ на: комментарий от alexru

Ну для некоторых вещей attiny самое то. Простая инициализация периферии и мало ног

cvs-255 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.