Streitgespräch: Ab wann darf eine CPU 8,16,32, oder 64 Bit breit genannt werden [Archiv]

Avalox

2009-08-02, 12:48:12

Ja sorry falsch ausgedrückt, meinte mit 24 Bit den linearen verfügbaren Adressbereich.

Ja. Aber dieser war immer breiter gewesen, als der Datenbus. Sonst hätte ja der C64(u.ä.) nur 256 Byte adressieren können. Diese 6502, Z80, u.w. 8Bit CPUs hatten ja auch alle einen 16Bit Adressbus. So hatte der 68k eben als 16Bit CPU einen 24Bit Adressbus.
Erst später wurde mit 32Bit CPUs ein 32Bit Adressraum eingeführt. Konnte sich bestimmt auch niemand vorstellen, dass man 2009 auch noch mit 32Bit CPUs rumgurkt. (Ab Pentium Pro ist ja wieder ein breiterer Adressraum genutzt worden)

Wishnu

2009-08-02, 13:16:58

Da niemand Bezug dazu genommen hat: Wo im Blogeintrag wird Bezug auf die Umstellung 16bit auf 32bit genommen?

Keine Ahnung - ich seh' da nix. ;)

Gast

2009-08-02, 13:42:47

Erst später wurde mit 32Bit CPUs ein 32Bit Adressraum eingeführt. Konnte sich bestimmt auch niemand vorstellen, dass man 2009 auch noch mit 32Bit CPUs rumgurkt.

Naja, CPUs eigentlich nicht wirklich, da sind wohl fast alle schon 64bit. Es gibt nur immer noch ein paar notorische 64bit-OS-verweigerer.

Avalox

2009-08-02, 13:55:25

Es gibt nur immer noch ein paar notorische 64bit-OS-verweigerer.

Bin mir absolut sicher, dass der allergrößte Teil aller Office und Heim x86 noch heute mit einem 32Bit OS betrieben wird. 64Bit x86 (also CPU im 64Bit Modus) sind nur in der Serverwelt etwas verbreiteter. Obwohl ich auch dort annehme, dass der überwiegende Teil mit einem 32Bit OS läuft.

Exxtreme

2009-08-02, 14:04:32

Einen Stichtag gibt es in der PC-Welt sowieso nicht. Das Ganze ist eh jedes Mal ein sanfter Übergang dank permanenter Abwärtskompatibilität.

sloth9

2009-08-02, 14:24:39

...

Thanatos

2009-08-02, 14:40:52

Naja, CPUs eigentlich nicht wirklich, da sind wohl fast alle schon 64bit. Es gibt nur immer noch ein paar notorische 64bit-OS-verweigerer.

Ein paar? X-D

Die meisten die ich kenne, mich eingeschlossen, nutzen noch ein 32bit System, insbesondere bei Laptops. Auf meinem x61t mit 4GiB Ram benutze ich auch Windows XP, da ich die Menge an verfügbarem Ram absolut nicht brauche und darauf verzichten kann, genau wie ich auf Vista verzichte.

Auf 64bit sind momentan nur die Personen angewiesen, welche mehr als 4GiB Ram benötigen, also entweder professionelle Nutzer oder Spieler, welche aber sicherlich nicht die Mehrheit der verkauften PCs ausmachen.

Gast

2009-08-02, 18:55:07

Auf 64bit sind momentan nur die Personen angewiesen, welche mehr als 4GiB Ram benötigen, also entweder professionelle Nutzer oder Spieler, welche aber sicherlich nicht die Mehrheit der verkauften PCs ausmachen.

Das ist absolut falsch. Wie oft wollen wir hier noch diskutieren, dass 64Bit weniger mit der Menge an verfügbaren RAM zu tun hat, sondern mit dem größeren Adressraum und der daraus erheblich einfacheren Softwareentwicklung, wenn es um die Verwaltung großer Objekte ab ca. 256MB geht.

Du wirst es nie kapieren.

Gast

2009-08-02, 18:58:46

Bin mir absolut sicher, dass der allergrößte Teil aller Office und Heim x86 noch heute mit einem 32Bit OS betrieben wird.

Trotzdem sind fast alle heute eingesetzten CPUs 64bit fähig.

Dass der kunde das nicht benutzt ist ja sein fehler.

Avalox

2009-08-02, 19:02:49

Trotzdem sind fast alle heute eingesetzten CPUs 64bit fähig.

Dass der kunde das nicht benutzt ist ja sein fehler.

Dieses nicht benutzen ist ja doch massiv forciert worden.
Ein Intel mit aller Macht Einfluss auf Microsoft genommen und ist ja für diese desolate Lage mit verantwortlich.
Es ist ja nicht mal so, dass sich der Kunde dieses überhaupt aussuchen kann. Oftmals gibt es auch keine Treiber für ein 64Bit System.

sputnik1969

2009-08-02, 20:09:35

16Bit. Der 68k war ein 16Bit Prozessor, welcher sich intern wie ein 32Bit Prozessor verhalten hat. Die CPU stammt ja schliesslich auch aus dem Jahr 1979, das sei ihr vergönnt.
Nein, das ist auch falsch.
Der 68000 war ein 32-Bitter (Registerbreite) dessen I/O-Infrastruktur für 16-Bit (68000/68010) oder 8-Bit (68008) Umgebungen optimiert war.
War halt eine Preisfrage, ob man alte 8-Bit I/O genutzt hat, modernere 16-Bit oder später ab dem 68020 mit 32-Bit.
Nichtsdestotrotz ist der 68000er ein 32-Bitter und kein 16-Bitter! Wenn auch ein "abgespeckter".

Das sieht man schon daran, das es beim 80x86 unterschiedliche Modi gibt (16-Bit,32-Bit und "neuerdings" 64-Bit), die es beim 680x0 nicht gibt (ein Modus: 32-Bit).
Machen wir uns nichts vor, der 8086 war ein für Programmier miserabel designter 16-Bitter mit gerade mal 16-Bit linearem Adressraum (Register/Offset-Programmierung) und die 68000er Reiher war um Längen moderner und durchdachter. Ich trauere ein wenig um die Linie...

Thanatos

2009-08-02, 20:17:50

Das ist absolut falsch. Wie oft wollen wir hier noch diskutieren, dass 64Bit weniger mit der Menge an verfügbaren RAM zu tun hat, sondern mit dem größeren Adressraum und der daraus erheblich einfacheren Softwareentwicklung, wenn es um die Verwaltung großer Objekte ab ca. 256MB geht.

Du wirst es nie kapieren.

Und der absolut unbedarfte Benutzer — der wohl aber einen Großteil der abgesetzten PCs ausmacht — merkt nun einen Vorteil, wenn es dem Ersteller der Software leichter von der Hand geht Objekte zu verwalten?

