в смысле, посмотреть на того, у кого времени ещё меньше, чтобы понять, что у нас его дофига?)

а, ну да

:)

Фреймы адресуются в общем битовом потоке, или в отдельном индексном словаре?

Релиз эмулятора DOSBox 0.75 https://opennet.ru/52911/

Короче, реально это Каспер его блочит. Второй раз за 2 дня такой глюк, отключаю защиту Каспера на минуту — всё ок.

Ох ты, ёлы-палы! Неужели?
А чего ж на официальном сайте его нет?

Добавлен режим корректного масштабирования пикселей с сохранением соотношения сторон (например, при запуске игры 320x200 на экране 1920x1080 пиксели будут отмасшатабированы 4x5 для получения изображения 1280x1000 без размытия.
Добавлен монохромный и композитный режимы вывода для игр, написанных для видеокарт CGA.
Ничосси

Да это я вижу, я про dosbox.com.
Видимо, не успели ещё. Либо я не понимаю, что значит staging...

¯\_(ツ)_/¯

А что там записывать? Спрей с изопропанолом, салфетка.

Такой интересный вопрос у меня.
Может, здешний народ знает ответ? :)

Необходимо выполнить умножение 2-х длинных целых знаковых чисел длиной N слов, которые хранятся в дополнительном коде little-endian. Т.е. 2 — это 0002 0000 (hex, при условии, что слово = 16 бит, побайтно: 02 00 00 00), а -2 — FFFE FFFF (побайтно: FE FF FF FF).

Для примера возьмём простой алгоритм умножения (без Карацубы), где для C = A * B каждое слово числа A умножается на каждое слово числа B и записывается в C со сдвигом и суммированием (с переносом при переполнении).

У нас есть операции умножения знаковых чисел и беззнаковых, причём результат произведения может быть в 2 раза больше, чем множители. По моим наблюдениям, удобнее использовать беззнаковое умножение (каждой пары слов), например:

FFFE FFFF
x
0002 0000
=
FFFC 0001
+
0000 FFFE 0002
=
FFFC FFFF 0002

2-ку убираем, получаем
FFFC FFFF = -4, всё ок.
Именно поэтому 2-3-операндный imul в асме (где старшая часть произведения отбрасывается) используется как для знаковых чисел, так и для беззнаковых.

При знаковом умножении получается так:

FFFE FFFF
x
0002 0000
=
FFFC FFFF
+
0000 FFFC FFFF
=
FFFC FFFB 0000 0001

Какая-то ерунда. По крайней мере, это требует преобразования но не очень понятному мне алгоритму.

А теперь самое главное :)

Необходимо определить — было бы переполнения при умножении.
Понятное дело, что если мы вылезли за диапазон N слов, то переполнение было.
А если нет?

Я пока вижу только такой алгоритм: умножать абсолютные значения множителей (C = abs(A)*abs(B)), поменять знак произведения, если знаки A и B отличаются и сравнить знак результата с тем, что должно получиться (т.е. если знаки A и B разные, значит должно получиться отрицательное число).

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

Вопрос: можно ли (и самое главное, как — по какому алгоритму) определить переполнение после умножения без приведения исходных множителей к абсолютным величинам?

Если нужно, алгоритм умножения можно чуть-чуть модифицировать (добавив что-то или заменив какие-то операции).
Цель — упрощение кода.

Не до конца стрирает.

я ничего не понял. надо понять когда умножение 32x32->32 переполнилось?

ну умножь их в 64 бита результата и старшее слово посмотри

если оно все 0 и все ффф, и если знак младшего с ним совпадает то переполннеия не было

а еще посмори в доку, вдруг 32битное умножение УЖЕ ставит флаг ПЕРЕПОЛНЕНИЯ...

Неее...
Число знаковое. Пусть будет 32x32 и умножаем по 16x16 (для упрощения).
Если результат вылезает за 32 бита — тут всё понятно.
А если вылезло за пределы значений?
Скажем, 3'000'000 * 1'000 = 3'000'000'000 — это тоже 32 бита, но положительные значения не могут превышать 2'147'483'648, т.е. 3 млрд — это фактически уже -1'294'967'296.
Вот эту ситуацию и нужно обнаружить.
Ну и то же самое с отрицательными числами.