zagladam do wyniku w asmie ale nie za kazdym
razem bo to troche nieporeczne

ogolnie faktycznie sporo potrafi wycinac
ale wtedy widac bo wynik zauwazalnie
spada itp - tak ze na razie testuje troche
niestarannie bo nie chce sie zameczyc
ale wyniki i tak bywaja pouczajace

do góry

Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
> zagladam do wyniku w asmie ale nie za kazdym
> razem bo to troche nieporeczne
>
> ogolnie faktycznie sporo potrafi wycinac
> ale wtedy widac bo wynik zauwazalnie
> spada itp - tak ze na razie testuje troche
> niestarannie bo nie chce sie zameczyc
> ale wyniki i tak bywaja pouczajace
>

Z obliczeniami zmiennoprzecinkowymi to jest czasem tak, że powiedzmy
kompilator w danym fragmencie kodu wykorzysta MMX ale gdzieś wewnątrz
tego kodu jest wywołanie zewnętrznej funkcji (kompilator nie wie co
się w niej dzieje, bo to plik obiektowy z biblioteki) a ta zewnętrzna
funkcja to powiedzmy sin(x), więc ok, jest zrzucenie x na stos i
wywołanie CALL _sin i już znajdujemy się wewnątrz funkcji _sin:
kod funkcji _sin "widzi", że procesor jest w trybie MMX, więc
bezpośrednio z FPU skorzystać nie można i są dwa wyjścia:

1) obliczenie wartości sin(x) "na piechotę" bez użycia FPU

2) zrzucenie wszystkich rejestrów MMX do pamięci tymczasowej (na
przykład na stos), potem reset układu aby przełączyć go w tryb FPU,
wyliczenie sin(x), potem reset układu i przełączenie go w tryb MMX,
potem przywrócenie zawartości wszystkich rejestrów MMX

To który wariant się wykona zależy od biblioteki. Niestety x86 mają ten
"błąd projektowy" że MMX i FPU to tak na aprawdę jeden układ pracujący
w dwóch różnych trybach (i mają wspólną "pamięć" na rejestry),
przełączanie kontekstu pracy tego układu jest niestety "cyklochłonne" :D

do góry

W dniu środa, 17 października 2012 15:51:55 UTC+2 użytkownik Baranosiu napisał:
> Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
>
> > zagladam do wyniku w asmie ale nie za kazdym
>
> > razem bo to troche nieporeczne
>
> >
>
> > ogolnie faktycznie sporo potrafi wycinac
>
> > ale wtedy widac bo wynik zauwazalnie
>
> > spada itp - tak ze na razie testuje troche
>
> > niestarannie bo nie chce sie zameczyc
>
> > ale wyniki i tak bywaja pouczajace
>
> >
>
>
>
> Z obliczeniami zmiennoprzecinkowymi to jest czasem tak, że powiedzmy
>
> kompilator w danym fragmencie kodu wykorzysta MMX ale gdzieś wewnątrz
>
> tego kodu jest wywołanie zewnętrznej funkcji (kompilator nie wie co
>
> się w niej dzieje, bo to plik obiektowy z biblioteki) a ta zewnętrzna
>
> funkcja to powiedzmy sin(x), więc ok, jest zrzucenie x na stos i
>
> wywołanie CALL _sin i już znajdujemy się wewnątrz funkcji _sin:
>
> kod funkcji _sin "widzi", że procesor jest w trybie MMX, więc
>
> bezpośrednio z FPU skorzystać nie można i są dwa wyjścia:
>
>
>
> 1) obliczenie wartości sin(x) "na piechotę" bez użycia FPU
>
>
>
> 2) zrzucenie wszystkich rejestrów MMX do pamięci tymczasowej (na
>
> przykład na stos), potem reset układu aby przełączyć go w tryb FPU,
>
> wyliczenie sin(x), potem reset układu i przełączenie go w tryb MMX,
>
> potem przywrócenie zawartości wszystkich rejestrów MMX
>
>
>
> To który wariant się wykona zależy od biblioteki. Niestety x86 mają ten
>
> "błąd projektowy" że MMX i FPU to tak na aprawdę jeden układ pracujący
>
> w dwóch różnych trybach (i mają wspólną "pamięć" na rejestry),
>
> przełączanie kontekstu pracy tego układu jest niestety "cyklochłonne" :D

