Вашу бы энергию на написание крутых демо-эффектов или хотя бы игр)
Вашу бы энергию на написание крутых демо-эффектов или хотя бы игр)
ё-маё, b2m уже успел и умножение на 10 оптимизнуть
Интересно, что деление выполнено обычным циклом с вычитанием. Видимо для данного алгоритма это быстрее (т.к. результат деления маленький). Можно попробовать и с моим кодом так поиграть...
---------- Post added at 17:29 ---------- Previous post was at 17:21 ----------
Развернул таки цикл в последовательность
Кстати, один из множителей всегда меньше 256, иначе было бы переполнение.
---------- Post added at 17:32 ---------- Previous post was at 17:29 ----------
Я думаю, если кардинальных оптимизаций больше не будет, на этом и остановимся.
Остановился на 34405448 тактов - 19.35 сек
Конечно же после разминки разойдутся и поймут что ассемблер - это не тайна за семью печатями, и явят ещё одну Колибри, но уже для РК-86.
Кстати вот новый (точнее незамеченный старый путь) для совершенствования расчета числа Пи, сдавала студентка и я её даже хорошо знаю, в 2009 году, причем успешно:
Думаю из этого куцего описания будет понятно куда можно попробовать дальше двинутся ? Или для ретро-процессоров это не по силам ?Код:; Зачетная задача: пользуясь рядом Тейлора для arctg, подсчитать число пи ; с 100 знаками после запятой. ; ; Расчет числа Пи сделаем по формуле Мачина ; ; 1 1 ; pi = 16 arc tg --- -4 arc tg--- ; 5 239 ; ; arc tg будем вычислять по формуле Тейлора: ; ; 3 5 7 9 ; x x x x ; arc tg x = x - --- + --- - --- + --- - ... ; 3 5 7 9 .186 stack segment stack dw 512 dup (?) stack ends data segment ; ------------------------------------------------------------------------------- ; Следующие числа указывают сколько цифр числа Пи нужно вычислять ; Я использовала программу MAKESZES.BAS чтобы вычислить эти значения ; в выводимом на экране результате только первые А (в нашем случе 100цифр) являются верными ; This BASIC program was used to calculate the equates for PIF.ASM. ; DEFDBL A-Z ; INPUT "Digits required"; A ; MPVSize = 32 * ((A / (LOG(2) / LOG(10)) + 255) \ 256) ; PRINT "NumDigits = "; A + 64 ; PRINT "MPVSize = "; MPVSize ; k = A / .69897 ; k = INT(15 + (k + k * .1)) 'floor 1 ; PRINT "Last1 = "; k ; k = INT(15 + (A / 2.37)) 'floor 2 ; PRINT "Last2 = "; k ; numDigits=164 mpvSize=74 last1=172 last2=57
Авторство программки конечно же не студентки, а уважаемого гуру:
https://sites.google.com/site/richgel99/; ASMPI by Rich Geldreich, December 1992 - June 1993
; (A FAST all-assembly PI calculator.)
; Thanks to Victor Yui for suggesting the division optimization.
; (This program has only been verified to 10,000 digits.)
https://sites.google.com/site/richge...-pi-calculator
Все что сделала студентка, так это покоцала оригинал (под процессор 286) до требований курса использовать процессор 86.
Теперь же надо тоже самое сделать, но уже покоцав оригинал до уровня команд любимых ретро-процессоров, причем глубокие оптимизации даже приветствуются.
Замечу, что схожие алгоритмы лежат в основе всех TOP-вычислителей числа Пи, но нам более чем будет достаточно для счастья и этого достаточно быстрого алгоритма, мне бы хотелось увидеть результат дальнейшего роста производительности нашей РК-86 в разы!
Последний раз редактировалось perestoronin; 08.11.2015 в 13:37.
Ретрокладовая продажи
Попробовал дожать spigot b2mа: 26539359 такта - 14.93 сек
pirk14.zip
Появилось желание повыпендриваться и сделал еще версию оптимизированную для 580ВМ1 и 8085 - в ней используются только общие для этих процов команды. Индивидуально для них можно оптимизировать лучше.
Оптимизированная версия:
на 580ВМ1: 24938659 тактов - 14.03 сек
на 8085: 24082312 такта - 13.55 сек
100 знаков считаются слишком быстро, вот результаты расчета 535 знаков:
1) Версия для 8080
8080 и 580ВМ1 - 755784115 тактов - 7 мин 5 сек;
8085 - 734253062 такта - 6 мин 53 сек;
2) Версия для ВМ1 и 8085
580ВМ1 - 709984370 тактов - 6 мин 39 сек;
8085 - 685592137 тактов - 6 мин 26 сек;
Насколько я понимаю, b2m использовал исходник отсюда (надо промотать вниз).
- - - Добавлено - - -
Забыл сразу написать. Еще резервы есть в использовании самомодифицирующегося кода (попробовал, а потом убрал). Кроме того, данный вариант может работать при разрешенных прерываниях, если не на РК (хитрое использование стека также в резерве).
Кардинального ускорения расчета большого количества знаков наверное лучше добиваться использованием другого алгоритма.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)