Th i x86_64

[Pawel Sikora]

On Tuesday 03 of May 2005 17:45, Jakub Bogusz wrote:
> On Tue, May 03, 2005 at 05:00:06PM +0200, Arkadiusz Miskiewicz wrote:
> > On Tuesday 03 of May 2005 16:48, Mariusz Mazur wrote:
> > > On wtorek 03 maj 2005 15:52, Pawel Sikora wrote:
> > > > a co z potokami? czy robiac galaz generic nie stracimy na wydajnosci?
> > > > (podobnie jak w przypadku kodu i686 na athlonie).
>
> Jak niżej - kod może być mniej optymalny, ale dla Intela, nie AMD.
>
> > > Znaczy robimy osobne ia32e? :)
> >
> > Jaki to ma niby sens? (zwłaszcza, że pluto nie ma pojęcia czy stracimy
> > istotnie na wydajności (jeśli w ogóle) czy nie).
>
> Patrząc do gcc 4.0.0 (gcc/config/i386.[ch] - łatwo znaleźć grepem
> i potem vimem):
> Są dwa rodzaje szeregowania instrukcji (nocona i x86-64).
> Domyślne jest x86-64 (czyli K8). Czyli brak opcji znaczy tyle co
> -mtune={x86-64,k8,opteron,athlon64,athlon-fx}.
>
> -march={k8,opteron,athlon64,athlon-fx} (wszystkie równoznaczne) od
> (domyślnego) -march=x86-64 różni się tylko 3dnow.

-march=nocona od x86-64 wyroznia sie obsluga sse3.


w rpmie mamy 3 zestawy flag: x86-64, amd64 i ia32e,
dla ktorych proponuje ustawic odpowiednio march=x86-64, k8 i nocona.

oczywiscie distro i tak bedzie budowane pod x86-64,
ale zeby juz pozniej ktos nie plakal ze po przebudowaniu
rpma nie ma sse3, albo 3dnow to zrobmy to do konca.

-- 
The only thing necessary for the triumph of evil
  is for good men to do nothing.
                                           - Edmund Burke