mmx to przestarzala podsekcja procka,
cos jak te funkcje do liczenia na bcd
nie wiem czy warto sie zajmowac i
przejmowac mmx a sse jest juz na innych
rejestrach i o ile wiem nie trzeba
nic przelaczac anie wlaczac. W kazdym razie
jak ja pisze sobie procke ktora uzywa sse
to nie mam zadnych problemow

do góry

Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
> mmx to przestarzala podsekcja procka,
> cos jak te funkcje do liczenia na bcd
> nie wiem czy warto sie zajmowac i
> przejmowac mmx a sse jest juz na innych
> rejestrach i o ile wiem nie trzeba
> nic przelaczac anie wlaczac. W kazdym razie
> jak ja pisze sobie procke ktora uzywa sse
> to nie mam zadnych problemow

Owszem zgoda, niemniej jednak żadna funkcja biblioteczna nie może
zakładać, że MMX nie jest używane i jak "widzi" że w rejestrach MMX są
dane różne od zera, to MUSI je jakoś zachować, bo nie wiadomo czy te
dane są potrzebne czy nie, a przed wykonaniem obliczeń
zmiennoprzecinkowych TRZEBA zresetować FPU (a przynajmniej tyle mówi
specyfikacja Intela) co spowoduje wyzerowanie wszystkich rejestrów
FPU/MMX a nie tylko tych, których użyjemy. Jeśli cały kod napiszesz w
assemblerze, to możesz iść "na skróty" i w ogóle nie dotykać MMX, ale
z punktu widzenia twórcy biblioteki nie można robić tego typu
założenia :D

do góry

Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
> mmx to przestarzala podsekcja procka,
> cos jak te funkcje do liczenia na bcd
> nie wiem czy warto sie zajmowac i
> przejmowac mmx a sse jest juz na innych
> rejestrach i o ile wiem nie trzeba
> nic przelaczac anie wlaczac. W kazdym razie
> jak ja pisze sobie procke ktora uzywa sse
> to nie mam zadnych problemow

Owszem zgoda, niemniej jednak żadna funkcja biblioteczna nie może
zakładać, że MMX nie jest używane i jak "widzi" że w rejestrach MMX są
dane różne od zera, to MUSI je jakoś zachować, bo nie wiadomo czy te
dane są potrzebne czy nie, a przed wykonaniem obliczeń
zmiennoprzecinkowych TRZEBA zresetować FPU (a przynajmniej tyle mówi
specyfikacja Intela) co spowoduje wyzerowanie wszystkich rejestrów
FPU/MMX a nie tylko tych, których użyjemy. Jeśli cały kod napiszesz w
assemblerze, to możesz iść "na skróty" i w ogóle nie dotykać MMX, ale
z punktu widzenia twórcy biblioteki nie można robić tego typu
założenia :D No chyba, że miałeś na myśli używanie SSE2 i późniejszych
jako zamiennika FPU do obliczeń zmiennoprzecinkowych ale tam chyba nie
ma trygonometrii, potęgowania, logarytmów i tego typu rzeczy (nie znam
SSE powyżej wersji 4.x)

do góry

