ASM: приказали долго жить?, Сколько еще продержится Опции

[OlegIvanov]

На досуге интересует мнение всех кто занимается программированием МК - коль долго еще возможно будет использовать ASM в разработках. Понимаю что тапочки и нужно спешить осваивать C (аппаратные возможности растут и проще написать A*B, например...). Но как сейчас какие плюсы - пишешь то что надо, не зависишь от уровня тупости разработчиков C компилятора, т.е. все на виду (предпочитаю надежность быстроте разработки). Но бесит реализация арифметики на ASMе. Ваше мнение, господа?

[prottoss]

На досуге интересует мнение всех кто занимается программированием МК - коль долго еще возможно будет использовать ASM в разработках.

ИМХО Асм в разработках будет использоваться всегда, потому как есть круг задач, для которых использование Си малоопроавдано, а порой и невозможно. В то же время большинство задач, наоборот, лучше создавать изначально на Си. Универсальность, легкость понимания, внедрение новых модулей, скорость разработки etc... Можно долго перечислять достоинства языка Си (и не только Си) перед Ассемблером

[haker_fox]

На досуге интересует мнение всех кто занимается программированием МК - коль долго еще возможно будет использовать ASM в разработках. Понимаю что тапочки и нужно спешить осваивать C (аппаратные возможности растут и проще написать A*B, например...). Но как сейчас какие плюсы - пишешь то что надо, не зависишь от уровня тупости разработчиков C компилятора, т.е. все на виду (предпочитаю надежность быстроте разработки). Но бесит реализация арифметики на ASMе. Ваше мнение, господа?

1. Какой тип МК имеется в виду?
2. Будут ли Ваши проекты развиваться в будущем? Если да, то не исключен переход на другие архитектуы, тогда нужно писать на СИ.

А вообще в инете много "религиозных" тем "АСМ vs. СИ"
Рекомендую почитать:
1. Это.
2. Это.

[arttab]

Даже программируя на асме не всегда можно получить что хотел - вмешивается компилятор. Иногда неудачно.
Согласен с предыдущими высказываниями - асм будет жить для определенных задач. Будут расти в мк объемы памяти, производительность повышаться, но найдутся задачи где нужен асм (например на с тяжело обеспечить точные интервалы, сопостовимые с временем выполнения команд. например 50-30 тактов для АВР)

[Harbour]

Сильно на C разгонишься когда памяти 512 байт.

[vanner]

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

2 arttab:
Первый раз слышу, чтобы компилятор мешал при компиляции ассемблерного кода. Может примерчик.

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

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

[dxp]

Сильно на C разгонишься когда памяти 512 байт.

Почти не слабее, чем на асме. На AT90S8515 все программы писались на С. В течение нескольких лет (с 1998 до 200х) пока не появились недорогие меги. Сам С никаких особых требований к памяти не предъявляет. Разве что стек для данных. Но это не мешает и даже наоборот способствует экономии памяти - память шарится под локальные объекты. Обычно стека в 50-80 байт хватало за глаза. В остальном память тратится ровно столько же, сколько и в асмовой программе - сколько глобальных/статических объектов там разместил, столько и съелось.

Попутно в те же времена и на AT90S2313 со 128 байтами ОЗУ вполне успешно писались программы на С без какого-либо напряга по памяти данных - там больше размер флеши напрягал, 2 килобайта маловато. А уж 512 байт ОЗУ - это даже роскошно было.

[arttab]

Глюки компилятора неисключены. и ошибки юзера, которые он не выдал.
Попробую чеговспомнить:
использовал мнемонику вида (1 << х) и для части команд она интарпитировалась неправильно. Помоему с портом работал и получалось что я хочу выставить бит 2^х в порте в 1. До х =3 не ругался и делал не то что я хотел. и с вводом цифр раз накасячил, а он ошибок не выдал и присвоил 0 значения.
Оптимизация в студии есть - вместо загрузки в рон 0, поменял на обнуление регистра рон

[defunct]

Даже программируя на асме не всегда можно получить что хотел - вмешивается компилятор. Иногда неудачно.

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

[beer_warrior]

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

[arttab]

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

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

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

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

[_Bill]

На досуге интересует мнение всех кто занимается программированием МК - коль долго еще возможно будет использовать ASM в разработках. Понимаю что тапочки и нужно спешить осваивать C (аппаратные возможности растут и проще написать A*B, например...). Но как сейчас какие плюсы - пишешь то что надо, не зависишь от уровня тупости разработчиков C компилятора, т.е. все на виду (предпочитаю надежность быстроте разработки). Но бесит реализация арифметики на ASMе. Ваше мнение, господа?

Ассемблер будет жить ВСЕГДА. А что касается арифметики, то все арифметические операции можно оформить в виде подпрограмм, это делается только один раз. Дальше ими только пользуешься.
Есть свои ++ при программировании как на ассемблере, так и на Си. Хотя я Использую Си больше 20 лет, но ассемблер не забываю. Ассемблер - это для души.
Если говорить о Си, то современные компиляторы генерируют код не намного хуже, чем это сделал бы программист. Мне, например, удается соптимизировать код, сгенерированный компилятором, от силы % на 10. Естественно, что прогаммист должен "прочувствовать" используемый им компилятор и помогать ему генерировать эффективный код.

[otrog]

Знаю людей, которые мегу 128 асемблерным кодом забили и им этой меги столо не хватать

ИМХО если бы писали на С, еще и место бы осталось.

[IgorKossak]

Хм, надо же.
Опять подняли религиозную тему!
Накняпали уже 11 постов и не переругались
Растём!
Теперь по теме.
Знать асм и писать на асме это далеко не одно и то же.
Здесь я где-то согласен с beer_warrior, что отлаживать тонкости, особенно связанные с железом, зная асм легче.
Другое дело - писать. Стараюсь в своих проектах избегать этого где только возможно.

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

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

2 arttab:
Первый раз слышу, чтобы компилятор мешал при компиляции ассемблерного кода. Может примерчик.

Пожалуйста. сделайте RJMP на +0x400 слов (переход из таблицы векторов Boot-области в Application). Согласно описанию AVR Instruction Set в качестве аргумента RJMP берет смещение в словах. Однако "втюхать" это смещение ассемблеру от IAR "в лоб" невозможно. Асм от WinAVR такое тоже есть отказался.

[white.wind]

Попробовал asm, ничего, не страшный совсем

Счас играю с видеовыводом на МК. Среди реализаций есть полностью на Си, однако помогает знать что генерит компилятор.

[IgorKossak]

... сделайте RJMP на +0x400 слов (переход из таблицы векторов Boot-области в Application). Согласно описанию AVR Instruction Set в качестве аргумента RJMP берет смещение в словах. Однако "втюхать" это смещение ассемблеру от IAR "в лоб" невозможно. Асм от WinAVR такое тоже есть отказался.

В Вашем случае предполагается "сворачивание" адреса через 0.
В EWAWR_AssemblerReference сказано:

In the options -v2, -v3, and -v4, jumps do not wrap.

и ещё:

-v3 ≤ 128 Kbytes code. RJMP wraparound is not possible, that is
RJMP and RCALL cannot reach the entire address space.

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

... сделайте RJMP на +0x400 слов (переход из таблицы векторов Boot-области в Application). Согласно описанию AVR Instruction Set в качестве аргумента RJMP берет смещение в словах. Однако "втюхать" это смещение ассемблеру от IAR "в лоб" невозможно. Асм от WinAVR такое тоже есть отказался.

В Вашем случае предполагается "сворачивание" адреса через 0.

Это следствие. Я прошу сделать RJMP вперед на 0x400 слов.
Syntax: Operands:
RJMP k -2K <k <2K
16-bit Opcode:
1100 kkkk kkkk kkkk
так вот я хочу получить после ассемблирования 16-битный opcode 1100 0100 0000 0000

В EWAWR_AssemblerReference сказано:

In the options -v2, -v3, and -v4, jumps do not wrap.

и ещё:

-v3 ≤ 128 Kbytes code. RJMP wraparound is not possible, that is
RJMP and RCALL cannot reach the entire address space.

Я не прошу (для меги-8) компилятор догадаться что для перехода с адреса 0x1802 в адрес 0x0002 нужно использовать wrap, я об этом уже догадался за него. Я хочу получить вполне легитимный опкод 0xC400. Исходно вопрос стоял:

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

Вот я и привожу пример: согласно описанию системы команд RJMP k, k может быть +-2К, а ассемблер не дает мне подставить это самое k. Решение есть, но через одно место.

[vanner]

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

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

Это понятно, разработчики компиляторов тоже люди, и тоже допускают ошибки. Но как это связано с самим ассемблером?

Да это не ошибка. Если на нужном адресе поставить метку и сделать RJMP на метку все будет отассемблировано как надо. С ассемблером это связано напрямую (именно с тем "компилятором" с языка ассемблера, каламбур :-)) ). Вот если бы мы писали сразу в кодах, тогда да - никаких ограничений, кроме времени жизни и психического здоровья разработчика.

[Serj78]

начинал на С, (cv) потом для тини12 пришлось поизучать асм, потом вернулся к си, уже с ассемблерными вставками- на 8мгц на си с тв сигналом работать было трудновато.

Сообщение отредактировал Serj78 - Jun 20 2006, 10:25

[kolobok0]

...Ассемблер - это для души...

Апсолютно верно...

с уважением
(круглый)

[OlegIvanov]

... сделайте RJMP на +0x400 слов (переход из таблицы векторов Boot-области в Application). Согласно описанию AVR Instruction Set в качестве аргумента RJMP берет смещение в словах. Однако "втюхать" это смещение ассемблеру от IAR "в лоб" невозможно. Асм от WinAVR такое тоже есть отказался.

В Вашем случае предполагается "сворачивание" адреса через 0.

Это следствие. Я прошу сделать RJMP вперед на 0x400 слов.
Syntax: Operands:
RJMP k -2K <k <2K
16-bit Opcode:
1100 kkkk kkkk kkkk
так вот я хочу получить после ассемблирования 16-битный opcode 1100 0100 0000 0000

В EWAWR_AssemblerReference сказано:

In the options -v2, -v3, and -v4, jumps do not wrap.

и ещё:

-v3 ≤ 128 Kbytes code. RJMP wraparound is not possible, that is
RJMP and RCALL cannot reach the entire address space.

Я не прошу (для меги-8) компилятор догадаться что для перехода с адреса 0x1802 в адрес 0x0002 нужно использовать wrap, я об этом уже догадался за него. Я хочу получить вполне легитимный опкод 0xC400. Исходно вопрос стоял:

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

Вот я и привожу пример: согласно описанию системы команд RJMP k, k может быть +-2К, а ассемблер не дает мне подставить это самое k. Решение есть, но через одно место.

Все там нормально рулит +/-2k нужно понимать +/-2047 (байт) = +/-1023 (слов)

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

Все там нормально рулит +/-2k нужно понимать +/-2047 (байт) = +/-1023 (слов)

1) Relative jump to an address within PC - 2K +1 and PC + 2K (words) Таки +- 2К слов.
2) речь не о превышении разрядной сетки, а о невозможности указания значения операнда "в лоб"

Код

      RJMP  0x400
Error[400]: Absolute operand is not possible here

Решение есть, но оно "через задницу":

