Verständnisfrage zu 64Bit-FreeBSD

Aldo

Aldo

Well-Known Member
Hallo,

meine Frage hört sich wahrscheinlich doof an, aber woher "weiß" ein installiertes FreeBSD eigentlich, ob es ein 32- oder 64 Bit-System ist?
Also konkret, wenn man ports installiert, woher wissen diese bzw. der Compiler, ober nun Code für 32- oder 64 Bit erzeugt werden soll?
Für SMP gibt es ja die Kerneloption SMP, aber wo steht was von 64 Bit?
Weder in der Kernconf, noch in der make.conf oder sonstwo...
Also woher weiß ports wofür es bauen soll?
In Gentoo-Linux gibt es ja die Option CHOST="x86_64-pc-linux-gnu" in der make.conf, gibt es bei FreeBSD was vergleichbares?
Ich weiß, doofe Frage, aber ich hab halt nichts entsprechendes gefunden... *rotwerd*
 
In der Kernelkonfiguration ist der Maschinentyp angegeben:
Code: 
machine alpha    # DEC Alpha = 64 Bit
machine amd64    # AMD64/EM64T = 64 Bit
machine i386     # Intel i386 = 32 Bit
machine sparc64  # Sun UltraSPARC = 64 Bit
...
Im Userland kann man das mittels uname -m abfragen.
 
Oder in der make.conf CPUTYPE.. der beinhaltet das auch.. wenn du also z.B. nen Pentium D hast und in deiner make.conf prescott als cputype bekommst 32bit binaries.. wenn du da nocona reinschreibst 64bit.
 
Aha.
Ich habe in der make.conf 'CPUTYPE=opteron' stehen.
Hab ich aus der examples.conf rausgesucht weil ich einen Opteron 175 hab.
Und mir fiel auf, daß beim compilieren dann '-march=athlon-mp' benutzt wird.
Ist das eigentlich korrekt?
Und warum werden beim Kernel bauen eigentlich automatisch die Optionen
'-mno-sse -mno-3dnow -mno-sse2' ect. gesetzt?
Wenn die Sachen schon hardwaremäßig da sind, warum werden sie dann nicht vom Kernel benutzt und explizit abgeschaltet beim bauen?
 
Dieses verhalten ist beim Kernel bauen eigentlich normal.

Optionen zum bauen des Kernels setzt du mit COPTFLAGS.. da werden nicht die normalen CFLAGS genommen.

Bei den COPTFLAGS solltest du generell etwas vorsichtiger als mit den CFLAGS sein.. und versuch erst garnicht da -msse -mmmx oder 3dnow mit reinzubauen.. es klappt nicht. -O2 -pipe -funroll-loops -ffast-math kannste dem antun.. mehr würd ich lassen.
 
Wenn COPTFLAGS nicht gesetzt wird, werden auch bei Kernel und Welt CFLAGS verwendet.

Die Optionen -mmmx und so weiter werden nie benötigt, weil die sowieso vom CPUTYPE impliziert werden. Die Option -funroll-loops kann die Performance auch verschlechtern (die Programme brauchen mehr Speicher → belegen mehr platz im Cache → häufigerer Cache-Miss). Die Option -ffast-math hat in einigen Fällen Einfluss auf die Präzision von Floating-Point-Operationen, das kann durchaus Schaden verursachen. Meine Empfehlung ist es die CFLAGS gar nicht zu setzen, der Standard ist nämlich gut gewählt.

Wenn schon eigene setzen, dann doch bitte mit -fno-strict-aliasing. Ohne kann es Ärger mit Kernel und Welt geben.
 
Das hat alles recht wenig mit irgendwelchen Flags oder Variablen zu tun. Entscheidend ist, dass dein cc(1) Binary unter FreeBSD/amd64 eben fuer amd64 uebersetzt ist und inhaerent "weiss", dass es erstmal nur amd64 Code erzeugen soll. Selbiges gilt fuer cc(1) unter i386, mips, alpha und ppc, etc.

Das Problem haben ja eh nur Compiler, welche nativen Bytecode erzeugen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben