Verständnisfrage: Zeiger auf Funktionen (AVR)

Ein indirekter Funktionsaufruf ist ja schon allein syntaktisch
erkennbar. Und vom Typ her auch. Also was bitte soll er da falsch
machen?

Eine andere Sache ist es, abhängig von einem Attribut des Zeigers
unterschiedlichen Code zu generieren. Der Datentyp ist ja der gleiche.
Dazu ist GCC erkennbar nicht in der Lage.

Interssant wird's mit künftigen AVRs mit mehr als 64KW Flash. Denn
dann unterscheiden sich die Zeiger nicht nur im Typ und Attribut,
sondern auch in der Grösse (Data: 16bit, Function: >=24bit). Keine
Ahnung ob dass mit GCC zu machen ist, kann gut sein das AVR-GCC dann am
Ende ist.

Da Zeiger auf Funktionen immer nur Zeiger auf Funktionen sind -also
immer nur auf den Codespeicher verweisen-, geht der Compiler
folgerichtig immer von Codezugriffen aus. Die Bestimmung der Adresse
einer Funktion liefert einen Zeiger auf Codespeicher, das
Dereferenzieren eines solchen Zeigers (sprich: Aufrufen einer Funktion)
wird auch im Codespeicher ausgeführt. Da sehe ich keine Probleme mit der
Harvard-Architektur.

Selbst eine Erweiterung des Adressraumes auf 24 Bit dürfte eigentlich
keine Probleme bereiten; der Compiler müsste dann "nur" darauf
vorbereitet werden, Codezeiger als 24- oder 32-Bit-Variablen zu
behandeln.
Wie einfach das ist und ob man gcc überhaupt dergestalt verbiegen kann,
das steht auf einem ganz anderen Blatt.

Wer weiß, vielleicht wird Atmel ja bei AVRs mit mehr als 128 KByte
Flash-ROM auch einen Banking-Mechanismus implementieren.

Mittlerweile gibt es ja sogar AVR-Varianten, die Code im RAM ablegen
können (mit einem Mapping-Mechanismus kann die Aufgabe von
Speicherblöcken umdefiniert werden) - AT76C712 ist so ein Kandidat.

Das ist überhaupt ein hochgradig interessanter Prozessor - einerseits,
weil er mit einem USB-Device-Controller ausgestattet ist, andererseits,
weil er vollständig ohne Flash- oder sonstiges ROM auskommt. Ein fest
eingebauter Bootloader lädt Firmware aus einem externen seriellen
EEPROM oder wahlweise auch per USB - genauso, wie es die
Ez-USB-Controller von Cypress machen.

Aufgrund dieser RAM-Architektur kann der (interne) Prozessortakt auf 48
MHz erhöht werden, etwas, was bei Flash-ROMs aufgrund deren relativ
langsamen Zugriffen nicht möglich war.

Bevor ich weiter ins Schwärmen komme - seht Euch einfach selbst das
Datenblatt an:
http://www.atmel.com/dyn/products/product_card.asp?part_id=3579

Wie Atmel mit >128KB umgeht ist doch schon längst definiert. Direkten
JMP/CALLs geht erst jenseits von 8MB die Luft aus, und indirekte
belegen auf dem Stack 3 Bytes. Soviel zu den Zeigern auf Funktionen.
Die werden halt grösser.

Und Daten im ROM werden heute schon in Banks adressiert, wenn's 128KB
ROM sind und man dusselig genug ist, in die oberen 64KB Daten
reinzupacken.

Nichts neues also. Neues ist also nur seitens der Compiler zu erwarten.

Das Problem ist, dass GCC wohl derzeit noch keine Variante hat, mit
24-bit-Zeigern umzugehen.  Ein Aufblähen auf 32-bit-Zeiger wäre nicht
so toll...

@ Rufus T. Firefly:
Zum Thema AT76C712:
Du schwärmst zwar von diesem Prozessor, aber der Programmspeicher, auch
wenn es RAM ist, wird ja immernoch anders adressiert als das Daten-RAM,
oder?

Sicher, an der Harvard-Architektur selbst ändert sich nichts. Das ist
halt eine der Kerneigenschaften der AVRs.
Ein Prozessor mit ähnlichem Aufbau, aber einem ARM7-Kern, dafür könnte
ich mich erst recht erwärmen.