Есть ли какой-то простой способ загрузить в FPU число 0xFFFFFFFFFFFFFFFF

?
Проблема в том что это UINT64, а FILD интерпретирует числа как INT64, и в st0 получается число "-1".

Так загружай через fld.

Вообще, для такого уже лучше SSE.

Не понял суть идеи. Как SSE тут поможет работать с 64-битными числами в FPU? Мне надо умножать целые 64-битные числа, и ошибки переполнения (если будут) обнаруживать. В SSE вроде ничего для этого нет.

SSE умеет работать с FPU.

Ну вот есть в памяти dq-число (0xFFFFFFFFFFFFFFFF). Как при помощи SSE его положить в регистры FPU? Не нашёл подходящих команд. Через MMX - MOVQ - получается в FPU не число а qnan-значение.

Причём тут FPU? Забудь про него, через SSE всё делай.

Мне надо умножение 64-битного числа. В SSE, насколько я понимаю, такой возможности нет (там предполагают только умножение за 4 захода, перемножать по 32 бита).

fldz fld1 fsubp st0,st1

а вообще смотри пределы fpu по числам. какое б целое ты не загрузил оно в дальнейшем переводится в 80bit. входит ли твое число, которое фпу может в себе хранить?

fld1 fchs

так даже лучше

a dt $7FFF+63:$FFFFFFFFFFFFFFFF; fld [a]

Я вообще не пойму, кто так числа записывает? Почему нельзя было написать "1.0"? a dt 1.0 fld tword[a]

поясни за +63 и :

FPU вроде бы не понимает такого способа, там просто -1 получается, и это не равно 0xFFFFFFFFFFFFFFFF.

Если тебе нужно тупо загрузить туда 0xFFFFFFFFFFFFFFFF, т.е. без преобразования из целого числа в дробное, то так и загружай

А, это не 1.0. Запутался из-за сообщений выше. Это 6. Но всё равно можно просто сделать dq 0xFFFFFFFFFFFFFFFF И так и загрузить. В чём проблема вообще...

fild dq - грузит только как int, а надо uint. fld dq - qnan fld dt - не позволяет написать 0xFFFFFFFFFFFFFFFF, надо неочевидное десятичное число писать (18446744073709551615.0).

КТ315
У меня всё позволяет. Ты на каком компиляторе пише...

значение в десятичном покажи st0

КТ315
У меня всё позволяет. Ты на каком компиляторе пише...

fasm. Для dt - только десятичные числа с точкой, hex-числа не хочет...

есть db dw+dd

6.724206286224187012e-4932

Вот тебе фокус-покус: val: db 0xFF, 0xFF, 0xFF,\ 0xFF, 0xFF, 0xFF, 0xFF,\ 0xFF, 0, 0 start: fld tword[val]

вот, а ему надо максимальное беззнаковое 64 битное

Не, ему надо как раз 0xFFFFFFFFFFFFFFFF

это исходное целое число максимальное беззнаковое 64 битное

Ничего не понял. Человеку надо в st0 чтобы было 0xFFFFFFFFFFFFFFFF. Как оно будет в десятичном, двоичном и других - без разницы. Число одно и то же.

Стикер

Стикер

это не соответствует максимальному uint64

А причём тут максимальный UINT64? Вопрос был о том, чтобы загрузить конкретное значение. Как его интерпретировал в плавающей точке x64dbg - дело вообще левое.

дальше читай, со слово "проблема"

"Проблема в том, что это UINT64, а fild загружает его как -1". Вот я и показал, как его можно загрузить не как -1, а как конкретное значение - 0xFFFFFFFFFFFFFFFF.

В итоге там в FPU получается какое-то специальное значение, не равное 18446744073709551615, и алгоритм рушится...

0xFFFFFFFFFFFFFFFF - переведи в десятичку и посмотри является ли это max uint64? вот эту десятичку ему и надо загрузить, но представил он ее в хексе

18446744073709551615 это не 0xFFFFFFFFFFFFFFFF.

Aiwan \ (•◡•) / _bot

Но не в представлении FPU.

ну да.

А чем mul плох? Целые числа. 64 бита. Ответ в два регистра.

mulsd вроде умножает только одно число

Тоже хочу перемножить пару чисел целых. На c++ перемножение двух 256 битных чисел занимает удивительных 400 тактов классическим математическим методом. На одном из Компов есть sse2

Попробуй с библиотекой GMP

В этом есть смысл.

Habr пишет 30000 тактов на умножение в gmp. Мои 400 тактов лучше.

Не верю. Слишком большая разница.