Вычисление числа Пи на ассемблере

[litwr]

Народ на лимонном форуме протестировали версию для Коммодора 64 с разными 8085 и 580ВМ1 или, точнее, с Хамелеоном и Суперпроцесором (SuperCPU довольно массовая приставка для означенного Коммодора, эмулируется в Vice). Результаты от 16 до 22 раз быстрее Коммодора 64. Это даже Вектору с Турбо+ многовато. Там ещё обозначилась тема не вполне точной эмуляции ускоряющих приставок.
Кстати, для интересующихся z80 самый быстрый относительно массовый компьютер на его основе - это SAM Coupé с z80 на 6 MHz, выпускавшийся с 1989 (!). Хотя сэр Синклер вроде собирался новый Спектрум сделать на 8 МГц, но "переспешил" на "квантовом скачке" с QL и сдал хозяйство консервативному Амстраду. Амстрад в 1992 сделал что-то на z80 c 16 Мгц, но в единичных экземплярах.

[Advertiser]

[ivagor]

blackmirror, интересный вариант, но 100 цифр с ним считается медленнее, а 1000 с той же скоростью, как здесь. Это без sp, с ним еще медленнее, плюс сложность с подсчетом времени. Возможно моя реализация была недостаточно эффективна и кто-нибудь сильнее раскроет потенциал этого варианта.

Результаты от 16 до 22 раз быстрее Коммодора 64. Это даже Вектору с Турбо+ многовато.

Тогда я бы сравнил реализации на ПЛИС, думаю 6502 будет быстрее максимум раза в 2.

- - - Добавлено - - -

Кстати, для интересующихся z80 самый быстрый относительно массовый компьютер на его основе - это SAM Coupé с z80 на 6 MHz

Если уж сравнивать с 65816, то и на стороне z80 пусть играет r800 в MSX Turbo R.

- - - Добавлено - - -

100 цифр с ним считается медленнее, а 1000 с той же скоростью

Маленько оптимизировал, теперь 100 считаются с той же скоростью, а 1000 цифр на 5 секунд быстрее - неплохо.

- - - Добавлено - - -

Добавил ветку для делителя<128 - 100 цифр стало быстрее на 0.06 сек, 1000 цифр - еще на 0.6 секунды (т.е. в сумме по сравнению с выложенной версией почти на 6 сек).

[blackmirror]

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

#define ADC8(a,b) do{a=(a&255)+(b&255)+C; C=a>>8; a&=255;}while(0)
#define ADD16(a,b) do{a=(a&65535)+(b&65535); C=a>>16; a&=65535;}while(0)
//вход:
//BC - делитель, должен быть в диапазоне от 256 до 32768
//DE = -BC
//HL - два байта делимого минус BC, |HL+BC|<BC
//выход:
//A - HL*256/BC
//HL - HL*256%BC-BC
void div_8080(int &a,int &bc, int &de,int &hl){
int C=0;
ADD16(hl,hl); ADD16(hl,bc); if(C) goto S1;
A1: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S2;
A2: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S3;
A3: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S4;
A4: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S5;
A5: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S6;
A6: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S7;
A7: ADC8(a,a); ADD16(hl,hl); ADD16(hl,bc); if(C) goto S8;
A8: ADC8(a,a);
return;
S1: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A2;
S2: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A3;
S3: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A4;
S4: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A5;
S5: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A6;
S6: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A7;
S7: ADC8(a,a); ADD16(hl,hl); ADD16(hl,de); if(!C) goto A8;
S8: ADC8(a,a); ADD16(hl,de);
return;
}
//bb делитель от 256 до 32768
//aa - делимое, aa<65536*bb
void div_32_16(int aa, int bb){
int a,bc,de,hl,C;
hl=aa>>16;//старшие два байта делимого
bc=bb;//делитель
de=-bb&0xFFFF;//-делитель
ADD16(hl,de);//корректируем старшие два байта, потому что деление работает с отрицательным остатком
div_8080(a,bc,de,hl);//делим 256*HL на BC
//PUSH BC
bc=(aa>>8)&255; //перед делением модифицируем данную команду LXI, чтобы загрузить предпоследний байт делимого
ADD16(hl,bc); //суммируем предпоследний байт делимого с остатком
bc=bb;//POP BC
if(C){//если остаток стал положительным, то корректируем остаток и старший байт частного
ADD16(hl,de);
++a;
}
printf("%3X",a);//старший байт частного
div_8080(a,bc,de,hl);//делим дальше
de=aa&255;//перед делением модифицируем данную команду LXI, чтобы загрузить младший байт делимого
ADD16(hl,de);//суммируем младший байт делимого с остатком
if(C)//если стал положительным, то корректируем младший байт частного, иначе корректируем остаток
++a;
else
ADD16(hl,bc);
printf("%02X",a);
printf("%4X",hl);
}

[ivagor]

грузить можно самомодифицируемыми командами LXI

Я так и сделал. Но я сейчас складываю внутри, на "после" может потом переделаю. Сейчас тяжеловесно выглядит ветка для 127<делителя<256, может для нее что-нибудь придумаю.

[blackmirror]

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

Там похоже без удвоения разрядности никак, то есть в BC придётся грузить делитель*128, начинать не с удвоения HL, а с вычитания, ну а в конец добавить удвоение HL, чтобы весь остаток оказался в H, в A мы получим байт частного, а в L нужно загрузить следующий байт делимого.

[litwr]

на стороне z80 пусть играет r800 в MSX Turbo R.

