Меня печалит, что ресурсы периодически дохнут, и не везде подробности есть.Цитата:
Сообщение от ivagor
Думаю, лучше на гитхаб класть.
Вид для печати
Меня печалит, что ресурсы периодически дохнут, и не везде подробности есть.Цитата:
Сообщение от ivagor
Думаю, лучше на гитхаб класть.
Это wikidot, а не сайт, она вряд ли подохнет. 15 лет уже работает. Но если боишься - сделай экспорт и заливай периодически на archive.org.
Всё верно, лучше дублировать нужную инфу. Я обычно скачиваю к себе локально на NAS, плюс дублирую в свою группу ВК.Цитата:
Сообщение от Bedazzle
- - - Добавлено - - -
Там используется "трюк": умножаем на 26 и делим на 256, т.е. по сути умножаем на 0,1015625 - что очень хорошо приближается к 1/10. Для 8-битных чисел, под которые заточена процедура, точность получается достаточная.Цитата:
Сообщение от ivagor
Всё делается сдвигами и парой сложений. Красиво придумано!
Смотря для каких задач. Деление на 10 у меня в первую очередь ассоциируется с преобразованием bin->dec для печати, для этой цели я бы не стал использовать приближенную процедуру. Но задачи бывают разные, для интерполяции при воспроизведении звука я использовал деление через умножение, там точности достаточно.Цитата:
Сообщение от Denn
- - - Добавлено - - -
Если подумать, то E_div_10 нельзя использовать для преобразования bin->dec не только из-за неточности, но и из-за того, что она не вычисляет остаток.
Хватит исправлять других, исправлю себя. Данная процедура будет правильно делить HL/C не при любых соотношениях HL и С. Но это можно легко поправить
Скрытый текст
Код:DIV_HL_C:
; Делимое: [HL]
; Делитель: [C]
; Частное: [HL]
; Остаток: [A]
XRA A
MVI B,16
LOOP:
DAD H
RAL
JC NOSKIP
CMP C
JC SKIP
NOSKIP:
SUB C
INR L
SKIP:
DCR B
JNZ LOOP
RET
[свернуть]
Именно для этой задачи мне и понадобилось деление на 10 ;)Цитата:
Сообщение от ivagor
Самая быстрая процедура перевода в десятичный вид делением вообще не пользуется - в зависимости знака текущего остатка(сначала он равен исходному числу) в HL она вычитает или добавляет:Цитата:
Сообщение от Denn
40K, 20K, 10K, 4K, 4K, 2K, 1K, 400, 400, 200, 100, 40, 40, 20, 10,
Параллельно при неотрицательном остатке в HL к A добавляется 4, 4, 2, 1.
Круто, но у меня получилось довольно громоздко. Оптимизировать можно, но скорее всего вариант с делением все же будет компактнее. Интересно бы сравнить с double dabble.Цитата:
Сообщение от blackmirror
- - - Добавлено - - -
Один момент не отметил - использовал флаг заема/переноса, не знака.
Долгое время пользовался какой-то чужой процедурой, честно спёртой из кода какой-то игры (вроде РКшной?). Сейчас решил разобраться, как она устроена. Там тоже сделано вычитаниями констант: сначала вычитают 10000 пока не уйдут в минус, потом -1000, потом -100 и т.д.. В общем не сильно громоздко, но скорость очень зависит от значения исходного числа, мне показалось это "некрасивым", решил сделать по-своему.Цитата:
Сообщение от blackmirror
В итоге придумалось так. Исходник в [HL]. Сначала умножаем [AHL] на 6,5536 (тобишь *65536/10000), в результате в [A] у нас оказывается первая (слева) цифра, её выводим на экран. Обнуляем аккумулятор. Далее 4 раза умножаем [AHL] на 10 (3хDAD H + 2xDAD D) и на каждом шаге выводим, а затем обнуляем значение [A].
Скорость не зависит от числа, а самый "тормозной" участок алгоритма - это деление на 10000 (два раза делим на 100 с помощью "марсианского" кода). Как-то так.
Если нужно вывести число, самый быстрый метод, на мой взгляд, перевод в BCD:Цитата:
Сообщение от Denn
Скрытый текст
Код:LXI H,1234
CALL TOBCD
JMP $ ; десятичное число в регистрах B,C,D = 00,12,34
TOBCD: LXI B,0
LXI D,16
L1: DAD H
MOV A,D
ADC A
DAA
MOV D,A
MOV A,C
ADC A
DAA
MOV C,A
MOV A,B
ADC A
DAA
MOV B,A
DCR E
JNZ L1
RET
[свернуть]
С выводом незначащих нулей придётся повозиться, но это уже мелочи.