Athlon 64 16bit Codeunterstützung?

S

SuperCow

Admiral Special
Mitglied seit
11.11.2001
Beiträge
1.318
Renomée
1
Ich hoffe die Frage ist nicht zu blöd oder wurde schon mal gestellt ...

Unterstützt der A64 16bit-Anwendungen/Treiber? Eigentlich schon, oder? Erstens baut er auf dem Athlon Xp Core auf und zweitens ist er x86 kompatibel???
Wenmn ich totalen Mist laber, verbessert mich bitte.

Ich weiß nur, dass der A64 unter Windows XP64 (WXP64 - Ich liebe Abkürzungen) mit dem WOW64 Treibern nur 32bit unterstützt.
 
Jo, auch auf dem Athlon64 wirst du deine 16-Bit-Uralt-Spiele daddeln können. Der A64 ist AFAIK vollständig abwärtskompatibel.
 
Beherrscht doch laut Andreas Stiller auch immernoch das allseits geliebte A20Gate. Das Teil hat ja mal wieder in der 20-jährigen Jubiläumsausgabe ne ganze Doppelseite spendiert bekommen......8)
Ich denke allerdings, dass sich in Win95 und co noch irgendwo zeitkritische Schleifen tummeln, die bei zu schneller Abarbeitung dann fleißig versuchen, durch Null zu teilen.........
 
Aber klar "unterstützt" der Athlon64 noch das A20-Gate... was dachtest du denn?!
OK, aber du sprichst natürlich einen ganz wichtigen Punkt an: Der A64 ist prinzipiell kompatibel, wenn die Software aber schlecht programmiert wurde (mit zeitkritischen Schleifen und ähnlichem), dann kann es u.U. schon sein, dass die 16-Bit-SW nicht auf dem A64 läuft.
 
Ich erwähne hier der Vollständigkeit halber, daß die 16bit-Kompatibilität nicht im 64bit-Modus gegeben ist. Also müssten Besitzer von 64bit-Windows (was ja eh noch Beta ist) dann mal ein anderes OS booten (von Disk oder anderer Partition).

Oder man nimmt einen PC-Emulator für den PC ;). Bochs oder Dosbox (zu finden auf http://bochs.sourceforge.net/ und http://dosbox.sourceforge.net/) helfen dabei auch, Geschwindigkeitsprobleme (von anderer Art.. *g*) in den Griff zu bekommen.
 
Original geschrieben von Seemann
Aber klar "unterstützt" der Athlon64 noch das A20-Gate... was dachtest du denn?!
Zum Vergrößern anklicken....

Na ja, ein Prozessor, der auf die 16Bit Hinterlassenschaft verzichten würde, könnte natürlich auch aufs A20-Gate verzichten. Soll ja schon angedacht worden sein von Intel und co.....;)
 
Wie oben erwähnt, unterstützt der Hammer natürlich 16 BIT da er zu 100% x86 Abwärtskompatibel ist, nur seitens des OS kann es Probleme geben.

Bleibt nur zu hoffen dass das 16BIT OS / Programm auch mit heutigen vergleichsweise astronomischen RAM und HDD größen zurecht kommt. ;D
 
Kurz
Knapp
Informativ
Spamfrei
Humor
Hammerhaltig
Nachhaltig

Der Thread schreit danach in die Hammersammlung Spezielle P3D Opteronlinksammlung aufgenommen zu werden.

Auch wenn die Frage bestimmt irgendwo, irgendwann bestimmt mal gestellt wurde... doof war die bestimmt nicht SuperCow

Danke!
 
Es ist nicht korrekt, dass der Prozessor im 64-bit keinen 16-bit Code unterstützt. Laut AMD sieht die Situation folgendermaßen aus:

Im 32-bit Modus unterstützt ein x86-64 Prozessor sowohl den Real-Mode als auch den Protected und Virtual Mode.
Im 64-bit Mode wird jedoch der Real- und Virtual Mode nicht unterstützt - nur Protected Mode. Desweiteren wird auch kein task_switching unterstützt. Das ganze sieht grafisch aufbereitet dann folgendermaßen aus:

hammer_modi.png
 
