Hallo, sollte man auf 32bit uc's mit genügend flash und ram eher mit c oder mit c++ programmieren? Frage zielt auf guten Programmierstil ab.
Solche Fragen zielen immer auf Glaubenskriege ab. "Am besten" ist meistens einfach die Sprache die du beherrscht. Popkorn rausholen und abwarten :-)
Wasnun schrieb: > Frage zielt auf guten Programmierstil ab. Du kannst saubere C Programme schreiben und C++ Programme, die schlimmer aussehen als Basicprogramme auf einem C64. Was du nimmst hängt davon ab was du kannst und für was du an leistungsfähigen Compiler/Build Tools, Entwicklungsumgebungen und Debugger oder Emulatoren bekommst. Wichtiger ist es sauber zu programmieren, also wenn objektorientiert dann richtig, und nicht prozedural mit eingesteuten Objekten und Zugriff auf hunderte in Objekten verteilten public deklarierten quasi globalen Variablen. Lernen kann man das nur duch Übung, Review von guten Programmierern und dem Lesen und verstehen entsprechender Literatur. Viel Spass
Wie schon erwähnt geht beides, aber mit C++ kann man schneller und sauberer vorankommen (muß aber natürlich nicht). Wenn man es kann... SW ab einer bestimmten Größe wird heute keiner mehr in C machen, wenn C++ auch irgendwie geht.
Klaus Wachtler schrieb: > SW ab einer bestimmten Größe wird heute keiner mehr in C machen, wenn > C++ auch irgendwie geht. Den Linux Kernel würde ich schon als grosse software ansehen.
Klaus Wachtler schrieb: > Würde man den heute noch komplett in C machen? Wenn es nach Linus Torvalds geht, der da ein bisschen :-) mitzureden hat: Ja. http://kerneltrap.org/node/2067
Vermutlich ja. Der Kernel von MacOS X wurde z.B. auch in C geschrieben. Und mir würde auch kein anderer moderner Kernel einfallen, der nicht in C geschrieben ist.
Mark Brandis schrieb: > Klaus Wachtler schrieb: >> Würde man den heute noch komplett in C machen? > > Wenn es nach Linus Torvalds geht, der da ein bisschen :-) mitzureden > hat: Ja. > > http://kerneltrap.org/node/2067
1 | "In fact, in Linux we did try C++ once already, back in 1992. It sucks. |
2 | Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. |
3 | |
4 | The fact is, C++ compilers are not trustworthy. They were even worse |
5 | in 1992, but some fundamental facts haven't changed: |
6 | 1) the whole C++ exception handling thing is fundamentally broken. It's |
7 | _especially_ broken for kernels. |
8 | 2) any compiler or language that likes to hide things like memory |
9 | allocations behind your back just isn't a good choice for a kernel. |
10 | 3) you can write object-oriented code (useful for filesystems etc) in C, |
11 | _without_ the crap that is C++." |
ganz ehrlich: überzeugt mich jetzt nicht besonders. Mit den Exceptions mag er recht haben - aber auch die muss man ja nicht benutzen. Wenn im Kernel keine Exception geworfen wird, dann tritt auch keine auf. Und die Sache mit der Memory Allocation: Noch jeder, der behauptet hat, dass Memory Allocation in C++ ein Problem wäre - nun ja - der hatte in C erst recht massive Probleme das hinzukriegen. Also das ist mit Sicherheit kein Argument. Memory Allocation ist in C++ genauso transparent wie sie es in C ist. Nur dass man die Problemstellen nicht über den halben Source Code verstreut, sondern in der jeweiligen Klasse unter Kontrolle hält. Linus Torvalds ist sicher kein schlechter Programmierer. Er ist aber auch nicht die Autorität, deren Argumentationen ich unbesehen akzeptieren würde.
ich finde diese zeile interessant wie grausam:
1 | 3) you can write object-oriented code (useful for filesystems etc) in C, |
2 | _without_ the crap that is C++." |
für mich ist die C++ nachahme in C der totale CRAP was soll dr mist ? warum muss der C Programmierer beweisen das es in C auch geht .. zwar auf total krankem wege .. aber er kann sagen das es geht kenne da einige Projekte .. ( OS , Treiber usw .. ) die auf Objekten basieren ... es liest sich nicht nur total bescheuert .. es programmiert sich auch so sorry das ist meine meinung ... und auf die frage ... naja also ich selbst würde C bevorzugen ... kann mich aber auch täuschen
> 2) any compiler or language that likes to hide things like memory > allocations behind your back just isn't a good choice for a kernel. Damit hat er Recht. Aber ich verstehe nicht ganz, warum das in C++ der Fall sein sollte.
Ich denke, es sind zwei unterschiedliche Fragestellungen zu beantworten. Einmal die Frage nach dem zu verwendenden Compiler. Und dann wohl die wesentlich größere Frage nach den Spracheigenschaften die im jeweiligen Projekt auch Sinn ergeben. Es ist durchaus möglich einen C++ Compiler zu verwenden und reinen C Code zu schreiben. Genau so würde das natürlich nur Sinn ergeben, wenn der vom C++ Compiler erzeugte Code dem C Compiler überlegen wäre. Beim GCC würde ich jedoch davon ausgehen, daß dies nicht oder in zu vernachlässigendem Umfang der Fall ist. Ich kenne aber den Fall, daß der, für die Plattform verfügbare, C Compiler ein ungeliebtes Steinzeitmonster war. Der C++ Compiler hingegen wurde aktiv entwickelt. Dort ist es ein C Projekt geblieben, nur eben der C++ Compiler verwendet. Wer jedoch einen C++ Compiler für sein C Projekt einsetzt, kann einzelne Sprachelemente aus C++ übernehmen. Welche im einzelnen Sinn ergeben, würde wohl den Rahmen hier sprengen. Einfach Template Funktionen können sehr komfortabel sein. Ich selber verwende gerne (trivial!) überladene Funktionen. Nicht selten zu sehen in C Projekten ist der Fall, daß zusammengehörige Daten in einer Struktur gehalten werden und sämtliche Funktionen des Moduls als jeweils ersten Parameter einen Zeiger auf diese Struktur verwenden. Das sind bereits objektorientierte Elemente, die in der C Programmierung eingesetzt werden. Und letztentlich besteht kein Unterschied zwischen einem Funktionsaufruf mit Parameter und einer Methode, welche über ein Objekt aufgerufen wird. Wer sich den generierten Assembler Code ansieht, kann mitunter sehen, daß Funktion und Aufruf beider Varianten (C und C++) in identischem Code resultieren. Von Spracheigenschaften wie Exceptions oder RTTI würde ich vorerst Abstand nehmen. Auch auf Laufzeitelemente wie std::string oder Streams im allgemeinen würde ich verzichten, bis die ersten Projekterfahrungen mit dem neuen Compiler gesammelt sind. Die Sprache C ist eine hervorragende Entwicklung, jedoch nicht der Weisheit letzter Schluß. Ich kann mich noch an die Diskussionen erinnern, wie unfähig Entwickler sein müssen, um auf die Idee zu kommen, C auf einem Mikrocontroller einzusetzen... Assembler wäre die einzig sinnvolle Möglichkeit. Assembler wurde natürlich nicht ersetzt. Aber der Anteil im MC Bereich doch deutlich reduziert. Auch ist der Schritt von Assembler zu C wesentlich größer als von C zu C++ - meiner Empfindung nach. Aber einmal wieder sollten wir uns der Frage stellen, mit welchen Spracheigenschaften wir unsere Systeme verständlicher, sicherer und schneller beschreiben können. Und hier kann C++ einige Elemente beisteuern. Um nun aber die eigentliche Frage zu beantworten - den guten Programmierstil würde ich nicht in der Sprache, sondern der Sorgfalt und Überlegung suchen, mit welcher Problemlösungen formuliert und dokumentiert werden. Wer einen schlechten Programmierstil in C pflegt, wird diesen aller Wahrscheinlichkeit nach in C++ übernehmen.
@Clown
Full Ack.
In allen Punkten.
> Und hier kann C++ einige Elemente beisteuern.
Inheritance/Polymorphie und virtuelle Funktionen fallen mir da auf
Anhieb ein, sowie sichere Initialisierung durch Konstruktoren.
Selbst wenn man sonst nichts von C++ nutzt, das alleine wäre es schon
wert. Klar: virtuelle Funktionen kann man auch in C mit
Funktionspointern nachbilden. Aber wenn der Compiler das macht, ist es
einfach sicherer. Und letzten Endes kann man das natürlich von jedem
Sprachelement sagen: Klar kann man alles auch in C machen und
nachbilden. Wer masochistisch genug ist, kann das auch in Assembler
machen. Ach was red ich: direkte Opcodes in Hex hinschreiben!
Ich habe die TI Microcontroller 28xx in C++ programmiert. Man muss nicht die ganzen Features wie Überladen oder virtuelle Funktionen benutzt. Aber normale Klassen sind angenehmer als struct's. Und Member-Funktionen tragen auch zu mehr Struktur bei, als wenn immer ein struct-Pointer mit übergeben wird. Sauberer und lesbarer wird das Programm meistens schon.
Ich würde mich für C entscheiden. Grund: Erweiterungen aus ISO/IEC DTR 1803 wie z.B: • Fixed point support • Saturierende Arithmetik • Named address spaces sind nur als C-Erweiterung beschrieben und z.B. in GCC auch nur als solche verfügabr.
Wasnun schrieb: > sollte man auf 32bit uc's mit genügend flash und ram eher mit c oder mit > c++ programmieren? > > Frage zielt auf guten Programmierstil ab. Kann C irgendwas, was C++ nicht kann? Warum dann auf die Vorteile von C++ verzichten? Ob man dann funktional oder objektorientiert entwickelt, haengt weniger von der Sprache, als vom Problem ab, was geloest werden soll.
Karl Heinz Buchegger schrieb: > Linus Torvalds ist sicher kein schlechter Programmierer. Wie kannst du dir da sicher sein? Er hat eine lange Karriere im Produzieren von unsinnigen Statements, die jedem erfahrenen Entwickler die Schamesroete in's Gesicht treiben. Die legendaere Debatte mit Tanenbaum ist nur der Anfang dieser Kette, das hier gepostete ein weitere Glied. Genauso koennte man behaupten, Steve Jobs oder Bill Gates seien sicher keine schlechten Programmierer (gewesen).
Udo Schmitt schrieb: > Du kannst saubere C Programme schreiben und C++ Programme, die schlimmer > aussehen als Basicprogramme auf einem C64. Ich protestigere :-) Selbst in BASIC auf dem C64 hab ich sauber mit GOSUB und RETURN gearbeitet **lacht**
xXx schrieb: > Karl Heinz Buchegger schrieb: >> Linus Torvalds ist sicher kein schlechter Programmierer. > > Wie kannst du dir da sicher sein? Bin ich nicht. Ich wollte ihm gegenüber nur höflich sein und ihm nicht aufgrund dieser Aussage generelle Inkompetenz unterstellen, die ich nicht belegen kann und von der ich auch keine Lust habe, sie durch Recherche zu belegen. Dass er programmieren kann, hat er belegt. Wie gut er das kann, kann ich ... ähm ... nicht wirklich beurteilen. ALso: Im Zweifel für den Angeklagten. > die Schamesroete in's Gesicht treiben. Die legendaere Debatte mit > Tanenbaum ist nur der Anfang dieser Kette -> neugierig gemacht.
xXx schrieb: > Die legendaere Debatte mit Tanenbaum ist nur der Anfang dieser Kette, > das hier gepostete ein weitere Glied. Nur hat die mit der Diskussion über Programmiersprachen eher wenig, dafür mit Software-Architektur um so mehr zu tun. Auch MINIX ist in C geschrieben. Karl Heinz Buchegger schrieb: > -> neugierig gemacht. Zum Nachlesen: http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
Clown schrieb: > Auch ist der Schritt von Assembler zu C wesentlich > größer als von C zu C++ - meiner Empfindung nach. Aber einmal > wieder sollten wir uns der Frage stellen, mit welchen > Spracheigenschaften wir unsere Systeme verständlicher, sicherer und > schneller beschreiben können. Und hier kann C++ einige Elemente > beisteuern. Wie sieht's denn mit Objective-C aus? Im Gegensatz zu C++ ist das eine Obermenge von C, und ein C-Projekt ist ohne jedgliches Anfassen der Quelle auch als Objective-C übersetzbar. Objective-C wird zB von GCC unterstützt und einige populäre Distributionen wie WinAVR-20100110 bringen auch einen Objective-C Compiler für AVR mit. Einem barrierefreien Einstieg in die OO-Welt steht also nichts im Wege.
Würde denn irgendwer in Objective C programmieren, wenn Apple es nicht aus der Versenkung geholt hätte?
> 3) you can write object-oriented code (useful for filesystems etc) in C, > without the crap that is C++." Ist halt manchmal arg emotional und impulsiv :-) Clown schrieb: > Es ist durchaus möglich einen C++ Compiler zu verwenden und reinen C > Code zu schreiben. Genau so würde das natürlich nur Sinn ergeben, wenn > der vom C++ Compiler erzeugte Code dem C Compiler überlegen wäre. Beim > GCC würde ich jedoch davon ausgehen, daß dies nicht oder in zu > vernachlässigendem Umfang der Fall ist. Ich mag geprüfte enums in C++. In Verbindung mit const kann das die Codegröße von switch/case ziemlich eindampfen. PittyJ schrieb: > Aber normale Klassen sind angenehmer als struct's. > Und Member-Funktionen tragen auch zu mehr Struktur bei, als wenn immer > ein struct-Pointer mit übergeben wird. > Sauberer und lesbarer wird das Programm meistens schon. Ja, das will ich auch nicht mehr missen. Johann L. schrieb: > • Fixed point support > • Saturierende Arithmetik > • Named address spaces Bildet der GCC die beiden ersten Punkte im Falle einer vorhandenen FPU auch darauf ab? Wofür benötigt man den letzten Punkt?
Roland H. schrieb: >> • Named address spaces > Wofür benötigt man den letzten Punkt? Viele 8- oder 16-Bit Mikrocontroller haben mehrere Adressräume. Etwa AVR mit Flash/RAM/EEPROM oder M16C mit 64K/1M, die seitens der Maschine verschieden angesprochen werden müssen und daher eine entsprechende Attributierung der Adressen und Pointer erfordern. Bislang kam GCC damit nicht zurecht, wie jeder weiss, der sich auf AVRs mit pgm_read_xxx() rumplagen musste. Andere Compiler hatten jeder für sich eine eigene Erweiterung dafür.
Roland H. schrieb: > Johann L. schrieb: >> • Fixed point support >> • Saturierende Arithmetik > > Bildet der GCC die beiden ersten Punkte im Falle einer vorhandenen FPU > auch darauf ab? Das kommt auf die Implementierung an. Gesehen hab ich bislang nur eine Implementierung für AVR, und die muss mangels FPU alles per Hand, also in Software, machen. Oder ist FPU "Fixed-Point Unit"? Genrell stell ich mir eine Abbildung auf FPU nicht trivial vor, da bei Fixed-Point die Ergebnisse Bitgenau sein müssen aber bei float gerundet werden darf. Und Saturierung in FPUs? A. K. schrieb: > Roland H. schrieb: > >>> • Named address spaces >> Wofür benötigt man den letzten Punkt? > > [...] mehrere Adressräume[...], die seitens der Maschine > verschieden angesprochen werden müssen und daher eine entsprechende > Attributierung der Adressen und Pointer erfordern. ^^^^^^^^^^^^^^ Attribute wie PROGMEM tun es eben nicht, wie brauchet es einen Qualifier, alto etwa auf der gleichen Ebene wie volatile oder const.
Johann L. schrieb: > Attribute wie PROGMEM tun es eben nicht, wie brauchet es einen > Qualifier, alto etwa auf der gleichen Ebene wie volatile oder const. Stimmt, das war schlecht ausgedrückt. Der Begriff "Attributierung" war von mir allerdings allgemeinsprachlich gemeint, bezog sich nicht auf den gleichnamigen Begriff von GCC.
Roland H. schrieb: >> • Fixed point support >> • Saturierende Arithmetik >> • Named address spaces > > Bildet der GCC die beiden ersten Punkte im Falle einer vorhandenen FPU > auch darauf ab? Eher nicht. Beide haben mit Gleitkomma nichts zu tun und haben daher auf einer FPU nichts zu suchen.
Wann wird endlich verstanden das eine Programmiersprache nur ein Mittel zum Zweck ist? Wann welche Programmiersprache eingesetzt wird hängt vor allem mit der Situation zusammen. So ist für Hardwarenahe Programmierung Assembler und C mit Sicherheit vorne dabei. Hingegen sind bei "normalen" Computeranwendungen Java und C++ besser geeignet. Um hier nur ein paar Sprachen zu nennen. Folgende Kriterien sind ausschlaggebend: # Hardwarenahe Programmierung oder Anwendungen # Meine eigenen Programmierkenntnisse # Von der Größe des Projektes # Bei Verwendung von GUIs (Welche Sprache kann für X verwendet werden) # Geschwindigkeit des Programmes # Fehleranfälligkeit in der Programmierung # Schnelligkeit der Fertigstellung # Sicheres Programmieren ( Speicherüberlauf ) # und und und
Michael schrieb: > So ist für Hardwarenahe Programmierung Assembler und C mit Sicherheit > vorne dabei. Hingegen sind bei "normalen" Computeranwendungen Java und > C++ besser geeignet. Um hier nur ein paar Sprachen zu nennen. Wann wird eine "hardwarenahe" Anwendung zu einer "normalen" Anwendung? Je grösser eine Controller-Anwendung wird, desto geringer ist der Anteil des direkt hardwarebezogenen Teils. So ist der Ethernet-Treiber eines Netzwerkstacks zweifellos hardwarenah. Ist es der TCP/IP-Stack auch noch? Ebenso ist der Treiber für ein Grafik-LCD hardwarenah, aber gilt das auch noch für höhere Grafikfunktionen wie Kurven, Fonts, etc? Genauso gilt das für den Rest vom Code. Wenn der sauber strukturiert wird, die direkt hardwarebezogenen Teile also entsprechend gekapselt werden, dann bestehen viele nicht allzu kleinen Controller-Anwendungen effektiv aus einem hardwarnahen und einem "normalen" Teil und nur letzterer wächst mit der Komplexität der Aufgabe. Ein klarer Sprung besteht nur bei der Separierung dieser beiden Teile in Form eines Betriebssystems, bzw. darin dessen HALs, soweit als eigene Komponente existent. Der Charme von C++ bei Mikrocontrollern besteht gerade darin, dass man für den hardwarenahen Teil einer Anwendungen keinen Sprachenbruch benötigt. Man kann sich in der Programmiertechnik dem anpassen, indem man in den unteren Layern entsprechend eingeschränktes also "C nahes" C++ verwendet.
>>> • Fixed point support >>> • Saturierende Arithmetik >>> • Named address spaces >> >> Bildet der GCC die beiden ersten Punkte im Falle einer vorhandenen FPU >> auch darauf ab? > > Eher nicht. Beide haben mit Gleitkomma nichts zu tun und haben daher auf > einer FPU nichts zu suchen. Hatte ich mich verlesen. Die Befehle für die "Saturierende Arithmetik" zählen nicht zur FPU, zumindest nicht beim CM4. Fixed point ist beim CM4 auch "nur" in der CMSIS DSP Library, allerdings auf dem CM4 angeblich doppelt so schnell wie auf CM3 (vielleicht weiss jemand, weshalb das so ist?). Wie dem auch sei, um auf die Frage des Threads zurückzukommen, mit Berücksichtigung der drei oben genannten Erweiterungen: Wenn ich die Wahl hätte, würde ich C++ auf CM3 nehmen. Wenn DSP/Fixed point etc. nötig ist, ginge das dann mit CM3 oder CM4, immerhin portabel zwischen den ARMs. PROGMEM wird mit "named address spaces" auch nicht wirklich schöner :-) Die "allgemeine" Begründung findet sich im vorigen Posting von A. K. Mit C++ verbaut man sich nichts, und es hat genug "Luft nach oben".
Roland H. schrieb: > Hatte ich mich verlesen. Die Befehle für die "Saturierende Arithmetik" > zählen nicht zur FPU, zumindest nicht beim CM4. Gegen welche Grenze will man bei FP auch sättigen? 3.4E38? > Fixed point ist beim CM4 auch "nur" in der CMSIS DSP Library, allerdings > auf dem CM4 angeblich doppelt so schnell wie auf CM3 (vielleicht weiss > jemand, weshalb das so ist?). Weil mit der SIMD Einheit zwei Q15 Zahlen gleichzeitig verarbeitet werden können. Nur ist nicht jede fixed point Rechnung in Q15... -- Marcus
> Viele 8- oder 16-Bit Mikrocontroller haben mehrere Adressräume. > Etwa AVR mit Flash/RAM/EEPROM oder M16C mit 64K/1M, die > seitens der Maschine verschieden angesprochen werden müssen > und daher eine entsprechende Attributierung der Adressen und > Pointer erfordern. Der M16C hat nur einen Adressraum. Was man schoen daran merkt das man einfach ueber Pointer auf Flash und Ram zugreifen kann und auch Code im Ram ausfuehren kann. Er hat aber 16Bit und 24Bit Pointer. Mit 24Bit Pointer kommt wohl der gcc nicht klar und verwendet dann 32Bit Pointer und das ist sehr viel langsamer. Deshalb haben bisherige gcc Versionen mit 16Bit Pointern gearbeitet und es gibt einen Bereich im Ram wo Spruenge auf den 24Bit Bereich liegen. Das hat den Nachteil das jede Funktion 4Byte im Ram benoetigt. Aber soweit ist weiss hat DJGPP da was in den allerneuesten Enwicklerversionen des gcc gebastelt um diese Problematik zu umgehen. Olaf
Olaf schrieb: > Der M16C hat nur einen Adressraum. Ich würde es im hier betrachteten Sinn als 2 Adressräume bezeichnen, von dem einer in den anderen eingebettet ist. Aber wie immer man das nennt, auch der M16C wird diesen Mechanismus gut gebrauchen können.
Olaf schrieb: > Deshalb haben bisherige gcc Versionen mit 16Bit Pointern gearbeitet und > es gibt einen Bereich im Ram wo Spruenge auf den 24Bit Bereich liegen. > Das hat den Nachteil das jede Funktion 4Byte im Ram benoetigt. Wird das wirklich so realisiert? Ich kann mir ein effizienteres Speichermodell vorstellen, bei dem nur sämtliche indirekt genutzten Einsprungstellen betrachtet werden müssen, und deren Sprungleiste innerhalb eines 64KB Fensters im ROM liegt. RAM wird in diesem Modell nicht dafür verschwendet. Soweit ich mit erinnere wird dieses Modell bei den AVRs mit mehr als 64KW/128KB Flash verwendet, die ja ein recht ähnliches Problem haben.
> Wird das wirklich so realisiert? Oh ja. Ich bin darauf gestossen als ich mir einen Multitasker geschrieben habe. Irgendwann fragt man sich dann, hey wieso ist ein Pointer nur 16Bit gross und wie soll ich damit ins Flashrom kommen das ja am oberen Ende des 1Mbyte Adressraums liegt. > Ich kann mir ein effizienteres > Speichermodell vorstellen, bei dem nur sämtliche indirekt genutzten > Einsprungstellen betrachtet werden müssen, und deren Sprungleiste > innerhalb eines 64KB Fensters im ROM liegt. Dann muesstest du aber die Basisadresse fuer die 16Bit Pointer auf deinen Rombereich verschieben koennen und das ist IMHO nicht moeglich. > RAM wird in diesem Modell nicht dafür verschwendet. Ein paar Byte fuer die Funktionsaufrufe sind eigentlich kein Problem zumal die M16C ja relativ viel Ram haben. Aber das ganze hat noch einen anderen Haken der viel schlimmer ist. Rate doch mal was der Compiler aus soetwas macht: const unsigned char char5x7[480] ={ [..] } Er packt diese Konstante in eine eigene Read-Only Section. (gut) Und sie wird dann beim start des Programms ins Ram kopiert. (argh!) Anders kommt der Compiler mit seinen 16Bit Pointer nicht dran. Die Alternative waere wohl die eklige AVR Loesung, das man nur mit speziellen Funktionen an seine Daten kommt. Sowas ist sicher schnell eingebaut, aber das war einer der Gruende warum ich irgendwann von den AVRs weg bin. Aber wie schon angedeutet, ich meine djdelorie hat mir gesagt das er bei der aktuellesten gcc Version da was eingebaut hat, oder das es dafuer einen Patch gibt. Ich habs aber selber noch nicht ausprobiert weil ich die aktuelle Entwicklerversion des gccs hier nicht uebersetzt bekomme und mir das Problem noch nicht wichtig genug war um mein System komplett rundzuerneuern. Und ich weiss auch nicht auf welchem Stand die Compiler von kpit sind. > Soweit ich mit erinnere wird dieses Modell bei den AVRs mit mehr als > 64KW/128KB Flash verwendet, die ja ein recht ähnliches Problem haben. Die optimale Loesung fuer den gcc waere wohl die Einfuehrung von far/near weil die Renesascompiler so arbeiten und man dann kompatible waere. Aber natuerlich kann Kompatiblitaet zu einem Firmenstandard kein Entwicklungsziel fuer den gcc sein. :-) Olaf
Olaf schrieb: > Dann muesstest du aber die Basisadresse fuer die 16Bit Pointer auf > deinen Rombereich verschieben koennen und das ist IMHO nicht moeglich. Aber natürlich geht das. Ziemlich unabhängig vom Prozessor kann man bei Architekturen mit Callstack im RAM immer so indirekt springen: push.w pointer push.b #page rts aber in diesem Fall tut es auch mov a1,#page jsri.a a1a0 und springt so auf eine Sprungleiste im ROM. Wenn man Compiler und binutils so dressiert, dass die indirekt verwendbare Adresse einer Funktion immer die Adresse eines Pointers auf diese Funktion in einer Sprungtabelle im ROM ist, dann geht sogar jsri.a table[a0] Getrennte Adressräume für Code und Daten waren in C noch nie ein Problem, deren Verwendung kann der Compiler auseinander halten. Das wurde auch bereits auf den PDP-11 Prozessoren aus der Kindheit von C praktiziert. Nur mussten die Pointer im GCC bisher gleich gross sein. > Aber wie schon angedeutet, ich meine djdelorie hat mir gesagt das er bei > der aktuellesten gcc Version da was eingebaut hat, Habs in der Doku vom GCC 4.6 gesehen. __far für Pointer jenseits der 64KB.
> push.w pointer > push.b #page Aber das impliziert das es eine direkte zuordnung zwischen pointer1+page1 und pointer2+page2 gibt weil sonster pointer1+konstante nicht mehr funktionieren wird wenn page1 unterschiedliche Werte annehmen kann. Damit ist man dann aber bei echten 24bit Pointern. Die sind ja nicht unmoeglich, nur habt man sich wohl mal dagegen entschieden weil den Code kompliziert und langsam gemacht haetten. Ausserdem, es braucht doch niemals jemand mehr als 64kByte. :-D Olaf
Olaf schrieb: > Aber das impliziert das es eine direkte zuordnung zwischen > pointer1+page1 und pointer2+page2 gibt weil sonster pointer1+konstante > nicht mehr funktionieren wird wenn page1 unterschiedliche Werte annehmen > kann. Natürlich muss diese Sprungleiste komplett in einer 64KB Page liegen. Das kriegt man aber problemlos gebacken. Man muss nur dafür sorgen, dass sie in einer eigenen Section liegt, die per Linker-Script im ROM vorneweg landet, Code etc. dahinter. Ich würde allerdings die andere Variante favorisieren, mit Sprungtabelle.
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.