Код

    COMMON    DRIVER_VECTORS:CODE:ROOT(1)
    ORG        INT0_vect
    RJMP    SFE(DRIVER_VECTORS) - SFB(DRIVER_VECTORS) - 0x024; Redirect to application section
    ORG        INT1_vect
    RJMP    SFE(DRIVER_VECTORS) - SFB(DRIVER_VECTORS) - 0x022; Redirect to application section
    ORG        TIMER2_COMP_vect
    RJMP    SFE(DRIVER_VECTORS) - SFB(DRIVER_VECTORS) - 0x020; Redirect to application section
    ORG        TIMER2_OVF_vect
    RJMP    SFE(DRIVER_VECTORS) - SFB(DRIVER_VECTORS) - 0x01E; Redirect to application section
    ORG        TIMER1_CAPT_vect

И все эти извращения компилируются в одинаковые опкоды C400

Сообщение отредактировал Сергей Борщ - Jun 20 2006, 16:02

[defunct]

Попробовал asm, ничего, не страшный совсем

Счас играю с видеовыводом на МК. Среди реализаций есть полностью на Си, однако помогает знать что генерит компилятор.

Он не просто не страшный совсем, я бы сказал AVR-ASM самый удачный и простой в использовании среди всех других ассемблеров MK. Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C. Порой даже проще (вчастности обработку прерываний проще и качественнее делать на asm).

[SasaVitebsk]

Это следствие. Я прошу сделать RJMP вперед на 0x400 слов.
Syntax: Operands:
RJMP k -2K <k <2K
16-bit Opcode:
1100 kkkk kkkk kkkk
так вот я хочу получить после ассемблирования 16-битный opcode 1100 0100 0000 0000

Простите, может я не понял вопроса, а что вариант
RJMP PC+$400
не катит?

Вообще такие вещи, я так не делаю. Предлагаю вариант.

ComExe:
ldi Zl, low(TabCom) ; Загрузить адрес
ldi Zh, high(TabCom) ; таблицы комманд в Z
add Zl, wl ; прибавить смещение
adc Zh, Yh ; скорректировать (Yh=0)
ijmp ; и перейти на выполнение комманды
.....

; Набор основных комманд

rjmp a0 ; a(0)
rjmp Ok2 ; b(0-1) (для совместимости)
rjmp Ok2 ; с(0-1) (для совместимости)
rjmp d0 ; d
rjmp e0 ; e(0-1)
.....

; *** Установить соединение (A0) ***
a0: cpi wh, 1
brsh errC
rjmp ata ; перейти на установление соединения

; *** Набор номера ***
d0: rcall swup ; Поднять трубку
ld wl, Y
andi wl, $df
.....

[dxp]

Попробовал asm, ничего, не страшный совсем

Счас играю с видеовыводом на МК. Среди реализаций есть полностью на Си, однако помогает знать что генерит компилятор.

Он не просто не страшный совсем, я бы сказал AVR-ASM самый удачный и простой в использовании среди всех других ассемблеров MK.

Очень спорный тезис. Меня так после асма 51-го AVR'овский просто ломал. Немного лучше стало, когда слепил кучу макросов, чтобы уменьшить объем писанины. Когда перешел на С (а это оказалось оченно правильным, т.к. С код на AVR ложится очень неплохо), то началась просто другая жизнь. Хотя асм AVR'овский не забывал - частенько инспектировал кодогенерацию по листингам. На сегодня могу сказать, что и асм MSP430 куда как удобнее и приятнее, чем AVR'овский.

Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C.

Опять не соглашусь - сложнее, дольше и получается громоздкий (по сравненю с С) и запутанный код, в котором через пару месяцев и автору с ходу не разобраться. Из всех асмов, которые приходилось видеть, самым похожим на С является ассемблер для Blackfin'а. AVR'у в этом смысле до Blackfin'а далеко.

Порой даже проще (вчастности обработку прерываний проще и качественнее делать на asm).

Качественнее в смысле быстродействия и размера кода - да. Проще - нет.

[forever failure]

коль долго еще возможно будет использовать ASM в разработках. Ваше мнение, господа?

Ответ - всегда, однозначно. При этом знать Ц и Ц++ тоже. Можно програмить на ЯВУ в основном, но асм знать - обязательно, особенно на МК.

[CDT]

Простите, может я не понял вопроса, а что вариант
RJMP PC+$400
не катит?

Это товарищ вредничает.

Одной мнемоникой все переходы и вызовы (это относиться и к условным переходам):
rjmp Lable
rjmp 0x400
rjmp pc+0x400
rjmp pc-0x400

.equ JmpShift=Lable1-Lable2
rjmp pc+JmpShift
rjmp pc-JmpShift

Только относительные скачки на конкретно заданное число шагов (+0х400) применять очень не удобно, поскольку при вводе одной команды по средине надо все поправлять ручками, вычисляя на калькуляторе.

Вообще такие вещи, я так не делаю. Предлагаю вариант.

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


Ругает народ AVR assembler. А в версии 2 очень не плохие макросы можно делать, передавая в них имена регистров и регистровых пар.
Хочешь - систему команд перепиши, хочешь - собери библиотеку и одним движением настрой ее на свои регистры, память и процессор:
--------------------------------------------------
.macro LDI2
ldi @0,low(@2)
ldi @1,high(@2)
.endm

----------------------------------------------------
.macro CPI2_2
cpi @1,high(@2)
brne _quit
cpi @0,low(@2)
_quit:
.endm

---------------------------------------------------------
.macro ADD2_1
add @0,@2
brcc _ADD2
subi @1,-1
_ADD2:
.endm

И пишется быстрее, и читается нормально.

ldi2 zl,zh, JmpTable
add2_1 zl,zh,rStatus
cpi2_2 zl,zh, JmpTableEnd
brsh Error
ijmp

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

[white.wind]

..хотя бы по тому, что для создания компилятора С он тоже нужен.

Не обязательно, пару лет назад мы с ребятами баловались над созданием расширения C#. По началу все (парсер, генерация) писалось на самом C#, а потом расширение парсило и генерировало само себя Вроде даже есть название такому подходу.

[Alex_Pol]

2 OlegIvanov. Слухи о смерти асма сильно преувеличены. Почти 30 лет на нём пишу. Начинал с КР580 (до чего приятный ассемблер), потом Зилог, 286, пик (гадость редкая) MSP (напомнило 8080),
сейчас АВР. Если не страдаешь склерозом, можно спокойно на нём писать. И на коментарии не скупиться. Всё сказанное, ясное дело, ИМХО.

[tag]

Хм, надо же.
Опять подняли религиозную тему!
Накняпали уже 11 постов и не переругались
Растём!
Теперь по теме.
Знать асм и писать на асме это далеко не одно и то же.
Здесь я где-то согласен с beer_warrior, что отлаживать тонкости, особенно связанные с железом, зная асм легче.
Другое дело - писать. Стараюсь в своих проектах избегать этого где только возможно.

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

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

Простите, может я не понял вопроса, а что вариант
RJMP PC+$400
не катит?

Проверил. Действительно сработало (для IAR получилось RJMP $+800). Запомню. А я как только ни пробовал...

P.S. Для тех кто писал позже: Я знаю что в общем случае использовать вычисленную самостоятельно константу смещения - это грязный хак, и что транслятор с языка ассемблера предоставляет для решения этой проблемы очень удобное средство - метки, но в том конкретном случае расстояние между одноименными векторами в boot и application областях фиксировано и одинаковое, а программа писалась с расчетом чтобы можно безболезненно поделить ее на две - для application и для boot области. И чтобы при этом будучи залиты в один кристалл они дружили между собой пользуя куски кода друг друга. Ну в общем "так было надо!"

Сообщение отредактировал Сергей Борщ - Jun 21 2006, 16:28

[SasaVitebsk]

Простите, может я не понял вопроса, а что вариант
RJMP PC+$400
не катит?

Проверил. Действительно сработало (для IAR получилось RJMP $+800). Запомню. А я как только ни пробовал...

P.S. Для тех кто писал позже: Я знаю что в общем случае использовать вычисленную самостоятельно константу смещения - это грязный хак, и что транслятор с языка ассемблера предоставляет для решения этой проблемы очень удобное средство - метки, но в том конкретном случае расстояние между одноименными векторами в boot и application областях фиксировано и одинаковое, а программа писалась с расчетом чтобы можно безболезненно поделить ее на две - для application и для boot области. И чтобы при этом будучи залиты в один кристалл они дружили между собой пользуя куски кода друг друга. Ну в общем "так было надо!"

1) Такой вариант написания часто используется при написании макросов. Ну например:
.MACRO LongBREQ
brne PC+2
rjmp @1
.ENDMACRO
Иногда для этих же целей используются локальные метки.

2) Применение значка $ для обозначения PC является "более стандартным". Практически во всех ASM я использовал такой вариант. Например нижеследующий вариант считается стандартной командой стоп.
jmp $

3) Я действительно избегаю всех чисел. Если необходим косвенный переход, то использую разность меток. Типа
step1:
....
rjmp $+(step2-step1)
....
step2:

Ещё чаще использую другой приём.
Очень часто в голове крутятся несколько задач. Назовём их к примеру step1,2,3,... Я пишу их таким образом чтобы был один вход и один выход. Поэтому они получаются перемещаемыми. Делаю я это так...

// Шаг 1
step1:
...
// тело
...
step1_end:

// Шаг 2
step2:
...
// тело
...
step2_end:

.....

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


Теперь по теме. Мне кажется предсказывать, - дело не благодарное. Конечно производительность и ресурсы камней растут. С др. стороны написание на Си строки типа:
PORTE &= ~(1<<DIR_RS485)
Которое так "грамотно" компилится на IAR AVR, может оказаться не таким грамотным для другого МП. Всвязи с этим хочется сказать, что программирование на С не так уж и независимо, как этого бы хотелось. А знание ассемблера частенько помогает понять действия компилятора, и соответственно подход к написанию прог на языке высокого уровня. С др. стороны, возможно иногда бывает сложно абстрагироваться, избавится от лишних знаний и подойти к написанию "чистым".
Как всегда - дуальность. А выбирать только Вам!

[defunct]

Он не просто не страшный совсем, я бы сказал AVR-ASM самый удачный и простой в использовании среди всех других ассемблеров MK.

Очень спорный тезис. Меня так после асма 51-го AVR'овский просто ломал. Немного лучше стало, когда слепил кучу макросов, чтобы уменьшить объем писанины. Когда перешел на С (а это оказалось оченно правильным, т.к. С код на AVR ложится очень неплохо), то началась просто другая жизнь. Хотя асм AVR'овский не забывал - частенько инспектировал кодогенерацию по листингам. На сегодня могу сказать, что и асм MSP430 куда как удобнее и приятнее, чем AVR'овский.

Я тоже мигрировал с 51-го на AVR, первую неделю плевался, а потом разобравшить понял насколько порядков AVR-Asm лучше. Слепил макросы в стиле x86 и стало вообще все просто.
чем меньше команд имеется в арсенале программиста, тем сложнее писать программу на ассемблере. У MSP всего 27 мнемоник, если не ошибаюсь, и операнды перевернуты (аргументы идут первыми параметром, рез-тат записывает во второй). Следовательно для программиста MSP-Asm просто не может быть куда удобнее и приятнее AVR-овского у которого 130+ мнемоник.

Писать программы (без математики с плавающей точкой) на Avr-ASM не сложнее чем на C.

Опять не соглашусь - сложнее, дольше и получается громоздкий (по сравненю с С) и запутанный код, в котором через пару месяцев и автору с ходу не разобраться. Из всех асмов, которые приходилось видеть, самым похожим на С является ассемблер для Blackfin'а. AVR'у в этом смысле до Blackfin'а далеко.