Original geschrieben von D'Espice
Es ist nicht korrekt, dass der Prozessor im 64-bit keinen 16-bit Code unterstützt.
Zum Vergrößern anklicken....
Mit 16-bit-Kompatibilität ist ja nicht gemeint, ob man 16-(oder :cool:Bit-Befehle verarbeiten kann (was weiterhin funktioniert), sondern ob Anwendungen für den 16-Bit-Modus (eigentlich Real Mode) funktionieren. Das hast du ja schon mit Hilfe der Tabelle beantwortet. Der Protected Mode ist ja auch kein 16-bit-Modus, wie ihn der 8086 kannte. Und der Protected Mode des 286 fand kaum Anwendung bzw. Akzeptanz. Inwieweit der Compatibility-Mode da hilft, müsste ich erst untersuchen.

Ein 386 konnte im 16-bit-Modus (also z.B. nur himem.sys geladen, aber kein emm386) trotzdem 32bit-Register ansprechen oder mit Tricks die ganzen 4GB Adressraum ohne Segmentierung nutzen (meist waren dann nur 4 oder 8 MB vorhanden). Das sollten aber dann nicht noch irgendwelche Treiber versuchen, da das DOS (evtl. sogar bis Version 7, da schaue ich jetzt nicht nach) bei Interrupts nur die 16-Bit-Register (also nur die halben Register) gesichert hat.
 
Zuletzt bearbeitet:
@SuperCow

Hi bin zwar kein Fachmann wie alle vorhergehenden...
aber nur MS weiss, weswegen sie eine recht unvollkommende Umsetzung dem TOLLEN NÄCHSTEM WINXP64 gönnt...

MS verspricht viel

Linux verspricht da mehr...
und hält bislang mehr...

Möglicherweise wird 3DNow! nicht mehr anständig mit WOW64 (HÄ?-64) anständig umgesetzt, bei linux ist dies sehr wohl möglich.

Solange dies aber noch nicht geklärt ist, wäre dieses WOW64 eher mit HÄ?64- Treibern zu übersetzen...macht sich aber nicht so gut.

Der Opteron ist aber so konservativ gehalten worden, dass sogar das von dem Heise Schreiber und CPU- Papst Andreas Stiller geliebte A20 Gate noch übernommen wurde.
 
Original geschrieben von Bokill
Der Opteron ist aber so konservativ gehalten worden, dass sogar das von dem Heise Schreiber und CPU- Papst Andreas Stiller geliebte A20 Gate noch übernommen wurde.
Zum Vergrößern anklicken....
Du kannst dir auch sicher sein, dass ohne dieses Gate die CPU niemals Fuß fassen könnte im komplexen x86 Markt *chatt*
 
Original geschrieben von D'Espice
Du kannst dir auch sicher sein, dass ohne dieses Gate die CPU niemals Fuß fassen könnte im komplexen x86 Markt *chatt*
Zum Vergrößern anklicken....
Obwohl in der neuesten c't (im 20-Jahre-c't-Gedächtnis-Artikel) steht, dass Intel und Kleinweich 2001 beschlossen haben das A20-gate abzuschaffen. Es wird auch die Mutmaßung angestellt, dass es schon im Prescott fehlen könnte (was meiner Meinung nach aber höchstens ein Wunschtraum ist). Andereseits: Ist das der Grund für die Presoott-Verzögerung *noahnung* *lol* Naja, kleiner Scherz meinerseits.
 
Original geschrieben von Bokill
Möglicherweise wird 3DNow! nicht mehr anständig mit WOW64 (HÄ?-64) anständig umgesetzt, bei linux ist dies sehr wohl möglich.

Solange dies aber noch nicht geklärt ist, wäre dieses WOW64 eher mit HÄ?64- Treibern zu übersetzen...macht sich aber nicht so gut.

Der Opteron ist aber so konservativ gehalten worden, dass sogar das von dem Heise Schreiber und CPU- Papst Andreas Stiller geliebte A20 Gate noch übernommen wurde.
Zum Vergrößern anklicken....

Alles, was mit den alten FPU-Registern zu tun hat, wird bei 64-bit-Windows-Anwendungen nicht unterstützt. Bei Linux ist das z.Z. nicht so - zumindest unter SuSE fand ich immer noch viel x87-Code in meinen Kompilaten. Das hat aber auch Performance-Gründe:
  • es müssen weniger Register gerettet/restauriert werden
  • das x86-64 Application Programming Interface sieht für Funktionen die Übergabe von Parametern in Registern vor - da ist es günstiger, nur eins der FPU-Registersets (und vorzugsweise das größere und komfortablere ;)) zu verwenden - insgesamt ist das gegenüber der ständigen Stack-Benutzung für Funktionsaufrufe ein großer Vorteil.

