wortbreite void*

Mal sizeof (void *) ausgeben lassen?

Ansonsten: Deine Annahme ist korrekt, in avr-gcc ist ein Pointer 16 Bit 
breit.

kosmonaut pirx wrote:

> [...] vll

Viel lieber?
Viel länger?

Wir sind doch hier nicht beim Morsecode.

> ist das auch der grund, warum die guten pgmspace-routinen nur bis 64k
> definiert sind

Naja, der Grund ist eher, dass ein uint8_t * auch 16 bits breit ist. ;-)
Ja, um auf mehr als 64 KiB ROM im Datenmodus zuzugreifen, muss man
zusätzlich zum normalen Zeiger noch RAMPZ behandeln, das machen all
die _P-Routinen nicht.  Dafür ist der Linkerscript so gebaut, dass er
ROM-Daten direkt nach der Initialisierung, aber vor dem restlichen
Code ablegt, damit sie möglichst unterhalb der 64-KiB-Grenze liegen.

Für Programmzugriffe wird der ROM 16-bit-weise adressiert, daher ist
dort die ,,magische Grenze'' erst bei 128 KiB -- was der Grund war,
warum der Patch für die ATmega256x so lange gebraucht hat, bis jemand
eine Idee hatte und jemand anders sie auch umgesetzt hat.

> kapier ich nicht .. 16Bit-weise?

1 Befehlswort = 1 Adresse. Nächstes Befehlswort = Adresse+1. Da ein 
Befehlswort 2 Bytes gross ist, sind mit einem 16 Bit breiten Program 
Counter 64KWorte = 128KByte realisierbar.

Und da GCC verschiedene Pointer nicht verschieden implementieren kann, 
gibt's bei >128KB Flash gewisse Probleme.

Für Datenzugriff auf Flash besteht das Problem seit langem, dank 
Mega128. Und deshalb existieren entsprechende Lib-Funktionen, die mehr 
als 64KB adressieren können. Nur kann man da nicht "void *" verwenden, 
sonden sollte den dort vereinbarten Datentyp nutzen.

In avr/pgmspace.h gibt es ein paar pgm_read_xxx_far Funktionen, denen 
die Adresse als uint32_t übergeben wird. Damit lassen sich Adressen 
jenseits der ersten 64KB ansprechen.

> Es gibt meines Wissens gcc-Targets, die sowas unterstützen.

Details?

Bislang hiess es immer, dass GCC nicht in der Lage ist, für verschiedene 
Pointer verschiedene Maschinendarstellungen zu verwenden. Das aber ist 
eine Grundvoraussetzung.

kosmonaut pirx wrote:
> ums kurz zu machen: der PC adressiert wörter?
Ja.

EDIT (jetzt wirds doch länger):
Macht ja auch Sinn. Schließlich sind alle AVR-Instruktionen 16 oder 
(seltener) 32 Bit breit. Deshalb wäre ein Byte-Zugriff ziemlich sinnlos. 
Beim Zugriff auf Daten sieht das natürlich anders aus, weshalb der 
(e)lpm-Befehl ja auch ein bisschen "tricksen" muss, um an einzelne Bytes 
heranzukommen.

Wenn du wirklich irritiert werden willst, dann programmier mal 
abwechselnd mit Atmels Assembler und mit dem GNU-Assembler. Atmel zählt 
nämlich im Code konsequenterweise Worte, GAS aber trotzdem Bytes.

Global kannst du alle Pointer einstellen wie du willst, d.h. per 
Compiler-Option von 16bit Pointern auf 32bit Pointer umstellen. Das 
betrifft dann aber alle Pointer. Was nicht geht: einzelne Pointer 
entsprechend kennzeichnen. Das ist die alte wohlbekannte Krux an GCC und 
grösstes Hindernis bei der Portierung auf etliche 
Controller-Architekturen.

Mit C++ bist zu wohl auf dem richtigen Weg, damit lassen sich jene 
generischen Pointer realisieren, wie sie von anderen Compilern für AVR 
oder 8051 implementiert werden. Als Kombination von Adresse und 
Addressraum. Billig ist das allerdings nicht und bei den 
Library-Funktionen wie strxxx und printf hilft das auch nicht weiter, es 
sei denn du implementierst auch diese neu.

Andreas Kaiser wrote:

> Wenn du wirklich irritiert werden willst, dann programmier mal
> abwechselnd mit Atmels Assembler und mit dem GNU-Assembler. Atmel zählt
> nämlich im Code konsequenterweise Worte, GAS aber trotzdem Bytes.

Atmel's Assembler ist da einfach in der eigenen Suppe gewachsen.
Macht niemand sonst, obwohl RISC-CPUs schon seit vielen Jahren
nur Vielfache ihrer Wortgröße adressieren können (und die ist dann
größer als 16 Bits).  Wenn du als Programmierer jedesmal zwischen
Bytes und der jeweiligen Maschinenwortgröße umrechnen darfst,
bekommste doch auf Dauer eine Macke.  Bekommste ja auch beim AVR,
da LPM inkonsequenterweise Bytes adressieren kann...  Meiner
Meinung nach wäre es sinnvoller gewesen, sie hätten LPM dann auch
auf 16-bit-Worten aufgesetzt.  Das gelegentlich mal verplemperte
Byte an Ende eines Strings macht das Kraut nicht fett.