"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.
По поводу сложнее и дольше - возможно.
По поводу запутанности кода, это смотря как писать, можно на C написать так, что через пару месяцев в коде не разберется даже автор. А можно написать на ассемблере так, что сходу будет все понятно.

[CD_Eater]

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

Большой минус АСМа - плохая переносимость на другие МК. Но зачем переходить, если область применимости каждой программы ограничена одним проектом и соответствующим железом ? Пока не сталкивался с задачами, которые формулировались бы так: "написать программу, которую потом можно будет откомпилировать под любой МК". Обычно сначала выбирают железо+алгоритм, потом определяют оптимальный МК, и только после этого пишут программу.

[vet]

CD_Eater
Поправьте, если я ошибаюсь, но, на мой взгляд, требования к ОЗУ одинаковы что у ассемблерной программы, что у сишной, и определяются исключительно потребностями алгоритма.
Память программ - да, расходуется экономнее, но совсем ненамного, да и критично это только на мелких контроллерах. К тому же, по отзывам, на больших проектах тот же IAR начинает создавать более плотный код, чем человек на ассемблере. Здесь это обсуждалось в одной из тем.
Что до переносимости - лично я занимаюсь переносом программ постоянно по мере появления новых МК и наращивания возможностей разрабатываемых устройств. Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

[COMA]

Не обязательно, пару лет назад мы с ребятами баловались над созданием расширения C#. По началу все (парсер, генерация) писалось на самом C#, а потом расширение парсило и генерировало само себя Вроде даже есть название такому подходу.

bootstrap.
Или вытягивания себя за шнурки.

[_Bill]

..хотя бы по тому, что для создания компилятора С он тоже нужен.

Не обязательно, пару лет назад мы с ребятами баловались над созданием расширения C#. По началу все (парсер, генерация) писалось на самом C#, а потом расширение парсило и генерировало само себя Вроде даже есть название такому подходу.

Вот и попробуйте сделать компилятор хотя бы для AVR. Лексический анализ, парсер, оптимизация на машинно-независимом уровне, все это можно без всякого ассемблера сделать. А вот дальше, кодогенератор (back-end часть) невозможно сделать без знания архитектуры целевого процессора. А архитектура процессора - это тот же самый ассемблер. Только не для программирования, а для описания. Да и отлаживать кодогенератор проще, если видеть какой он ассемблерный код генерирует.

[dxp]

Я тоже мигрировал с 51-го на AVR, первую неделю плевался, а потом разобравшить понял насколько порядков AVR-Asm лучше. Слепил макросы в стиле x86 и стало вообще все просто.
чем меньше команд имеется в арсенале программиста, тем сложнее писать программу на ассемблере. У MSP всего 27 мнемоник, если не ошибаюсь, и операнды перевернуты (аргументы идут первыми параметром, рез-тат записывает во второй). Следовательно для программиста MSP-Asm просто не может быть куда удобнее и приятнее AVR-овского у которого 130+ мнемоник.

Дело не в количестве мнемоник, а в удобстве системы команд. На 51-м если мне надо проинкрементировать счетчик - inc var, и все, а на AVR - три команды. И при этом вся операция получается неатомарной - если этот счетчик является разделяемым ресурсом, то придется дополнительний защитный код городить. И об этом надо всегда помнить. Макрос, конечно, писанину уменьшит, но зато способствует сокрытию проблемы неатомарности операции. В общем, по любому появляется дополнительний геморрой.

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

"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.

Хе. А как называется микросхема, у которой процессорное ядро, несколько таймеров с возможностями Compare/Capture/PWM, UART[s], SPI, многофункциональные последовательные порты (в т.ч. способные работать и как SPI), ноги на ввод/вывод, есть варианты с CAN и другими периферийными устройствами? Сейчас уже анонсированы чипы с набортной флешью. Есть режимы с пониженным энергопотреблением, в т.ч. и 200 МГц при 50 мВт потребления по ядру - по удельному потреблению мелкий МК, который бы мог тут поспорить, еще поискать.

Если АРМы считаются МК, в том числе и АРМ9, то уж Blackfin тут ничем не хуже. Это однокристальная микроЭВМ ака микроконтроллер. Конечно, весовая категория у него не та же, что у AVR, MSP430, PIC и другая мелкая братия, но тем не менее.

По поводу запутанности кода, это смотря как писать, можно на C написать так, что через пару месяцев в коде не разберется даже автор. А можно написать на ассемблере так, что сходу будет все понятно.

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

Т.ч. каждому свое - основной объем на ЯВУ, критичные по скорости/размеру куски, а также сильно платформеннозависимые - асму.

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

[_Bill]

Дело не в количестве мнемоник, а в удобстве системы команд. На 51-м если мне надо проинкрементировать счетчик - inc var, и все, а на AVR - три команды. И при этом вся операция получается неатомарной - если этот счетчик является разделяемым ресурсом, то придется дополнительний защитный код городить. И об этом надо всегда помнить.

Так а в AVR не сложнее.

Код

         inc       r15     ; Увеличить счетчик

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

[COMA]

чтение из ОЗУ
инкремент
запись в ОЗУ

3 команды

[beer_warrior]

Большой минус АСМа - плохая переносимость на другие МК. Но зачем переходить, если область применимости каждой программы ограничена одним проектом и соответствующим железом ? Пока не сталкивался с задачами, которые формулировались бы так: "написать программу, которую потом можно будет откомпилировать под любой МК". Обычно сначала выбирают железо+алгоритм, потом определяют оптимальный МК, и только после этого пишут программу.

Стеки протоколов, файловые системы, сложные математические алгоритмы (фурье, сжатие) не зависят от используемого железа.
Шедулеры операционных систем зависят от него незначительно.

Знаете ли быват очень приятно, общие константы и структуры расшарить между софтом МК и РС.
Одно изменение попадает сразу в оба проекта

[_Bill]

чтение из ОЗУ
инкремент
запись в ОЗУ

3 команды

Зачем, если можно хранить счетчик в регистре?

[COMA]

Случаи они разные бывают. Регистров может и не хватить.

[_Bill]

Случаи они разные бывают. Регистров может и не хватить.

Само собой. Но это бывает сравнительно редко. Как правило, регистров вполне хватает.

[IgorKossak]

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

Я знаю одно исключение из этого правила.
Это Форт-процессоры. Т. е. такие МК, для которых ЯВУ Форт является собственно ассемблером.
Такой вот каламбур. И кстати сразу заметил, что этот пример не только исключение из правил, но и в то же время (как это ни парадоксально) - подтверждение.
Второй (грядущий вскоре) вариант, это Java-процессоры, зачатки которого есть по-моему в AVR32.
Так что всё сводится к тому, что и ассемблеры и ЯВУ существовали, существуют и ещё долго существовать будут в том или ином весовом соотношении в каждом отдельном проекте на самых разных платформах и на AVR в частности.

[vet]

IgorKossak,
ну, Java-процессор выполняет всё-таки не исходник, а скомпилированный байт-код. В этом смысле он не отличается от обычных процессоров.

[white.wind]

кодогенератор (back-end часть) невозможно сделать без знания архитектуры целевого процессора. А архитектура процессора - это тот же самый ассемблер. Только не для программирования, а для описания. Да и отлаживать кодогенератор проще, если видеть какой он ассемблерный код генерирует.

Безоговорочно согласен

[Stanislav]

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

Я знаю одно исключение из этого правила.
Это Форт-процессоры. Т. е. такие МК, для которых ЯВУ Форт является собственно ассемблером.
Такой вот каламбур. И кстати сразу заметил, что этот пример не только исключение из правил, но и в то же время (как это ни парадоксально) - подтверждение...

Был ещё в начале 80-х у нас такой суперкомпуктер "Эльбрус", для него "ассемблером" являлся ЯВУ "ЭЛЬ". Насколько мне известно, это было первой в мире успешной попыткой реализовать ЯВУ аппаратно. Правда, приставку "микро" к процессору "Эльбруса" не приклеишь...

[CD_Eater]

Поправьте, если я ошибаюсь, но, на мой взгляд, требования к ОЗУ одинаковы что у ассемблерной программы, что у сишной, и определяются исключительно потребностями алгоритма.

Возможно, что я не прав, но меня пугает "вредная привычка" всех компиляторов - фривольное обращение со стеком. Типичный размер стека в моих программах = 6 байт (один уровень подпрограмм внутри фоновой задачи + один уровень подпрограмм внутри обработчика прерывания + один вызов обработчика прерывания). Как ни парадоксально, это вписывается в стандарты "хардварного" стека в старых МК (где не было ОЗУ). Да и за счёт человеческой оптимизации кода всю возню с передачей параметров внутрь функции можно сделать не столь прожорливой к ОЗУ.

Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

Как Вам так повезло, однако... Я, помнится, когда переводил программу с Тини15 на Тини13, ой как намучился - из-за того, что в Тини13 один таймер вместо двух и частота ШИМа меньше, пришлось перелопачивать большую часть логики работы программы. И это - различие периферии между очень похожими друг на друга МК.

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

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

Знаете ли быват очень приятно, общие константы и структуры расшарить между софтом МК и РС.
Одно изменение попадает сразу в оба проекта

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

[vet]

Свежий пример - возникла необходимость добавить функций в устройство; заменили в приборе мегу128 на SAM7S, т.к. перестало хватать ОЗУ под алгоритм. Весь перенос софта в результате был сведён к освоению новой периферии. Сколько бы я переносил его, будь он написан на ассемблере - страшно и представить

Как Вам так повезло, однако... Я, помнится, когда переводил программу с Тини15 на Тини13, ой как намучился - из-за того, что в Тини13 один таймер вместо двух и частота ШИМа меньше, пришлось перелопачивать большую часть логики работы программы. И это - различие периферии между очень похожими друг на друга МК.

Собственно, удивительного в этом нет; следую правилу максимально отделять логику программы от особенностей работы с периферией, ресурсы используемых м/к это позволяют (используем сравнительно навороченные кристаллы, мега8 и выше). При смене чипа, таким образом, переписываются только модули инициализации и обслуживания периферии, т.е. практически вся программа перекомпилируется с косметическими изменениями.
Так оно в этом случае и получилось. Освоить периферию SAM - это был, конечно, тот ещё цирк, но, кроме этого, в исходниках почти ничего не изменилось, разве что оптимизации, касающиеся разрядности - при том, что прошивка занимала больше пол-меги128, в ней пару кбайт занимают таблицы, строки и т.п. В конечном счёте осталось ещё время повозиться с ассемблерной оптимизацией алгоритмов кодирования, без необходимости, просто ради удовольствия.
В таких вот условиях в преимуществах программирования на Си сомневаться не приходится ни секунды

[defunct]

Я тоже мигрировал с 51-го на AVR, первую неделю плевался, а потом разобравшить понял насколько порядков AVR-Asm лучше. Слепил макросы в стиле x86 и стало вообще все просто.
чем меньше команд имеется в арсенале программиста, тем сложнее писать программу на ассемблере. У MSP всего 27 мнемоник, если не ошибаюсь, и операнды перевернуты (аргументы идут первыми параметром, рез-тат записывает во второй). Следовательно для программиста MSP-Asm просто не может быть куда удобнее и приятнее AVR-овского у которого 130+ мнемоник.

Дело не в количестве мнемоник, а в удобстве системы команд. На 51-м если мне надо проинкрементировать счетчик - inc var, и все, а на AVR - три команды. И при этом вся операция получается неатомарной - если этот счетчик является разделяемым ресурсом, то придется дополнительний защитный код городить.

