Hi Luetz,
ich wollte mal Fragen ob hier jemand näheres über 64-Systeme weiß. Soweit ich weiß gibts für den industriellen Gebrauch sowas schon seit einiger Zeit und für Privatkunden soll es bald kommen (es soll ja auch eine 64er XP-Version geben)

Ich nehme mal spontan an, dass eine 64-Bit CPU Basisregister zu 64-Bit besitzt.

Meine Fragen dazu:
- ist dann auch der Bus 64-Bit Breit oder koppelt man das über 2x32 Bit?
- wie heißen dann die symbolischen Namen der Register? etwa 'xeax', 'xebx' oder so?
- gibts dann auch (logischerweise) auf 64-Bit otimierte Ausführbare Dateien und Compiler? ( und oder werden auch 32-Bit Anwendungen schneller ausgeführt )
- wenn ja müsste man sich beim Programmaufbau nicht etwas umstellen? dann müssten ja int-Variablen plötzlich 64-Bit breit sein und 32-Bit Integers wären plötzlich so bescheurte Einheiten wie shorts auf 32-Bit Systemen.
- wie sieht dass dann mit der FPU aus? wird deren Standart dann auch gleich mit aufgebohrt?

wäre cool wenn da jemand Info's hätte...

google ist dein freund: x86-64 bzw. AA-64 heisst die 64bit architektur von intel
http://www.sandpile.org/

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

zum ia64 (intel) gibts auf developer.intel.com irgendwo tech files wo du entsprechende infos findest

hey cool die Nomeklatur is bei x86-64 mal wesentlich logischer aufgebaut!
habe ich das richtig verstanden, dass das 'AA-64' nen Intel-Standart is? Ich finde da sollten sich mal alle Developer auf _einheitlich_ standart einigen. (Das Geplänkel auf dem Gaphikartenmarkt zwischen Nvidia und ATI närvt genug!)

Nein, das war wohl ein Typo. Die 64-Bit-Architektur von Intel heißt IA-64, entsprechend der 32-Bit-Architektur (die heißt IA-32). Von Intel gibt's ja auch schon 64-Bit-Prozessoren (Itanium), die aber im Desktop praktisch ignoriert werden.

Deine Antworten lassen sich logischerweise nicht pauschal für _alle_ 64-Bit-Architekturen beantworten, denn jede Architektur ist anders, genau wie ja auch alle 32-Bit-Architekturen irgendwie anders sind. Es gibt noch viel mehr als nur IA-32-Prozessoren...

Aber ich will trotzdem mal mein Bestes versuchen:

Zitat:

- ist dann auch der Bus 64-Bit Breit oder koppelt man das über 2x32 Bit?

Der Bus hat nichts, aber auch gar nichts mit der Prozessorarchitektur zu tun. Es gab z.B. lange Zeit 32-Bit x86-CPUs mit einem 16-Bit-Bus (die SX-Varianten). Heutzutage sind AFAIK alle Busse schon 64 Bit breit. Das sagt aber sowieso nicht sooo wahnsinnig viel aus, denn das Memoryinterface arbeitet im allgemeinen mit Cachelines (die internen Caches sind in Cachelines aufgebaut), und diese sind inzwischen 32 _Byte_ (also 256 Bit) breit.

Zitat:

- wie heißen dann die symbolischen Namen der Register? etwa 'xeax', 'xebx' oder so?

Weiß ich nicht, ist aber auch egal. Oder?

Zitat:

- gibts dann auch (logischerweise) auf 64-Bit otimierte Ausführbare Dateien und Compiler? ( und oder werden auch 32-Bit Anwendungen schneller ausgeführt )

Es gibt nur "native"-Anwendungen und nicht-"native"-Anwendungen. Auf 64-Bit-Prozessoren sind native Anwendungen logischerweise 64-Bit-Anwendungen. Sowohl x86-64 als auch IA-64-Prozessoren sehen allerdings Backwardskompatibilität zu alten 32-Bit-Anwendungen vor. Prinzipiell schneller werden diese Anwendungen sicher nicht laufen - allerdings wirken sich schneller Taktzahlen und mehr Pipelines zumindest prinzipiell auch positiv auf alte Anwendungen aus.

Zitat:

- wenn ja müsste man sich beim Programmaufbau nicht etwas umstellen? dann müssten ja int-Variablen plötzlich 64-Bit breit sein und 32-Bit Integers wären plötzlich so bescheurte Einheiten wie shorts auf 32-Bit Systemen.

Das ist richtig. Wenn du gut programmierst dann beziehst du solche Überlegungen aber sowieso immer in dein Programmdesign mit ein.
Ein int ist nun Mal als die "natürliche" Ganzzahleneinheit eines Prozessors definiert. Bei einer 64-Bit-CPU ist das natürlich ein 64-Bit Integer. 32-Bit-Integers werden von einer 64-Bit-CPU womöglich sogar nicht so effizient verarbeitet, genauso wie das Arbeiten mit 16-Bit-Integers auf einem IA-32-Prozessor im allgemeinen nicht so effizient ist.

Zitat:

- wie sieht dass dann mit der FPU aus? wird deren Standart dann auch gleich mit aufgebohrt?

Die FPU ist schon lange keine getrennte Einheit mehr sondern zentraler Bestandteil aller Prozessoren. Damit erübrigt sich die Frage wohl.

Zitat:

Ich finde da sollten sich mal alle Developer auf _einheitlich_ standart einigen. (Das Geplänkel auf dem Gaphikartenmarkt zwischen Nvidia und ATI närvt genug!)

