GCC für M16C!

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.

@Andreas

schon entschieden ??

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.

@ marko

kannst du mal den direkten link zum gcc4.1 download posten ??

@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.

Kein Download. CVS-Zugriff. Per Web: http://gcc.gnu.org/cvs.html

@ A.K. Danke

@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

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.

Mehr Infos: http://gcc.gnu.org/ml/gcc/2005-07/

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

Hi,

das Verkaufen der DEV Kits ist untersagt.

Gruß,

Dirk

@Dietmar:

Schade! Ich meinte übrigens kein Instrument, sondern eine Sportart:
Volleyball. Naja, nichts für Ungut!  :)

Gruß, Michael

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.