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

[ivagor]

возможно ли её перенести на 8080 ?

У меня был опыт переноса небольшой программки с 8086 на 8080 (15 лет назад ). Получилось довольно медленно и длинно, но зато работало. Это, конечно, не значит, что нельзя нормально конверснуть с писи, но имхо лучше реализовывать алгоритм для 8080.

b2m, чтобы ты был в тонусе - в категории до 535 байт дожал (с предварительным расчетом таблицы и еще кое-какими изменениями) pirk 100 знаков до 10.61 сек. Твой ход . pi32 100% можно оптимизировать до 10 и менее секунд, может даже до 8-9.

[ivagor]

Насчет переносов могу привести такой пример. Несколько лет назад с помощью рекомпилятора Tim0xи адаптнул распаковщик megalz с z80 на 8080. Потом оптимизировал его и все такое. А потом b2m по сишному распаковщику написал распаковщик для 8080, который (если не изменяет память) в разы быстрее. Да, там тоже можно пару байтов и пару тактов скинуть, но в разы его уже не улучшить. Это я к тому, что с си вполне можно написать нормальную программу для 8080, что уже не раз демонстрировал b2m, и, с другой стороны, с асма на асм можно довольно неудачно перенести.

[b2m]

b2m, чтобы ты был в тонусе - в категории до 535 байт дожал (с предварительным расчетом таблицы и еще кое-какими изменениями) pirk 100 знаков до 10.61 сек. Твой ход .

Без таблиц 12.77 сек. Если добавишь свои таблицы, наверняка будет быстрее 10 сек.

pi32 100% можно оптимизировать до 10 и менее секунд, может даже до 8-9.

Ну не знаю, я уже и циклы деления/умножения развернул, а оно всё равно только 10.64 сек.

[ivagor]

pi.rar - зачетно. Я собирался модифицировать первоначальный spigot подобным образом, а ты уже сделал.

[litwr]

Под z80 можно заметно оптимизировать, да и для 8080 предел не достигнут.

Извините, но что можно тут оптимизировать под z80? Хотя бы одно что-нибудь можете указать? А предел никогда не будет достигнут, если не зафиксировать алгоритм. Неужели тут нет никого со Спектрумом?!

[ivagor]

что можно тут оптимизировать под z80? Хотя бы одно что-нибудь можете указать?

Первое, что приходит в голову - деление. Тут и команды вычитания регистровых пар пригодятся (для ускорения восстановления остатка) и дополнительные регистры.

[ivagor]

b2m ленится оптимизировать "по-мелкому", а мне было интересно. Заменил в последнем pi.rar умножение и деление:
100 цифр - 12868015 тактов - 7.24 сек
536 цифр (из них 535 верно) - 351958021 тактов - 3 мин 18 сек
Просто охренеть. И там еще есть резервы, я их не трогал, тупо заменил процедуры. А так явно можно 100 знаков меньше чем за 7 секунд посчитать. Как бороться с b2mом?

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

Уточню - это без учета времени расчета таблицы умножения

[balu_dark]

b2m ленится оптимизировать "по-мелкому", а мне было интересно. Как бороться с b2mом?

Самый простой вариант - добавить ему пурген в чай.

А вообше - очень интересная тема - с удовольствием слежу. пока нет возможности проверить или поправить на 8ми битке.

[b2m]

Как бороться с b2mом?

Исключительно личным примером

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

добавить ему пурген в чай.

Э... проверено на личном опыте?

[ivagor]

Во избежание недоразумений заменю формулировку своего риторического вопроса на более корректную - Как соревноваться с b2mом? Для себя у меня есть отмазка - я (практически) не программист.
Интересно было бы увидеть реализацию для 8080 более эффективного алгоритма.