Dem normalen Benutzer, mit rudimentären PC Kenntnissen, wird die Notwendigkeit — für ihn selbst! — erst durch das Arbeitsspeicherproblem ersichtlich, ob es da noch andere Probleme gibt oder Bedingungen, interessiert ihn nicht. Für ihn zählt, die bare und für ihn ersichtliche Faktenlage: >4GB->Nicht der gesamte Speicher wird erkannt->Problemlösung:64bit Betriebssystem->Umstieg.

Und falls Du es, insbesondere im Hinblick auf deine abschließende Freundlichkeit, nicht bemerkt hast, war der Zweck meines Beitrages nicht, dass ich die Notwendigkeit von 64bit in Abrede stellen wollte, sondern nur die schiefe Wahrnehmung korrigieren wollte, nach der die erdrückende Mehrheit der installierten Betriebssysteme 64bit ist, und nur noch eine kleine Randgruppe ein 32bit System benutzt, was aber einfach so nicht stimmt.

Gast

2009-08-02, 20:18:00

So hatte der 68k eben als 16Bit CPU einen 24Bit Adressbus.

Der 68k ist aber ein 32Bit Prozessor.

Coda

2009-08-02, 20:47:59

Würde ich auch sagen. Die "Bittigkeit" definiert sich normalerweise durch die Größe der Adressregister.

Avalox

2009-08-02, 21:09:56

Würde ich auch sagen. Die "Bittigkeit" definiert sich normalerweise durch die Größe der Adressregister.

Nein aus der Breite des Datenbusses.

Ansonsten wäre der 6800 ja schon eine 16 Bit CPU.
Auch der 6809 konnte seine zwei 8Bit Register zu einem 16Bit Register umfunktionieren. Beides reine 8Bit CPUs.

Der 68k war die logische Weiterentwicklung dieser 8Bit CPUs. Das sieht man ja schon daran, dass das Statusregister des 68k auch nur 16Bit breit war und dieser auch eine reine 16Bit ALU hatte und 16Bit Opcodes verwendete. Der 68020 war die erste richtige 32Bit CPU aus der 68k Familie.

Eine 16Bit CPU, mit der Option unter eines Performance Verlustes die CPU wie eine 32Bit CPU zu betreiben. Das ist natürlich ein gutes Feature, macht aber noch lange keine 32Bit CPU aus dem 68k.
Maßgeblich war immer die Breite des Datenbusses. Damit wurden die CPUs damals verglichen und es ist ja auch der Performance entscheidende Punkt.

Gast

2009-08-02, 21:31:12

Nein aus der Breite des Datenbusses.

Ganz sicher nicht, sonst wäre der erste PC nur ein 8Bit Rechner, weil da ein Intel 8088 drin saß.
Übrigens hat alles seit dem ersten Pentium einen 64Bit Datenbus und trotzdem ist der Pentium kein 64Bit Prozessor.

Der 68k hat 32Bit Adress- und Datenregister, er ist ein 32Bit Prozessor.

Avalox

2009-08-02, 21:44:33

Ganz sicher nicht, sonst wäre der erste PC nur ein 8Bit Rechner, weil da ein Intel 8088 drin saß.

Der 8088 ist damals tatsächlich oftmals als 8Bit CPU bezeichnet worden.
Er war ja auch gezielt geschaffen worden um in 8Bit Systemen Verwendung zu finden. Der Fall liegt aber etwas anders, da der 8088 tatsächlich eine 16Bit ALU hatte und dort der Datenbus tatsächlich reduziert wurde.

Übrigens hat alles seit dem ersten Pentium einen 64Bit Datenbus und trotzdem ist der Pentium kein 64Bit Prozessor.

Auch diese Diskussion gab es als der Pentium eingeführt wurde. Man hat dann die alte Betrachtung verworfen.

er ist ein 32Bit Prozessor.

Ganz sicher nicht. Der Atari ST hat seinen Namen z.B. daher. Das S beim ST steht für Sixteen/Thirtytwo Bits. Eben einer 16Bit CPU, welche 32Bit Software nutzen kann.

Das hat auch damals jeder gesehen. Dieses resultierte dann in Musik Bands, welche vom Amiga inspiriert sich dann "16Bit" nannten, oder Übersichten von damaligen 16Bit Heimcomputern (http://en.wikipedia.org/wiki/List_of_16-bit_computer_hardware_palettes).

Gast

2009-08-02, 21:59:36

Ich bin der Gast, das das 68k Thema aufgebracht hat.

Was redet ihr eigentlich alle? Wichtig ist einzig das Programmiermodell. Sprich der Assembler-Coder war 32 Bittig und nur darauf kommt es an. Es ist (fast) vollkommen egal, wie die darunter liegende Hardware implementiert war.
Immer diese Diskussionen, wer welchen Lötkolben benutzt hat, die sind doch sinnlos.

Avalox

2009-08-02, 22:05:20

Ich bin der Gast, das das 68k Thema aufgebracht hat.

Was redet ihr eigentlich alle? Wichtig ist einzig das Programmiermodell. Sprich der Assembler-Coder war 32 Bittig und nur darauf kommt es an.

Der vom Assembler übersetzte Opcode war aber in 16Bit. Ich denke eher darauf kommt es an.
Ausserdem war der 68k als mit einer 16Bit ALU gesegneter Prozessor gar nicht in der Lage durchgängig eine 32Bit Arithmetik durchzuführen.
Er konnte zwar damit 32Bit Adressen und Daten laden, aber nicht beliebig damit rechnen.
Auch das Statusregister war ein 16Bit Register, damit es schnell bearbeitet werden konnte.

Er konnte zwar mit 32Bit Software umgehen. Dieses aber nicht beliebig und nur unter enormen Performance Einschränkungen.

Selbst Motorola war nicht so vermessen den 68k als 32Bit CPU zu bezeichnen. Gängig war die Bezeichnung 16Bit/32Bit also eine 16Bit CPU, welche 32Bit Software nutzen kann. So wie einer 6809 vorher schon als 8Bit/16Bit CPU bezeichnet wurde.

Coda

2009-08-02, 22:37:50

Nein aus der Breite des Datenbusses.
Blödsinn. Schlicht und einfach.

Ich hab mal wieder ein Wörtchen gespart. Meistens sind natürlich Adressregister und Datenregister gleich breit und das ist die "Bittigkeit". Irgendwelche Obskuritäten mögen davon abweichen. Wenn man mit zwei 8-Bit-Registern 16-Bit adressieren kann ist es natürlich immer noch ein 8-Bit-Prozessor.

Das gleiche meint auch die Wikipedia
Vereinfacht dargestellt bedeutet 8 Bit, dass die Prozessoren durch ihr Design so ausgelegt sind, dass 8 Bit (also 1 Byte) gleichzeitig bzw. während eines Taktes verarbeitet werden können. Register und Adressbus sind dabei oft 16 Bit breit, der Speicherbereich wird teilweise durch Memory-Mapping noch erweitert.

Avalox

2009-08-02, 22:46:09

Das gleiche meint auch die Wikipedia
Vereinfacht dargestellt bedeutet 8 Bit, dass die Prozessoren durch ihr Design so ausgelegt sind, dass 8 Bit (also 1 Byte) gleichzeitig bzw. während eines Taktes verarbeitet werden können.

Der 68k kann aber nicht 32Bit gleichzeitig verarbeiten.

Coda

2009-08-02, 22:54:07

Aber sicher, der hat 32-Bit-Daten- und Adressregister.

Oder sind die Instructions irgendwie eingeschränkt auf 16-Bit?

Controller Khan

2009-08-02, 23:00:20

Der 68k kann aber nicht 32Bit gleichzeitig verarbeiten.
seit 68020 ist auch die ALU 32Bit.
Der Rest war ja schon 32Bit.

Avalox

2009-08-02, 23:02:43

Aber sicher, der hat 32-Bit-Daten- und Adressregister.

Ja, aber er benötigt aber zur Verarbeitung mehrere 16Bit Durchläufe.

Multiplikation und Division sind zudem eingeschränkt, bzw. mit 32Bit Werten nicht möglich.

seit 68020 ist auch die ALU 32Bit.

ja der 68020 wurde ja auch immer als erster echter 32Bit Prozessor der 68k Familie betitelt.

Der Rest war ja schon 32Bit.

Was heißt der Rest? Am 68k war ausser den Daten- und Adressregistern überhaupt nichts 32Bit.

Coda

2009-08-02, 23:05:27

Dann ist es halt irgend was dazwischen. Ein reines 16-Bit-Design ist es jedenfalls nicht. Ich würde eher 32-Bit sagen, da das wesentliche dafür vorhanden ist.

Gast

2009-08-02, 23:22:11

Ich finde es ganz interessant, wie lange man bestimmte CPUs früher genutzt hat, im Vergleich zu heute. Jahrelang die gleiche CPU.

Gast

2009-08-02, 23:56:03

Würde ich auch sagen. Die "Bittigkeit" definiert sich normalerweise durch die Größe der Adressregister.
Blödsinn. Dann hätte man ja 16bit übersprungen

Coda

2009-08-03, 01:13:06

Nein?

Gast

2009-08-03, 03:03:16

16Bit. Der 68k war ein 16Bit Prozessor, welcher sich intern wie ein 32Bit Prozessor verhalten hat. Die CPU stammt ja schliesslich auch aus dem Jahr 1979, das sei ihr vergönnt.Esoterisch. Der Umstieg hat wohl weniger mit irgendwelchen 16/32Bit Hymeren zu tun, sondern mit der Soft. 68k Software auf dem Amiga war vom Anfang an 32bit und ist auch 32bit immer geblieben. 24bit Adressraum war damals sowieso nur ein Traum =)