Ну хорошо с inc'ом допустим 51-й в выигрыше, и то сомнительно, т.к. никто не заставляет Вас хранить особо важный, разделяемый несколькими задачами счетчик в памяти (не на Cи ж пишем). Ему можно жестко назначить любой регистр из нижнего "бестолково-бесполезного" ряда R2-R15. Во-вторых никто не заставляет Вас строить программу так, чтобы появлялась необходимость в дополнительной синхронизации.
Как контр аргумент вашему примеру - целый класс задач, интенсивно использующих целочисленную арифметику и логические операции. Здесь 51-й явно будет в проигрыше со своим обязательным регистром Acc для всех арифметико-логических операций.

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

Это понятно, согласен. Просто этот дополнительный геморрой надо единожды учесть, и строить структуру программы таким образом, чтобы никогда не иметь геморроя.

И таких примеров можно привести кучу.

Вы возможно согласитесь, что таких примеров будет больше для 51-го. Тому способствует и Acc, и оствутствие команд сравнения, и многоуровневый КП (при необходимости могу привести больше аргументов).

Что касается MSP430, то разложите его 27 инструкций на способы адресации - там еще больше варинатов выйдет. У MSP430 система команд куда ортогональнее, чем на AVR, и именно это обстоятельство делает работу с его асмом значительно проще и приятнее. Порядок операндов - вообще мелочь и дело привычки.

Спорить не буду.

Скажите - Вы писали на асме для MSP430?

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

"Технически Вы не король" © Шрек
Высмысле, технически Blackfin не МК.

Хе. А как называется микросхема, у которой процессорное ядро....

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

Т.ч. каждому свое - основной объем на ЯВУ, критичные по скорости/размеру куски, а также сильно платформеннозависимые - асму.

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

Согласен и поддерживаю это высказывание.

[beer_warrior]

BTW, что меня убивало в 51 это односторонний переход по сравнению
(CJMP ???), из-за чего конструкции типа switch/case приобретали весьма интересный вид
Асм MSP действительно очень хорош благодаря ортогональности.

[defunct]

Был ещё в начале 80-х у нас такой суперкомпуктер "Эльбрус", для него "ассемблером" являлся ЯВУ "ЭЛЬ". Насколько мне известно, это было первой в мире успешной попыткой реализовать ЯВУ аппаратно. Правда, приставку "микро" к процессору "Эльбруса" не приклеишь...

Насколько мне извество Эльбрус был первой, но как раз безуспешной попыткой реализации ЯВУ аппаратно из-за сокращения финансирования. Часть аппарата в целях экономии была реализована программным путем, из-за чего СуперЭВМ превратилась в СуперТормоза и не получила практического применения.

[dxp]

Ну хорошо с inc'ом допустим 51-й в выигрыше, и то сомнительно, т.к. никто не заставляет Вас хранить особо важный, разделяемый несколькими задачами счетчик в памяти (не на Cи ж пишем). Ему можно жестко назначить любой регистр из нижнего "бестолково-бесполезного" ряда R2-R15. Во-вторых никто не заставляет Вас строить программу так, чтобы появлялась необходимость в дополнительной синхронизации.

Во-от! Уже всякие "если" полезли. "Если" уж на то пошлО, то писать на С/С++ основной объем и не парить мозги. Я в свое время вполне успешно писал на С целиком под 2313. Кодогенерацию анализировал, не находил там такого, что бы дало хоть какой-то значимый выигрыш при писании на асме. Но возвращясь к начальной точке - я оспаривал тезис, что AVR'овский ассемблер является самым удобным и легким в использовании. Утверждаю, что это не так, что у 51-го и MSP430 (особенно у последнего) ассемблер значительно проще и приятнее в использовании.

Как контр аргумент вашему примеру - целый класс задач, интенсивно использующих целочисленную арифметику и логические операции. Здесь 51-й явно будет в проигрыше со своим обязательным регистром Acc для всех арифметико-логических операций.

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

Скажите - Вы писали на асме для MSP430?

Меня сразу отпугнул непривычный для меня порядок следования операндов.

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

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

К сожалению, я не помню Вашего мнения на эту тему. Хотелось бы услышать техническое обоснование, почему, скажем АРМ9 является МК, а Blackfin - нет.

[Stanislav]

Насколько мне извество Эльбрус был первой, но как раз безуспешной попыткой реализации ЯВУ аппаратно из-за сокращения финансирования...

Я имел в виду техническую, а не политическую сторону дела.

...Часть аппарата в целях экономии была реализована программным путем, из-за чего СуперЭВМ превратилась в СуперТормоза и не получила практического применения.

Глубочайшее заблуждение. Более 10^8 инструкций ЯВУ в секунду при 64 битной суперскалярной (кстати, тоже первой в мире) архитектуре - это и по нынешним временам довольно круто.
Эльбрус-2 выпускался серийно и применялся, насколько мне известно, в военных и космических целях.

[defunct]

Во-от! Уже всякие "если" полезли. "Если" уж на то пошлО, то писать на С/С++ основной объем и не парить мозги.

е-мае! кто ж с этим спорить-то будет.

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

Я в свое время подружил 2313 с RTL8019AS, и воткнул в нее крохотных IP стек с поддержкой ICMP/UDP ну и естессно, что-то over UDP т.к. IP стек не был самоцелью. Фичи, которые с успехом реализуются на асм и криво реализуются на C, - например копирование из одного source в два dest, что является чуть ли не ключевой операцией при обработке ARP и IP пакетов (использование всех трех указателей под собственные нужды, без организации стека данных вообще).

Но возвращясь к начальной точке - я оспаривал тезис, что AVR'овский ассемблер является самым удобным и легким в использовании. Утверждаю, что это не так, что у 51-го и MSP430 (особенно у последнего) ассемблер значительно проще и приятнее в использовании.

Выглядит Ваше утверждение также голословно, как мое утверждение, что AVR-асм самый лучший.
Предлагаю придумать кукую-то несложную задачу и реализовать ее на всех названных асмах (A51, MSP-Asm, AVR-Asm), там и посмотрим, на каком асме решение получится наиболее красивым и понятным.

Как контр аргумент вашему примеру - целый класс задач, интенсивно использующих целочисленную арифметику и логические операции. Здесь 51-й явно будет в проигрыше со своим обязательным регистром Acc для всех арифметико-логических операций.

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

Драсти, надобность постоянно копировать один операнд в Acc это уже специфика не только архитектуры, но также и дебильности асма, сопровождающего эту архитектуру.

Скажите - Вы писали на асме для MSP430?

Меня сразу отпугнул непривычный для меня порядок следования операндов.

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

Согласен, что мелочь, но мне вероятно уже не доведется плотно работать с MSP-асмом, время ушло, сейчас решаю другие задачи для которых хватает avr, а там где нехватает применяется arm. 16-битный msp как бы посередине и совсем неактуален для решения моих задачь.

Даже когда работаешь параллельно с двумя архитектурами - например, AVR и MSP430, приходится то и дело то в том копаться, то в этом - нету проблемы, по самим мнемноникам уже автоматом правильно переключаешься на порядок операндов.

Это понятно, у меня тоже никогда не возникало проблем при копании параллельно с 51-м и Avr. Правда на переключение уходило пару часиков. Нет-нет да и вставишь вместо ldi - mov или наоборот.

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

К сожалению, я не помню Вашего мнения на эту тему. Хотелось бы услышать техническое обоснование, почему, скажем АРМ9 является МК, а Blackfin - нет.

since eh... because! ;>
Встроенным мат. аппаратом.

...Часть аппарата в целях экономии была реализована программным путем, из-за чего СуперЭВМ превратилась в СуперТормоза и не получила практического применения.

Глубочайшее заблуждение. Более 10^8 инструкций ЯВУ в секунду при 64 битной суперскалярной (кстати, тоже первой в мире) архитектуре - это и по нынешним временам довольно круто.
Эльбрус-2 выпускался серийно и применялся, насколько мне известно, в военных и космических целях.

Серийно в двух экземплярах?

"Машины "Эльбрус 1" и "Эльбрус 2"
......
....
Как только убрали аппаратную поддержку интерпретации производительность машины резко снизилась, что привело к прекращению развития этого семейства" ©

[vet]

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

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

[dxp]

Но возвращясь к начальной точке - я оспаривал тезис, что AVR'овский ассемблер является самым удобным и легким в использовании. Утверждаю, что это не так, что у 51-го и MSP430 (особенно у последнего) ассемблер значительно проще и приятнее в использовании.

Выглядит Ваше утверждение также голословно, как мое утверждение, что AVR-асм самый лучший.
Предлагаю придумать кукую-то несложную задачу и реализовать ее на всех названных асмах (A51, MSP-Asm, AVR-Asm), там и посмотрим, на каком асме решение получится наиболее красивым и понятным.

Вот делать будто нечего, тесты придумывать... У MSP430 12 16-битных регистров, каждый из которых может быть источником операции, назначением операции, хранить адреса объектов и функций, адресовать их - все совершенно прозрачно и ортогонально. У AVR по факту полноценных регистров 16 8-битных, т.е. всего 8 регистровых пар - в полтора раза меньше. Указателей из них полноценных только два... Да не спорьте Вы, проходили уже. Я с AVR работал лет пять плотно, тащился даже. Но когда познакомился с MSP430, так сразу увидел всю кривизну - недоделанная архитектура AVR, хотя идеи заложены хорошие. Атмел на AVR учился делать процессоры. Вопросы кривизны AVR я уже озвучивал на форуме, повторять не хочу.

Вы же уже знаете мое мнение относительно bf..
Технически он DSP. и говоря выше о "ассемблерах всех МК", лично я не подразумевал ни один DSP.

К сожалению, я не помню Вашего мнения на эту тему. Хотелось бы услышать техническое обоснование, почему, скажем АРМ9 является МК, а Blackfin - нет.

since eh... because! ;>
Встроенным мат. аппаратом.

Не аргумент. Каким таким аппаратом? Наличием аппаратного умножителя-аккумулятора? В АРМах он тоже есть. Наличием barrel shifter? В АРМах он тоже есть. Что еще?

Я довольно продолжительное время уделил осмыслению этих моментов - DSP/не DSP, МК/не МК и т.д. и пришел к определенному выводу относительно этой классификации, который мне кажется весьма здравым и правильным. Я его озвучу, если хотите.

[upc2]

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

[dxp]

Мы здесь, напомню, не архитектуру процов обсуждаем (хотя асм на нее тоже "завязан"), мне 51-й на фоне AVR'а тоже претит, но это очень древняя архитектура, что с нее взять на сегодняшний день. А если отвечать на Ваше вышеотквоченное замечание, то возьмите опять же тот же MSP430 - AVR "нервно курит в уголке". И по скорости, и по размеру кода. И по удобству кодирования на ассемблере. Мне довелось плотно поработать и с тем, и с другим, поверьте разница по всем параметрам значительная и не в пользу AVR.

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

Насчет частот, я при равных тактовых сравнивал, чтобы выявить именно плюсы и минусы архитектуры. С самого начала мне казалось, что если данные 8-разрядные, то AVR должен быть быстрее, т.к. он гарвард, в память шустрее лазит - фон неймановский MSP430 за опкодами и данными лазит по тем же шинам, поэтому должен быть медленнее по определению. Его выигрыш состоит в большей разрядности шины данных, поэтому на 16-ти и более разрядных данных он может вполне составить конкуренцию и даже обогнать. Таково было предположение.

