Wenn ich deklariere volatile myvar = "asdfg" char *point = &myvar myvar kann ja eine Adresse, im RAM oder flash sein. Wie ist das auch noch mit Neumann oder Harvardstruktur des chips? Wenn was aus dem flash genommen wird, muss es aber eine Konstante sein. const myvar = "asdfg" So stelle ich mir das vor, ehe ich korrigiert werde. Wenn ich den Pointer als char festlege, so kann er ja nur 256 Byte abdecken. Oder er bezieht sich auf die Datenbreite die ich von *point holen will. Konnte das nicht finden, deshalb die Frage als Anfänger. LG Rudi
Rudi D. schrieb: > volatile myvar = "asdfg" > char *point = &myvar Da fehlt was... Rudi D. schrieb: > Wie ist das auch noch mit Neumann oder Harvardstruktur des chips? Welcher Chip? :-O Rudi D. schrieb: > const myvar = "asdfg" Syntax Error again Rudi D. schrieb: > Wenn ich den Pointer als char festlege, so kann er ja nur 256 Byte > abdecken. Was meinst du damit? Adressen?
Rudi D. schrieb: > Wenn ich den Pointer als char festlege, so kann er ja nur 256 Byte > abdecken. warum? ein char* ist immer noch sizeof(char*) gross und nicht sizeof(char).
Silvan König schrieb: > Rudi D. schrieb: >> volatile myvar = "asdfg" >> char *point = &myvar > > Da fehlt was... Bitte was ? > > Rudi D. schrieb: >> Wie ist das auch noch mit Neumann oder Harvardstruktur des chips? > > Welcher Chip? :-O z.b. Z80 ...Neumann AVR... Harvard > > Rudi D. schrieb: >> const myvar = "asdfg" > > Syntax Error again Was denn? > > Rudi D. schrieb: >> Wenn ich den Pointer als char festlege, so kann er ja nur 256 Byte >> abdecken. > > Was meinst du damit? Adressen? Ja
Peter II schrieb: > Rudi D. schrieb: >> Wenn ich den Pointer als char festlege, so kann er ja nur 256 Byte >> abdecken. > > warum? ein char* ist immer noch sizeof(char*) gross und nicht > sizeof(char). Das finde ich eben nicht in der C/C++ Referenz, darum frage ich
Rudi D. schrieb: > Das finde ich eben nicht in der C/C++ Referenz, darum frage ich keine ahnung wo man das suchen müsste. Aber ein Pointer ist immer gleich gross egal wohin er zeigt. sizeof(int*)==sizeof(void*)==sizeof(char*)==sizeof(struct xyz*)
Peter II schrieb: > sizeof(int*)==sizeof(void*)==sizeof(char*)==sizeof(struct xyz*) = 2 [Byte] (ATmega8)
Peter II schrieb: > Aber ein Pointer ist immer gleich > gross egal wohin er zeigt. Schon einmal etwas von unterschiedlichen Speichermodellen gehört? Die Speichergröße von einem pointer hängt auch vom erreichbaren Adressbereich ab.
near or far schrieb: > Schon einmal etwas von unterschiedlichen Speichermodellen gehört? Die > Speichergröße von einem pointer hängt auch vom erreichbaren > Adressbereich ab. ja habe ich. Ich habe ja nicht geschrieben wie gross der pointer ist - nur das sie gleich sind. (in einem Programm)
Silvan König schrieb: > Peter II schrieb: >> sizeof(int*)==sizeof(void*)==sizeof(char*)==sizeof(struct xyz*) > > = 2 [Byte] > > (ATmega8) Was ist das für eine Schreibweise? ein Pointer hat das * immer vorangestellt Ein Schlüsselwort mit * dahinter kenne ich, bis jetzt, nicht. Aber mit etwas Interpretation ist klar, dass man bei mega8 und 1kByte RAM einen Pointer mit 2 Byte braucht. o.k. Aber was ich nicht weiss ist ob der Compiler auch Konstanten aus dem Flash verwendet. Da müsste der Pointer aber dann u.U. > 2 Byte haben. Ich nehme also an, dass der Typ des Pointers, ob char oder int sich auf die Wortbreite bezieht Oder nicht?
Peter II schrieb: > nur das sie gleich sind. (in einem Programm) Dein Weltbild ist etwas eingeschränkt.
./. schrieb: > Dein Weltbild ist etwas eingeschränkt. dann klär mich doch mal auf, wissen kann ja nie schaden. > Aber was ich nicht weiss ist ob der Compiler auch Konstanten aus dem > Flash verwendet. Da müsste der Pointer aber dann u.U. > 2 Byte haben. nein, denn der Flash wird auch nur duch die eine 16bit adresse abgerufen. Nur das das ganze auf WORD adressen sich bezieht.
Rudi D. schrieb: > Ich nehme also an, dass der Typ des Pointers, ob char oder int sich auf > die Wortbreite bezieht Oder nicht? Im reservierten Speicher für den pointer ist die Adresse auf das Ziel - also wo der pointer hin ziegt - abgelegt. Und dabei ist es natürlich völlig egal, wie das Ziel interpretiert wird: char, int, long, oder was auch immer.
near or far schrieb: > Rudi D. schrieb: >> Ich nehme also an, dass der Typ des Pointers, ob char oder int sich auf >> die Wortbreite bezieht Oder nicht? > > Im reservierten Speicher für den pointer ist die Adresse auf das Ziel - > also wo der pointer hin ziegt - abgelegt. Und dabei ist es natürlich > völlig egal, wie das Ziel interpretiert wird: char, int, long, oder was > auch immer. Das ist ja mein Wissensproblem. Annahme: Bei einem Bytepointer wird eben 1 Byte von der Adresse, wo der Pointer hinzeigt geholt. Bei einem Pointer auf ein Array mit Int Zahlen muss ja der Pointer ggfs. um 2 Byte incrementiert werden um auf den nächsten Eintrag zu zeigen. Bei einem float array .... Woher weiss der Pointer um welchen Step er increm. werden muss? Oder ist das alles uninteressant und ich mache mir unnötig Gedanken?
Rudi D. schrieb: > Das ist ja mein Wissensproblem. Annahme: > Bei einem Bytepointer wird eben 1 Byte von der Adresse, wo der Pointer > hinzeigt geholt. > > Bei einem Pointer auf ein Array mit Int Zahlen muss ja der Pointer ggfs. > um 2 Byte incrementiert werden um auf den nächsten Eintrag zu zeigen. > Bei einem float array .... > Woher weiss der Pointer um welchen Step er increm. werden muss? > Oder ist das alles uninteressant und ich mache mir unnötig Gedanken? nur hat das ganze überhaupt nicht mit der größe eines Pointers zu tun.
Rudi D. schrieb: > Woher weiss der Pointer um welchen Step er increm. werden muss? > > Oder ist das alles uninteressant und ich mache mir unnötig Gedanken? Also der Speicherbedarf des pointer ist immer gleich, da er immer auf eine Adresse zeigt. Der Typ des poiters gibt an, wie der Speicher interpretiert wird: char = 1 Byte, int = 2 Byte (8 / 16 Bit CPU), long = 4 Byte.
Rudi D. schrieb: > Woher weiss der Pointer um welchen Step er increm. werden muss? der pointer weiss es überhaupt nicht. Der Compiler legt es einfach fest. int* p; p[x] enstpricht einfach p + (x * sizeof(int))
Rudi D. schrieb: > Woher weiss der Pointer um welchen Step er increm. werden muss? Was denkst du? Warum muss man wohl bei der Defintion eines Pointers immer den Datentyp mit angeben, auf den der Pointer zeigt? char * Pointer; dort wo der Pointer hinzeigt, ist ein char int * Pointer; dort wo der Pointer hinzeigt, ist ein int float * Pointer; dort wo der Pointer hinzeigt, ist ein float struct xy * Pointer; dort wo der Pointer hinzeigt, ist ein ... ....
Rudi D. schrieb: > Ich nehme also an, dass der Typ des Pointers, ob char oder int sich auf > die Wortbreite bezieht Oder nicht? Ganz schlecht. Also: etwas anzunehmen. Besorg dir lieber ein C-Buch und lerne anstatt Dinge anzunehmen.
Karl Heinz Buchegger schrieb: > Rudi D. schrieb: > >> Ich nehme also an, dass der Typ des Pointers, ob char oder int sich auf >> die Wortbreite bezieht Oder nicht? > > > Ganz schlecht. Also: etwas anzunehmen. > > Besorg dir lieber ein C-Buch und lerne anstatt Dinge anzunehmen. Hab ich ja, aber dort steht es für mich nicht deutlich genug. Da stehen nur Tatsachen ohne Begründung. Ich weiss ja nicht wie man Compiler baut, obwohl meine Annahme s.o. zutrifft. Jetzt ist es klar. Danke Dir und PeterII
Rudi D. schrieb: > Hab ich ja, aber dort steht es für mich nicht deutlich genug. > Da stehen nur Tatsachen ohne Begründung. Was soll da auch stehen? "Weil es so definiert ist" wäre die allgemeingültige Begründung…
Andreas B. schrieb: > Rudi D. schrieb: >> Hab ich ja, aber dort steht es für mich nicht deutlich genug. >> Da stehen nur Tatsachen ohne Begründung. > > Was soll da auch stehen? "Weil es so definiert ist" wäre die > allgemeingültige Begründung… Ich lerne eben besser, wenn ich es noch diskutieren kann. Was ich nur lese ist nur "volatile". Ich bewundere jene, die nur aus Büchern lernen können. LG Rudi
Rudi D. schrieb: > Ich lerne eben besser, wenn ich es noch diskutieren kann. > Was ich nur lese ist nur "volatile". Ähm. volatile hat damit aber überhaup tnichts zu tun. http://www.mikrocontroller.net/articles/FAQ#Was_hat_es_mit_volatile_auf_sich > Ich bewundere jene, die nur aus > Büchern lernen können. Du solltest dir das besser auch relativ zügig aneignen. Letztenendes wirst du nicht umhinkommen.
Karl Heinz Buchegger schrieb: > Rudi D. schrieb: > Ähm. > volatile hat damit aber überhaupt nichts zu tun. > > http://www.mikrocontroller.net/articles/FAQ#Was_hat_es_mit_volatile_auf_sich das sehe ich jetzt auch und verstehe es auch >> Ich bewundere jene, die nur aus >> Büchern lernen können. > > Du solltest dir das besser auch relativ zügig aneignen. Letztenendes > wirst du nicht umhinkommen. Na ja, ich hab ja "nur aus Büchern" geschrieben. Eine Antwort im Forum ist ja wie ein Gespräch, als auditiver Typ. Aber diese, meine Eigenschaft wird sich, glaube ich nicht großartig verbessern lassen. Außerdem ist es ja Hobby in der Pension. In der Zwischenzeit beschäftigt mich die Frage, ob ein Compiler das versteht: char astring = "asdfg" ohne [] vor dem = Aber ich habe mich entschlossen für solche Fragen gcc, ich bin mit Ubuntu unterwegs, zu benützen und zu üben. Für AVR bin ich noch in XP mit dem AVR-Studio 4.18 unterwegs.
Rudi D. schrieb: > In der Zwischenzeit beschäftigt mich die Frage, ob ein Compiler das > versteht: > > char astring = "asdfg" Solche sachen stehen im C Standard. C99 oder C11 oder wasimmer du lernen willst.
Rudi D. schrieb: > In der Zwischenzeit beschäftigt mich die Frage, ob ein Compiler das > versteht: > > char astring = "asdfg" ohne [] vor dem = Siehst du. Genau solche Dinge stehen in jedem noch so grindigem C-Buch. Bzw. sie folgen ganz automatisch aus dem Wissen, welches in den ersten paar Kapitel vermittelt wird. Da ist nichts geheimnisvolles daran, das ergibt sich ganz automatisch aus der Fragestellung "Was ist denn eigentlich ein String, wie wird er in C dargestellt und was ist denn eigentlich ein einzelner char, was kann man in ihm speichern?" Deine 'Antworter' werden ganz schnell die Lust verlieren, auf solche Fragen zu antworten, dann das sind alles Grundlagen. Das ist so, wie wenn du sagst du möchtest dich mit jemandem über Differentialgleichungen und deren Lösungsstrategien unterhalten und dann stellt sich raus, dass du mit simplen Klammernauflösen in banalen linearen Gleichungen Schwierigkeiten hast. Kein Mensch wird dir auf Diff-gleichungen eingehen sondern dir erst mal sagen, du mögest doch bitte die Grundlagen erst mal durchgehen, ein paar Jahre üben und dann kannst du wieder kommen. > Aber ich habe mich entschlossen für solche Fragen gcc, ich bin mit > Ubuntu unterwegs, zu benützen und zu üben. > Für AVR bin ich noch in XP mit dem AVR-Studio 4.18 unterwegs. Das ist so erst mal relativ uninteressant, denn C ist eine genormte Sprache (auch so ein Punkt: welche Dinge sind denn eigentlich genormt und daher auf allen Systemen gleich und was ist in der Sprache so weit offen gelassen, das es vom jeweiligen konkreten System abhängt?)
near or far schrieb: > Also der Speicherbedarf des pointer ist immer gleich, da er immer auf > eine Adresse zeigt. Blödsinn.
Karl Heinz Buchegger schrieb: > Rudi D. schrieb: > >> > Deine 'Antworter' werden ganz schnell die Lust verlieren, auf solche > Fragen zu antworten, dann das sind alles Grundlagen. Das ist deutlich. o.k. Werde das annehmen. LG Rudi
ich muss wirklich vorher mehr suchen, z.B. http://msdn.microsoft.com/en-us/library/7w7xccx8%28v=vs.80%29.aspx Da steht es sehr schön und mit Hintergrund. LG Rudi
mal etwas zum Lesen: http://openbook.galileocomputing.de/c_von_a_bis_z/ Florian schrieb: > Peter II schrieb: >> Aber ein Pointer ist immer gleich gross egal wohin er zeigt. > > Das ist falsch. Florian schrieb: > near or far schrieb: >> Also der Speicherbedarf des pointer ist immer gleich, da er immer auf >> eine Adresse zeigt. > > Blödsinn. Tja, Florian, Du musst schon den Kontext dazu sehen: Pointer sind immer gleich groß, egal auf was für einen Datentyp sie zeigen.
near or far schrieb: > Tja, Florian, Du musst schon den Kontext dazu sehen: Pointer sind immer > gleich groß, egal auf was für einen Datentyp sie zeigen. Bei GCC ist das meines Wissens immer so, aber allgemein in C ist das nicht zwingend der Fall.
near or far schrieb: > Tja, Florian, Du musst schon den Kontext dazu sehen: Pointer sind immer > gleich groß, egal auf was für einen Datentyp sie zeigen. Das ist von der Maschinendefinition her nicht zwingend. Noch bis Anfang der 80er waren Maschinen mitunter wortadressierend. Wenn bei der Adressierung des Speichers die Wortbreite ausgereizt wurde, dann fehlten für Byte/Teilwort-Operationen Bits. Manche lösten das Problem, indem es keine solchen Operationen gab - was die Problematik aber nur in Software verlagert. Andere suchten sich die Bits anderswo zusammen. Der Fairchild 9445, ein Single-Chip Derivat des 16-Bit Minicomputers Data General Nova, addressierte im erweiterten Modus in den Befehlen 64K Worte oder 128K Byte. Für 128KB wurde das Carry-Bit mit eingespannt. Wollte man C auf einem solchen Gerät implementieren ohne die Adressierbarkeit des gesamten Speichers in Bytes zu verlieren, dann wäre ein "char *" breiter als ein "int *". Und wer jetzt mit "was ein Schmäh, das war vor Urzeiten" kommt, der sollte sich den MaxQ 2000 von Dallas/Maxim ansehen. Ist nicht so arg weit weg davon.
near or far schrieb: > Tja, Florian, Du musst schon den Kontext dazu sehen: Pointer sind immer > gleich groß, egal auf was für einen Datentyp sie zeigen. Das mag zufällig bei deinem Compiler für deine Zielplattform so sein, es ist aber nicht nur nicht garantiert, sondern es gibt und gab genügend Compiler-Architektur-Kombinationen, wo dem nicht so ist. Aber warum informieren? Kiddies wie du programmieren heutzutage schließlich nicht mehr, sondern klicken solange irgendwas zusammen, bis zufällig ein Executable hinten rauskommt.
Florian schrieb: > Aber warum informieren? Tja Florian, dann ziehe Deine Windel etwas strammer, wir sind hier im gcc Forum und nicht im Deutschen Museum. Aber für Spätzünder wie Dich formuliere ich es etwas anders: Die Speichergröße eines Pointers ist unabhängig vom referenzierten Datentypen. Und nicht vergessen, gcc Forum.
Auch wenn es sich um das GCC-Forum handelt und sich Fragen (hoffentlich) auf GCC beziehen, sollte man bedenken, daß die meisten Fragen hier von Leuten kommen, die gerade damit beginnen, C zu lernen. Die nehmen dann das, was man ihnen ohne weiteren Kommentar eintrichtert, als allgemeingültig hin und wundern sich dann, warum's später auf einem anderen Compiler nicht geht. Deshalb finde ich es sinnvoll und hilfreich, auf GCC-Spezifika, so sie denn überhaupt nötig sind, explizit hinzuweisen.
Ich kann es immer noch nicht glauben das es (aktuelle) Platformen gibt wo pointer auf daten (also keine funktionszeiger) unterschiedlich gross sind. Kann jemand mal ein Beispiel oder in link posten?
Peter II schrieb: > Ich kann es immer noch nicht glauben das es (aktuelle) Platformen gibt > wo pointer auf daten (also keine funktionszeiger) unterschiedlich gross > sind. In dieser allgemeinen Formulierung existiert das auch für GCC für AVR. Der in seiner aktuellen Fassung 16-bit und 24-bit Pointer implementiert. Das ist zwar nicht abhängig vom Datentyp, aber doch von den Eigenschaften des Speichers, auf den der Pointer zeigen kann. 16-bit Pointer vs 24-Bit managed Pointer, nun auch in GCC: http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Named-Address-Spaces.html#Named-Address-Spaces
Peter II schrieb: > Ich kann es immer noch nicht glauben das es (aktuelle) Platformen gibt > wo pointer auf daten (also keine funktionszeiger) unterschiedlich gross > sind. Je nachdem für wie aktuell du die 8051er hältst: der SDCC hat dort Pointer mit 3 und 2 byte, das Zusatzbyte enthält Informationen, in welchen Speicher gezeigt werden soll. Zugriff erfolgt dann über automatisch dazugepackte Funktionen. => Langsamer, aber praktisch für Bibliotheken, die dann nur noch eine Variante implementieren müssen
Rudi D. schrieb: > Karl Heinz Buchegger schrieb: >> Rudi D. schrieb: > In der Zwischenzeit beschäftigt mich die Frage, ob ein Compiler das > versteht: > > char astring = "asdfg" ohne [] vor dem = Der Weg, eine Programmiersprache über "Trial & Error" und Rumraterei zu lernen, ist einer der nervenzehrendsten und langsamsten Wege überhaupt. Ohne ein Grundkonzept der jeweiligen Programmiersprache und von Zeigern, Datenstrukturen etc. ist Frustration vorprogrammiert. A. K. schrieb: > Peter II schrieb: > >> Ich kann es immer noch nicht glauben das es (aktuelle) Platformen gibt >> wo pointer auf daten (also keine funktionszeiger) unterschiedlich gross >> sind. > > In dieser allgemeinen Formulierung existiert das auch für GCC für AVR. Nö, nicht wenn es um Standard-C geht. Die unten erwähnten Erweiterungen sind nicht Teil von Standard-C; ebenso wie near, far oder huge nicht Teil davon sind. > Der in seiner aktuellen Fassung 16-bit und 24-bit Pointer implementiert. > Das ist zwar nicht abhängig vom Datentyp, aber doch von den > Eigenschaften des Speichers, auf den der Pointer zeigen kann. 16-bit > Pointer vs 24-Bit managed Pointer, nun auch in GCC: > http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Named-Address-Spaces.html#Named-Address-Spaces Dazu sei noch angemerkt, daß die Adress-Arithmetik immer noch gemäß Standard-C erfolgt, also als 16-Bit Arithmetik. Auch sind keine Objkektgrößen größer der in C festgelegten möglich oder adressierbar.
Johann L. schrieb: >> In dieser allgemeinen Formulierung existiert das auch für GCC für AVR. > > Nö, nicht wenn es um Standard-C geht. "As an extension, the GNU C compiler supports named address spaces as defined in the N1275 draft of ISO/IEC DTR 18037. Support for named address spaces in GCC will evolve as the draft technical report changes." > Die unten erwähnten Erweiterungen > sind nicht Teil von Standard-C; Noch nicht, aber wohl auf dem Weg dorthin, will mir scheinen. Nicht die spezifischen Address Spaces selbst, aber das Framework zur architekturabhängigen Definition solcher als eine Art stardisierter Erweiterung. Letztlich ist mir nichts im Standard bekannt, das verschiedene Pointergrössen für verschiedene Pointertypen ausschliesst. Dass dies bisher abgesehen von near/far und dem eben erwähnten Kram nicht üblich war, das lag an dem mangelnden Bedarf der bei Speicheradressierung mittlerweile ziemlich uniformen Mainstream-Architekturen der C Ära.
Kommt auch nen bischen auf die Speciehrorganisierung drauf an. z.B. beim AVR hat der Flasdh ja ein 16Bit Datenbus zum Speicher und mit jedem increment des Adresszeigers um 1 würde nicht ein Byte sondern incrementiert werden sondern 2 ! Also wenn ich das Register Z mit 64 Lade und mit LPM r16,Z+ arbeite, dann greift die CPU auf das Byte 128 zu. Benutze ich LD r16,Z+ greife ich im SRAM auf das Byte 64 zu. Es wird also ein ganz anderer Befehl benutzt und man (bzw. der Compiler) muß wissen ob der Befehl die 64 als Word oder als Byte zu interpretieren hat. Dies haätte auch die Konsequenz, das wenn ich z.B. strings oder char arrays im Flash anspreche ich immer 2 Byte pro Zugriff zurückbekomme und ich eigentlich nicht so einfach auf einzelne Bytes zugreifen kann wie im SRAM. Es gäbe Zwei Unterschiedliche Kompillate ob der String im Flash oder im SRAM liegt. Bei einer Neumann Architektur würde es keinen Unterschied geben.
Uwe schrieb: > Also wenn ich das Register Z mit 64 > Lade und mit LPM r16,Z+ arbeite, dann greift die CPU auf das Byte 128 > zu. Nein, Byte 64. Oberen 15 Bit von Z = Flash-Adresse Unterstes Bit von Z = Auswahl High- oder Low-Byte
A. K. schrieb: > Johann L. schrieb: > >> Die unten erwähnten Erweiterungen [N1275 draft of ISO/IEC DTR 18037] >> sind nicht Teil von Standard-C; > > Noch nicht, aber wohl auf dem Weg dorthin, will mir scheinen. > Nicht die spezifischen Address Spaces selbst, aber das Framework zur > architekturabhängigen Definition solcher als eine Art stardisierter > Erweiterung. An einigen Stellen gibt es IMO noch Nachholbedarf bzw. "weiße Flecken": Zum Beispiel ist folgendes nicht erlaubt:
1 | const __flash char *str = "Hallo"; |
Was der Anwender damit sagen will ist klar: > "Lege ein Literal "Hallo" im Flash an und initialisiere damit > den Flash-Zeiger str. Das String-Literal "Hallo" wird allerdings im Generic angelegt, also im RAM und nicht in __flash. str ist jedoch die einzige Variable, die die Adresse von "Hallo" enthält und somit einen Zugriff auf das Literal erlaubt, und dieser geht ins Flash. Obige Initialisierung geht nur mühsam über eine Zwischenvariable:
1 | const __flash char hallo[] = "Hallo"; |
2 | const __flash char *str = hallo; |
Für eine einzige Variable ist das noch nicht unbequem, aber wenn man zB die Initialisierung einem Menüstruktur betrachtet, wird das alles andere als schön. Zudem wird die Portierbarkeit von "normalem C-Code" von einer anderen Architektur erschwert: Man kann nicht einfach ein __flash an die Menü-Variable kleben um Ablage und Zugriff zu regeln, sondern muss die Variablendefinitionen komplett neu schreiben und zerpflücken. An der "Standardfindung" mitwirken zu wollen ist leider schlicht und einfach unrealistisch... Was GCC angeht, sind die Address Spaces sehr kurzsichtig implementiert: Dabei handelt es sich eigentlich nur um "target specific Qualifiers", aber im GCC ist es dennoch nicht möglich, architekturspezifischge Qualifier zu implementieren. Wesentlich allgemeiner wäre es also gewesen, maschinenspezifische Qualifier zu implementieren und mit deren Hilfe Named Addresses abzubilden. Aus unerfindlichen Gründen wurde dieser Ansatz nicht gewählt.
Peter II schrieb: > keine ahnung wo man das suchen müsste. Aber ein Pointer ist immer gleich > gross egal wohin er zeigt. > > sizeof(int*)==sizeof(void*)==sizeof(char*)==sizeof(struct xyz*) Nochmals: das ist definitiv falsch. Für den GCC und für ISO-C sowieso. Begründung: nirgends im Standard steht, dass Pointer gleich groß sein müssen, also darf man sich darauf auch nicht verlassen. Ich habe hier einen GCC-Port für die gute PDP-10. Deren Speicher ließ sich nur wortweise adressieren, bei 36-Bit-Worten. Da man allerdings Objekte vom Typ char einzeln adressieren möchte, hat man nun die Wahl, ob man pro char 36 Bits verbrät oder sich was anderes überlegt. Beim PDP10-GCC ist CHAR_BIT == 9. Man speichert also 4 chars in einem Wort. Während man zum Ansprechen eines ints ganz einfach eine Maschinenadresse nehmen kann, muss ein char-Pointer zusätzlich noch einen "Offset" enthalten, um innerhalb des Worts den entsprechenden char zu identifizieren. Folge: sizeof(char*) != sizeof(int*). Der Voidpointer muss natürlich so ausgelegt sein, dass man die anderen Zeigertypen in ihn konvertieren kann und auch verlustfrei wieder zurückbekommen kann. AFAIK verhält sich das ganze bei einigen Cray-Maschinen sehr ähnlich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.