Avalox

2009-08-03, 09:38:12

68k Software auf dem Amiga war vom Anfang an 32bit und ist auch 32bit immer geblieben.

Nein, der überwiegende Teil war 16Bit Software. 32Bit Software ist enorm langsam und vor allen nicht notwendig gewesen. Das System war 32Bit tauglich in einer 32Bit Architektur.
Das ist schon ein Unterschied.

Gast

2009-08-03, 10:49:20

Nein, der überwiegende Teil war 16Bit Software. 32Bit Software ist enorm langsam und vor allen nicht notwendig gewesen. Das System war 32Bit tauglich in einer 32Bit Architektur.
Das ist schon ein Unterschied.

Langsam frage ich mich, ob du jemals etwas für den 68K, geschweige denn für den Amiga entwickelt hast. Wenn der Assembler 32-Bit kann, dann zeig mir mal ein Stück Software, welches auf Krampf, auf 16-Bit macht. Das ist auf dem 68K gar nicht mal so einfach. Auf einer Intel CPU hingegen, ist das sogar sehr viel einfacher.

Auch die C-Compiler haben 32-Bit Code produziert. Klar konnte man zu den Adressregistern relative 16-Bit Offsets addieren und diese waren auch schnell. Das war aber auch schon eine der wenigen Ausnahmen, bei denen man effektiv mit 16-Bit arbeiten konnte.

Wie immer echt geiler Diskussionsverlauf hier. Der arme Threadstarter.
Bitte den Thread an entsprechender Stelle aufsplitten und das Thema: "War der 68K eine 32- oder nur 16-Bit CPU?", wählen.

Danke.

Avalox

2009-08-03, 11:40:52

Auch die C-Compiler haben 32-Bit Code produziert. Klar konnte man zu den Adressregistern relative 16-Bit Offsets addieren und diese waren auch schnell. Das war aber auch schon eine der wenigen Ausnahmen, bei denen man effektiv mit 16-Bit arbeiten konnte.

Du hast doch kein DoubleWord verwendet, wo du ein Word verwenden konntest.

Controller Khan

2009-08-03, 12:36:34

Du hast doch kein DoubleWord verwendet, wo du ein Word verwenden konntest.
Offtopic.

Wie immer echt geiler Diskussionsverlauf hier. Der arme Threadstarter.
Bitte den Thread an entsprechender Stelle aufsplitten und das Thema: "War der 68K eine 32- oder nur 16-Bit CPU?", wählen.

Second that.

Nein, der überwiegende Teil war 16Bit Software. 32Bit Software ist enorm langsam und vor allen nicht notwendig gewesen. Das System war 32Bit tauglich in einer 32Bit Architektur.
Das ist schon ein Unterschied.
hast Du einen Amiga benutzt ?
Nach deiner Logik kann man den 386SX als 16 Bit CPU bezeichnen.
Windows 3.0 und dessen Erblasten in Win9x ist schoenes Beispiel fuer Software, die 16-Bit entwickelt worden war.
Amiga Software mit solchen Problemen ist mir nie untergekommen. Es gibt andere Probleme.

Avalox

2009-08-03, 13:28:04

Offtopic.

Überhaupt nicht, ist entscheidend.
Warum hat der 68000er ein 16Bit Word? Aus Kompatibilität? Zu was?
Ganz einfach, weil es eine 16Bit CPU war, eine 16Bit CPU mit 32Bit Registern. Sehr schickt, aber immer noch eine 16Bit CPU.
Sicherlich eine 16Bit CPU, welche man unter Performance Einschränkungen ähnlich einer 32Bit CPU programmieren konnte.
Aber eben war das 16Bit Word der Standard und wurde auch tunlichst genutzt.

Windows 3.0 und dessen Erblasten in Win9x ist schoenes Beispiel fuer Software, die 16-Bit entwickelt worden war.

Dagegen sage ich gar nichts.

Amiga Software mit solchen Problemen ist mir nie untergekommen.

Na auf dem 68k war es schlicht ein Performance Frage.