WOW64 muß zwar noch die x87-Register beachten, aber da es sich nur um 32-bit Apps handelt, sind auch nur 8 SSE-Register (und nur 8 - und halb so breite - Integer-Register) da. Somit ist der beanspruchte Platz auf dem Stack zum Retten von Registern sogar kleiner.

Das A20-Gate wirkt sich wahrscheinlich im 64-bit-Modus nicht mehr aus (durch das Fehlen des Real Modes).
 
@Dresdenboy

> Alles, was mit den alten FPU-Registern zu tun hat, wird bei 64-bit-Windows-Anwendungen nicht unterstützt.

Bist du dir da sicher? Ich weis das dies für Treiber der Fall ist, aber für Anwendungen kann ich mir das nicht vorstellen?!
 
@HenryWince
Hatte mal eine ausführliche PM mit Dredenboy auf Athlon.de...

Solange MS sich da recht bedeckt hält und noch kein reales MS OS mit AMD64- Unterstützung auf dem Markt hat...
benenne ich deren WOW64 in HÄ?64 um...

könnte ja doch möglich sein, dass doch alles auf dem Athlon 64 ausgenutzt wird... aber bis dahin...
 
Ich habe eine Bestätigung für oben stehendes gefunden:

Can x87 instructions still be used by 64-bit applications?

64-bit applications cannot use x87 instructions because 64-bit operating systems are
not required to preserve the x87 stack across interrupts and context switches. AMD
has gone to great lengths to ensure that SSE/SSE2 math library performance and
accuracy exceeds that of the x87 instruction set. We anticipate no need to use x87
instructions in 64-bit applications.

(http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD64_Porting_FAQ.pdf, Seite 11)

Bei der Frage "Which compilers generate SSE/SSE2 code?" wird das noch einmal bestätigt.

Für 32bit-Code ist das kein Problem, da solche Prozesse vom OS anders als 64bit-Prozesse behandelt werden.

Wir schweifen schon ganz schön ab.. ;)

Nochmal Kurzfassung der Antwort zu SuperCows Frage:
Die 64bit-Chips von AMD sind zu 16-Bit-Anwendungen (DOS, Win 3.1 usw.) kompatibel, allerdings nicht innerhalb eines 64bit-Betriebssystems.
 
Heißt das, dass man ab einem 64bit Windows keine 16-bit Programme mehr ausführen kann? Das wäre ja ein deutlicher Nachteil, denn du würdest dich wundern, was da alles nicht gehen würde. Für micht würde das bedeuten, dass ich mir einen zweiten PC zum Programmieren suchen muss, da wir in der Schule noch mit DOS-Entwicklungsumgebungen arbeiten, die eben nur 16 bit haben. Das ist es mir echt nicht wert. Da verzichte ich gern auf ein paar Prozent mehr Leistung, als dass ich dann immer zwischen zwei PCs hin und her wechseln muss.
 
@Dresdenboy

Thx.

> [SSE/SSE2 math library] accuracy exceeds that of the x87 instruction set...

Aha. Wie soll das gehen? Kennen die dort was exakteres als IEEE Double?

> Wir schweifen schon ganz schön ab.

Macht nix :-)

P.S. Wer kennt denn noch die KeSaveFloatingPointState() Krücke aus der MMX Zeit?
 
@andr_gin
Du kannst mit einem 32Bit OS ja auch schnell mit dem Hammer arbeiten, daaa sind dann keine Begrenzungen!

Der Name "WOW64" erschliesst sich mir nun aber wirklich nicht.

HÄ?64 erscheint mir vorläufig doch noch passender.

Für noch schwerwiegender halte ich die mögliche Entwicklung von besseren Hämmern bzw. dem K9, eine mögliche stark verbesserte FPU- Einheit halte ich so für unmöglich, (Klassische 80Bit FPU) nur noch eine verbesserte SSEx- Einheit, die auf den vergifteten Schleimspurpfaden von Intel wandelt, ist so gesehen möglich-
(Geht immer um das Marketing, technisch möglich ist dies sehr wohl)

Die Entscheidungen von Heute, werden die Entwicklungen von Morgen und die Produkte von Übermorgen sein.
 