Далее стал сравнивать. Для сравнения использовал не какие-то непонятные тесты, а прямо свои рабочие проекты. Надо сказать, что код там вполне обычный, контроллерный - проверка флагов, вызов функций (прямо и по адресу (индексу) из массива указателей), работа с одиночными переменными 8-, 16-, 32-бит, работа с агрегатными типами вроде структур и массивов, и, конечно, работа с объектами классов. Компиляторы в обоих случаях были от IAR. Ожидал увидеть одно, а на деле увидел другое.

Оказалось, что и на 8-битных данных AVR не блещет, а показывает даже немного худший результат. Анализ причин показал следующее (как раз то, что в голову не приходило, пока не увидел это на сравнении): у AVR неортогональный регистровый файл, очень мало аппаратных указателей. Это первая причина, которая и сводит на нет преимущества гарварда по доступу в память. Вторая причина - это отсутствие нормального указателя стека - это усугубляет предыдущий момент - отъедает одну полноценную регистровую пару (указатель стека - Y). В итоге при реальной работе в программе приходится гонять адреса через Z-указатель, получается своего рода "бутылочное горлышко". Например, зашли в функцию, надо обратиться к объекту по адресу - грузим его адрес в Z (две инструкции), обратились; теперь надо обратиться к другому объекту, а с предыдущим работа еще не закончена - в него в конце будет помещен результат; но как быть с адресом? Либо забить на него и в конце еще раз грузить, либо сохранить куда-то временно - т.е. копирование, накладные расходы в том и другом случае примерно одинаковы. И вся программа буквально изобилует такими примерами, когда надо адреса гонять через Z-pointer. Для сравнения - у MSP430 такой проблемы вообще нет - берем и адресуемся с любого из 12 РОН. Надо один объект - адресуемся с одного регистра, надо другой - с другого, а предыдущий никуда не делся, хранится до момента своего следующего использования. Если бы у AVR был бы еще хоть один указатель типа Y или Z, а еще лучше два - то это была бы совсем другая картина. И разрядность данных тут не много значит - адресная арифметика все равно в подавляющем количестве случаев 16-битная.

Из простых тестов могу привести следующее. Вернее, это не тест в самом деле, а просто сравнение эффективности одного и того же куска кода из аналогичных проектов. Там в том и другом было вычисление полинома (от двух переменных) вида:

Код

float math::Pxy(__flash PxyCOEFFS a, const float x, const float y)
{
    float X_2 = x*x;
    float Y_2 = y*y;

    return a[9]*X_2*x + a[8]*Y_2*y +
           a[7]*X_2*y + a[6]*x*Y_2 +
           a[5]*X_2   + a[4]*Y_2   +
           a[3]*x*y   + a[2]*x     + a[1]*y + a[0];
}

Результат:
MSP430F149 : 5197 тактов
ATmega163 : 11941 такт

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

В целом MSP430 за счет более прямого ядра оказывается быстрее AVR'а даже несмотря на свою неймановость. Кстати, обращение в память у AVR - 2 такта, - тоже не впечатляет, медленно это. Должен за такт лазить, принципиально этому ничего не мешает. Этот момент я тоже уже озвучивал здесь на форуме, вступал в дискуссию с некоторыми уважаемыми коллегами, просьба к ним не поднимать тут в очередной раз спор не эту тему.

Надеюсь, я ответил на Ваш вопрос удовлетворительно.

Чтобы не подумали, что лажаю AVR, скажу, что ядро ядром, но есть и другие факторы - корпус, наличие флеши и ЕЕПРОМ, диапазон напряжений питания, цена и многое другое - по совокупности характеристик AVR выплядит очень даже неплохо! И хотя по многим (большинству) параметров он уступает тому же MSP430, есть несколько позиций, где MSP430 не предлагает адекватную замену. Прежде всего это диапазон питаний - MSP430 имеют диапазон 1.8-3.6 В, если надо 5-вольтовость, то AVR рулит. Второе - наличие поддержки аппаратной внешней шины в некоторых чипах (мега8515, мега128), у MSP430 этого нет вообще. Третье - наличие байтовоадресуемой, стираемой и записываемой энергонезависимой памяти - EEPROM. В MSP430 такого нет, там только флешь, стереть можно только блоком. Правда, при такой организации есть свои преимущества - блоков много и можно произвольно их стирать/записывать прямо на рантайме. Ну, и у AVR есть чипы с большим объемом флеши (ТИ, правда, тоже обещал в MSP430 нового поколения расширения адресного пространства и многих других фич, но это пока обещания). Вот если какие-то из этих моментов актуальны, то AVR вполне рулит. В общем, нету ничего белого или черного - все серое.

[vet]

dxp, спасибо за подробный ответ.

[IgorKossak]

dxp, насколько я знаю применение аппаратного умножителя AVR в операциях с float IAR реализовал только в версии 4.20а.
Если Ваш тест с полиномом делался в предыдущей версии, то он слегка некорректен.

[dxp]

dxp, насколько я знаю применение аппаратного умножителя AVR в операциях с float IAR реализовал только в версии 4.20а.
Если Ваш тест с полиномом делался в предыдущей версии, то он слегка некорректен.

Я честно написал, что при выключенном умножителе в MSP430 будет проигрыш в полтора раза, т.е. порядка 7.5 тыс. тактов. Что все равно гораздо быстрее AVR'а. И также упомянул, что пример этот полную картину не характеризует, т.к. плавучка - это только полавучка, она больше в реализацию библиотеки упирается. Но поверьте, во всем остальном картина именно такая, как я описал - ядро MSP430 действительно лучше и дает этому МК преимущество как по скорости, так и по размеру кода. И все это при меньшем потреблении.

[CD_Eater]

dxp, тест очень неудачный
Сравнение вычислительных операций всегда будет в пользу проца с большей разрядностью регистров.
Простой пример - умножение чисел двойной разрядности потребует в 4 раза больше времени (используя карацубу - в три раза, но выигрыш от этого получается только при очень большой разрядности). Даже больше, чем в 4 раза (надо ещё прибавить сложения промежуточных результатов)Поэтому 16-битный аналог АВР опережал бы в 4 с лишним раза, а МСП - только в 2. Хы-хы.

Возьми задачку, где разрядность выше 8 бит почти не требуется, и сравни такты. (Типичные задачки МК уровня АВР именно таковы).

[dxp]

dxp, тест очень неудачный
Сравнение вычислительных операций всегда будет в пользу проца с большей разрядностью регистров.
Простой пример - умножение чисел двойной разрядности потребует в 4 раза больше времени (используя карацубу - в три раза, но выигрыш от этого получается только при очень большой разрядности). Даже больше, чем в 4 раза (надо ещё прибавить сложения промежуточных результатов)Поэтому 16-битный аналог АВР опережал бы в 4 с лишним раза, а МСП - только в 2. Хы-хы.

"Бы да бы, да бы мешает" (с) пословица. "Если б бабушка была дедушкой..." (с) Если бы у AVR было 8 регистровых пар - аппаратных указателей типа Z, если бы на уровне этих регистровых пар поддерживалась арифметика, если бы AVR имел нормальный указатель стека, если бы AVR имел доступ в память в один такт, если бы он вообще был 16-разрядным, а еще лучше - 32-разрядным... и еще много-много всяких если. Однако текущий факт, что MSP430 быстрее (в тактах), код у него меньше, ассемблер приятнее. Это первое.

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

И кстати, 32-разрядный Blackfin что-то не опережает MSP430 в 4 (!) раза. А уж у него-то все в наличие - и шины, и регистры, и все остальное.

Возьми задачку, где разрядность выше 8 бит почти не требуется, и сравни такты. (Типичные задачки МК уровня АВР именно таковы).

Вы, очевидно, невнимательно читали. Я подробно описал, что и сам так думал до сравнения. А когда сравнил, то и удивился, почему оно не так. И когда стал разбираться с причинами, то выяснил, что главная проблема с тормозами у AVR - бедные возможности по адресации, когда почти все адреса идут через один аппаратный указатель. И адреса 16-битные и от разрядности данных это не зависит. Перечитайте внимательнее предыдущие посты и подумайте над этим хорошенько. Если это Вас не убеждает, спорить все равно не буду - я уже один раз это прошел, у меня нет ни времени, ни желания, ни сил повторять эксперименты. Возьмите AVR и MSP430, возьмите какую-нибудь задачу, прогоните, сравните. Только не надо брать рекламные примеры, возьмите рабочую программу. В готовом виде есть примеры почти одного и того же кода тут. Код обычный - функции, условия, ветвления. Скомпилируйте и сравните. И посмотрите листинги - все сразу станет понятным.

[SpiritDance]

dxp
Поддерживаю Вас. В MSP430 ядро несравнено лучше. Хоть сам я до реальных задач на MSP не добрался, однако в АЛУ влюбился сразу, грамотно все сделано, даже АРМ мне меньше понравился. (PDP11 rules )
Вот только ядро, как верно было подмечено - это еще не все, батарейные они mspшки эти, такими видно и останутся. Особенно удручило отсутсвие толерантности к 5V. Ну и еще неудобного есть по мелочи. И дорогие они, в основном.

[CD_Eater]

dxp
Я не говорю, что AVR существенно мощнее )))))))
Однако был приведён всего единственный тест, результат которого мог быть предсказан заранее и не мог отражать реального соотношения производительностей на характерных задачах МК.
Моя критика направлена не на утверждение о соотношении производительностей этих МК, а на метод доказательства этого утверждения.

Несчёт "узкого горлышка", которое Вы обнаружили в малом количестве указателей у AVR и в неполноценном указателе стека. Это действительно нехорошо с точки зрения общепринятого способа компиляции с ЯВУ, но при программировании на АСМе это не вызывает каких-либо затруднений. У меня сложилась практика использовать в качестве указателей только X и Y, а регистр Z - для "временных" целей (то есть, не ассоциировать его с каким-то значением, постоянным по ходу выполнения всей программы). Если обрабатываем два массива - X и Y. Если работаем со структурой - Y+displacement. Если нужно прочитать из флеша (или временно нужен дополнительный указатель) - используем Z. В частности, я никогда не использовал Z для обращений вида Z+displacement, и в этом вижу даже некоторую избыточность. Трёх указателей всегда хватало.

По поводу стека - при правильном распределении регистров использование стека минимально. Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.
Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR. Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ? )
Стек хорош для алгоритмов, когда размер данных, помещаемых в стек, предсказать сложно. Например, рекурсий. Для МК это непозволительная роскошь (по крайней мере, пока размер стека исчисляется сотнями байт). И подход к использованию стека в МК должен отличаться от принятого в софте настольных компьютеров.

Моё мнение - насаживание ЯВУ (напр., Си) на МК по своей природе противоестественно, но выполняется для благой цели - чтобы программисты, знакомые с ЯВУ, смогли писать прошивки. Ведь Атмелу, например, хочется продать побольше чипов, а ЯВУ - это хороший маркетинговый ход. Аналогия - чтобы продать больше компьютеров, их стали использовать как печатные машинки - тоже хороший маркетинговый ход. В результате компьютерами пользуются секретарши, а на МК программируют не знающие ассемблера прогеры.

К чему это я ? Просто все "узкие горлышки" куда-то исчезают, как только забываешь про Си и начинаешь писать на ассемблере - под это дело AVR заточен вполне пристойно, и в плане компактности кода, и в плане быстроты выполнения инструкций, и в плане удобства программирования (не идеал, но близко).

[haker_fox]

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

Знание асма для программиста ЯВУ никто не отменял. Язык Си - это инструмент, которы позволяет лишь ускорить разработку программы, сделать ее более наглядной, обеспечить переносимость на другие платформы.
И не могли бы Вы пояснить, почему насаживание ЯВУ (напр., Си) на МК по своей природе противоестественно? В принципе МК - компьютер (ИМХО) и стандарт на язык Си не огаваривает аппаратную платформу.