Es ist hier im Kontext überhaupt interessant, da es schon schwer fällt überhaupt CPUs und Betriebssystem überhaupt strickt zuzuordnen.

sputnik1969

2009-08-03, 17:55:19

Du hast doch kein DoubleWord verwendet, wo du ein Word verwenden konntest.
Wenn Du das heute anders machst, bist du kein guter Programmierer!
Das hat man schon IMMER so gemacht, dass man nur die Datenbreite benutzt hat, die man auch wirklich brauchte....Alles andere zeugt von schlechter Programmierung oder wird aus geschwindigkeitsgründen (alignment) gemacht...

Gast

2009-08-03, 18:20:09

Du hast doch kein DoubleWord verwendet, wo du ein Word verwenden konntest.

Wenn Du das heute anders machst, bist du kein guter Programmierer!
Das hat man schon IMMER so gemacht...

Ich weiß nicht so recht, aber ich denke ihr redet beide über Dinge die jeweils völlig aus dem Kontext gerissen sind. Die Wahl des Datentypen ist nicht abhängig davon, welche CPU mir unter dem Hintern sitzt, sondern ganz alleine abhängig von der fachlichen Problemstellung. Es sei denn, Teile des Codes müssen sehr schnell laufen. Im Übrigen wurde gerade das Design der 68K Linie von etlichen Informatikern mitentwickelt. Gottseidank ist das so. Den Murks erkennt man an den Intel CPUs und deren Befehlssatz.

Ich werde hier Manchmal das Gefühl nicht los, dass es hier zu wenig Informatiker aber dafür überproportional zu viele Leute gibt, die nachts mit Ihrem Lötkolben ins Bett gehen.

Coda

2009-08-03, 18:25:53

Wenn Du das heute anders machst, bist du kein guter Programmierer!
Das hat man schon IMMER so gemacht, dass man nur die Datenbreite benutzt hat, die man auch wirklich brauchte....Alles andere zeugt von schlechter Programmierung oder wird aus geschwindigkeitsgründen (alignment) gemacht...
Genau aus den beiden letzteren Gründen werden heute praktisch ausschließlich 32-Bit-Werte verwendet, außer wenn man Platz sparen muss (sei es im Cache, oder im RAM).

sputnik1969

2009-08-03, 20:45:30

Ich weiß nicht so recht, aber ich denke ihr redet beide über Dinge die jeweils völlig aus dem Kontext gerissen sind. Die Wahl des Datentypen ist nicht abhängig davon, welche CPU mir unter dem Hintern sitzt, sondern ganz alleine abhängig von der fachlichen Problemstellung. Es sei denn, Teile des Codes müssen sehr schnell laufen. Im Übrigen wurde gerade das Design der 68K Linie von etlichen Informatikern mitentwickelt. Gottseidank ist das so. Den Murks erkennt man an den Intel CPUs und deren Befehlssatz.

Als jemand, der Jahrelang verschiedene CPUs (auch beruflich) in Assembler programmiert hat kann ich dazu nur eins sagen: Wie Recht Du hast!

Ich werde hier Manchmal das Gefühl nicht los, dass es hier zu wenig Informatiker aber dafür überproportional zu viele Leute gibt, die nachts mit Ihrem Lötkolben ins Bett gehen.
LOL... Da könntest Du auch Recht haben...:)

Genau aus den beiden letzteren Gründen werden heute praktisch ausschließlich 32-Bit-Werte verwendet, außer wenn man Platz sparen muss (sei es im Cache, oder im RAM).
Jein. Kommt darauf an, welches System für welchen Zweck du programmierst.
Bei ARM-Systemen stimmt die Aussage so definitiv nicht. Und x86-PCs programmiert heute (fast) kein Schwein mehr per Hand in Assembler. Und wer das da macht wird sogar heute viel öfter 64- oder 128-Bit Alignment nutzen ;) Auch ohne das wir 128-Bit CPUs nutzen.
Davon abgesehen kann man am Alignment sicher nicht festmachen, zu welcher Architektur eine CPU gehört.

Aber gehen wir doch mal andersrum vor:
Welche Kenngrößen können NICHT für die Bestimmung der Architektur (8/16/32/64-Bittig) herangezogen werden?
1. Die Adressbusbreite -> Sonst wäre der 8088 ein 8-Bitter und der 386SX ein 16-Bitter
2. Der adressierbare Adressraum -> 6502 (8-Bit) -> 16 Bit, 68008, 8086 -> 20 Bit, 68000 -> 24 Bit
3. Der linear adressierbare Speicher -> 6502, 8080/8086/8088 -> 64 kib, 68008 -> 1 MiB, 68000 -> 16 MiB
4. Der relative Offset, der von programmen über Register genutzt werden kann -> 6502 -> 8 Bit, 8086 -> 16 Bit, 6800x -> 16 Bit, 68020+ -> 32 Bit
5. Die Größe des Adressregisters -> 6502 = 0!!!! 680x0 = 32 Bit
6. Die Anzahl der Takte, die eine CPU benötigt um Daten im 16/32/64/128-Bit Formats zu verarbeiten -> 6502 = 2 x 8 Bit (1 pro Taktflanke!), 68000 = 16 Bit, 8088, 68008 -> Teilweise nur 8 Bit, teilweise 16 Bit, P4=2 x 32 Bit (Doublepumped ALU)
7. Die Vielfalt an Befehlen zur Manipulation bestimmter Datentypen -> RISC/CISC Unterschiede, SSE/SSE2/SSE3/AltiVec ?? Wieviel Bits haben die CPUs wenn man das als Definition nehmen würde...
8. Die Größe der codierten Anweisungen -> Man denke an moderne ARM-Architekturen mit ihrem Thumb-Code. Oder an diverse RISC-CPUs mit fester Befehlslänge.

Was bleibt übrig?

Die Größe der Datenregister!
6502 -> 8 Bit = 8 Bitter
8088 -> 16 Bit = 16 Bitter
68000 -> 32 Bit = 32 Bitter

Gast

2009-08-03, 21:27:48

@sputnik1969, sehe ich genauso, sehr schöne Auflistung.

Coda

2009-08-03, 21:30:31

Rein aus Interesse: Mit was hat der 6502 denn Speicher angesprochen, wenn es keine Adressregister gibt?

Avalox

2009-08-03, 21:47:41

1. Die Adressbusbreite -> Sonst wäre der 8088 ein 8-Bitter und der 386SX ein 16-Bitter

Das ist der klassische Ansatz.

6. Die Anzahl der Takte, die eine CPU benötigt um Daten im 16/32/64/128-Bit Formats zu verarbeiten -> 6502 = 2 x 8 Bit (1 pro Taktflanke!), 68000 = 16

Das ist ein neuerer Ansatz.

Was bleibt übrig?

Die Größe der Datenregister!