Zuletzt bearbeitet:
Original geschrieben von andr_gin
Da verzichte ich gern auf ein paar Prozent mehr Leistung, als dass ich dann immer zwischen zwei PCs hin und her wechseln muss.
Zum Vergrößern anklicken....
Hast du schon von Boot-Menüs und dergleichen gehört? Ich wähle beim Booten zw. Linux und Windows, und letzteres fragt mich nochmal nach Win2k oder Win98 :)

Dann bräuchte man nur Win64, wenn notwendig (man wird ja nicht dazu gezwungen) und ein Win32 für die Entwicklung mit DOS-IDEs.

Ich glaube, auf einem Hammer wäre ein PC-Emulator (wie oben erwähnt) schon auf 386er Niveau oder besser. Beim Amiga-Emulator hat man ja dank JIT soviel erreicht, daß man locker mit den ganzen Apps arbeiten kann. Sogar Demos für 68040 oder '060 laufen prima (selbst auf 600MHz-Rechnern recht gut).
 
Trotzdem muss ich immer den Computer neu booten und es kann ja nicht der Sinn der Sache sein, dass man dann wegen jedem kleinen Dosprogramm gleich Win 98 oder XP braucht. Wieso kann 16 bit nicht gleich mitunterstützt werden.
 
Wofür brauchst du noch DOS ? Irgendwann muss auch einmal Schluss sein mit Abwärtskompatiblität, da es nur noch unnötiger Ballast ist !

MfG
 
Original geschrieben von andr_gin
Trotzdem muss ich immer den Computer neu booten und es kann ja nicht der Sinn der Sache sein, dass man dann wegen jedem kleinen Dosprogramm gleich Win 98 oder XP braucht. Wieso kann 16 bit nicht gleich mitunterstützt werden.
Zum Vergrößern anklicken....

Weil das vielleicht auch die Performance einschränkt oder den Entwicklungsaufwand unnötig erhöht. Was soll das Diskutieren jetzt eigentlich? Warum wechselt man so oft in die IDE und geht wieder heraus? Warum entwickelt man in 16bit? Embedded Systems Softwareentwicklung?

Wozu braucht man dann ein 64bit-Windows? Installiere einfach ein OS, wo auch deine 16bit-Anwendungen laufen. Windows XP kennt doch auch nur den Virtual Mode. Da habe ich noch einige alte Software, die sich daran stört und nach Real Mode bettelt. Was für eine IDE ist das bei dir und was wird darauf entwickelt? Ich habe hier auch noch einige DOS-IDEs, kam in letzter Zeit aber erstmal ohne aus.

Wie gesagt, es gibt Emulatoren. Bochs und Dosbox (letzterer kann noch nicht soviel wie Bochs, welcher sogar schon SSE2 und x86-64 kennt). Die sollten doch wohl für 16bit-Anwendungsentwicklung ausreichen. Ich werde auch bald selbst darauf zurückgreifen, da ein paar Kollegen paar alte Demos von mir sehen wollen und die selbst auf einem PIII zu schnell für die Wahrnehmungsgabe oder einfach durch Windows gestört laufen.

Selbst auf A1200 mit 68040/40 habe ich mit einem PC-Emulator (mit JIT) etwa einen 386SX-16 erreicht. Dann sollte ein im Durchschnitt ca. 200-300mal schnellerer Rechner mit ähnlich guter Emulation doch auch mehr schaffen. Das ist nur noch eine Frage der Software.
 

Ähnliche Themen

EselTreiber
AMD-Grafikkarten unter Linux: Treiber, OpenCL, BOINC, amdconfig und headless per ssh
17 18 19
Antworten
469
Aufrufe
77K
Mike
Mike
Nero24
News "Bulldozer war ein totaler Fehlschlag - und wir wissen das"
2 3 4
Antworten
88
Aufrufe
18K
Markus Everson
Markus Everson
heikosch
Die neue Basis für unsere mITX-Gehäusetests: MSIs FM2-A75IA-E53
Antworten
0
Aufrufe
36K
heikosch
heikosch
Onkel_Dithmeyer
AMD A10 6800K und A10 6700 im Test - neue APUs, alter Kern
Antworten
0
Aufrufe
62K
Onkel_Dithmeyer
Onkel_Dithmeyer
Nero24
E-Mail an einen verunsicherten Bulldozer-Kunden
Antworten
14
Aufrufe
18K
OBrian
OBrian
Zurück
Oben Unten