AVR GCC&IAR

AM> Hе вижу противоречий с тем, что программа-ассемблер является AM> компилятором, поскольку ассемблер является языком программирования AM> конкретного типа процессора.

AVB> Спорно. Давай тогда уж определение языка программирования. Hа мой взгляд AVB> ассемблер таковым не является, т.к. не имеет средств описания алгоритмов,

Язык программрования не обязательно должен быть алгоритмическим.

AVB> а имеет только средства символической записи исполняемого кода процессора.

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

AVB> Я все таки сторонник считать ассемблер просто транслятором AVB> (что есть более общее понятие, чем компилятор).

В общем-то это дело вкуса, не вижу в этом споре какого-то принципиального момента и углубляться внего не буду.

DO> > Очевидно, что для понимания Си нужно знать только Си, для понимания DO> > алгоритма на ассемблере знать N ассемблеров. Вообще никогда не видел, DO> > чтобы в книгах алгоритмы писали на каком-то ассемблере, поскольку DO> > якобы это проще для понимания :)

DO> Значит ты никогда не читал Кнута...

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

SB> Dear Maxim,

SB> 13 Jan 04 00:35, Maxim Polyanskiy wrote to Vladimir Vassilevsky:

MP> В очередной раз доказываешь несостоятельность СИ.

VV>> #define LED_MASK 0x01 VV>> #define LED_PORT PORTC VV>> #define LED_ON LED_PORT &= ~LED_MASK VV>> #define LED_OFF LED_PORT |= LED_MASK VV>> #define BUTTON_MASK 0x01 VV>> #define BUTTON_PORT PINA VV>> #define GET_BUTTON (BUTTON_PORT&BUTTON_MASK) VV>> main() VV>> { VV>> if(GET_BUTTON) LED_ON; VV>> else LED_OFF; VV>> }

MP> #define LED P0.0 MP> #define BUTTON P3.0 MP> MAIN: MOV C,BUTTON MP> MOV LED,C MP> SJMP MAIN

SB> Молодец, так их! :-) SB> Теперь я желаю видеть код Владимира, начисто лишенный оверхэда.

Keil 5.20

sbit BUTTON = 0x90; //P1.0 sbit LED = 0x91; //P1.1

void main() { for (;;) { LED = BUTTON; } }

ASSEMBLY LISTING OF GENERATED OBJECT CODE

; FUNCTION main (BEGIN) ; SOURCE LINE # 7 ; SOURCE LINE # 8 ; SOURCE LINE # 9

0000 ?C0001: ; SOURCE LINE # 10 ; SOURCE LINE # 11 0000 A290 MOV C,BUTTON 0002 9291 MOV LED,C ; SOURCE LINE # 12 0004 80FA SJMP ?C0001 ; SOURCE LINE # 13 0006 22 RET ; FUNCTION main (END)

Привет, 12 января 2004 г., 11:05:58, ты писал(а):

UA> Это я к тому что не всё так клёва в avr-gcc, хотя сам пользую пока UA> avr-gcc + emacs, но начинаю в сторону IAR-а поглядывать.

IAR кстати тоже не безгрешен. Пару раз вызов функции пропустил (полдня искал ошибку). С оптимизацией тоже не все гладко - компилятор очень любит выносить одинаковые куски кода (порой, состоящие из пары команд и ret) в подпрограммы даже на самом высоком уровне оптимизации _по_ _скорости_, что выглядит, мягко говоря нелогично. Версия 2.28A.

Всего хорошего.

Привет, 13 января 2004 г., 0:36:51, ты писал(а):

MP> Почему никто не обсуждает грабли и глюки ассемблера MPASM? В то-же MP> время GCC и MP> IAR мы тут трем регулярно ;)

Может, это зависит от распространенности продукта ?

Всего хорошего.