6502 -> 8 Bit, 8088 -> 16 Bit, 68k -> 32 Bit, Z8000 -> 64Bit, 6809 -> 16Bit

Passt nicht.

Coda

2009-08-03, 23:55:02

Ein 8088 ist auch EINDEUTIG ein 16-Bit-Prozessor, wo ist dein Problem? Genauso hat ein Z8000 16-Bit-Register.

Natürlich passt das.

Avalox

2009-08-04, 00:04:17

Genauso hat ein Z8000 16-Bit-Register.

Welche sich zu vier 64Bit Register vereinen lassen. Oder zu 8 32Bit Register. Die CPU hatte sogar eine richtige 32Bit Multiplikation und Division.

Es war aber eine 16Bit CPU, mit einem 16Bit Datenbus und einer 16Bit ALU. Wie der 68k.
Ähnliches gilt für den 6809, eine 8Bit CPU.

Der 8088 ist aus sputnik1969 Aufzählung übernommen.

Man kann die Registerbreite nicht als exklusives Merkmal der Einsortierung heranziehen.

Coda

2009-08-04, 00:12:02

Dann können wir uns diese komplette Diskussion auch einfach sparen, weil es dann genau gar kein exklusives Merkmal gibt und letztenendes eh alles nur esoterisches Gebabbel ist.

Tiamat

2009-08-04, 00:17:58

Bezeichnen wir ihn doch einfach als Pseudo 32 Bitter mit einer 32 Bit Architektur, fertig :D

Gast

2009-08-04, 00:18:06

Avalox, verrenne dich jetzt bitte nicht. Siehe es aus der Sicht des Assemblers und bleiben wir wenigstens beim 68k. Danach ist dieser eine 32-Bit CPU. Es gibt natürlich immer die hardwareseitige Sicht. Aber betrachte es doch mal von der Softwareseite her. Die Software sieht eine 32-Bit CPU und nur darauf kommt es nach meiner Meinung nach an.

Avalox

2009-08-04, 00:22:27

Dann können wir uns diese komplette Diskussion auch einfach sparen, weil es dann genau gar kein exklusives Merkmal gibt und letztenendes eh alles nur esoterisches Gebabbel ist.

Du hast doch eine interessante Definition gestern gespostet.

Vereinfacht dargestellt bedeutet 8 Bit, dass die Prozessoren durch ihr Design so ausgelegt sind, dass 8 Bit (also 1 Byte) gleichzeitig

Wenn nicht das Rechenwerk massgeblich sein soll, was dann?
Der Datenbus spielt natürlich eine Rolle, denn wenn weniger Daten in diesen Cache-losen CPUs angeliefert, bzw. geschrieben werden können, dann macht es auch wenig Sinn, ständig in den Registern zu rechnen zu können.

Die 32Bit Register der 68k waren eher so was wie ein Kompatibilitätsmodus. Eine 32Bit Emulation, auf einer 16Bit CPU.

Avalox, verrenne dich jetzt bitte nicht. Siehe es aus der Sicht des Assemblers und bleiben wir wenigstens beim 68k. Danach ist dieser eine 32-Bit CPU. Es gibt natürlich immer die hardwareseitige Sicht. Aber betrachte es doch mal von der Softwareseite her. Die Software sieht eine 32-Bit CPU und nur darauf kommt es nach meiner Meinung nach an.

Doch grade der Assembler macht es doch besonders deutlich. Beschränkung auf einen 16Bit Opcode und das Word als Standard Datentyp. Die Software sieht eine virtuelle 32Bit CPU. Das will ich keinesfalls schmälern, aber eine 32Bit CPU war der 68k nicht.

sputnik1969

2009-08-04, 00:39:58

Rein aus Interesse: Mit was hat der 6502 denn Speicher angesprochen, wenn es keine Adressregister gibt?

Direkt oder Direkt mit Register-Offset. Der 6502 hatte 3 Register: A(kku), X + Y Register, jeweils 8 Bit breit. Die CPU war vollkommen auf direkte Speicheroperationen zugeschnitten. Kleiner, fast RISC-artiger Befehlssatz, wenige Takte pro Befehl (viele Ops liefen in 2 oder 4 Zyklen ab) und war ähnlich dem Pentium 4 durchgehend "Doublepumped". Mit 1 MHz ähnlich schnell wie ein Z80 mit etwa 4 MHz. Aber der Z80 war deutlich angenehmer in Assembler zu programmieren... ;)

Doch grade der Assembler macht es doch besonders deutlich. Beschränkung auf einen 16Bit Opcode und das Word als Standard Datentyp. Die Software sieht eine virtuelle 32Bit CPU. Das will ich keinesfalls schmälern, aber eine 32Bit CPU war der 68k nicht.

Dann sind die aktuellen ARM-Architekturen alles 16-Bitter, wegen dem Thumb-Code??? Und beim 68000 wird nichts "emuliert" oder aus "kompatiblität" mitgeschleift... das war ja nicht nötig.

BlackBirdSR

2009-08-04, 00:56:00

Im Grunde ist es doch ganz simpel:

Es gibt 2 Entscheidungswege, ob eine CPU xx-Bit breit ist oder nicht.

b) Den subjektiven
a) Den der µArchitektur

a) lässt eigentlich eine eindeutige Zuordnung zu, sagt über die CPU aber wirklich nicht viel aus. Es ist und bleibt einfach die breite der primären ALU Datenregister und zwar nicht irgendeine fiktive durch spezielle Operationen kombinierte Größe, sondern die direkte Größe der physikalischen Register bzw. Einträge in der File.
Das sind dann IMO auch beim Z8000 16Bit und fertig!

b) ist sowieso völlig willkürlich. Hier entscheidet neben der nutzbaren Performance auch das Softwareangebot und die Useradaption.

Ihr könnt euch nun Jahrelang weiter streiten... wenn euch der Stoff ausgeht können wir ja darüber diskutieren, was eurer Meinung nach der K8 ist oder der Atom...(32 Bit Datentyp als Standard in der primären Softwareumgebung, 64Bit beim Atom mit miesen Latenzen und Durchsatz aber Performance nur wenig schlechter als 32Bit)

Warum hat der 68000er ein 16Bit Word? Aus Kompatibilität? Zu was?
Ganz einfach, weil es eine 16Bit CPU war, eine 16Bit CPU mit 32Bit Registern. Sehr schickt, aber immer noch eine 16Bit CPU.
Sicherlich eine 16Bit CPU, welche man unter Performance Einschränkungen ähnlich einer 32Bit CPU programmieren konnte.
Aber eben war das 16Bit Word der Standard und wurde auch tunlichst genutzt.

Also doch alle AMD64er nur 32er?

Avalox

2009-08-04, 09:10:43

Dann sind die aktuellen ARM-Architekturen alles 16-Bitter, wegen dem Thumb-Code???

