NKC Forum
Registrieren | FAQ | Suche | Wer ist online? | Mitgliederliste | Heutige Beiträge | Einloggen



Autor Thema: Projekt C-Crosscompiler
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 01. Juni 2022 19:30 (#21)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,
ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC
Damit hab ich auch schon erfolgreich einige Jados-Programme geschrieben. Zwei davon (Dhrystone-benchmark und 4-gewinnt Spiel) sind im Source dabei.

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
cerker68k
Kennt sich schon aus
**
ID # 219


  Erstellt am 01. Juni 2022 21:28 (#22)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Zitat von Torsten:
Hi,

sollte mit allen CPUs laufen.
-> Setting 'CPU' in Makefile.rules

Habe allerdings lange nix mehr an der LIB geschraubt, evtl. gehts ja dieses Jahr mal weiter.

LG
Torsten



Bei 68008 wirft er mir in der Ursprungsversion einen Haufen Fehler, erstmal weil er versucht den GCC mit -m68008 aufzurufen, was natürlich nix ist.

Wenn ich das korrigiere und auch die ganzen #ifdefs anpasse, kompiliert er, aber wirft mir immer wieder "ADRESS FEHLER" weil offenbar öfter versucht mit Word- und Langwortzugriffen auf ungerade Adressen zu gehen. Warum versuche ich gerade rauszufinden.

Nach meinem Gefühl gerne im Bereich der Debugausgaben. Vermutlich hat nur ein Makro ein Problem. Vielleicht sind es auch meine 68008 "Fixes" die was versaut haben ;)

Ich hab das Repo mal geforked und spiele etwas damit.
(Bin gestern um 1 ins Bett gekommen, heute muss ich früher, brr)

Ich hab die Änderungen mal in den Fork gepushed:
https://github.com/cerker68k/NKC-CLIB

Vermutlich sind ein paar von den LEA32A0 etc. auch überflüssig. Wenn ich CONFIG_DEBUG_MM anschalte, kackt er im dbg_walk_heap ab .. und zwar an der Stelle wo er "FREE" anzeigen sollte.


void dbg_walk_heap(void)
{
struct block_header *location = (struct block_header*)_HEAP;
int i = 0;
int j = 0;

mm_lldbg("\n memory map: \n\n");

//mm_lldbg(" Block No. Start Size Free Next Hdr\n\n");

while(location != 0)
{
while(location != 0 && i < 5)
{
mm_lldbghex(" BLOCK-NR = 0x",j);
mm_lldbghex(" FREE = 0x",location->free);
mm_lldbghex(" START = 0x",location->start);
mm_lldbghex(" SIZE = 0x",location->size);
mm_lldbghex(" NEXT = 0x",location->next);

location = (struct block_header*)location->next;

i++; j++;
};
i=0;
};

}


Im mm_lldbghex und offenbar passiert es beim dereferenzieren von location->free .. obwohl location ja auf _HEAP stehen sollte und _HEAP zuvor, mit mm_lldbghex, korrekt angezeigt wird. In D0 und A0 steht dann übrigens die gleiche ungerade Zahl .. die auch auf nichts sinnvolles zeigt.


serial debugging enabled
mm_init
_RAM_TOP = 0x000C63FE
_HEAP = 0x000353C8
_ram_size = 0x00091036

memory map:

BLOCK-NR = 0x00000000
FREE = 0x


Zitat:

Hallo,
ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC



Auch mal anschauen...

Gruß,
Christian

Beiträge: 71 | Mitglied seit: Oktober 2021 | IP-Adresse: nicht gespeichert
cerker68k
Kennt sich schon aus
**
ID # 219


  Erstellt am 02. Juni 2022 07:12 (#23)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ich habe nochmal schnell das "j" hinter "BLOCK..." durch location ersetzt, um zu sehen ob der Pointer richtig ist.

Er ist es, steht auf Heap und ....C ist auch gerade. Warum kommt dann bei "location->free" Mist raus.


serial debugging enabled
mm_init
_RAM_TOP = 0x000C63FE
_HEAP = 0x00054B7C
_ram_size = 0x00071882

memory map:

BLOCK-NR = 0x00054B7C
FREE = 0x


Im Fehlerscreen sind D0 und A0 beide auf 0x221F4E75, das ganze auf 0xF702 im Code (habe das Shell-Demoprojekt probiert) was laut mapfile in mm_free/dbg_walk_heap liegt. Mit Disassembly an folgender Instruktion:


542 0624 4E56 FFF4 link.w %fp,#-12
543 0628 2039 0000 move.l _HEAP,%d0
543 0000
544 062e 2D40 FFFC move.l %d0,-4(%fp)

.. hier klappt alles ..

560 0672 588F addq.l #4,%sp
561 0674 4879 0000 pea .LC24
561 0000
562 067a 4EB9 0000 jsr nkc_ser1_write
562 0000
563 0680 588F addq.l #4,%sp
564 0682 202E FFFC move.l -4(%fp),%d0
565 0686 2040 move.l %d0,%a0
** 566 0688 2028 000C move.l 12(%a0),%d0 **
567 068c 2F00 move.l %d0,-(%sp)
568 068e 4EB9 0000 jsr gp_ser1_write_hex8


Die 2 vorgehenden sind recht sicher die Dereferenzierung, die aber schiefläuft und dann schlägt move.l 12(%a0) fehl weil %a0 eben ungerade ist .. interessant ist, dass in -4(%fp) eben _HEAP stehen sollte, wurde ja am Anfang gesetzt? Macht irgendwas zwischendurch A6 (den Framepointer) kaputt (blöderweise hab ich den NKC gerade abgedreht und kann ned in A6 schauen und muss jetzt dringend los) ..

Compilerfehler? (Ja ich weiß ists fast nie, aber da die uclinux-Seite down ist musste ich mir die vorgeschlagene Toolchain aus diversen Mirrors zusammenkratzen .. vielleicht buggy?)

Ich glaub ich hab gerade erfolgreiches Rubber-Duck-Debugging betrieben. Ich hab mich erinnert, dass ich mal den Monitor gefilmt hatte um die kurz aufblinkenden Meldungen zu sehen und auf dem Video auch der Fehlerscreen war .. Jup. A6 steht auf $D4... irgendwas. Das ist im Grundprogramm. Und ja, Aufrufe von Grundprogrammroutinen über TRAP nutzen A6 um die Adresse zu berechnen, d.H. sie zerschießen den Framepointer und move.l -4(%fp),%d0 / move.l %d0,%a0 zieht nicht die Basisadresse der Location-Struct, sondern die ersten Befehle von CO2SER (glaube ich).

Die Frage ist nun, ist das ein Problem in Compilersettings, oder muss man den einfach in den GP-Aufrufen auf den Stack retten? Die Lib lief ja so schonmal?


Gruß,
Christian

Beiträge: 71 | Mitglied seit: Oktober 2021 | IP-Adresse: nicht gespeichert
cerker68k
Kennt sich schon aus
**
ID # 219


  Erstellt am 02. Juni 2022 11:01 (#24)  |  Zitat Zitat   PN PN   E-Mail E-Mail
So. Jetzt hab ich gerade Mittagspause und schau nochmal theoretisch in den Code, ausprobieren kann ich es vermutlich erst morgen.

Wirklich zuverlässig ist die Adressfehler-Stelle wie gesagt wenn man das Debugging über serielle Schnittstelle anschaltet.

Dann p

Beiträge: 71 | Mitglied seit: Oktober 2021 | IP-Adresse: nicht gespeichert
hschuetz
Administrator
Seitenadmins
******
ID # 3


  Erstellt am 17. Juni 2022 15:44 (#25)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
test

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Beiträge: 817 | Mitglied seit: Juni 2004 | IP-Adresse: nicht gespeichert
Torsten
Kennt sich schon aus
**
ID # 92


  Erstellt am 17. Juni 2022 21:21 (#26)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hi Christian,

bitte poste doch deinen letzten Beitrag nochmal, irgendwie sind die letzten Beiträge in dem Thread verloren gegangen.

LG
Torsten

Beiträge: 74 | Mitglied seit: März 2008 | IP-Adresse: nicht gespeichert
cerker68k
Kennt sich schon aus
**
ID # 219


  Erstellt am 18. Juni 2022 18:40 (#27)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hmm, das hab ich schon wieder vergessen, was ich da geschrieben hatte, darum hatte ichs ja geschrieben ;)

Muss ich rekonstruieren.

Beiträge: 71 | Mitglied seit: Oktober 2021 | IP-Adresse: nicht gespeichert
tuti
Kennt sich schon aus
**
ID # 225


  Erstellt am 23. September 2022 20:26 (#28)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Zitat von andi:
Hallo,
ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC
Damit hab ich auch schon erfolgreich einige Jados-Programme geschrieben. Zwei davon (Dhrystone-benchmark und 4-gewinnt Spiel) sind im Source dabei.




Hallo, andi (aber auch gerne alle anderen).

Als erste kleine Programmierübung wollte ich mal einen Player für VGM-Dateien mit Ausgabe auf SOUND3 basteln (zumindest für solche Dateien mit Inhalt für "unseren" AY-3-8910). Leider scheitere ich schon beim Einlesen der Datei mit getc, fgetc oder auch fread. Die liefern letzten Endes alle das Gleiche. Aber es ist binäre Grütze!

Das parallel auf einem "normalen" Linux-System compilierte Programm läuft dort einwandfrei.

Frage: Hat schon jemand erfolgreich was mit diesen Funktionen gebaut?

Ansonsten würde ich mich mal mit diesen Jados-Traps befassen und damit mein Glück versuchen. Da gibt es ja offensichtlich vielversprechende Routinen.

Ich hatte nur eigentlich gehofft, dass diese Lib hier sich mit diesen Funktionen vielleicht schon selbst an die Traps dran hängt und ich mir das sparen kann... :)


Gruß, Torsten (der für jedes funktionierende Fragment mit getc und Co. dankbar ist).

-----------------------
Definitiv sind Frösche und Himbeeren am besten!

Beiträge: 66 | Mitglied seit: Juli 2022 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 23. September 2022 22:02 (#29)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ah ja bei meinem GCC-Port sind leider (noch) nicht die Jados-Traps mit den file-Funktionen verbunden. Das steht auch auf meiner Todo-Liste. Mit fopen, read, write kannst derzeit nur auf die Ser lesen / schreiben (auch Interrupt-getrieben). Wenn du files lesen willst musst die Jafos-Traps direkt via Inline-Assembly verwenden.
LG Andi

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
tuti
Kennt sich schon aus
**
ID # 225


  Erstellt am 29. September 2022 06:44 (#30)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ich habe jetzt meine ersten Routinen zum Aufruf von Jados-Traps mit Inline-Assembler fertig. Ist aber noch nicht ganz rund. Insbesondere die Parameter-Übergabe in die Funktion - und damit in den Inline-Assembler - hinein habe ich sehr hausbacken gelöst: Böse böse die Bytes gezählt und zur Laufzeit eine Konstante in einer Speicherzelle des Inline-Assemblers modifiziert!

Ähnlich für die Rückgabe von Werten der Funktion.

Hat da jemand schon Erfahrung mit und evtl. ein Code-Fragment, das das vielleicht sauber über den Stack löst?


Ebenso für das Auslesen der Kommandozeilen-Parameter beim Aufruf des Progrämmchens ("argc" und "argv")? Bei Nutzung der Lib bekam ich immerhin argc und argv[1]; argv[0] war immer leer). Ohne Lib muss man das auch noch selbst machen.

Will als Nächstes den Stack beim Aufruf untersuchen und habe mir dafür eine Routine zur Ermittlung des SP bei Aufruf und Ausgabe eines Hexdumps ab dieser Adresse zur Laufzeit geschrieben. Ist dann jetzt aber erst einmal Fleißarbeit...

-----------------------
Definitiv sind Frösche und Himbeeren am besten!

Beiträge: 66 | Mitglied seit: Juli 2022 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 29. September 2022 19:09 (#31)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Kommandozeilen-parameter liest meine gcc Library schon aus und übergibt diese an main (argc, argv).
Für die wichtigsten Jados-Aufrufe hab ich auch schon C-Funktionen (mit Inline-Assembly). Ich würd übrigens nur in Ausnahmefällen Parameter am Stack übergeben (ist zu ineffizient). Besser ist in Registern (gcc hat dazu eine calling convention). Ich stell mal ein kleines Jados_Example das das Disk-Directory ausliest und anzeigt online.

LG,
Andi

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 30. September 2022 20:08 (#32)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,
ich hab mal ein kleines Beispiel eingecheckt für
- Commandline parameter
- System-Uhrzeit auslesen und anzeigen
- Jados Version auslesen und anzeigen
- Directory von Laufwerk 0 anzeigen
https://github.com/avg67/nkc/tree/main/SW/Jados_test
Das file nkc.h hab ich leider updaten müssen. Dieses gehört in das Verzeichnis C:\SysGCC\m68k-elf\nkc_common\nkc\
Man sieht hier sehr schön dass der Compiler nichts am Stack übergibt sondern direkt mit den Registern arbeitet. Das ist speziell beim 68008 viel effizienter.
z.B. folgende C-Zeile:
uint8_t result = jd_directory((void*)buf, (void*)"0:*.*", 0, 1, sizeof(buf));

ergibt folgenden ASM-Code:
uint8_t jd_directory(void* pbuf, void* ppattern, uint8_t attrib, uint16_t columns, uint16_t size) {
uint8_t ret = 0u;
asm volatile(
78ba:280e movel %fp,%d4
78bc:0684 ffff f000 addil #-4096,%d4
78c2:7e4a moveq #74,%d7
78c4:2044 moveal %d4,%a0
78c6:227c 0000 7976 moveal #31094,%a1
78cc:143c 0000 moveb #0,%d2
78d0:363c 0001 movew #1,%d3
78d4:323c 1000 movew #4096,%d1
78d8:48e7 0006 moveml %a5-%fp,%sp@-
78dc:4e46 trap #6
78de:4cdf 6000 moveml %sp@+,%a5-%fp
78e2:1800 moveb %d0,%d4

Ich finde das ist recht effizienter code. Händisch würde ich es kaum besser hin bringen

Aufruf z.B. mit test 1 2 3 4 5


Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
tuti
Kennt sich schon aus
**
ID # 225


  Erstellt am 30. September 2022 21:59 (#33)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Oh! Das sieht spannend aus!

Wollte das schnell mal testen, lief aber auf einen Compiler-Fehler.

Habe dann ein #define USE_JADOS in die target.h eingefügt. Direkt hinter das #define TARGET_H gleich zu Beginn. Ist das richtig so?


Jetzt bekomme ich immerhin schon mal ein test.68k, das auch auf dem NKC läuft und einen Output entsprechend deinem Foto produziert. Vielen Dank für das Beispiel. Muss ich die Tage mal genauer ansehen.

Eines fällt mir direkt auf: In deinem argp[0] befindet sich offensichtlich der erste Parameter und nicht der Name des Programmes. Auf deinem Foto die "1". Das war mir letztens bei meinen ersten Versuchen mit deiner Lib schon aufgefallen. Ist das Absicht? Kommst du an den Namen nicht ran?


Gruß, Torsten (der jetzt aber erstmal den Tag beendet :) )

-----------------------
Definitiv sind Frösche und Himbeeren am besten!

Beiträge: 66 | Mitglied seit: Juli 2022 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 30. September 2022 22:33 (#34)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hi,
so kannst du es auch machen. dann ist halt Jados global enabled. Ich hab das immer im makefile gesetzt um das für jedes projekt individuell machen zu können.
(CFLAGS=-g -Os -m68000 -Wall -fomit-frame-pointer -nostartfiles -std=gnu99 -Dndrcomp $(ISEARCH) -DUSE_JADOS)
Warum ich für den ersten Parameter anstelle des Programmnamens den gesamten Parameter-string übergebe weiss ich ehrlich gesagt nicht mehr (ist ca. 20 jahre her dass ich das gemacht habe). Vl. kann man bei Jados den Programmnamen wirklich nicht auslesen. Ich muss mal in die Jados Doku rein schauen. Das ganze passiert jedenfalls in crt0.c ab Zeile 199 (C:\SysGCC\m68k-elf\nkc_common\nkc\).

LG,
Andi

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 02. Oktober 2022 11:30 (#35)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,
Ich hab nun ein weiteres Update zum Jados-Test eingecheckt.
Und zwar fragt er nun nach dem Anzeigen des Directories von Laufwerk A nach einem Filenamen, liest dieses file ein und zeigt es am Bildschirm an (sollte ein ASCII file sein)
LG,
Andi

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
tuti
Kennt sich schon aus
**
ID # 225


  Erstellt am 03. Oktober 2022 14:14 (#36)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Zitat von andi:
Ich hab das immer im makefile gesetzt um das für jedes projekt individuell machen zu können.
(CFLAGS=-g -Os -m68000 -Wall -fomit-frame-pointer -nostartfiles -std=gnu99 -Dndrcomp $(ISEARCH) -DUSE_JADOS)



Da hast du Recht. Ist doch eleganter im Makefile...


Zitat von andi:
Hallo, Ich hab nun ein weiteres Update zum Jados-Test eingecheckt.



Den Rest des Nachmittags habe ich endlich mal "frei". Jetzt kann ich gucken, testen und spielen.

Danke für das betreute Crosscompiler-Lernen... :)

Torsten

-----------------------
Definitiv sind Frösche und Himbeeren am besten!

Beiträge: 66 | Mitglied seit: Juli 2022 | IP-Adresse: nicht gespeichert
andi
Kennt sich schon aus
**
ID # 213


  Erstellt am 31. Oktober 2022 18:16 (#37)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,
hab gerade meinen nächsten großen Meilenstein in Punkto cross-development mit GCC für den NKC erreicht - und zwar das Remote Debuggen. Hab seit längerer Zeit an einem seriellen Debug-Stub gearbeitet den man in ein (GCC) C-Projekt mit dazu compiliert um dann vom PC aus bequem das Programm am GDB zu debuggen (auch grafisch via z.B. DDD). Hab gerade den letzten Bug gefixt und das erste mal erfolgreich debuggt (inkl. Variablen, Memory anschauen und editieren). Ist ein großer Schritt vorwärts von Debug-prints's zum GDB!

Beiträge: 72 | Mitglied seit: Mai 2021 | IP-Adresse: nicht gespeichert
smed
Stammgast
**
ID # 114


  Erstellt am 31. Oktober 2022 19:55 (#38)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Super :) !!!

-----------------------
NKC'ler und RDK Fan seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,FLO2,PROMER,CENT,SER,SOUND,CAS,4xBUS2,3xPOW5V,2xTAST..und neuerdings einen Arduino mit auf dem BUS. Und eine selbstgebastelte MEM960k. UHR, IDE und COL256 noch nicht gebastelt.

NKC - OpenSource since 1983

Beiträge: 155 | Mitglied seit: Januar 2011 | IP-Adresse: nicht gespeichert



| NDR Computer | Boardregeln


Tritanium Bulletin Board 1.6
© 2010–2016 Tritanium Scripts


Seite in 1,941800 Sekunden erstellt
22 Dateien verarbeitet
gzip Komprimierung ausgeschaltet
1597,73 KiB Speichernutzung