В результате компьютерами пользуются секретарши, а на МК программируют не знающие ассемблера прогеры.

Голословное утверждение (ИМХО).

К чему это я ? Просто все "узкие горлышки" куда-то исчезают, как только забываешь про Си и начинаешь писать на ассемблере - под это дело AVR заточен вполне пристойно, и в плане компактности кода, и в плане быстроты выполнения инструкций, и в плане удобства программирования (не идеал, но близко).

Нет, еще понятно, если человек просто пишет), т.е. не заглядывает в листинг. Не интересуется возможностями МК, его ограничениями и проч. Такие люди просто ламеры и все.

[spf]

Трёх указателей всегда хватало.

Видимо задачи большего не требовали или желание всегда ограничивалось на корню.

По поводу стека - при правильном распределении регистров использование стека минимально.

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

Пихать в него параметры функций и создавать там локальные переменные - дурная привычка компиляторов с ЯВУ.

ИМХО. Подобные мысли можно обосновать только плохой реализацией в проце работы со стеком.

Кстати, раньше, как Вы, наверное, помните, в x86 был тот же подход - кроме указателя стека (SP, относительно которого нельзя адресоваться к данным в стеке) для стековых операций резервировался ещё один регистр (BP, полноценный), полную аналогию чему наблюдаем в компиляторах под AVR.

Аналогия с x86 не впользу AVR, x86 разрабатывали 40 лет назад а AVR 10 и далеко не ушли...

Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ?

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.

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

Чаще необходима реентерабильность, которая без полноценногог стека нереализуема. Эта самая вещь позволяет экономить память и не ломать голову по ручному распределению памяти - экономия времени/нервов и крохотных ресурсов RAM МК.

ИМХО: Тащиться от асма в в век когда межпланетные корабли бороздят просторы вселенной как то не серьезно...

[Kopa]

ИМХО: Тащиться от асма в в век когда межпланетные корабли бороздят просторы вселенной как то не серьезно...

Отчасти согласен, но в альтернативе кроме Си использую Forth ( при всей его непопулярности
Что гораздо ближе к внутренностям контроллеров.
Есть мнение, что Си это высокоуровневый ассемблер заметно
удалившийся от прародителя.

P.S. MSP не было бы без PDP11. Жаль что урезали от способов адресации больше чем нужно.
На асме есть любители писать ОС для PC.
Если бы не переносимость, то это было бы оправдано.
А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

[SpiritDance]

А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

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

[Kopa]

А так надо изобретать универсальный ассемблер ( примерно, как в Algoritm Builder)

Все изобретено до нас. IL из .NET вполне годится под определение универсального ассемблера. Универсальность просто как проавило достигается за счет уменьшения эффективности кода, то есть его заточенности под конкретную архитектуру.

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

P.S. Встречный вопрос.
Подходит ли Форт под понятие универсального ассемблера из сравнения с IL:)
( промежуточного языка )

[spf]

Трёх указателей всегда хватало.

Вспомнилось, в загрузщике по UART от Fujitsu кода на 800 байт написанном на асме изпользуется аж 6 (шесть) указателей. Хотя код как сами понимаете простейший.

[SpiritDance]

P.S. Встречный вопрос.
Подходит ли Форт под понятие универсального ассемблера из сравнения с IL:)
( промежуточного языка )

Честно говоря о форте знаю только то что он есть. И знаю что он уже довольно долгое время после своего появления остается экзотическим языком, так что за его универсальность я бы не поручился. Однако, повторюсь, с языком не знаком.

[CD_Eater]

Трёх указателей всегда хватало.

Вспомнилось, в загрузщике по UART от Fujitsu кода на 800 байт написанном на асме изпользуется аж 6 (шесть) указателей. Хотя код как сами понимаете простейший.

Да, пятью указателями там явно не обойтись

[CD_Eater]

По поводу стека - при правильном распределении регистров использование стека минимально.

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

Сомневаюсь, что оптимизацию кода, выполняемую вручную, можно описать простым алгоритмом. К тому же это зависит от опыта программиста. Лично мне доставляет неописуемое удовольствие процесс "утаптывания" программы, с целью получить сэкономленные байты и такты. Когда кажется, что всё уже минимизировано дальше некуда, приходит очередная хитрая идея, как изменить подход или алгоритм. Не понимаю тех, кто придерживается коммерческого подхода - побольше килобайт кода на скорую руку. Программирование превращается из искусства в ремесло.
Сорри, отвлёкся. Если бы "правильное" распределение регистров (а также много чего ещё "правильного") можно было бы описать алгоритмически, это бы давно уже вставили в компиляторы. Но компиляторы используют обобщённые методы оптимизации, дающие средний результат на типичных задачах. А когда к каждой задаче подходишь индивидуально, с одной стороны есть семантика исходной задачи, с другой - особенности аппаратуры, и твоя задача - прокинуть наиболее элегантный мостик между этими берегами. Мне именно это и нравится в программировании - заставляет шевелить извилинами.
Сорри, опять отвлёкся. Короче, обобщённого "правильного" распределения не существует, т.к. оптимизация существенно использует как особенности задачи, так и железа. А универсальность всегда получается в ущерб оптимальности.

Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ?

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.

Не проверял, но сомневаюсь, что в МК засунут инструкцию, выполняющуюся сотни тактов.
Для справки: у интеловской x86 инструкции enter есть параметр level, который может изменяться от 0 до 31. Именно об этой вложенности я и говорю. А Вы, вероятно, только про случай level=0. Если ошибаюсь - поправьте.

Чаще необходима реентерабильность, которая без полноценногог стека нереализуема. Эта самая вещь позволяет экономить память и не ломать голову по ручному распределению памяти - экономия времени/нервов и крохотных ресурсов RAM МК.

Почему сразу стек ? Удобнее каждому экземпляру давать структуру, в которой будут все локальности (а также входные параметры), а функциям передавать единственный параметр - адрес этой структуры. Располагая эти структуры в глобальной памяти, можно ограничивать одновременную количество экземпляров, которые сможет обработать МК. (Экземпляр - это ветвь и т.п.). А стек оставьте исключительно для push/pop, call/ret

[spf]

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

То есть интересен сам процесс, а не результат . Коммерческий подход - получить результат меньшей кровью и за меньшее время.

Может, Вам ещё вложенные стековые кадры с инструкциями enter/leave хочется в 8-битном МК ?

Есть и такое, например у всей линейки МК от Fujitsu, начиная с 8-ми битников.

Не проверял, но сомневаюсь, что в МК засунут инструкцию, выполняющуюся сотни тактов.
Для справки: у интеловской x86 инструкции enter есть параметр level, который может изменяться от 0 до 31. Именно об этой вложенности я и говорю. А Вы, вероятно, только про случай level=0. Если ошибаюсь - поправьте.

Может быть о разном говорим хотя названия похожи, асма на x86 под рукой нет. Для справки по МК от Fujitsu:
ENTER #N - Function entry processing (где N - объем резервируемой памяти)
LEAVE - Function exit processing
Первая резервирует память в стеке для локальных переменных, вторая освобождает. При этом определенный регистр получает значение адреса начала локальных переменных в стеке, через этот регистр выполняются все операции с локальными переменными.

Чаще необходима реентерабильность, которая без полноценногог стека нереализуема. Эта самая вещь позволяет экономить память и не ломать голову по ручному распределению памяти - экономия времени/нервов и крохотных ресурсов RAM МК.

Почему сразу стек ? Удобнее каждому экземпляру давать структуру, в которой будут все локальности (а также входные параметры), а функциям передавать единственный параметр - адрес этой структуры. Располагая эти структуры в глобальной памяти, можно ограничивать одновременную количество экземпляров, которые сможет обработать МК. (Экземпляр - это ветвь и т.п.). А стек оставьте исключительно для push/pop, call/ret

Зашибись, еще осталось определить union этих структур для каждого уровня вложенности вызовов функций и экономия памяти будет на уровне... про оптимизацию кода и говорить нечего. Титанический труд, сложность сопровождения, т.п. и т.д. и ни какой практической выгоды данного метода. А если OS потребуется запустить то там вообще туши свет, этож придется для каждой задачи объявлять отдельные экземпляры структуры и везде таскать указатели на них. Что-то я не пойму в чем удобство?!
Написал считалку стека для MB9X, достаточно много анализировал расход памяти (стека в том числе) при разных подходах ее распределения. Пришел к выводу что ручное/статическое распределения памяти не дает экономии, часто даже проигрывает варианту с локальными переменными. Не думаю что для других процессоров ситуация будет иная.

[beer_warrior]

Но компиляторы используют обобщённые методы оптимизации, дающие средний результат на типичных задачах.

Вы не любите котов? Вы просто не умеете их готовить
Сам долго исповедывал взгляды сходные вашим....Пока жизнь не заставила хорошенько покопаться в Сишных листингах. Итак, чем же код генерируемый компилятором отличается от написанного ручками?
1.Стартапом
2.Вызовами/завершениями функций.
Циклы, ветвления, присваивания итп. это и есть тривиальные задачи, котроые мало-мальски нормальный компилятор сгенерит также, как и самый искушенный программист.
Стартап освобождает от совершенно рутинной и тривиальной задачи начальной инициализации памяти.Если у вас на этот счет свои соображения - никто не запрещает вам подключать собственный стартап или вообще обходиться без такового.
Наиболее больной вопрос - вызовы функций и передача аргументов.
Да, нужно это или нет, компилятор приведет все вызовы к стандартному виду. Это дает вполне очевидное преимущество - не задумываться о порядке вызова функций - аргументы передаются гарантировано, гарантировано сохраняется контекст. Расплата за это - несколько больший расход стека и снижение быстродействия.
Однако, если вы более-менее хорошо знаете свой компилятор, это не есть проблема - вы четко знаете, сколько аргументов передастся через регистры, сколько раз вызовется push/pop. Дальше все в ваших руках - минимизация передаваемых аргументов, минимизация локальных переменных, привязка переменных к регистрам, inline -функции.Если вы правильно описали задачу - С быстро сгенерит вам работоспособный код, избавив от рутины и ошибок связанных с ней.
Если время позволяет ее вылизывать - вы можете сделать это не хуже , чем на ассемблере. Если нет, можете оставить все как есть. Меньшее количество текста и недоступные явно метки и распределение памяти сильно облегчит модификцию кода методом copy/paste. Вместе с тем они не будут представлять из себя черный ящик - на физические адреса вы сможете посмотреть в любой момент.

P.S.Здесь длинный спор между мной и dxp на тему оптимизации
у gcc и IAR. Приводится ассемблерный код, можете ознакомится.
http://electronix.ru/forum/index.php?showtopic=12284&st=75

Интересным является два подхода к оптимизации - прямолинейный у gcc и с вывертами у IAR. Так что, и компилятор можно подыскать по вкусу.

[Kopa]

Честно говоря о форте знаю только то что он есть. И знаю что он уже довольно долгое время после своего появления остается экзотическим языком, так что за его универсальность я бы не поручился. Однако, повторюсь, с языком не знаком.

Данный ответ был мной предугадан
Жаль, знание возможностей данного языка не было бы лишним.
Экзотичность языка, прежде всего, связана с его малой известностью( если не сказать почти 0-й)
среди российских разработчиков аппаратуры и непониманием его идеалогии.

[dxp]

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