Er tut zumindest so im 16Bit Betrieb, ähnlich MIPS16

Und beim 68000 wird nichts "emuliert" oder aus "kompatiblität" mitgeschleift... das war ja nicht nötig.

Der Knacktus liegt dort sicherlich in der Philosophie von Motorola damals.
Fast alle 8Bit CPUs damals nutzen 16Bit Adressregister. Motorola fügte im Vorgänger des 68000er dem 6809 eben noch ein 16Bit Datenregister dazu. Man konnte die 8Bit Datenregister zu einem 16Bit Datenregister verbinden.
Dieses hat Motorola einfach im Nachfolger übernommen und dieser 16Bit CPU ein 32Bit Adressregister und entsprechende Datenregister spendiert. Der 16Bit Befehlssatz konnte mit 32Bit Datentypen umgehen. Trotzdem ist es ein 16Bit Befehlssatz, welcher auf einer 16Bit ALU ausgeführt wird. Motorola hat sich scheinbar weil der 68000er schon über eine ordentliche Anzahl von Datenregister verfügt nur die Funktion gespart, die 32Bit Datenregister in jeweils 2 16Bit Register aufzutrennen. Ein 32Bit Register lässt sich ja auch vorzüglich für 16Bit Operationen nutzen.

Einträge in der File.
Das sind dann IMO auch beim Z8000 16Bit und fertig!

16Bit ist dort nur der kleinste Konfigurationsgröße. Ich denke schon, dass man nach der Definition nach den Datenregister den Z8000 als waschechte 64Bit CPU bezeichnen muss, zumindest als vollwertige 32Bit CPU. Der Z8000 konnte zumindest entgegen dem 68000 zwei 32Bit Werte multiplizieren, oder dividieren.

Gast

2009-08-04, 09:21:57

Ein 32Bit Register lässt sich ja auch vorzüglich für 16Bit Operationen nutzen.

Ein 32Bit Register lässt sich auch für 8-Bit Daten benutzten. Warum erzählst du etwas, was sowieso klar ist?

Wenn es aber keine zwei oder gar 4 Registerhälften wie bei Intel gibt, dann muss der geladene 16-Bit Wert auf 32-Bit erweitert werden (Vorzeichen). Also, was möchtest du uns sagen? Das der 68K doch ein 32-bitter war?

Avalox

2009-08-04, 09:38:56

Wenn es aber keine zwei oder gar 4 Registerhälften wie bei Intel gibt, dann muss der geladene 16-Bit Wert auf 32-Bit erweitert werden (Vorzeichen).

Was? Führe mal genauer aus, ich glaube ich verstehe dich jetzt nicht.
Der Standard Datentyp es 68000er war das Word und dort wurde kein Registereintrag erweitert.

BlackBirdSR

2009-08-04, 09:44:37

16Bit ist dort nur der kleinste Konfigurationsgröße. Ich denke schon, dass man nach der Definition nach den Datenregister den Z8000 als waschechte 64Bit CPU bezeichnen muss, zumindest als vollwertige 32Bit CPU. Der Z8000 konnte zumindest entgegen dem 68000 zwei 32Bit Werte multiplizieren, oder dividieren.

Aber waren es physiklaisch ausgelegte 64Bit breite Register? Nein
Also ist es nach der Definition eine 16Bit CPU.

Was kämpfst du so dagegen an, diese Definition sagt doch nichts anderes aus, als wie breit die Datenregister ausgelegt wurden.

Und Thema "word". Wie schon gesagt, sonst können wir gleich mit AMD64 anfangen...

Avalox

2009-08-04, 09:55:23

Was kämpfst du so dagegen an, diese Definition sagt doch nichts anderes aus, als wie breit die Datenregister ausgelegt wurden.

Na, weil sich hier die Wertigkeit negiert. Zusammen geschaltet, waren es beim 6809 eben 16Bit Register und beim Z8000 völlig physikalisch 64Bit Register.

Es ist doch ein Vorteil solch eine Funktion zu haben und kein Nachteil.

Nur weil der 68000er seine Register nicht auftrennen kann, was bei der CPU aber Sinn machen könnte, soll dieses eine 32Bit CPU sein, während eine CPU welche diese Funktion hat auf einmal eine 16Bit, statt einer 32Bit CPU ist? Dabei kann alles gleich sein, nur das fehlen einer optionalen Funktion führt dazu, dass aus einer 16Bit CPU eine 32Bit CPU wird?

Ne. Das ist nicht logisch, legt zudem eine fällig falsche Wertung in die Betrachtung.

Und Thema "word". Wie schon gesagt, sonst können wir gleich mit AMD64 anfangen...

Das kann man kaum noch vergleichen.

Edit:

Manchmal macht es ja auch Sinn in Wikipedia zu sehen.
Dort ist der 68k als 16Bit CPU geführt.
Natürlich gab es auch dort eine Diskussion, welche so beendet wurde:

"Auch falsch ist übrigens die Behauptung, die interne Verarbeitung beim 68000 erfolge 32-bitig: Datenpfade, Register und ALU sind vollständig 16-bitig, wenngleich der Befehlssatz die verwendete Mikroarchitektur so gut abstrahiert, dass sie für den Programmierer fast vollständig transparent ist. Es ist ein selbst von Motorola unbestrittenes Faktum, dass es sich beim 68000 um eine 16-Bit-CPU mit 32-Bit-Befehlssatz handelt. Nachzulesen bspw. in "M68000-Famiele Teil 1, Grundlagen und Architektur" aus dem TeWi-Verlag."

http://de.wikipedia.org/wiki/16-Bit-Architektur

Gast

2009-08-04, 11:29:38

Allein das die alte Gen 8-bit war, sagt ja schon aus, das Amiga 16-bit ist. Man hat das Space Shuttle auch nicht vor dem Heißluftballon erfunden.
Amiga wurde immer als 16-bit Computer, das Megadrive immer als 16-bit Konsole gelistet.
Der Hit "Changing Minds" von 16-bit wurde auf dem Amiga erstellt.

Gast

2009-08-04, 12:12:34

"Es ist ein selbst von Motorola unbestrittenes Faktum, dass es sich beim 68000 um eine 16-Bit-CPU mit 32-Bit-Befehlssatz handelt. Nachzulesen bspw. in "M68000-Famiele Teil 1, Grundlagen und Architektur" aus dem TeWi-Verlag."

http://de.wikipedia.org/wiki/16-Bit-Architektur

Ist doch schön diese Definition. Es wäre noch schöner, wenn man sich auf eine Sicht beschränkt hätte. Mal ehrlich, die Implementierung einer CPU ist doch völlig nebensächlich! Erzähl doch mal einem Softwareentwickler folgendes: "Du hast ein 32-Bit OS, du hast einen 32-Bit C/C++ Compiler, ja du hast sogar ein 32-Bit Assembler Befehlssatz. Aber achte mir ja schön darauf, dass du 16-Bit Software schreibst". Was soll das denn werden?

