Hallo zusammen. Soeben lese ich folgende Meldung auf http://gcc.gnu.org/: "Red Hat Inc has contributed a port for the Renesas R8C/M16C/M32C families." Hat schon jemand irgendwelche Erfahrungen? Ich werde das auf jeden Fall mal testen.
Nein, aber klingt doch prima. Habe noch ein paar dev-kits samt Controllern aus dem Wettbewerb hier rumliegen...
Hallo , @ Andreas ..kannst du die dev kits mal näher beschreiben. Vielleicht nehm ich dir eins ab ??
@Marko bezieht sich die Meldung auf die Version gcc 4.0.1...mehr steht ja leider nicht dabei .... Oder hast du schon was genaues gefunden ??
Na, was soll man da gross beschreiben? Sind zwei SKP32C84 und ein SKP16C62P. Aber wenn, dann gehen die hier vor Ort weg ;)
Ich habe mal die aktuellen Sourcen über CVS runtergeladen und bin gerade am Compilieren. In der 4.0.1 ist der m32c-Support noch nicht drin. Andreas: definiere vor Ort. ;) Ich wäre scharf auf das SKP32C84, wegen dem DRAM-Controller im M32C.
Aus dem gcc 4.1: /* Target Definitions for R8C/M16C/M32C Copyright (C) 2005 Free Software Foundation, Inc. Contributed by Red Hat. This file is part of GCC. [...] */ und /* There are four CPU series we support, but they basically break down into two families - the R8C/M16C families, with 16 bit address registers and one set of opcodes, and the M32CM/M32C group, with 24 bit address registers and a different set of opcodes. The assembler doesn't care except for which opcode set is needed; the big difference is in the memory maps, which we cover in LIB_SPEC. */
@Andreas Ich nehme das andere SKP32C84.... wenn du einen akzeptablen Preis definierst.
@ Dirk Also Version 4.1 sieht ja gut aus ... es werden also die 16bitter und 32 bitter unterstützt.
Eigentlich erstaunlich, daß der gcc-Port erst jetzt kommt. Renesas als Marktführer, dazu die sehr große und weit verbreitete Familie M16C - und die Architektur kann als Ausrede sicherlich nicht herhalten, für den AVR gibt es den gcc schließlich auch ;)
Wie ist das Adressraumproblem beim M16C gelöst? Immerhin klebt dem GCC der Ruf an, dass er nur eine einzige Pointergrösse kann. Hier also 20bit, wenn man damit auch Flash-Daten adressieren will (und nicht bei beim AVR mit pgm_read_byte Krücken leben will). Aber grad der M16C tut sich damit etwas schwer, 16bit Pointer mag er viel lieber. Ulkigerweise ist der R8C exakt identisch zum M16C hat genau dieses Problem aber nicht. Weil alles in eine 16bit Adressraum passt. Also sollte man eigentlich 3 Varianten erwarten: R8C 16bit-Adressraum. M16C 20bit-Adressraum, M16C/80 und M32C 24bit-Adressraum.
Ich seh schon, pgm_read_byte grüsst alle Freunde des M16C. Und mehr als 64KB Code ist wohl dem M32 vorbehalten. Mehr geht halt in einen 16bit Pointer nicht rein.
Hilfe - welcher Teufel hat Redhat denn da geritten... Wenn ich noch nicht völlig vertrottelt bin, dann ist der indirekte Funktionsaufruf mit Hilfe statischer Daten realisiert (config/m32c/m32c-lib1.S:m32c_jsri16). Komme bloss niemand auf die Idee, in Interrupts indirekte Funktionsaufrufe zu verwenden (was man grad bei Timern gerne macht). Das gibt Zoff, wenn der damit grad einen solche vom Hauptprogramm unterbricht. Leute, stürzt euch lieber nicht gleich drauf, lasst es noch eine Weile reifen. Es ist nötig.
A.K.: schreib doch eine Mail an den Maintainer DJ Delorie (dj@redhat.com), der freut sich bestimmt über Verbesserungsvorschläge. Das ist übrigens der selbe DJ Delorie, auf dessen Konto DJGPP geht. Im übrigen: daß ein 6 Tage alter Port nicht für serienreife Programme taugt sollte wohl klar sein. Trotzdem kann man den Compiler testen und über Bugs berichten, damit diese ausgemerzt werden.
@Dietmar: Ich kam halt auch die Idee, mir den Quellcode anzusehen. Ich weiss nicht, wie die Adressraumproblematik vom Codespace genau angegangen wurde, immerhin liegt das ROM vom M16C jenseits von 64K, aber die Frage zur Grösse der Pointer ist im Code eindeutig beantwortet. Weshalb ich mir auch keinen Weg vorstellen kann, wie beim M16C ein Pointer auf Daten ins ROM zeigen kann. Und an Controllern dieser Grössenordnung ohne transparenten Zugriff auf Daten im ROM kann ich mich nicht recht erfreuen.
@A.K.: Doch Downloads, es gibt regelmäßige snapshots, beispielsweise: ftp://ftp.gwdg.de/pub/misc/gcc/snapshots/
Stimmt !! Was muss man eigentlich alles installieren !! gcc-4.1-20050723.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050723.tar.bz2 C front end and core compiler gcc-ada-4.1-20050723.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050723.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050723.tar.bz2 C++ front end and runtime gcc-java-4.1-20050723.tar.bz2 Java front end and runtime gcc-objc-4.1-20050723.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050723.tar.bz2 The GCC testsuite
> Was muss man eigentlich alles installieren !! (Sollte das nicht ein Fragezeichen statt ein Leerzeichen, gefolgt von zwei Ausrufezeichen werden?) Wenn du nur den C-Compiler brauchst, dann brauchst du nur `core', da C darin enthalten ist. Eventuell kann ja C++ noch Sinn haben, dann bräuchtest du das g++-Modul noch dazu. Die anderen wirst du so erstmal kaum brauchen können, da sie ohnehin mehr oder weniger noch Laufzeitsysteme benötigen, die sicher noch keiner geschrieben hat. (Für den AVR hat mittlerweile jemand gerade mal so Ada in einem sinnvollen Zustand zusammengenagelt.) Damit brauchst du natürlich auf keinen Fall das ``all inclusive'' file.
Es gibt an dieser Stelle nur ein winziges Problem: es gibt noch keine libc, die m32c als Target unterstützt. Die binutils und gcc habe ich schon gebaut. Object files erzeugen geht. Linken geht nicht, da anscheinend die Linker-Scripts noch fehlen. Ist aber nicht so wild, kann man selber schreiben, hier ist ein Beispiel: http://www.embedded.com/2000/0002/0002feat2.htm Lauffähige Programme sollten sich schon mal erstellen lassen. Ich werde am Ball bleiben.
@Jörg danke fuer den Hinweis. Sollte eigentlich ein Fragezeichen sein. Die core Datei werde ich erst mal installieren. Beuntzt ihr eigentlich schon Linux 9.3 ( Suse ) ? Das Ganze lohnt sich aber nur wenn auch die M32Cxx unterstützt werden. @Marko Schön das du am Ball bleibst.
Hallo Marko, habe ich mir mal durchgelesen. DJ Delorie ist aber noch fleissig am basteln. Besonders was die pointerproblematik betrift. So wie er es lösen will ist es doch ok .. oder ?? Muss man halt als Kommandooption mit dazugeben.
@Andreas Hast du noch ein Kit SKP32C84 rumliegen ? Ist dort auch ein Display drauf ?
@Dietmar H: Persönliche Frage: Ich kannte einmal einen Dietmar H, der wohnte in B und spielte V (bei den Preußen). Bist Du zufällig dieser Dieter H? (Der, den ich kannte, befaßte sich nämlich beruflich mit µCs.) Gruß, Michael (Montags, 17Uhr in Lankwitz, genaue Adresse hab' ich vergessen...)
@Micheal, Hallo, für den du mich hälst bin ich leider nicht. Ich hab mal ein Instrument gespielt. Wa r aber nicht V , sindern A wie Akkordeon. Gruß Dietmar
@Dietmar: Schade! Ich meinte übrigens kein Instrument, sondern eine Sportart: Volleyball. Naja, nichts für Ungut! :) Gruß, Michael
Na aber das Weiterleiten gegen eine geringe Aufwandsentschädigung doch sicher nicht, oder?
Hallo A.K., ich habe mir erlaubt, Deinen Beitrag vom 26.07.2005 rudimentär übersetzt an DJ Delorie weiterzuleiten. Hier seine Antwort - Kommentare bitte auf Englisch an ihn ;-) --------------------------------------------- I considered recursion when I wrote that, but not interrupts. Yeah, I suppose if an interrupt happened at just the wrong time, it would be bad. I think it's possible to simply adjust the stack appropriately (in place) and "return" Come to think of it, I could probably do push/push/return in the indirect jump pattern itself and save some overhead. I'd have to review the specs and see if that would work. As for the pointer issue, I had "words" with the gcc crowd about the fact that gcc naively assumes that targets always have just one type of pointer in hardware. Even the i386 has two types! Yet gcc only supports one. I can think of a few tricks to get some read-only data into high memory, but getting gcc to support multiple pointer types in general is a big project.
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.