Если писать на том же асме код значительного размера, то приходишь к той же схеме - придумываешь сам себе соглашения о вызове и свято их придерживаешься! Иначе программа делается не сопровождаемоей даже автором, когда в каждом вызове свои "нюансы". Т.е. залог успеха - формализация подхода. Отсюда и небольшие накладные расходы в некоторых случаях на дополнительное копирование аргументов между регистрами. В подавляющем большинстве случаев роли это сегодня не играет никакой.

[forever failure]

Судя по объёму флуда, - асм жив, и более того - alive forever.
Даже те, кто кодят на ЯВУ - всё равно его знают, хотя бы для того чтобы убедится, что высокоуровневый копмилятор не наворотил чего лишнего.

Про альтернативные соглашения при передаче аргументов в асмовской программе - полностью за и тоже использую этот метод.

[defunct]

Если бы у AVR было 8 регистровых пар - аппаратных указателей типа Z, если бы на уровне этих регистровых пар поддерживалась арифметика, если бы AVR имел нормальный указатель стека, если бы AVR имел доступ в память в один такт, если бы он вообще был 16-разрядным, а еще лучше - 32-разрядным... и еще много-много всяких если.

Со всем уважением к Вам. Не надо никаких если, давайте просто оценим, что же показывает ваш тест!
8 битный AVR - 11+тыс. тактов.
16-битный MSP - 5+ тыс. тактов.
Только с учетом того, что рабочая частота AVR в два раза выше чем MSP, то 8-ми разрядный AVR по суммарной производительности практически равен производительности 16-ти разрядного MSP. Теперь об аппаратном умножителе. Судя по всему аппаратный умножитель AVR не применялся, следовательно для чистоты сравнения надо брать результат для MSP без аппаратного умножителя. Как Вы говорите, без аппаратного умножителя MSP справляется с задачей в 1.5 раза дольше, т.е. 7.5+ тыс. тактов. AVR - 11+ (~12) тыс. тактов
Теперь давайте учтем соотношение частот AVR-16Mhz, MSP-8Mhz.
Сведем все к MSPшным тактам. Один такт AVR равен 8/16 = 1/2 такта MSP.
Домножаем 12 тыс на 1/2
12 * 1/2 = 6тыс. MSPшных тактов.
И получаем, что AVR справляется с задачей за 6 тыс MSPшных тактов, а MSP за 7.5 тыс. тактов.
LOL, так получается AVR еще и "сделал" MSP на 25%.

Однако текущий факт, что MSP430 быстрее (в тактах), код у него меньше, ассемблер приятнее. Это первое.

Если РОНы "шире" - неизбежно операции с плавающей точкой потребуют меньше тактов для исполнения. Поэтому все законно и ожидаемо на 16-bit РОНах FP операции выполняются быстрее, чем на 8 битных. И более того, я сказал бы, что результаты этого теста больше в пользу AVR, т.к. имея в два раза меньшую разрядность, наблюдается замедлениние в два раза (практически линейная зависимость, что вполне естественно).

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

Я из вашего теста могу построить следующий вывод:
На одинаковых тактовых частотах AVR проигрывает MSP приблизительно в два раза (в большинстве задач - меньше чем в два раза). В реальных задачах AVR работает быстрее чем MSP430 за счет более высокой тактовой частоты ядра, поэтому добавив еще и факт, что AVR дешевле MSP - целесообразнее применять именно AVR.

И кстати, 32-разрядный Blackfin что-то не опережает MSP430 в 4 (!) раза. А уж у него-то все в наличие - и шины, и регистры, и все остальное.

Вы хотите сказать, что Bf будет 1.25+ тыс тактов выполнять код из Вашего теста?

[dxp]

Не надо никаких если, давайте просто оценим, что же показывает ваш тест!

Да что вы все прицепились к этому тесту?! Я сразу сказал и повторил, что это, во-первых, не тест как таковой, во-вторых, он не характеризует картину в полной мере - тут плавучка, а значит тут доминируют два фактора: 1) реализация библиотек, где определены подпрограммы операций с плавающей точкой; 2) эффективность ядра, т.к. операции в ядре доминируют над операциями с памятью. У MSP430, как и у любого фон Неймана, работа с памятью - слабое место. А вот ядро у него хорошее - регистровый файл, каждая операция в регистрах за один такт. Никакой 8-битных процессор тут не поспорит. Вот и все. И давайте уже оставим этот фрагмент кода.

На деле, как уже неоднократно сказал, MSP430 быстрее почти везде. При равных тактовых, ессно, т.к. сравнивается эффективность ядра.

8 битный AVR - 11+тыс. тактов.
16-битный MSP - 5+ тыс. тактов.
Только с учетом того, что рабочая частота AVR в два раза выше чем MSP, то 8-ми разрядный AVR
[...]
И получаем, что AVR справляется с задачей за 6 тыс MSPшных тактов, а MSP за 7.5 тыс. тактов.
LOL, так получается AVR еще и "сделал" MSP на 25%.

Какую-то Вы тут софистику устроили. Зачем это? В реальных проектах MSP430 быстрее почти везде. Не в два раза, конечно, но процентов на 10-20. Это неоднократно установленный мной факт. Хотите поисследовать - пожалуйста, все в Ваших силах. Начать можете с того примера, который я уже предлагал, там почти одинаковый код. Очень хорошо видна реализация в обоих случаях. Упора на 16-битность данных там нет.

Я из вашего теста могу построить следующий вывод:
На одинаковых тактовых частотах AVR проигрывает MSP приблизительно в два раза (в большинстве задач - меньше чем в два раза). В реальных задачах AVR работает быстрее чем MSP430 за счет более высокой тактовой частоты ядра, поэтому добавив еще и факт, что AVR дешевле MSP - целесообразнее применять именно AVR.

Вы еще забыли про потребление. Вот тот полином у меня вычислялся в проце, работающем на 5 МГц - хватало, - при этом весь МК побреблял около 2.4 мА при питании от 3 В. Дивайс батарейный. Найдите-ка мне такой AVR? В реальных задачах надо не максимальную скорость - тут главное, чтоб успевал с некоторым запасом. А вот потребление частенько требуется как можно меньше. Вот у меня МК посчитал результат, отправил его на вывод, и на боковую (в Idle). А из Idle он просыпается за 6 мкс. Таким образом, почти все неактивное время он спит, переход ко сну и обратно почти ничего не занимает. Эффективность максимальная.

Насчет того, дешевле ли AVR - это еще вопрос! AVR не предлагает полноценной замены MSP430 почти во всем: он медленее, он больше потребляет, у него почти во всем хуже периферия, у него нет такой удобной и гибкой системы распределения тактовых частот. Кроме того, у MSP430 на борту встроенный отладчик, который требует копеечного адаптера, в отличие от AVR, которому нужен недешевый JTAG-ICE, работающий к тому же нестабильнее и медленнее. Возможности отладчика в MSP430 новых моделей несравенно богаче - до 8 аппаратных брейкоинтов, не только на код, но и на данные, всякие условные брейкпоинты и т.д.