Träum weiter. Es hat noch nie einen einheitlichen Assemblerstandard bei Prozessoren gegeben. Nur weil du noch nie Assembler für einen Z-80, PPC, ARM oder sonstigen Prozessor geschrieben hast heißt das noch lange nicht daß es solche Prozessoren nicht gab. Der Prozessormarkt war schon immer fragmentiert.

Und es gibt ja auch einheitliche Standards. C ist ein solcher einheitlicher Standard - um genau zu sein wurde C entwickelt, damit UNIX auf mehr als nur einem Prozessortyp lauffähig ist.

Der Markt für GPUs ist im Prinzip genau gleich. Auch hier gibt es keinen einheitlichen Assemblerstandard. Aber es gibt eben Standards wie OpenGL - besonders wenn OpenGL 2.0 dann endlich durch ist.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ich denke mal, daß es bei den Standards bleiben wird und einfach nur die Quasi-neuerungen standardisiert werden:

short = 16 Bit,
int = 32 Bit,
long = 64 Bit (endlich auch unter Windoof?!? =)
long long = 128 bit (?)

Zum Bleistift emuliert Java auf Win den Datentyp long (64 bit) mit zwei ints usw., während auf Tux echte 64 Bit genommen werden.

xeax oder eaxx ? Eaxx läßt sich schneller tippen ;)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

in der iX - januar 2003 sind auch noch infos darüber

Zitat:

Kriz postete
Ich denke mal, daß es bei den Standards bleiben wird und einfach nur die Quasi-neuerungen standardisiert werden:

short = 16 Bit,
int = 32 Bit,

Zitat:

xeax oder eaxx ? Eaxx läßt sich schneller tippen ;)

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Zitat:

Tron postete

Zitat:

long = 64 Bit (endlich auch unter Windoof?!? =)

mein MinGW hat keine probleme mit 64bit (long long)
iirc hat sogar der vc++ nen 64bit datentyp[/i]

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Hehehe, mit "echten" 64 Bit meine ich keinen zusammengeschusterten Datentyp, sondern einen für den Gebrauch einheitlichen 64 Bit Datentyp. Daß Tux unter einem PC auch nur mit 32 Bit Wasser köchelt, is doch klar =)

__int64 o_O - Weiche Satan, weiche!

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

lol, was soll denn aber jetz schon die entwicklung von programmen bringen die 64 bit usen ? bis jeder user son prozessort hat wird sicherlich noch ein oder zwei jahre dauern

mal so ne frage wie soll man den an 64 bit ran kommen ohne "zusammengeschusterten" Datentyps ?

Coding Center --- Tutorials über Programmierung und andere Themen
Amazon Preisbeobachung mit Preisalarm

Tja, das ist ja die Frage bei "nieder-bittigen" Prozessoren. Das geht garnicht als nativer Datentyp. So muß jeder Compiler / Interpreter sich bei bedarf mit seinen Sprachmitteln selber was... zusammenschustern :P

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Meine Sorge bei dieser Sache ist, dass es bei 64-Bit Compilern für den 64er Neulinge ein heilloses Durcheinander bei den Datebtypen gibt. Man müsste ja schließlich sich mental (und alte Codes die man wiederverwenden will) komplett umstellen. Mir würde es da schon genügen, wenn dann wenigstens die Compiler sich einigen, welcher Datentyp wie viel Bit hat.

Im Bezug auf Datentypen drängt sich allerdings eine Frage auf:
auf einem 16-Bit System:

byte = 8 Bit
int = 16 Bit
long = 32 Bit
long long = (gabs das ?)

Warum ist dann auf 32-Bit Systemen nicht konsequent vorgangen ? - also etwa so: [denn beim jetzigen Standart is 'long' überflüssig!]

byte = 8 Bit
short = 16 Bit
int = 32 Bit
long = 64 Bit

etwa aus Kompatibilitätsgründen zu altem Quellcode ?

mein Vorschlag/Wunschtraum für 64-Bit wäre [long long halt ich net für sinnvoll]

short = 32
int = 64
long = 128

also 3 Integer-Datentypen ( natürlich noch byte und short short oder so)

Wahrscheinlich wird man aber so vorgehen [bisherige Entwicklungen verfolgend]:

short = 16
int = 32
long = 64
long long = 128 (?)

@v|->Tron: da wär ich mir nicht so sicher.... - Du hast keine Ahnung was diese wuseligen Gnome bei M$M sich so alles einfallen lassen (man denke nur an TCPA etc.. )

ganz sicher nicht!
int wird auf jeden fall 64bit breit sein, da es den nativen datentyp des jeweiligen prozessors repraesentiert, was ich auch schon weiter oben geschrieben habe.

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Es gibt keinen Standard der besagt, wieviele Bits ein Datentyp haben muß. Es ist lediglich vorgegeben, daß sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long).

Und jeder der meint, die Datentypen wären heutzutage einheitlich hat ganz offensichtlich noch nie einen anderen Prozessor als einen x86er gesehen. Und selbst wer x86-Prozessoren gesehen hat dürfte eigentlich wissen, daß bei den 16-Bit-Varianten die Datentypen üblicherweise auch anders festgelegt werden.

Es gibt einfach keine Garantie dafür, daß ein Datentyp eine bestimmte Größe hat. Sobald man portablen Code und damit für mehrere Prozessortypen schreibt muß man solche Probleme einfach im Hinterkopf behalten.
Ein einheitlicher Standard a la Java ist auch keine Lösung. Wie Tron schon mehrmals gesagt hat hat jeder Prozessor einen nativen Datentypen, also quasi einen Datentypen, mit dem er am besten rechnen kann. Also sollten sich auch die Programme in einem gewissen Rahmen an den optimalen Datentypen anpassen.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.