Вы и это в Вектор вставите?
Кстати, Хамелеон это именно ПЛИС и возможно лучший из существующих эмулятор такого рода - рекомендую посмотреть, позавидовать.
Перенёс final_precise на СР/М на Амстраде (final-precise-z80.zip) и результаты получились странные: 100 цифр за 2.81 (2.98 - ваши данные), 1000 цифр за 253.9 (299) - это на 100 цифрах получается Амстрад быстрее на тех же кодах только на 6%, что делает эффективную частоту Bектора чуть-чуть большей 3 МГц... Хотя возможно нашёл объяснение: торможение BDOS - вы вместо него используете что-то побыстрее. Без печати Амстрад делает 100 цифр за 2.49, а 1000 за 250. С такими таймингами Амстрад стабильно на 19% быстрее по 100 и 1000 цифрам, что тактирует Вектор в 2.68 МГц!
Получается, что на 100 цифрах на 15% сравнивается скорость печати символов на экран. С ростом скорости основного алгоритма эта доля будет расти... Уже писал об этом - кажется, что такая оптимизация не есть что-то правильное... Интересно бы данные по Корвету получить, Микроше и т.п.
Раньше время измерялось из бейсика и поэтому в данных по Амстраду учитывалось и время построения таблиц, но это примерно полсекунды в final_precise, влияет только на результаты по 100 цифрам. И повторю вопрос. Почему не класть таблицы готовыми? При загрузке система сразу определит хватает ли ей памяти... И тестировать проще и вам меньше кода носить.
A коды интересные: штучки вроде check - это даже слов не нахожу - прямо пимания какая-то.

[ivagor]

Перенёс final_precise на СР/М на Амстраде (final-precise-z80.zip) и результаты получились странные

Вполне возможно, что тормозит вывод на экран. В векторовских cp/mах эта проблема есть, поэтому я и сделал стэндэлон.

Почему не класть таблицы готовыми?

Просто лень.

[litwr]

В векторовских cp/mах эта проблема есть, поэтому я и сделал стэндэлон.

Как видите проблема есть не только у Вектора. Без такого, что вы сделали с кодом, мы могли бы сравнивать разные системы. Например, Корвет мог бы быть быстрее на 100 цифрах, но медленнее на 1000. Это бы реально отражало архитектурные особенности компьютеров, а не трудовое усердие энтузиастов.
Уважаемый perestoronin, на лимонном форуме (http://www.lemon64.com/forum/viewtop...r=asc&start=24) выложены данные по железному самому быстрому Коммодору в сравнении с программой на си.

[perestoronin]

мог бы быть быстрее на 100 цифрах, но медленнее на 1000.

Предлагаю ограничиться, пока не пройдем барьер 1сек, для КР580ВМ80А на его штатных частотах, 100 цифрами, а 1000 приводим справочно, по желанию, и лишь для тех архитектур и алгоритмов, которые уже преодолели 1 с. Для остальных случаев остановимся на глубокой оптимизации для лишь для 100 цифр.

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

в сравнении с программой на си.

Это не интересно, Си заведомо в невыгодной позиции, думаю это должно быть уже давно очевидно быть. На Си быстрее кодить в продакшн, когда работа должна быть завершена еще вчера, но создавать шедевры, доступные лишь свободному художнику, на Си сложнее, чем на ассемблере, если вообще возможен шедевр на Си. Я знаю лишь один пример шедевра на Си - веб-сервер nginx, остальное всё - изделия для "продакшн", пускай даже и с лейблой СПО.

на лимонном форуме

Кто бы потрудился из знатоков Коммодоров и еже с ними Хамелеонов, смог проинтерпретировать те расчеты? А также привести подробности того самого расхваливаемого Хамелеона, разрядность этого сопроцессорного блока на ПЛИС (если я правильно понял) и его тактовую частоту.
Можно краткую выжимку сюда запостить, как ранее делали, 100 знаков (на такой то машине столько-то 0,00хх сек, с ускорителем Хамелеон столько то ..., Хамелеон разрядность хх бит, частота хх МГц, команды умножения такие-то, столько-то тактов) ?

Конечно любопытно знать, что кроме 1801ВМ1 и 580ВМ80 что-то еще существует, но нам бы в первую очередь доступное железо прогнуть нужно
Хотя думаю в Евросоюзах наверное Коммодоры достаются за "500р", а то и вовсе за 10 рублей как в России в Митино процессоры КР580ВМ80А ? Впрочем можно и к ретро-машине соорудить приставочку на ПЛИС и на мощном ARM-процессоре и похвалиться какие мы молодцы, только зачем ? Пока в этом не вижу необходимости, есть запас и без сопроцессоров для достижения новых рекордов, до 1 сек "еще далеко".

Также не понятно зачем в той теме прикрывают расчёт чисел числа Пи заголовком "демо", вместо нормального названия. Чего стесняются ?

[ivagor]

Мое мнение насчет разделения расчета и вывода на экран - это нормально только для расчета 100 цифр. Несколько секунд можно и подождать, когда казалось бы ничего не происходит. А для 1000 цифр это уже не здорово. Насколько помню, litwr писал нечто похожее, т.е. я фактически присоединяюсь к его мнению по этому вопросу.
Можно сделать версию для cp/m, но не знаю универсального способа подсчета времени, разве что поручить это "оператору" с секундомером.
Насчет быстродействия реализаций на ПЛИС - v06cc svofski в максимальном разгоне, который мне удался на DE1, работал примерно в 12 раз быстрее стандартного вектора. Для DE1-SoC и DE2-115 можно сделать и побыстрее, да и для DE1 предел не достигнут, но оказалось, что на векторе практически нет программ, которым нужно такое быстродействие.