W dniu środa, 17 października 2012 16:45:35 UTC+2 użytkownik Baranosiu napisał:
> Dnia 17.10.2012 kenobi <p...@g...com> napisaďż˝/a:
>
> > mmx to przestarzala podsekcja procka,
>
> > cos jak te funkcje do liczenia na bcd
>
> > nie wiem czy warto sie zajmowac i
>
> > przejmowac mmx a sse jest juz na innych
>
> > rejestrach i o ile wiem nie trzeba
>
> > nic przelaczac anie wlaczac. W kazdym razie
>
> > jak ja pisze sobie procke ktora uzywa sse
>
> > to nie mam zadnych problemow
>
>
>
> Owszem zgoda, niemniej jednak �adna funkcja biblioteczna nie mo�e
>
> zak�ada�, �e MMX nie jest u�ywane i jak "widzi" �e w rejestrach MMX s�
>
> dane r�ne od zera, to MUSI je jako� zachowa�, bo nie wiadomo czy te
>
> dane sďż˝ potrzebne czy nie, a przed wykonaniem obliczeďż˝
>
> zmiennoprzecinkowych TRZEBA zresetowa� FPU (a przynajmniej tyle m�wi
>
> specyfikacja Intela) co spowoduje wyzerowanie wszystkich rejestr�w
>
> FPU/MMX a nie tylko tych, kt�rych u�yjemy. Je�li ca�y kod napiszesz w
>
> assemblerze, to mo�esz i�� "na skr�ty" i w og�le nie dotyka� MMX, ale
>
> z punktu widzenia tw�rcy biblioteki nie mo�na robi� tego typu
>
> za�o�enia :D No chyba, �e mia�e� na my�li u�ywanie SSE2 i
p�niejszych
>
> jako zamiennika FPU do obliczeďż˝ zmiennoprzecinkowych ale tam chyba nie
>
> ma trygonometrii, pot�gowania, logarytm�w i tego typu rzeczy (nie znam
>
> SSE powy�ej wersji 4.x)

no ja sse tez znam dosyc slabo,

czyli co - kazda funkcja biblioteczna jest
obciazona tym sprawdzaniem i obslugiwaniem
mmx i innych rzeczy ? (nie tylko mmx mozna
zmienic mozna tez zmienic np tryb zaokraglaniaalbo ustawiona precyzje obliczen )
- interesowalem sie tym ale nie mam jasnosci

do góry

Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
> no ja sse tez znam dosyc slabo,
>
> czyli co - kazda funkcja biblioteczna jest
> obciazona tym sprawdzaniem i obslugiwaniem
> mmx i innych rzeczy ? (nie tylko mmx mozna
> zmienic mozna tez zmienic np tryb zaokraglaniaalbo ustawiona precyzje obliczen )
> - interesowalem sie tym ale nie mam jasnosci
>

Jeśli funkcja biblioteczna nie korzysta z MMX/FPU to może po prostu
tego "nie dotykać" ale większość funkcji z <math.h> niestety musi. Na
szczęście są instrukcje maszynowe FXSAVE/FXRSTOR którymi można
najpierw zapisać stan FPU/MMX do bloku pamięci, potem zrobić swoje, a
potem przywrucić stan z wykonanego wcześniej "zrzutu" (Intel w specyfikacji
określa, że taki zrzut nie zajmie więcej niż 512 bajtów i tyle
trzeba zagwarantować, choć w praktyce zajmuje to nieco mniej
miejsca). Instrukcje zaprojektowano pod kątem przełączania zadań, ale
można ich używać także w trybie nieuprzywilejowanym i część bibliotek
matematycznych z tego właśnie korzysta.

Nie mam pojęcia co przyświecało "geniuszowi" który postanowił
zaoszczędzić na pamięci rejestrów, przecież gdyby to były fizycznie
osobne komórki pamięci w procesorze, to nie byłoby żadnych problemów z
tym związanych.

do góry

Dnia 17.10.2012 kenobi <p...@g...com> napisał/a:
> no ja sse tez znam dosyc slabo,
>
> czyli co - kazda funkcja biblioteczna jest
> obciazona tym sprawdzaniem i obslugiwaniem
> mmx i innych rzeczy ? (nie tylko mmx mozna
> zmienic mozna tez zmienic np tryb zaokraglaniaalbo ustawiona precyzje obliczen )
> - interesowalem sie tym ale nie mam jasnosci
>

Jeśli funkcja biblioteczna nie korzysta z MMX/FPU to może po prostu
tego "nie dotykać" ale większość funkcji z <math.h> niestety musi. Na
szczęście są instrukcje maszynowe FXSAVE/FXRSTOR którymi można
najpierw zapisać stan FPU/MMX do bloku pamięci, potem zrobić swoje, a
potem przywrócić stan z wykonanego wcześniej "zrzutu" (Intel w specyfikacji
określa, że taki zrzut nie zajmie więcej niż 512 bajtów i tyle
trzeba zagwarantować, choć w praktyce zajmuje to nieco mniej
miejsca). Instrukcje zaprojektowano pod kątem przełączania zadań, ale
można ich używać także w trybie nieuprzywilejowanym i część bibliotek
matematycznych z tego właśnie korzysta.