Die Frage des Threaderstellers bezog sich nach meiner Meinung wohl eher auf die Sicht der Software und nicht wie CPU XY 32-Bit implementiert. Die 68K CPU mag was die Definition anging, wohl ein Spezialfall gewesen sein, aber muss man das jetzt alles in epischer Breite ausdiskutieren? Hätte man dafür nicht einen eigenen Thread machen sollen?

Avalox

2009-08-04, 14:10:54

Softwareentwickler folgendes: "Du hast ein 32-Bit OS, du hast einen 32-Bit C/C++ Compiler, ja du hast sogar ein 32-Bit Assembler Befehlssatz. Aber achte mir ja schön darauf, dass du 16-Bit Software schreibst". Was soll das denn werden?

"Aber achte schön drauf, dass du 16 Bit Operationen verwendest, damit es performant bleibt." Das ist schon ein Unterschied, zu einem System welches nicht den Hintergrund hat. Es ist eine andere Programmierung, als man gemeinhin von einem echten 32Bit System ausgehen tut. So schließt sich der Kreis.

Tigerchen

2009-08-04, 15:42:21

Ich denke sind 1988 sind die ersten Spiele mit DOS4GW DOS Extender erschienen. Gab bestimmt aber schon vorher Spiele(und vor allen andere Software) mit anderen Dos Extendern. Die ersten 32Bit Dos Extender sind 1986 erschienen.

1985 ist der 386er erschienen. Und dieses ist nur die PC Schiene.
Richtig. Mein erstes 32 Bit Programm war Panzer General. Das lief nur mit DOS4GW und VGA.

Tigerchen

2009-08-04, 15:56:48

Na, weil sich hier die Wertigkeit negiert. Zusammen geschaltet, waren es beim 6809 eben 16Bit Register und beim Z8000 völlig physikalisch 64Bit Register.

Es ist doch ein Vorteil solch eine Funktion zu haben und kein Nachteil.

Nur weil der 68000er seine Register nicht auftrennen kann, was bei der CPU aber Sinn machen könnte, soll dieses eine 32Bit CPU sein, während eine CPU welche diese Funktion hat auf einmal eine 16Bit, statt einer 32Bit CPU ist? Dabei kann alles gleich sein, nur das fehlen einer optionalen Funktion führt dazu, dass aus einer 16Bit CPU eine 32Bit CPU wird?

Ne. Das ist nicht logisch, legt zudem eine fällig falsche Wertung in die Betrachtung.

Das kann man kaum noch vergleichen.

Edit:

Manchmal macht es ja auch Sinn in Wikipedia zu sehen.
Dort ist der 68k als 16Bit CPU geführt.
Natürlich gab es auch dort eine Diskussion, welche so beendet wurde:

"Auch falsch ist übrigens die Behauptung, die interne Verarbeitung beim 68000 erfolge 32-bitig: Datenpfade, Register und ALU sind vollständig 16-bitig, wenngleich der Befehlssatz die verwendete Mikroarchitektur so gut abstrahiert, dass sie für den Programmierer fast vollständig transparent ist. Es ist ein selbst von Motorola unbestrittenes Faktum, dass es sich beim 68000 um eine 16-Bit-CPU mit 32-Bit-Befehlssatz handelt. Nachzulesen bspw. in "M68000-Famiele Teil 1, Grundlagen und Architektur" aus dem TeWi-Verlag."

http://de.wikipedia.org/wiki/16-Bit-Architektur
Der 68000er ist eine 32 Bit CPU. Deine Meinung zu dem Thema ist für nicht mehrheitsfähig.
Er hat 32 Bit Adressregister und 32 Bit Datenregister. Das die Daten für einen 32 Bit Wert via Multiplex geladen werden müßen ist irrelevant. Ein Intel 8088 ist auch keine 8 Bit CPU nur weil sie auf diesen Trick zurückgreifen muß.

Gast

2009-08-04, 17:10:17

Ließ wiki, der 68k im A500 ist 16bit an einer 32bit-Sauce. Der erste echte 32bitter ist erst der 68020.

Tigerchen

2009-08-05, 08:31:24

Ließ wiki, der 68k im A500 ist 16bit an einer 32bit-Sauce. Der erste echte 32bitter ist erst der 68020.
Das ist eben eine falsche Sichtweise. Lies das was ich geschrieben habe dann hast du meine Begründung.

Avalox

2009-08-05, 08:42:50

Das ist eben eine falsche Sichtweise. Lies das was ich geschrieben habe dann hast du meine Begründung.

Das was du geschrieben hast ist aber nicht richtig. Der 68k nutzt keinen Multiplexer für den Datenbus, er schreibt und liesst schlicht 2 Words hintereinander.

Der fundamentale Unterschied ist der, dass die ALU des 8088 tatsächlich mit 16Bit arbeitet, trotz des 8Bit Datenbusses. Die Breite dieses Datenbuses ist reduziert worden und es wird gemultiplext. Der 68000 verfügt ebenfalls über eine 16Bit ALU und er er hat einen 16Bit Datenbus, die 32Bit Register werden geschickt über den Microcode gesteuert mit zwei Words gefüllt (oder weg geschrieben), dazu benötigt die CPU mehrere Durchläufe. Der Datenbus des 68000 ist nicht künstlich reduziert, der 68000er könnte mit einem 32Bit Datenbus überhaupt nichts anfangen.

s.o.
unbestrittenes Faktum, dass es sich beim 68000 um eine 16-Bit-CPU mit 32-Bit-Befehlssatz handelt.

Gast

2009-08-05, 10:27:08

Jetzt splittet doch mal bitte jemand diese unsägliche Diskussion auf! Hier gibt es offensichtlich zwei Lager. Das Hardware-Lager und das Software-Lager. Ich zähle mich zu letzterem. Wenn hier jemand behauptet hat, der 68K sei eine 32-Bit CPU aus Sicht der Hardware, dann sorry. Aus Software-Sicht verhält er sich jedenfalls wie eine 32-Bit CPU. Bittet liebes Hardwarelager, akzeptiert dieses endlich.

Tigerchen

2009-08-05, 15:07:35

Das was du geschrieben hast ist aber nicht richtig. Der 68k nutzt keinen Multiplexer für den Datenbus, er schreibt und liesst schlicht 2 Words hintereinander.

Der fundamentale Unterschied ist der, dass die ALU des 8088 tatsächlich mit 16Bit arbeitet, trotz des 8Bit Datenbusses. Die Breite dieses Datenbuses ist reduziert worden und es wird gemultiplext. Der 68000 verfügt ebenfalls über eine 16Bit ALU und er er hat einen 16Bit Datenbus, die 32Bit Register werden geschickt über den Microcode gesteuert mit zwei Words gefüllt (oder weg geschrieben), dazu benötigt die CPU mehrere Durchläufe. Der Datenbus des 68000 ist nicht künstlich reduziert, der 68000er könnte mit einem 32Bit Datenbus überhaupt nichts anfangen.

