Ich habe wahrscheinlich aus einem nostalgischen Anfall heraus eine
meiner KATCE-1.4E Platinen hervorgekramt um damit wieder mal zu spielen.
Die KATCE waren wohl mal vor Jahrzehnten ein Projekt der MC (schade um
diese Zeitung!) und wurden mit irgendeinem Pearl RTOS verkauft.
Ich habe 2 dieser Platinen aber mit Pearl oder Pascal da nie was am Hut
gehabt.
Vor vielen Jahren habe ich die Dinger mit einer MC68010 CPU ausgerüstet,
die gefiel mir besser al die MC68000, und darauf einen frei im
Sourcecode erhältlichen Motorola Debugger portiert (FBUG). Der FBUg ist
relativ komplex und enthält u.A. einen Assembler, einen Disassembler und
ein Testsystem das u.a. die Traps der CPU nutzt und diese auch
behandelt.
Der Debugger ist in Assembler und C geschrieben, ich habe die Syntax
damals angepaßt und eine Cross Umgebung auf FreeBSD aufgesetzt
(m68k-coff). Der Compiler war damals ein gcc-2.9.5.
Weiterhin hatte ich crt0.o etc angepaßt, das ich Programme compilieren
und als s-Record auf diese KATCE laden und dort ausführen konnte, der
Debugger übernahm einen Teil der IO-Bibliothek.
Einen gcc-2.9.5 kann ich auf "amd64-unknown-freebsd" nicht mehr
vernünftig übersetzen, so bin ich jetzt bei binutils-2.16.1,newlib-1.9.0
und gcc-3.3.6 gelandet, selbst da gabs noch einige Bugs die die
Übersetzung erst mal verhinderten, habe aber noch gegoogelt und
gepatched so das ich das Ding zumindest durchkompiliert bekomme.
Ich habe den FBUG neu übersetzt und eine Mimik gebastelt die mir die
beiden ROMS erzeugt, das Ding läuft auch an aber wirft bei jedem
Kommando exeptions.
Copyright Motorola Inc. 1989 All Rights Reserved
Fbug68 Monitor/Debugger Version 1.1 - 9/28/89
MOTOROLA> rd
im ersten case
in printreg()
PC =$Address Error
"im ersten case und in printreg()) sind debugging printfs von mir, der
Adress Error ist das Problem, normalerweise sollte der da die
Registerinhalte der Debugging CPU (copy der Register im RAM) anzeigen.
Ich habe noch einen EPROM Satz der das kann und ich habe noch alte
compilate auf der Platte. Deshalb bin ich auf einigeUnterscheide bei der
Übersetzung gestoßen:
Hier Datenbereiche im .bss segment:
alt:
COMMON 0x001fe000 0xa64 coldport.o
0x001fe000 sizechar
0x001fe004 condition
0x001fe010 argv
0x001fe060 tracecount
0x001fe064 stackptr
0x001fe070 brtable
0x001fe110 lastcmd
0x001fe160 asmaddr
0x001fe164 handlerflag
0x001fe170 assemblycode
0x001fe1a0 actualfield
0x001fe1e0 regdata
0x001fe264 MIPOST
0x001fe268 confres
0x001fe26c argc
0x001fe270 opwordsyntax
0x001fe338 overheadRTS
0x001fe340 mpu
0x001fe448 asmdata
0x001fe44c startbenchmark
0x001fe450 m8
0x001fe850 Field_option
0x001fe85c error
0x001fe860 instructnum
0x001fe870 Fieldoption
0x001fe87c snum
neu:
COMMON 0x00000000001fe000 0xa0a coldport.o
0x00000000001fe000 sizechar
0x00000000001fe002 condition
0x00000000001fe006 argv
0x00000000001fe056 tracecount
0x00000000001fe05a stackptr
0x00000000001fe05e brtable
0x00000000001fe0fe lastcmd
0x00000000001fe14e asmaddr
0x00000000001fe152 handlerflag
0x00000000001fe156 assemblycode
0x00000000001fe182 actualfield
0x00000000001fe1b4 regdata
0x00000000001fe238 MIPOST
0x00000000001fe23c confres
0x00000000001fe240 argc
0x00000000001fe244 opwordsyntax
0x00000000001fe30c overheadRTS
0x00000000001fe310 mpu
0x00000000001fe418 asmdata
0x00000000001fe41c startbenchmark
0x00000000001fe420 m8
0x00000000001fe81c Field_option
0x00000000001fe826 error
0x00000000001fe82a instructnum
0x00000000001fe82e Fieldoption
0x00000000001fe838 snum
Man sieht, dass der Bereich sizechar im alten compilat 4 Byte groß ist,
im neuen nur 2. Normalerweise ist das neue richtiger, denn sizechar ist
als
char sizechar[2]; definiert, also Ein Feld mit 2 Byte Elementen. Mit den
alten ROMS kann ich mir den Bereich anzeigen lassen und sehe das der
auch nur das erste und dritte Byte benutzt.
Der Bereich regdata ist aber in beiden Compilaten 84Byte groß, das ist
der Bereich in dem die oben angeführten Copies der CPU Register liegen.
Ich weiß nach all den Jahren in denen ich mit M68K nichts mehr gemacht
habe nun nicht mehr wirklich wie die CPU auf ein Byte zugreift. Geht
hier wirklich Byte Zugriff auf unaligned Adressen oder ist das das
Problem mit dem Address Error?
Die KATCE 1.4 hat derzeit 2 Eproms mit 64Kbyte (27c512, das Debugging
gestaltet sich durch die Erase/Burn Zyklen etwas zäh, auch mit einem
Stapel Eproms) und 4 Stück 628128 RAMs, also 512K, beides
Wortorganisiert.
Steht hier noch Jemand in der Materie?
BTW: Gibts hier Gnu LD Linkerscript-Spezis? Die ganzen komischen
Sections in einem ELF File sind einfach nur krank. Da war COFF ja echt
easy..
Ich lade das ganze fbug Directory mit den Sourcen und den Objects auf
den Webserver.
In 10 Minuten mal auf http://www.tiffe.de/Robotron/Motorola/fbug
gucken...
Gruß,
Holm
Holm Tiffe schrieb:> Steht hier noch Jemand in der Materie?
ein wenig.
Wenn ich das auf die Schnelle richtig sehe, kracht's ja wohl hier:
1
print("=%c%8x ",HEXDEL,reg[i].value);
Gehen wir mal davon aus, daß print() halbwegs richtig funktioniert
(schließlich hast Du ja andere Ausgaben hingekriegt), kann der
Addressfehler ja wohl nur bedeuten, daß reg[i].value (ein int) - warum
auch immer - an einer ungeraden Adresse liegt.
Ich würde mal annehmen, daß mit deinem Compiler was nicht stimmt. Hier
im Board gibt's irgendwo eine Anleitung, den m68k ELF compiler zu bauen,
das hat für mich ohne Patchen auf Anhieb funktioniert.
Holm Tiffe schrieb:> Ich habe wahrscheinlich aus einem nostalgischen Anfall heraus eine> meiner KATCE-1.4E Platinen hervorgekramt um damit wieder mal zu spielen.
Nein, das ist/war kein nostalgischer Anfall :-)
Angekotzt von den Arduino-Freds hier habe ich heute abend mein im
Studium selbstgefädeltes Z80-Board(8255 etc.) (1MHz maximum)
hervorgekramt und den Pascal-Compiler (im Soure) weiterentwickelt.
Mach weiter so!
Markus F. schrieb:> Holm Tiffe schrieb:>> Steht hier noch Jemand in der Materie?>> ein wenig.>> Wenn ich das auf die Schnelle richtig sehe, kracht's ja wohl hier:>>
1
print("=%c%8x ",HEXDEL,reg[i].value);
>
..fast..
> Gehen wir mal davon aus, daß print() halbwegs richtig funktioniert
...nein.
ein print("blah\n"); funktioniert, ein print("balh%d\n",5); fliegt auf
die Gusche.
Es knall scheinbar irgendwo in int format(pfmt) im File printport.c.
> (schließlich hast Du ja andere Ausgaben hingekriegt), kann der> Addressfehler ja wohl nur bedeuten, daß reg[i].value (ein int) - warum> auch immer - an einer ungeraden Adresse liegt.>> Ich würde mal annehmen, daß mit deinem Compiler was nicht stimmt. Hier> im Board gibt's irgendwo eine Anleitung, den m68k ELF compiler zu bauen,> das hat für mich ohne Patchen auf Anhieb funktioniert.
Ich habe das eigentlich schon ein paar mal gemacht, meist zu den Zeiten,
als es hier noch keine Anleitungen dafür gab.
/Binutils konfigurieren und bauen, danach gcc als Crosscompiler ohne
standardincludes mit newlib konfigurieren und basteln. Das Ergebnis
sollte tun..)
Ich schätze mal ein Teil meines Problems ist das ich unter x86_64 als
Host arbeite, also mit einem 64 Bit System. Ich hatte auch gelesen das
andere Leute so ihre Sorgen damit hatten, auch scheint m68k-elf
zumindest im gcc-3.4.6 noch nicht das Gelbe vom Ei zu sein.
Ich scheine hier Probleme damit zu haben, das die alten gccs auf amd64
nicht recht zu bauen sind und bei neueren compilern m68k nicht mehr
taugt...
Ich werde morgen m68k noch mal als m68k-coff bauen und gucken was
passiert (Binaries vergleichen) danach baue ich das ganze noch mal in
einer 32Bit VM...
Hatte ich erwähnt das das Löschen und nachfolgende Bruzeln von 28F010
viel länger dauert als das von 27C512 (bei selbem Inhalt)? Ich habe die
Dinger wieder Beiseite gelegt. :-|
Gruß,
Holm
Myxo Matrose schrieb:> Holm Tiffe schrieb:>> Ich habe wahrscheinlich aus einem nostalgischen Anfall heraus eine>> meiner KATCE-1.4E Platinen hervorgekramt um damit wieder mal zu spielen.>> Nein, das ist/war kein nostalgischer Anfall :-)>> Angekotzt von den Arduino-Freds hier habe ich heute abend mein im> Studium selbstgefädeltes Z80-Board(8255 etc.) (1MHz maximum)> hervorgekramt und den Pascal-Compiler (im Soure) weiterentwickelt.> Mach weiter so!
...Ich habe nix gegen Arduinos. Ich finde die kleinen Platinen Klasse,
allerdings habe ich die Software mit dem Arsch noch nicht angeguckt und
werde das wohl auch nie tun.
Z80 Zeugs liegt hier auch rum. Pascal habe ich verlernt, unter
Turbopascal 3.02A habe ich mal Pascal programmiert und bei C wie eine
Sau ins Uhrwerk geguckt. Heute ist das irnkwie anders herum...
Gruß,
Holm
Wie gesagt, ich hatte keine Probleme, m68k-elf-gcc nach dieser:
http://www.mikrocontroller.net/articles/GCC_M68k Anleitung zu bauen (nur
neuere gcc-Version: 4.6.4 mit den dazugehörigen binutils) und der funzt
einwandfrei. Mit x86_64 als host, versteht sich.
Holm Tiffe schrieb:> Es knall scheinbar irgendwo in int format(pfmt) im File printport.c.
Ok. Dann ist da wahrscheinlich der Hund begraben und der Compiler
möglicherweise in Ordnung:
1
intprint(pfmt)
2
char*pfmt;
3
{
4
return(format(&pfmt));/* pass ptr to fmt ptr */
5
}
6
7
intformat(pfmt)
8
char**pfmt;/* pointer to pointer to format string */
9
{
10
...
11
pformat=*pfmt++;/* set "format" to the format string */
12
pargument=(char*)pfmt;
Variable Argumentliste ohne stdarg.h/varargs.h (ohne dem Compiler was
davon zu verraten) und und dann irgendwann das da:
1
pvalue=*(int*)pargument;
Ich hab's nicht vollständig durchbohrt (ist also durchaus möglich, daß
ich falsch liege), würde aber fast wetten, daß es da dran liegt.
1
print("irgendwas %d\n",5);
Geht wohl schon schief, weil eben nicht die Adresse der Konstanten auf
dem Stack liegt, sondern die Konstante selbst.
Erstaunlich, daß das schon mal funktioniert haben soll. In printunix.c
scheint's einigermaßen sauber gemacht zu sein (und da steht auch im
Kommentar, warum's so gemacht werden muß).
Du hast sicherlich Recht, aber funktioniert hat das mal, ich habe ja 2
EPROMS mit einem Compilat der selben Source drin das funktioniert.
Das war aber sicherlich ein GCC vom Anfang der 2er Versionen oder ein
1.4 der das übersetzt hat, es rüde mich nicht wundern wenn sicher hier
die calling conventions mittlerweile deutlich verändert haben.
Was die Programmierer von Motorola sich dabei gedacht haben ist auch für
mich nicht so ohne Weiteres nachvollziehbar, dummerweise ist auch die
printunix.c Version mit der alten pre-ISO Variante von Varargs seit gcc3
raus geflogen.
Ich werde als den varags- Kram lernen müssen und versuchen das zu
portieren,
das habe ich bisher noch nie benutzt.
Der Vollständigkeit halber werde ich mal den gcc mit den configs die Du
verlinkt hast durchdrehen, denke aber nicht das das was ändert.
Gruß,
Holm
So. Ich habe jetzt nach obier Anleitung den gcc4 mit Newlib gebaut und
installiert. Zusätzlich habe ich das file printport.c geändert und das
tiny printf von hier eingebaut:
http://www.xappsoftware.com/wordpress/2011/01/17/a-tiny-printf-for-embedded-systems/
Ergebnis: Keine Änderung :-|
Jetzt knallt es in printi():
Copyright Motorola Inc. 1989 All Rights Reserved
Fbug68 Monitor/Debugger Version 1.1 - 9/28/89
MOTOROLA> rd
hallo 124Address Error
PC =$124Address Error
PC =$124Address Error
PC =$124Address Error
PC =$124Address Error
printi() hatte ich mit putchars gespickt, das sind diese "124"
1
#define PRINT_BUF_LEN 12
2
3
static int printi(char **out, int i, int b, int sg, int width, int pad, int letbase)
4
{
5
char print_buf[PRINT_BUF_LEN];
6
register char *s;
7
register int t, neg = 0, pc = 0;
8
register unsigned int u = i;
9
10
if (i == 0) {
11
print_buf[0] = '0';
12
print_buf[1] = '\0';
13
return prints (out, print_buf, width, pad);
14
}
15
putcr('1');
16
17
if (sg && b == 10 && i < 0) {
18
neg = 1;
19
u = -i;
20
}
21
putcr('2');
22
23
s = print_buf + PRINT_BUF_LEN-1;
24
*s = '\0';
25
putcr('4');
26
27
while (u) {
28
t = u % b;
29
if( t >= 10 )
30
t += letbase - '0' - 10;
31
*--s = t + '0';
32
u /= b;
33
}
34
35
putcr('3');
Die Dateien auf dem Webserver sind aktualisiert.
Gruß,
Holm
Nimm' das hier. Ist zwar auch größtenteils "zusammengeklaut",
funktioniert aber.
xputchar() in xprintf.c wirst Du anpassen müssen, möglicherweise auch
mangels FPU die Fließkomma-Ausgabe lieber entfernen, ansonsten müsste
das aber tun.
Also im Prinzip das Selbe.
Nach mindestens 4 Compilern und 3 Varianten der Ausgabe scheppert das an
der selben Stelle, kann doch nicht sein...
Dieses "hallo 1" oben ist ein print("hallo 1 %d\n",1);
(xprintf("hal..).
Der String wird jedes Mal ausgegeben, aber bei numerischen Variabeln
bekomme ich eine Exeption.
Ich muß erst mal zur Familie, aktualisiere den Webserver noch...
Gruß,
Holm
Ich habe deutliche Unterschiede im Verhalten des alten cpp und As zu dem
aktuellen festgestellt.
Der erste Code den der 68k nach Reset ausführen soll befindet sich in
asmstartport.s. Im Makefile sieht die Übersetzung so aus:
asmstartport.o : textdef.h vardef.h userdef.h targetsys.h
cpp asmstartport.s > temp.s
$(AS) -a=asmstartport.l -o asmstartport.o temp.s
rm temp.s
Die Assemblerquelle wird also erst durch den (system-)cpp geleiert um
#include und #define -s aufzulösen und dann dem gas vorgeworfen.
Das asmstartport.l Listing der alten funktionierenden Variante sa so aus
(sorry für das länglich Posting):
1
68K GAS temp.s page 1
2
3
4
1 # 1 "asmstartport.s"
5
2 # 1 "targetsys.h" 1
6
1:asmstartport.s **** #include "targetsys.h"
7
3
8
4
9
.... leere Zeilen
10
143
11
144
12
145
13
146 # 164 "targetsys.h"
14
147
15
1:targetsys.h ****
16
2:targetsys.h **** /*
17
3:targetsys.h **** This is the easiest place to make change. If you make a change here,
18
4:targetsys.h **** then all the .c files must be recompiled. This can be done with the
19
5:targetsys.h **** make command and the appropriate makefile.
20
6:targetsys.h **** */
21
7:targetsys.h ****
22
8:targetsys.h **** /*
23
9:targetsys.h **** the boolean logic symbols defined for code readability.
... weiter mit Kommentar 108:asmstartport.s **** short 0x0000 #fmove.x #0,fp7
120
109:asmstartport.s **** #endif
121
504
122
505
123
506
124
507 0060 2E7C 0008
125
507 0000
126
508 0066 4EF9 0000
127
508 0000
128
509
129
510 ...
130
^L68K GAS temp.s page 16
131
132
133
DEFINED SYMBOLS
134
temp.s:459 e0:00000000 INITSP
135
temp.s:460 e0:00000004 INITPC
136
temp.s:462 e0:00000008 start
137
temp.s:464 e0:00000012 abortstart
138
139
UNDEFINED SYMBOLS
140
.file
141
.file
142
.file
143
.file
144
.file
145
.file
146
.file
147
.file
148
.text
149
.data
150
.bss
151
main_without__main
Mit den neuen Tools sieht das anders aus, der cpp scheint sich nicht
mehr um viel zu kümmern...
1
68K GAS temp.s page 1
2
3
4
1 # 1 "asmstartport.s"
5
1 #include "targetsys.h"
6
0
7
0
8
1
9
2 .file "asmstart.s"
10
0
11
3 .global _start,abortstart
12
4 .text
13
5
14
6 INITSP: .long 0x0080000
15
7 INITPC: .long _start
16
8
17
9 _start:
18
10 mov.l &0x1,(SYSRAMLOC+0x1000)
19
11 abortstart: mov.l &SYSRAMLOC+0x1b00,%d0
20
12 #if(DEVICE>=68010)
21
13 mov.l &SYSRAMLOC+0x1000,%d1
22
14 #endif
23
15 #if(DEVICE>=68020)
24
16 mov.l &SYSRAMLOC+0x2000,%d2
25
17 mov.l &SYSRAMLOC+0x1c00,%d3
26
18 #endif
27
19 mov.l &0x0,%d4
28
20 mov.l &0x0,%d5
29
21 mov.l &0x0,%d6
30
22 mov.l &0x0,%d7
31
23 mov.l &0x0,%a0
32
24 mov.l &0x0,%a1
33
25 mov.l &0x0,%a2
34
26 mov.l &0x0,%a3
35
27 mov.l &0x0,%a4
36
28 mov.l &0x0,%a5
37
29 mov.l &0x0,%a6
38
30 #if(DEVICE>=68020)
39
31 movec.l %d4,%caar
40
32 movec.l %d4,%cacr
41
33 movec.l %d4,%sfc
42
34 movec.l %d4,%dfc
43
35 #endif
44
36 movec.l %d0,%usp
45
37 #if(DEVICE>=68010)
46
38 movec.l %d1,%vbr
47
39 #endif
48
40 #if(DEVICE>=68020)
49
41 movec.l %d2,%isp
50
42 movec.l %d3,%msp
51
43 #endif
52
44 mov.l &0x0,%d0
53
45 mov.l &0x0,%d1
54
46 mov.l &0x0,%d2
55
47 mov.l &0x0,%d3
56
48 #if(DEVICE==68030)
57
49 lea.l CRP_INIT,%a0
58
50 short 0xf010
59
51 short 0x4c00 #pmove (a0),crp
60
52 short 0xf010
61
^L68K GAS temp.s page 2
62
53 short 0x4800 #pmove (a0),srp
63
54 lea.l LONG_0,%a0
64
55 short 0xf010
65
56 short 0x4000 #pmove (a0),tc
66
57 short 0xf010
67
58 short 0x0800 #pmove (a0),tt0
68
59 short 0xf010
69
60 short 0x0c00 #pmove (a0),tt1
70
61 short 0xf010
71
62 short 0x6000 #pmove (a0),psr
72
63 #endif
73
64 #if(DEVICE==68040 || COPROCESSOR==TRUE)
74
65 short 0xf23c
75
66 short 0x9000
76
67 short 0x0000
77
68 short 0x0000 #fmove.l #0,fpcr
78
69 short 0xf23c
79
70 short 0x8800
80
71 short 0x0000
81
72 short 0x0000 #fmove.l #0,fpsr
82
73 short 0xf23c
83
74 short 0x8400
84
75 short 0x0000
85
76 short 0x0000 #fmove.l #0,fpiar
86
77 short 0xf23c
87
78 short 0x4000
88
79 short 0x1234
89
80 short 0x5678 #fmove.x #0,fp0
90
81 short 0xf23c
91
82 short 0x4080
92
83 short 0x0000
93
84 short 0x0000 #fmove.x #0,fp1
94
85 short 0xf23c
95
86 short 0x4100
96
87 short 0x0000
97
88 short 0x0000 #fmove.x #0,fp2
98
89 short 0xf23c
99
90 short 0x4180
100
91 short 0x0000
101
92 short 0x0000 #fmove.x #0,fp3
102
93 short 0xf23c
103
94 short 0x4200
104
95 short 0x0000
105
96 short 0x0000 #fmove.x #0,fp4
106
97 short 0xf23c
107
98 short 0x4280
108
99 short 0x0000
109
100 short 0x0000 #fmove.x #0,fp5
110
101 short 0xf23c
111
102 short 0x4300
112
103 short 0x0000
113
104 short 0x0000 #fmove.x #0,fp6
114
105 short 0xf23c
115
106 short 0x4380
116
107 short 0x0000
117
108 short 0x0000 #fmove.x #0,fp7
118
109 #endif
119
^L68K GAS temp.s page 3
120
121
122
110 0060 2E7C 0008 mov.l &ISPLOC,%a7
123
110 0000
124
111 0066 4EF9 0000 jmp main_without__main
125
111 0000
126
^L68K GAS temp.s page 4
127
128
129
DEFINED SYMBOLS
130
*ABS*:0000000000000000 asmstart.s
131
asmstart.s:9 .text:0000000000000008 _start
132
asmstart.s:11 .text:0000000000000012 abortstart
133
asmstart.s:6 .text:0000000000000000 INITSP
134
asmstart.s:7 .text:0000000000000004 INITPC
135
136
UNDEFINED SYMBOLS
137
main_without__main
Hieraus WÜRDE ich entnehmen das der Assembler nur m letzten Stück
überhaupt Code erzeugt, die ganzen Präprozessordirectiven stehen noch im
Quelltext und sind durch cpp nicht ersetzt worden.
Wie kriege ich das ursprüngliche Verhalten des cpp wieder hin?
Wie kriege ich vom Assembler eine Ausgabe über das was er ab _start
generiert? Das das noch kein auf 800000 gelinkter Code ist, ist mir
klar, aber da sind "rts" dazwischen über die der Disassembler stolpert,
im Linkerscript steht drin, das der Linker mit rts füllen soll, ich weiß
das, nur wie komme ich zu einem korrekten Listing?
Gruß,
Holm
wenn Du die Assemblerfiles durch den Präprozessor verwursten lassen
willst, muß die Dateiendung ".S" (großes "S") statt ".s" lauten und Du
solltest gcc (statt gas) drauf loslassen.
Kann mich aber nicht erinnern, daß das neu wäre - ich meine, das war
schon immer so...
Wenn man den gcc mit einem .s aufruft mag das so sein, bei einem Aufruf
wie /home/holm/cross/m68k/bin/m68k-elf-cpp asmstartport.s > temp.s
macht das keinerlei Unterschied, das habe ich gerade verifiziert.
temp.s sieht danach so aus:
1
# 1 "asmstartport.s"
2
# 1 "<built-in>"
3
# 1 "<command-line>"
4
# 1 "asmstartport.s"
5
# 1 "targetsys.h" 1
6
# 2 "asmstartport.s" 2
7
.file "asmstart.s"
8
.global _start,abortstart
9
.text
10
11
INITSP: .long 0x0080000
12
INITPC: .long _start
13
14
_start:
15
mov.l &0x1,(0x0007e000 +0x1000)
16
abortstart: mov.l &0x0007e000 +0x1b00,%d0
17
18
mov.l &0x0007e000 +0x1000,%d1
19
20
mov.l &0x0,%d4
21
mov.l &0x0,%d5
22
mov.l &0x0,%d6
23
mov.l &0x0,%d7
24
mov.l &0x0,%a0
25
mov.l &0x0,%a1
26
mov.l &0x0,%a2
27
mov.l &0x0,%a3
28
mov.l &0x0,%a4
29
mov.l &0x0,%a5
30
mov.l &0x0,%a6
31
32
movec.l %d0,%usp
33
34
movec.l %d1,%vbr
35
36
mov.l &0x0,%d0
37
mov.l &0x0,%d1
38
mov.l &0x0,%d2
39
mov.l &0x0,%d3
40
# 110 "asmstartport.s"
41
mov.l &0x0007e000 +0x2000,%a7
42
jmp main_without__main
und ich frage mich wo der Code im Listing file hin ist:
m68k-elf-as -m68010 -a=asmstartport.l -o asmstartport.o temp.s
1
2 .file "asmstart.s"
2
0
3
3 .global _start,abortstart
4
4 .text
5
5
6
6 INITSP: .long 0x0080000
7
7 INITPC: .long _start
8
8
9
9 _start:
10
10 mov.l &0x1,(SYSRAMLOC+0x1000)
11
11 abortstart: mov.l &SYSRAMLOC+0x1b00,%d0
12
12 #if(DEVICE>=68010)
13
13 mov.l &SYSRAMLOC+0x1000,%d1
14
14 #endif
15
15 #if(DEVICE>=68020)
16
16 mov.l &SYSRAMLOC+0x2000,%d2
17
17 mov.l &SYSRAMLOC+0x1c00,%d3
18
18 #endif
19
19 mov.l &0x0,%d4
20
20 mov.l &0x0,%d5
21
21 mov.l &0x0,%d6
22
22 mov.l &0x0,%d7
23
23 mov.l &0x0,%a0
24
^L68K GAS temp.s page 10
25
26
27
24 mov.l &0x0,%a1
28
25 mov.l &0x0,%a2
29
26 mov.l &0x0,%a3
30
27 mov.l &0x0,%a4
31
28 mov.l &0x0,%a5
32
29 mov.l &0x0,%a6
33
30 #if(DEVICE>=68020)
34
31 movec.l %d4,%caar
35
32 movec.l %d4,%cacr
36
33 movec.l %d4,%sfc
37
34 movec.l %d4,%dfc
38
35 #endif
39
36 movec.l %d0,%usp
40
37 #if(DEVICE>=68010)
41
38 movec.l %d1,%vbr
42
39 #endif
43
40 #if(DEVICE>=68020)
44
41 movec.l %d2,%isp
45
42 movec.l %d3,%msp
46
43 #endif
47
44 mov.l &0x0,%d0
48
45 mov.l &0x0,%d1
49
46 mov.l &0x0,%d2
50
47 mov.l &0x0,%d3
51
48 #if(DEVICE==68030)
52
49 lea.l CRP_INIT,%a0
53
50 short 0xf010
54
51 short 0x4c00 #pmove (a0),crp
55
52 short 0xf010
56
53 short 0x4800 #pmove (a0),srp
57
54 lea.l LONG_0,%a0
58
55 short 0xf010
59
56 short 0x4000 #pmove (a0),tc
60
57 short 0xf010
61
58 short 0x0800 #pmove (a0),tt0
62
59 short 0xf010
63
60 short 0x0c00 #pmove (a0),tt1
64
61 short 0xf010
65
62 short 0x6000 #pmove (a0),psr
66
63 #endif
67
64 #if(DEVICE==68040 || COPROCESSOR==TRUE)
68
65 short 0xf23c
69
66 short 0x9000
70
67 short 0x0000
71
68 short 0x0000 #fmove.l #0,fpcr
72
69 short 0xf23c
73
70 short 0x8800
74
71 short 0x0000
75
72 short 0x0000 #fmove.l #0,fpsr
76
73 short 0xf23c
77
74 short 0x8400
78
75 short 0x0000
79
76 short 0x0000 #fmove.l #0,fpiar
80
77 short 0xf23c
81
78 short 0x4000
82
79 short 0x1234
83
80 short 0x5678 #fmove.x #0,fp0
84
^L68K GAS temp.s page 11
85
86
87
81 short 0xf23c
88
82 short 0x4080
89
83 short 0x0000
90
84 short 0x0000 #fmove.x #0,fp1
91
85 short 0xf23c
92
86 short 0x4100
93
87 short 0x0000
94
88 short 0x0000 #fmove.x #0,fp2
95
89 short 0xf23c
96
90 short 0x4180
97
91 short 0x0000
98
92 short 0x0000 #fmove.x #0,fp3
99
93 short 0xf23c
100
94 short 0x4200
101
95 short 0x0000
102
96 short 0x0000 #fmove.x #0,fp4
103
97 short 0xf23c
104
98 short 0x4280
105
99 short 0x0000
106
100 short 0x0000 #fmove.x #0,fp5
107
101 short 0xf23c
108
102 short 0x4300
109
103 short 0x0000
110
104 short 0x0000 #fmove.x #0,fp6
111
105 short 0xf23c
112
106 short 0x4380
113
107 short 0x0000
114
108 short 0x0000 #fmove.x #0,fp7
115
109 #endif
116
110 0060 2E7C 0008 mov.l &ISPLOC,%a7
117
110 0000
118
111 0066 4EF9 0000 jmp main_without__main
119
111 0000
120
^L68K GAS temp.s page 12
121
122
123
DEFINED SYMBOLS
124
*ABS*:0000000000000000 asmstart.s
125
asmstart.s:9 .text:0000000000000008 _start
126
asmstart.s:11 .text:0000000000000012 abortstart
127
asmstart.s:6 .text:0000000000000000 INITSP
128
asmstart.s:7 .text:0000000000000004 INITPC
129
130
UNDEFINED SYMBOLS
131
main_without__main
Auf der Zeile 110 steht generierter Code, "0060 2e7c 0008"
aber wo ist der der Zeile 10 (_start) und der darauf folgenden
geblieben?
Im Disassembler sehe ich den code aber
m68k-elf-objdump -S fbug000TT.elf >fbug000TT.disas:
Ich habe es gerade mal kontrolliert, Du meinst sicher einen
Assembleraufruf dieser Art:
/home/holm/cross/m68k/bin/m68k-elf-gcc -c -Wa,-alhn=asmstartport.l
asmstartport.S
...der macht das Selbe wie mein Zeuch oben, also cpp und as
hintereinander, das Listing sieht jedenfalls genauso aus und auch da
fehlen die Code Bytes ab _start...
Allerdings macht es hier wirklich einen Unterschied ob ich '.s' oder
'.S' verwende.
gcc selbst ist ja nur der Compiler driver, der die verschiedenen Pässe
nacheinander ruft, aber zaubern tut der auch nicht. Das geht genauso
wenn man das einzeln macht.
Ich war jetzt nur auf der Suche was "generell" falsch sein könnte und
wollte mir den Initialisierungscode ansehen, dazu wäre ja ein
Assemblerlisting nicht das Ungeeignetste. Irgend Jemand scheint was
dagegen zu haben das ich das alte Schätzchen wecke. Ich habe aber noch
ein 2. identisches und eine "Raubkatze" (nicht meine Idee) mit dem 68332
habe ich auch noch. Es lohnt sich also die Toolchain mal zum Laufen zu
bekommen..
Ich weiß ja nicht wie Ihr das hier so seht, aber für mich hat die
Platine deutlich mehr Sexappeal als ein Arduino...
Gruß,
Holm
Hurra!
Es gibt Forschritte.
Irgendwann schoß mir durch den Kopf, das gemeinsam an allen
ausprobierten printf - Routinen mit Integerausgabe eine Modulo -
Division des Integers zur Zerlegung der Zahl ist. Mein Blick viiel auf
die verwendeten Floatingpoint Routinen bzw. Bibliotheken. Da gibt es ja
bei MC68K eine ganze Anzahl.
Ich hatte folgenden Library Path:
LD_LIBS= -L/usr/home/holm/cross/m68k/lib/gcc/m68k-elf/4.6.2/softfp
LD_LIBS+= -L/home/holm/cross/m68k/lib
LD_LIBS+= -L/home/holm/cross/m68k/m68k-elf/lib/m68000 -lgcc -liberty -lc
Wobei der oberste Teil scheinbar der Schuldige war.
Ich muß nachschalgen was "softfp" denn so zu bedeuten hat, ich hatte mir
was Naheliegendes drunter vorgestellt.
Zur Auswahl stehen da noch:
crtbegin.o libgcc.a m5208 m5475 mfidoa
crtend.o libgcov.a m5307 m68000 plugin
include m51qe m5329 m68040 softfp
include-fixed m5206 m5407 m68060
install-tools m5206e m54455 mcpu32
..und Ersatz der fraglichen Zeile durch
LD_LIBS= -L/usr/home/holm/cross/m68k/lib/gcc/m68k-elf/4.6.2/m68000
führte dazu das endlich was geht:
Thread beobachten
Seitenaufteilung abschalten