🚀 go-pugleaf

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
>> PS1: Nie zawsze teoretycznie mamy IEEE. Na rzeczonej Odrze
>> czy Merze (czy nawet na PC-tach w poczatkowym okresie w
>> kompilatorach MS-sa) liczby FP wcale nie byly IEEE-owe
>> wiec nawet zalozenie o tych 17 cyfrach znaczacyh mantysy nie jest
>> bezwzgledniee jedynie sluszne.
>
> Zdziwisz się - FPU PC liczy na liczbach 80-bitowych, czyli nie są to typowe IEEE-754.

Jakos nie jestem w ogole zdziwiony hihi :)

> Ale... choćby w tym nielubianym przez ciebie Fortranie - da się wybrać jak mają być przeprowadzane 
> obliczenia - czy FPU, czy SSE itd. itp.

No i co z tego?
Poza tym to nieprawda. W Fortranie nie  (pokaz mi odpowiedni zapis standardu)
tylko w _kompilatorze/srodowisku_.

> Jeszcze bardziej się zdziwisz gdy przeczytasz w/w standard: jest gwarantowane że liczby całkowite 
> 32 bitowe można bezpiecznie trzymać (oraz porównywać) jako float point 64 bitowy.

Ale skadze!. Np. na Waiteku (o ile dobrze pamietam) operacje na nich
byly czesto _szybsze_ niz te wykonywane wtedy przez zwykly procesor (386/386SX)
na 'longach' (bo wtedy int ===short a long == 32b a dzialania na longach to juz
byla (prosta bo prosta, ale jednak) procedura, a nie jeden rozkaz maszynowy
jak dzis.

Np. w takim BorlandzieC mam ja nawet pod reka:

F_LXMUL@        proc    far

                push    si
                mov     si,ax       ; bylo xchg
                mov     ax,dx   ; bylo xchg
                or      ax,ax
                jz      @@loc_1
                mul     bx
@@loc_1:
                jcxz    @@loc_2
                xchg    ax,cx
                mul     si
                add     ax,cx
@@loc_2:
                xchg    ax,si
                mul     bx
                add     dx,si
                pop     si
                ret

F_LXMUL@        endp

AK