Nie mam pojęcia co przyświecało "geniuszowi" który postanowił
zaoszczędzić na pamięci rejestrów, przecież gdyby to były fizycznie
osobne komórki pamięci w procesorze, to nie byłoby żadnych problemów z
tym związanych.

do góry

W dniu środa, 17 października 2012 17:46:08 UTC+2 użytkownik Baranosiu napisał:
> Dnia 17.10.2012 kenobi <p...@g...com> napisaďż˝/a:
>
> > no ja sse tez znam dosyc slabo,
>
> >
>
> > czyli co - kazda funkcja biblioteczna jest
>
> > obciazona tym sprawdzaniem i obslugiwaniem
>
> > mmx i innych rzeczy ? (nie tylko mmx mozna
>
> > zmienic mozna tez zmienic np tryb zaokraglaniaalbo ustawiona precyzje obliczen )
>
> > - interesowalem sie tym ale nie mam jasnosci
>
> >
>
>
>
> Je�li funkcja biblioteczna nie korzysta z MMX/FPU to mo�e po prostu
>
> tego "nie dotyka�" ale wi�kszo�� funkcji z <math.h> niestety musi. Na
>
> szcz�cie s� instrukcje maszynowe FXSAVE/FXRSTOR kt�rymi mo�na
>
> najpierw zapisa� stan FPU/MMX do bloku pami�ci, potem zrobi� swoje, a
>
> potem przywruci� stan z wykonanego wcze�niej "zrzutu" (Intel w specyfikacji
>
> okre�la, �e taki zrzut nie zajmie wi�cej ni� 512 bajt�w i tyle
>
> trzeba zagwarantowaďż˝, choďż˝ w praktyce zajmuje to nieco mniej
>
> miejsca). Instrukcje zaprojektowano pod k�tem prze��czania zada�, ale
>
> mo�na ich u�ywa� tak�e w trybie nieuprzywilejowanym i cz�� bibliotek
>
> matematycznych z tego w�a�nie korzysta.
>
>
>
> Nie mam poj�cia co przy�wieca�o "geniuszowi" kt�ry postanowi�
>
> zaoszcz�dzi� na pami�ci rejestr�w, przecie� gdyby to by�y fizycznie
>
> osobne kom�rki pami�ci w procesorze, to nie by�oby �adnych problem�w z
>
> tym zwi�zanych.

zapewne taniosc rozwiazania, i tak raczej
wiadomo ze x86 ma fatalnie zaprojektowana
liste rozkazow itd, Zaluje tez ze nie wiem
wiecej nt 'reszty' hardwaru (tak zeby widziec
dokladniej jak soft dziala na sprzecie),
ale to moze kiedy indziej ostatnio czuje sie
troche wypalony i stary, moze wogole za duzo
zajmuje sie optymalizacjami przydaloby sie
zrobic cos troche mniej technicznego

do góry

Ponurą porą Wed, 17 Oct 2012 15:47:32 +0000, Baranosiu wyszeptał:

> Nie mam pojęcia co przyświecało "geniuszowi" który postanowił
> zaoszczędzić na pamięci rejestrów, przecież gdyby to były fizycznie
> osobne komórki pamięci w procesorze, to nie byłoby żadnych problemów z
> tym związanych.

Rejestr to nie jest komórka pamięci. To znaczy może masz generalnie
rację, ale to nie jest takie proste. Na wszystkim większym od jakiegoś
małego Atomka istnieje "register rename", "retire unit", i pozostałe
elementy pipeline, a z tego wynika, że rejestr o ile w ogóle
istnieje jako komórka pamięci (jedna lub w ogóle) to łączy się z całą
architekturą wokoło. Być może MMX/FPU są prościej zaimplementowane,
być może też jest to historyczna naleciałość - nawet nie wiedziałem.

W każdym razie takie eax na pewno istnieje w asm i jako zapisany
przed context switchem stan (czy w core), ale istnienia fizycznego
dawno nikt nie udowodnił. Asm definiuje maszynę a procesor ją
implementuje, ale ma wolną rękę jak to robi.

--
Edek

do góry