Ansi C; Syntax einer Funktion, die eine ROM-Adresse zurückgibt

BL schrieb:
> Das nimmt der Compiler z.B. nicht.

Wie wäre es mit 'ner Fehlermeldung?

Btw., ANSI-C (oder auch seine deutlich jüngeren ISO-Pendants) haben
keine Idee von RAM, ROM oder sowas.

Jörg W. schrieb:
> BL schrieb:
>> Das nimmt der Compiler z.B. nicht.
>
> Wie wäre es mit 'ner Fehlermeldung?
>
> Btw., ANSI-C (oder auch seine deutlich jüngeren ISO-Pendants) haben
> keine Idee von RAM, ROM oder sowas.

Ich würde sogar meinen, dass das auf die allermeisten 
Programmiersprachen ab der 3. Generation zutrifft.

Das wollte ich jetzt aber nicht groß auswalzen.  Die Fehlermeldung
wäre schon von Interesse, dann kann sich vielleicht auch jemand einen
Reim drauf machen, der den fraglichen Compiler nicht zur Hand hat.

CC8e ist offensichtlich ein Compiler für PIC18?

Nachdem meiner Erinnerung nach das Memory-Layout der PICs - sagen wir 
mal so - eher unkonventionell ist, kann es durchaus sein, daß Du da mit 
Banking fummeln mußt. Wie das geht, sollte eigentlich im Datenblatt 
stehen.

Ich würde mal raten(nachdem die PICs nach meiner Erinnerung - zumindest 
in einem für C einigermaßen brauchbaren Memory-Modell - mit 12 Bit 
Adressen arbeiten), daß der Zeiger 16 Bit haben muß.

An das "uns8 Zeiger" glaube ich aber immer noch nicht. Entweder ist das 
ein blöd gewählter Parametername, oder es ist falsch.

Oliver

Ich denke, das muß

1

const size2 char *text(int index) { return txt[index]; }

(oder so ähnlich) heißen. size2 ist anscheinend ein "type modifier" der 
sagt, daß das ein 16-Bit langer Zeiger sein soll.

aber: das ist alles Mögliche, aber "ANSI C", wie in der Fred-Überschrift 
verlangt, ist das ganz bestimmt nicht ;).

W.S. schrieb:
> Da ist überhaupt nichts unkonventinelles dran, sondern Harvard ist für
> Controllersysteme eigentlich die viel bessere Architektur, weil sie
> Daten und Befehle in getrennten Adreßräumen führt

Sieht man ja prima daran, dass sich ARMs, bei denen alles in einem
Adressraum liegt, partout nirgends durchsetzen konnten.

W.S. schrieb:
> Du bist bloß nicht dran gewöhnt, daß es eben neben der
> v.Neumann-Architektur eben auch noch was Anderes gibt, z.B. Harvard. Da
> ist überhaupt nichts unkonventinelles dran, sondern Harvard ist für
> Controllersysteme eigentlich die viel bessere Architektur, weil sie
> Daten und Befehle in getrennten Adreßräumen führt, was wiederum zu
> beträchtlich einfacherer und damit stromsparender Konstruktion des Chips
> führt.

Jo, da hast Du völlig recht. Daran bin ich nicht gewöhnt.

Will mich aber auch nicht daran gewöhnen.

Muß ich auch - zum Glück - nicht ;).

BL schrieb:
> Der Compiler -ja, für PIC18- frißt es erst mal. Im Controller hab ich's
> noch nicht ausprobiert.

Zwischen "kein Syntaxfehler" und "funktioniert auch" liegen aber Welten.

Wenn Du nicht ins Assemblerlisting schauen willst, kannst Du einfach ein 
Minimalprogramm drumrum schreiben und es in den Simulator laden.

Wenn ich Funktionspointer oder Structs übergeben will, mache ich das 
vorzugsweise mit typedef.

W.S. schrieb:
> Anstatt mal wieder herumzupolemisieren,

Machst du doch auch.

> hättest du besser an die
> Milliarden 8051 denken können.

Ja, Totgesagte leben länger.  Eine moderne Architektur wird es aber
deshalb trotzdem nicht mehr.  Sie waren gut für ihre Zeit.  Die
getrennten Adressräume sind wohl dennoch das, was ein Programmierer
beim Übergang auf eine Architektur mit flachem Adressraum am wenigsten
vermissen wird.