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

[Titus]

Не юмор - факты. Если до сих пор таких не видели, могу дать ссылку.

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

[Advertiser]

[litwr]

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

Ерунду какую-то говорите. Почему по вашему кодов на ассемблере почти не пишут?

/*RUN IT BY (GNU compiler)
   gcc -O5  FN.c; time ./a.out
OR (it is without optimisation)
   gcc FN.c; time ./a.out
OR (Intel compiler)
   icc -fast FN.c; time ./a.out
OR (LLVM compiler)
   clang -O3 FN.c; time ./a.out
OR (Amsterdam Compiler Kit)
   ack -mlinux386 -O4 -o fib fib.c; time ./fib
*/
#include <stdio.h>
#define bestint long   //64 bits
bestint fib (bestint n) {
  return n < 3 ? 1 : fib(n - 1) + fib(n - 2);
}
main() {
  int k = 41;
  printf("%d %ld\n", k, fib(k));
}

Вот вам программка на си. Её ассемблерный аналог на 45% медленнее. Пробовал и с x86 и с x86-64, x86-64 процентов на 15 быстрее, но именно она и отстаёт почти на все 50 от си. Кстати, даже ява почти догоняет ассемблер, всего процентов на 30 медленнее. Аналогичная картинка и по функции Аккермана. Конечно, можно взять ассемблерный код, сгенерированный си-компилятором, но такое человек не напишет.

[Titus]

Ерунду какую-то говорите. Почему по вашему кодов на ассемблере почти не пишут?

Дорого, долго, и в большинстве случаев не оправдано, за исключением ситуаций, когда необходимо написать ОЧЕНЬ БЫСТРЫЙ фрагмент кода.

[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.

[litwr]

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

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

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

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