Кросс-средства для программирования под МП 1801, 1806, 588

[Patron]

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

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

[Titus]

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

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

Я говорю об оптимизации вычислительноемких участков программы, например, вычисление БПФ, свертка, фильтры и прочая ЦОС, и прочее, и прочее - тут при правильном подходе человеческая оптимизация алгоритма под ресурсы процессора даст всегда наилучший результат, с приростом быстродействия от 2 до более раз. Именно потому, что человек, видя возможности ресурсов процессора может крутить и вертеть этим алгоритмом и так и эдак, задействуя самое оптимальное, что может дать вычислитель данного процессора, тогда как компилятор может предложить лишь математическо-логическую оптимизацию и все. Говоря иными словами, человек подгоняет нюансы алгоритма под оптимальные стороны вычислителя, тогда как компилятор видоизменять алгоритм не может.

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

Кстати, где-то на форуме была именно эта тема 'си vs ассемблер', там все было многократно разжевано и оспорено)

[Patron]

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

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

[litwr]

Да, основная часть пишется на си, но критичные участки (если они есть) на асме.
Кстати, где-то на форуме была именно эта тема 'си vs ассемблер', там все было многократно разжевано и оспорено)

"Критические участки" выглядят в программах на си часто типа asm("LIDT [IDT]"); :-) C ассемблером как раз и работают гуру по оптимизации. Если писать просто одинаковые алгоритмы чистым кодом, то ассемблер его превратит в эквивалентный машинный код, а оптимизирующий компилятор превратит его в что-то неудобочитаемое, не похожее на оригинал, но очень быстрое.

fib:    cmp     rax,2           ;in: rax;  out: rcx
        ja      .l1
        mov     rcx,1
        ret

.l1:    dec     rax
        push    rax
        call    fib
        pop     rax
        push    rcx
        dec     rax
        call    fib
        pop     rax
        add     rcx,rax
        ret

Вот, кстати, эквивалент кода на ассемблере для приведённой ранее функции Фибоначчи. Если вы так хорошо знаете ассемблер, то попробуйте написать быстрее, не изуродовав код и сознание пишущего его программиста.
И спорить тут не о чем: ЛЮБАЯ проблема кодируются хорошим оптимизирующим транслятором в более быстрый код. Если потратить на кодирование в разы больше времени и получить совершенно нечитаемый код, то можно чуть-чуть и обогнать транслятор, но ценой возможно подорванного здоровья. ;-)
Вот и спрашивал, как хороша оптимизация для бк-ного кода? Сам хотел gcc для этого настроить, но так и не получилось. Интересно, на системах, сравнимых с БК gcc используют? GCC вроде не поддерживает 6502 и z80, но поддерживает лучший 8-битник 6809 (использовался на Tandy TRS-80 Color, Dragon-32/64, ...).

[litwr]

http://litwr2.atspace.eu/bk11.html
Для моих нужд хватает, если кому нужно больше, то ничего не обещал.
Тут на форуме большой выбор смайликов и среди них даже лого известных ретрокомпьютеров ( ...). А существует ли что-то похожее для БК? Обделили смайликом

[Vslav]

fib:    cmp     rax,2           ;in: rax;  out: rcx
        ja      .l1
        mov     rcx,1
        ret

.l1:    dec     rax
        push    rax
        call    fib
        pop     rax
        push    rcx
        dec     rax
        call    fib
        pop     rax
        add     rcx,rax
        ret

Очень плохой пример. Я как раз посмотрел ассемблер, решил что надо оптимизировать обращения к памяти, а потом вообще пришел к выводу что алгоритм мусорный и пример "высосан из пальца". Для прикола я его на ARM-е запустил на 120МГц, оно тупо зависло, неудивительно - вызов функции осуществляется примерно 2^40 раз, жесть.

Вот на коленке за пару минут набросанная функция:

int fib (int n)
{
	register int a, b, c;
	if (n < 3) return 1;

	a = b = 1;
	n -= 2;
	do
	{
		c = a + b;
		a = b;
		b = c;
	}
	while(--n);
	return с;
}

Попробуйте что там компилятор нагенерит.

Update: я немного погорячился, там не 2^40 вызовов, но число вызовов представляет собой смещенный ряд Фиббоначи, и все равно значительное. Ваш пример у меня секунд 10 считал на довольно быстром i7.

[Advertiser]

[litwr]

Очень плохой пример.

Уважаемый, пожалуйста, не спешите так, не разобравшись. Тема была о быстродействии трансляторов, потому и была выбрана функция, которая считается медленно. Если вас интересует как побыстрее рассчитать число Фиббоначи, то есть ещё алгоритм Дейкстры, время счёта которого пропорционально корню из n, а есть ещё и прямая формула с корнями из 5...
Вопрос был как коды для PDP-11 сгенерируются GCC с оптимизацией именно для такой функции и, конечно, надо будет заменить аргумент на меньший, на 30, например.

Ваш пример у меня секунд 10 считал на довольно быстром i7..

Странно, все примеры подобраны так, чтобы считались не более нескольких секунд на посредственном AMD 3.2 ГГц - конкретно си и ассемблер примерно за 1 сек

[Vslav]

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

Я ведь про компилятор ничего не сказал? Основная идея моего поста была, что компилятор компилятором, но про алгоритм не следует забывать.
Часто грамотным алгоритмом можно выиграть порядки по скорости, никакая оптимизация не сравнится. Холивар по компилятору начинать не хочу, на основной работе уже наелся досыта, поэтому помалкиваю.

Вопрос был как коды для PDP-11 сгенерируются GCC с оптимизацией именно для такой функции

Так попробуйте, ссылка на собранный GCC/PDP-11 тут в теме есть. Хочу только отметить, что x86 вылизывают и маркетируют - отсюда все эти разговоры про "чудо" оптимизацию, а ветку GCC для PDP уже с начала 2000-х не поддерживают официально.

Странно, все примеры подобраны так, чтобы считались не более нескольких секунд на посредственном AMD 3.2 ГГц - конкретно си и ассемблер примерно за 1 сек

В моей программке не одно число Фибоначчи выводилось, а все от 1 до 41, да отладка была не отключена. У меня просто мелькнула мысль что рекурсия хоть и неглубокая, но вызовов будет много и алгоритм медленный получается. Вот и попробовал на той плате ARM что у меня сейчас в работе на столе. Сначало оно тупо умерло по watchdog - решил эту проблему, потом увидел что все равно долго, уже под Win запустил пример и тоже насладился быстродействием алгоритма, потом уже вставил 5 копеек на форуме .

[litwr]

про алгоритм не следует забывать

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

"чудо" оптимизацию

Можете как-то фактами подтвердить свой сарказм? Кстати, перенос gcc под БК считаю крупнейшим достижением в мире БК (а может и PDP-11) за последние 15 или может более лет. К сожалению, нет возможности сейчас заняться пуско-наладкой gcc. Поэтому и спросил, может проводили такие эксперименты. А если тема вам неинтересна, то вопрос был не вам. ;-)

насладился быстродействием

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

[Ал-р]

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

Да хоть на Фортране алгоритм из нескольких строчек (согласно ОПТИМАЛЬНОМУ математическому определению) будет таким же бистрим как на супер СИ-Си-си ...
(Ваш прогрэм на Си переводится в Ассемблер Микро11 без всяких "оптимизирующих" компиляторов - есть оператор цикла SOB ... - и пошла Ваша С-оптимизация в ж...)