Преимущества AVR я уже перечислял выше - возможность 5 В питания, если кому актуально (мне,например, никогда это не было актуально - наоборот, от 5 В только лишнее энергопотребление), возможность внешней аппаратной шины у некоторых МК (опять же это только пара чипов, да и на MSP430 можно программно это организовать, написав класс-шлюз, чтобы работа со стороны программы была прозначной по отношению к этой шине), наличие EEPROM (здесь удобство AVR неоспоримо, но с MSP430 большого головняка не вышло - тоже написал класс, который манагит запись данных в блоки флеши попеременно, пользоваться этим просто и безопасно. С EEPROM'ом, кстати, тоже для надежности надо дополнительный код писать, с резервированием значений и проверкой при записи/чтении, т.ч. оно где-то одно к одному и выходит). Это практически все.

На деле существуют ситуации, когда AVR выгоднее и без этих оговорок - когда требования проекта удовлетворяются возможностями МК. Например, если хватает меги8, то и замечательно, ничего больше не нужно, даже если есть и более замечательные МК. Фактически же главным фактором является даже не возможности МК, а владение конкретным разработчиком тем или иным МК. Если человеку, работающему с AVR что-то в нем не хватает, он в большинстве случаев поставит недостающую часть снаружи (вплоть до применения второго МК), но не будет переходить на MSP430. Это психология и инертность мышления. А также требования по времени к выполнению работы на фоне внутренней увереннности в результате. По этой причине до сих пор жив 51-й (конечно, есть тут и другая причина - поддержка старых разработок, но старые разработки требуют старых МК, на оригинальном 12-тактовом ядре, а вот все новые, с новой периферией и новыми возможностями - это исключительно психология).

И кстати, 32-разрядный Blackfin что-то не опережает MSP430 в 4 (!) раза. А уж у него-то все в наличие - и шины, и регистры, и все остальное.

Вы хотите сказать, что Bf будет 1.25+ тыс тактов выполнять код из Вашего теста?

Что Вас удивляет? У него нет аппаратной поддержки плавающей точки.

[Kopa]

Ссылка на интересную статью и ресурс для роботостроителей.
( в проекте используется ATMEGA128 )

http://rema.44.ru/about/persons/dobrinin/

P.S. Не ассемблер, но тоже интересный подход.
Не знаю, в какой топик лучше поместить.?

[upc2]

Еше 2 года назад писал Vxd драйверы под windows на асм.Умер 98 и умер ассемблер.Последнее за,
что он цеплялся , так это Vxd драйверы.Кто из вас пишет WDM драйверы на асм.?Хотя на WASM.ru
еще остались защитники ассемблера.Сидят и переписывают всю майкрософтскую библиотеку под
асм.Зачем? Также будет и микроконтроллерами.Меня уже не заставить писать на асм.Программу,
которую я напишу на Си за 1 час ,на асм. буду писать около месяца.Для меня это уже недопустимо.
Вспомните как противились использованию калькуляторов в школах.Боялись, что ученик разучится
умножать в столбик.Хотя калькулятор его избавил от того, что он мог не решить основную задачу
если не умножил бы 2х2.
Прощай асм.

[dxp]

Прощай асм.

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

[forever failure]

Ну вот ещё пример - о вечном. Совершенно прикладная прога - огромный объём вычислений с плавучкой - обработка больших объёмов экспериментальных данных. Среда разработки - даже никакой не МК, не ДСП -а борланд Ц++ под виндой 2000 - казалось бы какой в баню ассемблер - это даже не системный уровень.
Ан нет - мне показалось не влом потратить день на переписывание трёх строчек Ц на 18 строк асма х86 и сократить время обработки блока данных с 12 минут до 2. Временные затраты на отладу отбились за неделю использования проги. Опять же код переносим на любой х86 проц с FPU - то есть практически работает на любой машине.

[viael]

Сильно на C разгонишься когда памяти 512 байт.

Дык если с умом писать то разгонишся очень сильно
Было у меня куча проектов достаточно сложных и объемных и в 512байт влезал аж бегом.Асм нужен для того чтобы тока критические секции писать.

[pokos]

А вот ядро у него хорошее - регистровый файл, каждая операция в регистрах за один такт. ....Насчет того, дешевле ли AVR - это еще вопрос!

У AVR регистр-регистр тоже за один такт. А ещё за один такт - вывод в порт, в отличие от 3-х тактов MSP. Не знаю, как у кого, а на моих задачах MSP всегда оказывался медленнее AVR. Правда, DMA я не использовал. Поэтому я потренировался немного на нём, да и передумал с AVR на MSP переходить.

Что касается цены, то MSP-149 стоит в районе $3.5, а AtMega8 $0.8.
Единственное, что остаётся у MSP - энергопотребление. Но если исполнительные устройства едят на два порядка больше проца, то какая разница?

[dxp]

А вот ядро у него хорошее - регистровый файл, каждая операция в регистрах за один такт. ....Насчет того, дешевле ли AVR - это еще вопрос!

У AVR регистр-регистр тоже за один такт.

Только у MSP430 16 бит, а не 8. :-Р Потому и сказано было, что никакой 8-битник тут не угонится, не нужно из контекста выдирать.

А ещё за один такт - вывод в порт, в отличие от 3-х тактов MSP.

У MSP430 это не вывод в порт, а обращение в память. А то, что порты и другие регистры на память отмаплены - это очень правильное, здравое и зрелое решение. AVR из-за своих in/out, во-первых, ввел еще одно адресное пространство - трех имеющихся ему мало, во-вторых, на меге128 и других толстых чипах имеем форменный геморрой, когда регистры специальных функций не помещаются в это маленькое адресное пространство. Кроме того, за сколько тактов выполняется инверсия пина на AVR? И не забываем весь связанный с этим геморрой, когда нужно использовать два регистра - а если это делается в прерывании, то их надо сохрянять - еще оверхед, когда операция эти неатомарна и т.д. :-Р

Не знаю, как у кого, а на моих задачах MSP всегда оказывался медленнее AVR. Правда, DMA я не использовал. Поэтому я потренировался немного на нём, да и передумал с AVR на MSP переходить.

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

Что касается цены, то MSP-149 стоит в районе $3.5, а AtMega8 $0.8.

Ха! Нашли что сравнивать! Да MSP430F149 кроет ATmega8 как бык овцу! У меги скока флеши? 8 кил, а у F149 - 60! ОЗУ у меги 1 килобайт (и это много для такого чипа, непропорционально, я бы сказал, много), у F149 - 2 килобайта. У F149 12-разрядный АЦП с 200 К выборок в секунду, с секвенсором на 16 значений, с индивидуальными настройками опорных напряжений для каждого канала, с различными режимами запуска и т.д. Тут вообще ни один AVR близко не стоял! У F149 два полноценных таймера с суммарно 10 модулями Compare/Capture/PWM. У F149 два USART'а, каждый из которых может быть сконфигурирован либо как UART, либо как SPI. Наконец, у F149 6 8-битных портов, т.е. 48 ног на ввод/вывод.

Кроме того, откуда такие сведения про цены? MSP430F149 стоит существенно дороже - порядка 7-10 баксов. Мега8 тоже больше бакса - порядка двух баксов. Но в любом случае это МК разной весовой категории уже по объему флеши. Одноклассником MSP430F149 является Мега64, и стоит она примерно те же пятаки. А по периферии все так же пролетает. Кстати, MSP430F149 - это уже старый чип, сегодня за почти такие же деньги есть MSP430F169, у которого помимо вышеперечисленного еще есть два 12-битных аналоговых ЦАПа, DMA.

Единственное, что остаётся у MSP - энергопотребление. Но если исполнительные устройства едят на два порядка больше проца, то какая разница?

Да уж конечно! Особенно если забыть, что ни у одного AVR нет такого АЦП, ни у одного AVR нет таких ЦАПов (если вообще есть какие-то, я уже перестал за ними следить), если забыть про десяток ШИМов, в том числе и 3 синхронных парафазных с мертвыми зонами, если забыть про аппаратный умножитель-аккумулятор 16х16, которого в AVR нет и, очевидно, не будет.

В заключение, имея пятилетний опыт плотной работы с AVR, имея 3-летний опыт не менее плотной работы с MSP430 (т.е. не потренировался, а именно поработал, сделал эн проектов на нем), могу ответственно сказать, что работать с MSP430 намного приятнее во всех смыслах. Благодаря более стройной архитектуре с одним адресным пространством вместо четырех у AVR, и благодаря более прямой, гибкой и богатой периферии.

[upc2]

Прощай асм.

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

Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.587 я программировал.
И менчя до сих пор в жар бросает.
Ваши споры полезны в отдельном форуме по максимальному, рациональному использованию МК и
его компиляторов , а не о вечности ассемблера.

[singlskv]

Вы еще забыли про потребление. Вот тот полином у меня вычислялся в проце, работающем на 5 МГц - хватало, - при этом весь МК побреблял около 2.4 мА при питании от 3 В. Дивайс батарейный. Найдите-ка мне такой AVR? В реальных задачах надо не максимальную скорость - тут главное, чтоб успевал с некоторым запасом. А вот потребление частенько требуется как можно меньше. Вот у меня МК посчитал результат, отправил его на вывод, и на боковую (в Idle). А из Idle он просыпается за 6 мкс. Таким образом, почти все неактивное время он спит, переход ко сну и обратно почти ничего не занимает. Эффективность максимальная.

Ну вот например смотрим в ДШ на ATmega 48/88/168 и видим
ACTIVE SUPPLY CURRENT vs. VCC
INTERNAL RC OSCILLATOR, 8 MHz
на 3V примерно 2,7ma

А еще у него есть такой регистр CLKPR который позволяет делить тактовую в
1,2,4,8,16,32,64,128,256 раз. (с соответствующим уменьшением потребления)

ИМХО: как раз для батарейных девайсов актуально писать на ASM, т.к. это позволяет
быстрее сваливаться в Idle или Power Down и экономить энергию.

[dxp]

Прощай асм.

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

Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.

Бейсик изучать точно не буду.

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.

Ваши споры полезны в отдельном форуме по максимальному, рациональному использованию МК и
его компиляторов , а не о вечности ассемблера.

Какая разница, где дискутировать. Главное, чтобы это было интересно и конструктивно (конструктивно - это когда участники дискуссии и читающие ее находят для себя что-то новое). Случилось это здесь, ничем оно не плохо.

[pokos]

....А то, что порты и другие регистры на память отмаплены - это очень правильное, здравое и зрелое решение.

Абсолютно необоснованное. Тяжкое наследие ПДП-11.

Да MSP430F149 кроет ATmega8 как бык овцу!

Я тут не трактую за всех, только лишь за себя. На моих задачах хватает и 4К флеша. Зато не хватает быстродействия у MSP. Его сильно шустрый АЦП и вовсе членомерия, поскольку сделать сколько-нибудь осмысленную обработку отсчётов, прущих на такой скорости, MSP всё равно не успевает. И периферия его замечательная меня не лечит. В последней задаче каналов ШИМ мне надо 12. А входной сигнал имеет Ft=19кГц. Его надо фильтровать и шевелить каналами ШИМ.

[upc2]

Ну,в общем я с вами согласен.Мы говорим об одном и том.
Только я не согласен со временем.Все наступит намого быстрее.

[dxp]

....А то, что порты и другие регистры на память отмаплены - это очень правильное, здравое и зрелое решение.

Абсолютно необоснованное.

Обоснованное именно зрелостью подхода. Когда надо расширять, то есть куда это делать. Это Атмел по молодости пролетел, думал, что 64 байта - это бесконечно много. У всех серьезных МК регистры спецфункций отмаплены на память.

Тяжкое наследие ПДП-11.

PDP-11 был прекрасный процессор, гибкий, продуманный. Жаль, что развития эта ветка не получила. Во мне говорит не ностальгия, я с ним не работал, не застал уже. И если сегодня уже давно смогли соорудить 1-тактовый 51-й, то и PDP-11 реализовать на быстром ядре было бы возможно.

Да MSP430F149 кроет ATmega8 как бык овцу!

Я тут не трактую за всех, только лишь за себя. На моих задачах хватает и 4К флеша. Зато не хватает быстродействия у MSP.

Быстродействия какого? Вычислительного? Это вряд ли. Ногодрыгания? Вот на это похоже. Для формирования жестких времянок вообще надо периферию использовать. Делать это с помощью программной реализации - хакерство, чреватое гемором.

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

Никакая не членомерия. Для таких быстрых потоков там у АЦП есть секвенсор, который собирает сразу до 16 отсчетов, благодаря чему не надо прыгать за каждым отсчетом отдельно, имея оверхед, что и происходит с AVR'ом, а один раз пошли и забрали сразу все 16. Получается для максимальной скорости 5 мкс * 16 = 80 мкс период поступления прерываний, вполне реально. Насчет "делать осмысленную обработку отсчетов, прущих на такой скорости" - есть задачи, когда надо собрать данные, собирать надо на максимальной скорости. А обсчитать их можно и потом. В любом случае AVR тут курит в уголке.

И периферия его замечательная меня не лечит. В последней задаче каналов ШИМ мне надо 12. А входной сигнал имеет Ft=19кГц. Его надо фильтровать и шевелить каналами ШИМ.

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

[Kopa]

[quote name='dxp' date='Jun 29 2006, 11:17' post='129281']
Если вы помните микропроцессоры классифицируются на 2 группы.Микропрограммные серий 587,589 ..и микрокомандные,например, 580 серии.Микропрограммные используют код операции, а микропрограммные мнемонику кода,т.е асм.Я думаю, что вы не захотите связываться с микропрограммными контроллерами.Здесь надо под каждую задачу создавать свою систему команд.
Вас устроило , что разработчик уже вам предоставил какой-то инструмент.Завтра засунут туда
Паскаль или Бейсик и , что вы будете делать? Я думаю будете изучать бейсик.[/quote]

Когда внутрь микропроцессора засунут Бейсик/Паскаль/С/С++/Питон/др., это будут уже не Бейсик/Паскаль/С/С++/Питон/др - это будут уже ассемблеры, похожие на Бейсик/Паскаль/С/С++/Питон/др. Сегодня (и уже давно) фирма ADI применяет для своих DSP ассемблер с алгебраическим синтаксисом, он очень похож на С. И тем не менее, это ассемблер. Не думаете же Вы в самом деле, что появится процессор, у которого на асме можно будет написать TSlon *p = new TSlon;? В любом случае это будет язык элементарных операций данного процессора - его инструкций. И если мнемоники типа mov и jmp будут заменены на свои аналоги из ЯВУ, ассемблер от этого ассемблером быть не перестанет. Уровень абстракции все равно низок, переносимости и стандартности все равно нет.

Вот когда на уровень железа процессоров перенесут абстракции высокого уровня, т.ч. не будет никаких байтов и битов, а будут только объекты в памяти, не будет никаких разных адресных пространств, а будет просто память, где лежат объекты, когда работа с этими объектами - создание, удаление, инкапсуляция (сокрытие внутренней реализации) и многое другое, что свойственно ЯВУ будет реализована на уровне железа процессора, вот тогда можно будет говорить о смерти ассемблера. Только это будет (если будет) уже совсем другой процессор, и вряд ли мы дождемся наступления этих времен.

[/quote]

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

ЯВУ уже вставляли и вставляют в процы. Например Java, Forth:)

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

Сообщение отредактировал Kopa - Jun 30 2006, 03:31

[beer_warrior]

Чтобы не путаться в терминологии, наверное надо четко разделить.
Ассемблер - язык соответствующий аппаратным примитивам процессора. Будь он сколь угодно сложным или сменяемым он прямо и однозначно переносится в двоичные коды команд. Если процессор работает с java байт-кодом, значит это и есть его ассемблер. Наглядные примеры это две системы команд у АРМ или, как уже говорилось, ассемблеры ДСПшников, они еще и расспараллеливание поддерживают.

А вот если для исполнения кода требуется компиляция или интерпретация, другими словами каждый оператор может быть представлен несколькими кодами команд, причем это преобразование не четко детерминировано и зависит от текста программы и компилятора/интерпретатора, тогда можно говорить о ЯВУ.