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

[litwr]

Дошло, тут тема 8080, а все остальное сбоку. Хотя быстрый вывод на экран проблема частная, неинтересная, присущая и БК, и Спектруму, и Амстраду, ... И поднимать её было немного по моему скромному мнению не совсем прилично. Типа "защитим наши Жигули" от Вольво (Коммодора) и Москвича (Корвета) - 100% политика. А делать можно просто для 1000 и больше знаков и нет проблемы.
Похоже надвигается смена алгоритма. С текущим версия для Амстрада под СР/М может до 8000 знаков считать.
Но пока использовал предложенный уважаемым ivagor супер-алгоритм для деления в версии для Амстрада и получил новые цифры (для 100, 1000, 3000). Для коммодора деления ещё не перенёс, но кое-что улучшил.
Коммодор +4 - 1.72 - 172 - 1545
Амстрад 6128 - 2.48 - 186.5 - 1646.8
В коммодоровской версии использовал разные банки памяти, что позволило считать до почти 8000 цифр, но замедлило на несколько процентов. Не смог психологически использовать для умножения на 10000 32 килобайта в таблицах как делают некоторые. Использовал таблицу на 768 байт - это отнимает у версии Амстрада примерно 30 тактов в каждом цикле.
Удивительно, но Амстрад обогнал Коммодор 128. В некоторых частных случаях (копирование памяти, деление 32/16, ...) z80 показывает отличную эффективность, уступая не более 50% 6502. Хотя с переносом супер-деления 6502 наверное доведет перевес до 70-80%.
БК по-прежнему никто не тестирует. :-( Уважаемый ММ помог не так давно по теме с бейсиком...

100К цифр

Коммодору понадобится всего-то 172*100² с ≈ 20 суток.

[Advertiser]

[perestoronin]

БК по-прежнему никто не тестирует.

Все БКшники находятся на отдыхе до 10 января

Для коммодора

результаты обновил в шапке

Дошло, тут тема 8080

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

[ivagor]

Амстрад 6128 - 2.48 - 186.5 - 1646.8

Какой сильный перекос для 100 и 1000 цифр. То ли умножение на 10000 сказывается, то ли вывод на экран, но ПК-6128Ц и вектор с z80 считают 100 цифр быстрее, а 1000 медленнее.

почти 8000 цифр

Посчитать можно, а как их контролировать? На экран вектора в 512x256 одновременно можно вывести 5376 символов 4x6 (надо еще написать процедуру вывода). Выводить с прокруткой, сохранять на диск?

понадобится всего-то 172*100² с

С учетом увеличения разрядности умножения и деления скорее всего будет дольше

[perestoronin]

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

Много цифр пока рано считать. А контроль можно наладить уже сейчас, например по какой-нибудь быстрой короткой хэш-функции, коих море и которые на выходе выдают для длинного входного массива двоичных данных контрольное относительно короткое число - как результат хэш-функции. Его же заранее обсчитать для 100 цифр результата и сравнивать с результатом аналогичной функции. Кстати в рамках задачи по расчету числа Пи очень полезное упражнение, причем не сложнее чем собственно алгоритмы расчета числа Пи. Эти функции тоже желательно заоптимизировать. Рекомендую начать с устаревшей md5sum и затем продолжить с более надежной sha256sum. Кстати они, как и подпрограммы быстрого деления и умножения длинных чисел (десятки и сотни цифр в числе), будут очень полезны не только как наглядное пособие для изучающих программирование на ретропроцессорах.
Заниматься же оптимизацией вывода результата на экран тоже нужно, но эту задачку, относительно простую, лучше отложить, сделав предположение что вывод уже давно заоптимизирован дальше не куда Тем более мы договорились время вывода из памяти результат расчета на экран исключить из рейтинга алгоритмов расчета.

Отправными точками можно считать следующие реализации на ассемблере алгоритмов упомянутых хэш-функций для оффтопика
http://www.nayuki.io/res/fast-sha2-h...embly/sha256.S
http://www.nayuki.io/page/fast-sha2-...n-x86-assembly

http://www.nayuki.io/res/fast-md5-ha...bly/md5-fast.S
http://www.nayuki.io/page/fast-md5-h...n-x86-assembly

[ivagor]

Не смог психологически использовать для умножения на 10000 32 килобайта в таблицах как делают некоторые. Использовал таблицу на 768 байт

Временно вернул умножение на 10000 по маленькой таблице, чтобы проверить сколько это дает - всего 2% с копейками.

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

Чтобы закрыть тему влияния больших таблиц убрал еще и таблицу процедур для умножения младшего байта. Суммарный проигрыш (без большой таблицы *10000 и без таблицы процедур для умножения младшего байта) - примерно четыре с половиной процента, т.е. вклад каждой большой таблицы примерно 2 с небольшим процента.