Wie stellst du dir ein solches LPM vor? Als 16bit Ladebefehl? Ok. Dann 
werden aber alle String-Operation *_p deutlich komplizierter, denn wo 
steht geschrieben, dass der String an einer geraden Adresse anfängt.

Bliebe allenfalls die Variante eines Byte-LPM mit Byteauswahl im 
Carr<flag oder so. Auch nicht der Weisheit letzter Schluss.

Die angesprochenen RISCs übrigens arbeiten zwar wortweise, adressieren 
aber durchaus Bytes, anders als AVR im Code. Besseres Beispiel ist Maxim 
MAX2000 (auch sonst lohnend, in dessen Doku mal reinzuschauen). Das ist 
die wohl einzige Mikroprozessorarchitektur jenseits der 70er Jahre, die 
allen Ernstes auch Daten wortweise adressiert. Will man Bytes 
laden/speichern, stellt man das Speicherinterface ad hoc auf 
Byteadressierung um. Da kommt Freude auf, zumal die Adresse eines 
Objektes auch noch davon abhängt, in welchem Speicher der Befehl steht, 
der darauf zugreift.

Andreas Kaiser wrote:

> Wie stellst du dir ein solches LPM vor? Als 16bit Ladebefehl? Ok.

Ja, werden eben als Ziel immer zwei Register geladen.

> Dann
> werden aber alle String-Operation *_p deutlich komplizierter, denn wo
> steht geschrieben, dass der String an einer geraden Adresse anfängt.

Das wäre dann die Bedingung gewesen.  Lässt sich im Compiler einfach
realisieren.  Wie geschrieben, man verplempert mit 50%iger
Wahrscheinlichkeit ein Byte, aber das stört beim ROM eher nicht.

Auch den Rest (Zugriff auf die beiden gelesenen Bytes) kann ein
Compiler einfach erledigen, und das war ja mal die Grundidee hinter
RISC.

Dafür wäre wenigstens die Adressierung konsistent gewesen.

> Das wäre dann die Bedingung gewesen.  Lässt sich im Compiler einfach
> realisieren.

Und was wird aus:

1

char hex[] PROGMEM = "0123456789ABCDEF";

2

pgm_read_byte(&hex[i]);

3

strcpy_p(buf, "unsinn"+(sinn ? 2 : 0));

sizeof(char)==1 per Definition. Geht also nur, wenn pro Wort nur 1 Byte 
gespeichert wird.

Andreas Kaiser wrote:

> Und was wird aus:
>

1

char hex[] PROGMEM = "0123456789ABCDEF";

2

> pgm_read_byte(&hex[i]);

pgm_read_byte() kann es logischerweise nicht geben, wenn die
zu Grunde liegende Maschine das nicht kann.

>

1

strcpy_p(buf, "unsinn"+(sinn ? 2 : 0));

Verboten. ;-)  strcpy_p() ist keine Standard-Funktion, es wäre der
Implementierung also einfach möglich gewesen zu erklären, dass das
Ergebnis nur definiert ist, solange der Parameter ein string
literal ist, das vom Compiler in den Flash gelegt worden ist.

Jörg Wunsch wrote:

> pgm_read_byte() kann es logischerweise nicht geben, wenn die
> zu Grunde liegende Maschine das nicht kann.

Und was ist mit &hex[i]? Wenn es dem Compiler überhaupt noch gestattet 
sein soll, selbst Adressen für Flash-Datenobjekte zu vergeben und zu 
nutzen, dann muss dieser Ausdruck erlaubt sein. Sofern man sich 
einigermassen an den C Kontext halten und keine neue Programmiersprache 
für die Flash-Objekte erfinden will.

Nope. Wenn &hex[i] überhaupt definiert ist, dann ist 1 char = 1 
Flash-Wort, alle Probleme sind gelöst - ausser dem entstehenden 
Platzproblem. Nur diese Variante ist wirklich konsistent.

Wenn es dir dann noch gelingt, im Codeword 2 Bits einzusparen, dann hast 
du einen PIC14 ;-).

> Wenn es dir dann noch gelingt, im Codeword 2 Bits einzusparen, dann hast
> du einen PIC14 ;-).

Ick. ;-)

Ich würde wohl eher das Codewort auf 32 Bits ausdehnen.  Ach nee,
hilft auch nicht, dann hab' ich einen ARM. ;-)

> Doch, wenn man es richtig implementiert schon.

Ich dachte eher an generische Pointer, d.h. 3 Byte für die Adresse, 1 
für den Adressraum (code/data). Das ist schon ein bischen teurer. Das 
wird man bei AVRs aus Platzgründen eher nicht inlinen wollen, und kostet 
damit doch etwas mehr Zeit.