Gast
#708270
Hallo, ich verstehe nicht so ganz den Vorteil der 32bitter, in "C" bei 16bitter kann ich auch eine variable als "long" definieren dann habe ich auch 32Bit?? Gruß
Gast
#708275
ich kann auch au einem 8-bitter eine 32 bit variable definieren..... Der 32-Bitter kann sie aber AUF EINMAL verarbeiten wo der 16 bitter halt schon 2 mal und der 8-bitter 4 mal dran muss.
Gast
#708276
ok, ist auch ein Argument. Danke
Gast
#708278
Außerdem haben 32-Bitter i.Allg. aucheinen 32-Bit-Adressraum, so dass man bis zu 4 GB Speicher an einem Stück ansprechen kann. Bei den 16-Bittern ist dieser Adressraum oft eingeschränkt. Der größere Adressraum ist auch eines der Hauptargumente für 64-Bit-Prozessoren, 64-Bit-Rechenoperationen hingegen werden eher selten benötigt.
In der Praxis liegt der Unterschied nicht so sehr darin, Daten wie breit auch immer verarbeiten zu können, sondern in der Fähigkeit mit Adressen umzugehen. 8/16-Bit Controller verarbeiten Adressen von Daten i.d.R. 16 Bit breit. Was für variable Daten bei vollintegrierten Controllen auch meist ausreicht. Aufgrund der Notwendigkeit, mehr Code als 64K adressieren zu können, sind Codeadressen jedoch entsprechend breiter und die direkte Konsequenz sind getrennte Adressräume für RAM und ROM, folglich getrennte Befehle für Zugriff auf Daten im RAM und auf Daten im ROM, was sowohl dem Compiler als auch dem Programmierer das Leben erschwert. 32-Bit Controller hingegen arbeiten stets mit einem einzigen Adressraum und ein Zeiger kann gleichermassen auf RAM oder auf ROM zeigen. Es gibt intelligente Kompromisse, wie Microchips PIC30, wo ein Teil vom ROM im Datenadressraum eingeblendet ist, um Tabelle, Strings und andere konstante Daten ohne Klimmzüge direkt adressieren zu können. Aber die Regel ist das nicht, auch Atmel hatte sich da bei den AVRs bislang konsequent verweigert, was GCC-Anwendern umständliche und fehlerträchtige pgm_read_byte()-Orgien einbringt.
Gast
#708332
Lieber Andi Da verwechselst du was: >Aufgrund der Notwendigkeit, mehr Code als 64K adressieren zu >können, sind Codeadressen jedoch entsprechend breiter und die direkte >Konsequenz sind getrennte Adressräume für RAM und ROM, folglich >getrennte Befehle für Zugriff auf Daten im RAM und auf Daten im ROM, was >sowohl dem Compiler als auch dem Programmierer das Leben erschwert. Getrennte Addressräume for RAM(Daten) und ROM(Code) kommen daher, weil es sich um Harvard Architekturen handelt (8051 ist ein gutes Beispiel 64k Code, 64k Daten). Gemeinsamer Adressraum gibt's bei der von Neumann Architektur(Bsp. Motorola 6800, 64k Daten und Code) Übrigens moderne Architekturen haben meist eine Harvard-Architektur, also getrennter Adressraum.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.