Как загрузить в FPU число без знака?

Есть инструкция FILD, но она "видит" знак числа.
Может кто знает инструкцию для беззнаковых чисел?
Просмотрел все инструкции из руководства Intel - вроде нет такого.

Делаю пока таким образом:

Если бит 31 == 1, то снимаю этот бит и затем (после FILD) добавляю 2 в степени 31.
Но морока это конечно.

 

AsmGuru62
sub [int16],8000h
fild [int16]
fisub [C8000];=8000h

 

Mikl___
То что надо!
FILD 64-битный бывает!
Это я просмотрел - старею, однако...

 

То что надо!
А что надо ? Нехилые тормоза на чтение 8 байт после записи двух по 4 (store-to-load forwarding stall) ?!

Еще вариантик:

Код (Text):

1. f32 dd 0, 4F800000h ;2^32 в формате single
2.  
3. fild [i32]
4. mov eax,[i32]
5. shr eax,31
6. fadd dword ptr [f32+eax*4]

 

leo
ну я бы проще сделал...

Код (Text):

1. bs  dd  4F800000h
2.  
3. sub     [i32], 80000000h
4. fild    [i32]
5. fadd    [bs]

gcc вообще не заморачивается:

Код (Text):

1.     xorl    %edx, %edx
2.     movl    16(%esp), %eax
3.     movl    %edx, 4(%esp)
4.     movl    %eax, (%esp)
5.     fildq   (%esp)

ms тоже

Код (Text):

1.     fild    DWORD PTR _x$[esp-4]
2.     test    eax, eax
3.     jge SHORT $LN3@ff
4.     fadd    QWORD PTR __real@41f0000000000000
5. $LN3@ff:

 

leo
З.Ы. давненько вас чего-то видно не было

 

А что, в самом FPU нету FABS? Или это некошерно по соображениям производительности?

 

PSR1257
Я так понял, что тк надо, чтобы при наличии числа скажем 3753753753h в копроцессор загружалось 3753753753, а не -541213543.
Ну и при чем здесь FABS? Получить не -541213543, а 541213543? Ржунимагу.

 

AsmGuru62
А можно на x64 и с SSE3?

 

Замечательный поток предложений - буду учиться!
Про stall (large load after two short stores) - это верно. В принципе скорости мне не надо, но всё таки интересно покопать!
Дисассемблировать как хороший компилер это делает - тоже неплохая идея.

 

leo
Твой код работает великолепно!

 

Ustus

Во-первых, аналогичный вариант уже Black_mirror предложил в #2 (правда с опечаткой fisub вместо fiadd). Во-вторых, он "проще" по размеру\числу_команд, а по кол-ву "блох" (микроопераций и их зависимости) - "хуже" Ну и самое главное - он изменяет исходный операнд, что во многих случаях недопустимо

ms "заморачивается", т.к. partial write тормозит всегда, а jcc только в случае непредсказанного перехода

Mikl___

В данном случае я не ворчу, а просто принимаю посильное участие, вставляя свои 5 копеек
А вариант с пушами и мувами юзается и gcc, и борманом, т.к. он прост и очевиден "как валенок". С загрузкой беззнакового целого еще можно как-то обойтись без partial write, а вот при передаче double в функцию (по значению) наверняка все компилеры юзают пуши и "ворчать" тут бесполезно - можно только самому "заморачиваться" и передавать их по ссылке\указателю

 

leo
Никакой опечатки там нет, там числа просто двухбайтовые.

 

Black_mirror
Упс, пардон. Не учел, что вычитание - целочисленное и соотв-но 8000h воспринимается как отрицательное и "минус на минус дает плюс"

 

leo

Не заметил, торможу

Это да.

Переходите на x64 Кстати, многие компилеры умеют и на 32 передавать double через регистры, если их как следует попросить. Правда это нифига не стандартизовано, что плохо.

 

Mikl___
Ну вообще-то я имел ввиду SSE. С FPU такое можно проделать только через извращения. Например Watcom'овский компилер в свое время был очень популярен в частности потому, что хорошо оптимизил вещественную арифметику сам по себе и кроме того позволял чуть ли не собственные соглашения вызовов сочинить используя pragma aux.