mhash na sparc - testy

[Tomasz Mateja]

Paweł Sikora napisał(a):
> Tomasz Mateja pisze:
> 
>> #0  0xf7f07540 in mutils_memset (s=0xffadf6e7, c=0 '\0', n=<value 
>> #1  0x00010844 in frag_test (hashid=<value optimized out>) at frag_test.c:70
> 
> mutils_word8 buf1[MAX_INPUT_SIZE + 1];
> (...)
> mutils_memset(buf1, val, input_size + 1);
> 
> mutils_memset sztywno zaklada, ze bufor lezy na granicy slowa,
> bo rzutuje sobie (void*)s na (word32*) leci zapis.
> w praktyce jak dostanie jakis bufor na bazie char[] ktory nie
> musi lezec na granicu slowa to sie spotka z wyjatkiem procesora.
> zreszta caly zbiorek tych algorytmow dlubiacych po pamieci
> z stdfns.c jest okdr. imlementacja analogicznych funkcji
> w glibcu, czy rozwijalnych odpowiednikow w gcc jest lepsza
> i przenosna.

Z tego wynika że zbudowanie sobie mhash na sparcu (pewnie wszystkich 
dużych indianach też) to proszenie sie o klopoty. Ale taki np. php 
wymaga mhash. Więc jaka politykę uprawiamy: budujemy takie pakiety (no 
bo sie budują) i na ich podstawie inne czy dajemy exclusive arch i koniec?

-- 
T.