s.o.
Es gab bei Erscheinen des 68000er niemanden, aber auch wirklich niemanden der deine Sichtweise gehabt hätte. Die gesamte Fachpresse bezdeichnete Computer wie den Sinclair QL oder Commodore Amiga als 32 Bit Rechner. Allein schon der 32 Bit breite lineare Adressraum macht das auch deutlich.

Wegen der 16-Bit-ALU und des 16-Bit-Datenbusses wird der 68000 heute oft 16-Bit-Prozessor genannt, er führt jedoch klaglos 32-Bit-Software aus. Wegen der 16-Bit-ALU kostet z. B. eine 32-Bit-Addition die doppelte Zeit. Der Schaltkreis zur Generierung von Adressen hat jedoch volle 32 Bit, so dass z. B. das Durchsuchen eines Textes mit 8 Bit breiten Zeichen nicht langsamer ist, als von einem reinen 16-Bitter zu erwarten wäre. Zudem kann der Text länger als 64 kB sein, ohne Modifikation des Programms. 68000-Software ist 32-Bit-Software.

Ectoplasma

2009-08-05, 15:44:47

68000-Software ist 32-Bit-Software.

Full ack!

O.T.:
Übrigens bin ich der Gast der das Thema 68K zur Ansprache gebracht hat und mehrfach darum bat, diesen Thread aufzusplitten. Ist ja nicht so, dass ich mich hier verstecken will.

BlackBirdSR

2009-08-05, 15:59:01

Ich hab den ganzen Thread umbenannt. Es gab anscheinend nur 7 Posts oder so, die sich mehr oder weniger mit dem Thema "Wann war der Umstieg" auseinandergesetzt haben (wollten). Die restlichen 3 1/2 Seiten sind 68K ;)

Bei Bedarf kann man ja einen neuen Thread für den Blog erstellen.

PHuV

2009-08-05, 16:05:32

68000-Software ist 32-Bit-Software.

Korrekt, und nichts anderes! Jeder, der den Amiga mal programmiert hat, weiß das. Die Programme liefen auch anstandslos auf einer 68020/30/40-CPU. Bei allen anderen OS (Windows 95-98) wurden die 16-Bit-Programme nur in einer emulierten Umgebung lauffähig. So was war auf dem Amiga überhaupt nicht notwendig. Gut, man mußte neu kompilieren, um Geschwindigkeitsvorteile des 68020/68881 aufwärts nutzen zu können, aber das ist ein anderes Thema.

Update: Hab diesen ganzen MMU-Mist ganz vergessen. :redface: Na, so ganz ohne gings doch nicht.

Spasstiger

2009-08-05, 19:59:43

Wenn Anwendungen für einen Prozessor einen 32-Bit-Adressraum nutzen können, ist der Prozessor imo ein 32-Bit-Prozessor.

Avalox

2009-08-05, 21:09:44

Es gab bei Erscheinen des 68000er niemanden, aber auch wirklich niemanden der deine Sichtweise gehabt hätte. Die gesamte Fachpresse bezdeichnete Computer wie den Sinclair QL oder Commodore Amiga als 32 Bit Rechner. Allein schon der 32 Bit breite lineare Adressraum macht das auch deutlich.

Das waren alles in der Presse 16 Bit Rechner.
Selbst die Pop Gruppe 16 Bit, nannte sich 16 Bit, weil sie Musik auf dem Amiga gemacht haben.
Das Buch was ich oben zitiert habe ist zeitgenössisch und dokumentiert, dass der 68k eben von Motorola selbst als 16Bit CPU bezeichnet wurde.

Der Schaltkreis zur Generierung von Adressen hat jedoch volle 32 Bit,

Nahezu alle 8Bit CPU hatten einen 16Bit Adressraum und konnten damit 64kByte adressieren. Demzufolge hatten die 16Bit CPUs als Nachfolger einen grösseren Adressraum. Der 68000er eben 24Bit. Die oberen 8 Bit wurden bei der Adressvergabe nicht beachtet und konnten so für allerhand Schweinereien benutzt werden, die dann erst später bei folgenden CPUs ein auf die Füße gefallen sind.

Das Adressregister kann dort nicht heran gezogen werden. Zumal die CPU maximal 24Bit tatsächlich adressieren konnte.

68000-Software ist 32-Bit-Software

Aus mehreren Gründen ist dieses eingeschränkt.
Zum einen wurde aus Performancegründen sehr viel 16Bit Artmetrik genutzt, zum anderen hat sich der 68000er nicht zu 100% wie ein echter 32Bit Prozessor verhalten. Es war 32Bit Software, aber eben doch in ihrer Art speziell.

Wenn Anwendungen für einen Prozessor einen 32-Bit-Adressraum nutzen können, ist der Prozessor imo ein 32-Bit-Prozessor.

Der Schneider CPC hatte 64kByte Hauptspeicher. 64kByte benötigt ein 16Bit Adressraum. Ist der Z80 deshalb eine 16Bit CPU? Es war eine 8Bit CPU mit einer 8Bit ALU.
Dabei fällt mir ein, dass der Z80 auch über ein 16Bit Datenregister verfügte. War trotzdem eine 8Bit CPU.

Gast

2009-08-13, 23:50:26

Ich würde sagen, wenn ihre Rechenregister 32 Bit breit sind und sie somit 2 32 Bit Zahlen in einem Schritt addieren kann, dann ist es ne 32 Bit CPU

No.3

2009-08-14, 00:04:04

Ganz sicher nicht. Der Atari ST hat seinen Namen z.B. daher. Das S beim ST steht für Sixteen/Thirtytwo Bits. Eben einer 16Bit CPU, welche 32Bit Software nutzen kann.

Das hat auch damals jeder gesehen. Dieses resultierte dann in Musik Bands, welche vom Amiga inspiriert sich dann "16Bit" nannten, oder Übersichten von damaligen 16Bit Heimcomputern (http://en.wikipedia.org/wiki/List_of_16-bit_computer_hardware_palettes).

vielleicht weil der Atari ST und der Amiga und Co "auf der Platine" 16 Bit sind und der 68000 "16 Bit zur Platine hin" und "32 Bit CPU intern" ist?

Mit AA (bzw AGA) war der Amiga dann auch "auf der Platine" in 32 Bit.

Auch die C-Compiler haben 32-Bit Code produziert. Klar konnte man zu den Adressregistern relative 16-Bit Offsets addieren und diese waren auch schnell. Das war aber auch schon eine der wenigen Ausnahmen, bei denen man effektiv mit 16-Bit arbeiten konnte.

jou, "Large" vs "Small" Compiler Model oder wie das damals hies