Bin dabei, ein altes 68k-Programm, das in Motorola 68000 Assembler geschrieben ist, zu übersetzen und anschließend auf STM32-Architektur zu portieren. Da mir die ursprüngliche Plattform - eine PDP-11 mit RT-11 Betriebssystem und dem (damals in Fortran geschriebenen) Motorola Crossassembler nicht mehr zur Verfügung steht, versuche ich unter einem UNIX mit den gnu-binutils das Programm erst mal formal fehlerfrei zu übersetzen. Auch das CP/M68k, das ich damals auch zur Verfügung hatte, ist nativ nicht mehr da, zumal mir die Hardware fehlt. Welchen Assembler nimmt man da am besten? Wo, in welchem Forum, kann man die Assembler Syntax mal diskutieren? Es gibt so einige Themenkreise, zu denen ich Fragen habe. Comments EQU statements mit Labels Immediate Konstanten wahrscheinlich noch mehr Fragen, die kommen werden.
:
Bearbeitet durch User
Christoph K. schrieb: > Bin dabei, ein altes 68k-Programm, das in Motorola 68000 Assembler > geschrieben ist, zu übersetzen und anschließend auf STM32-Architektur zu > portieren. Oh, das wird eine Fleißaufgabe. Von CISC auf RISC portieren... Auch die vielen schönen Adressierungsarten des 68k werden Dir viel Spaß bereiten :-) > Da mir die ursprüngliche Plattform - eine PDP-11 mit RT-11 > Betriebssystem und dem (damals in Fortran geschriebenen) Motorola > Crossassembler nicht mehr zur Verfügung steht, versuche ich unter einem > UNIX mit den gnu-binutils das Programm erst mal formal fehlerfrei zu > übersetzen. Auch das CP/M68k, das ich damals auch zur Verfügung hatte, > ist nativ nicht mehr da, zumal mir die Hardware fehlt. > > Welchen Assembler nimmt man da am besten? Nun ja, ich würde die Version des GAS wählen, die meine CPU unterstützt. Also 68000, -10, -20, -30, -40 oder was auch immer und diese dann auf dem Unix-System compilieren. > Wo, in welchem Forum, kann man > die Assembler Syntax mal diskutieren? Es gibt so einige Themenkreise, zu > denen ich Fragen habe. Besorg' Dir antiquarisch die beiden Bücher von Wener Hilf und Anton Nausch: Die M68000-Familie, te-wi Verlag GmbH. Eine sehr schöne und übersichtliche Darstellung des Assemblerbefehlssatzes (und nein, meine Exemplare gebe ich nicht her :-) > Comments > EQU statements mit Labels > Immediate Konstanten Du kannst doch den GCC Assembler-Code von verschiedenen einfachen Test-Programme, wie "Hello World", erzeugen lassen. Der passt dann zum zugehörigen GAS. Nachtrag: Ein Simulator wäre evtl. auch hilfreich... Grüßle Volker
:
Bearbeitet durch User
Volker B. schrieb: > Christoph K. schrieb: >> Bin dabei, ein altes 68k-Programm, das in Motorola 68000 Assembler >> geschrieben ist, zu übersetzen und anschließend auf STM32-Architektur zu >> portieren. > > Oh, das wird eine Fleißaufgabe. Von CISC auf RISC portieren... > >> Da mir die ursprüngliche Plattform - eine PDP-11 mit RT-11 >> Betriebssystem und dem (damals in Fortran geschriebenen) Motorola >> Crossassembler nicht mehr zur Verfügung steht, versuche ich unter einem >> UNIX mit den gnu-binutils das Programm erst mal formal fehlerfrei zu >> übersetzen. Auch das CP/M68k, das ich damals auch zur Verfügung hatte, >> ist nativ nicht mehr da, zumal mir die Hardware fehlt. >> >> Welchen Assembler nimmt man da am besten? > > Nun ja, ich würde die Version des GAS wählen, die meine CPU unterstützt. > Also 68000, -10, -20, -30, -40 oder was auch immer und diese dann auf > dem Unix-System compilieren. 68000 ist klar. Aber meine Frage war ja, welchen der 68K Assembler nimmt man. gas > >> Wo, in welchem Forum, kann man >> die Assembler Syntax mal diskutieren? Es gibt so einige Themenkreise, zu >> denen ich Fragen habe. > > Besorg' Dir antiquarisch die beiden Bücher von Wener Hilf und Anton > Nausch: Die M68000-Familie, te-wi Verlag GmbH. Es geht mir nicht um den 68000 Instruktionssatz - ich habe das Original Motorola Soft Cover Buch aus 1982. Habe das Programm ja selber geschrieben. In 68k kannte ich mich, und kenne mich vielleicht noch aus. Es geht um die Überführung in die as-Syntax. Der as ist ja ein unverseller Assembler mit verschiedenen backends. Z.B. sagt die man page -m68000 sei der Schalter für die 68k-Codegenerierung/Syntax. Neuere as kennen den Switch aber nicht. Ich finde Seiten im Internet, die setzen auf binutils-2.2.16 (und nicht höher) auf und benutzen m68k-coff-as > Eine sehr schöne und übersichtliche Darstellung des > Assemblerbefehlssatzes (und nein, meine Exemplare gebe ich nicht her :-) > >> Comments >> EQU statements mit Labels >> Immediate Konstanten > > Du kannst doch den GCC Assembler-Code von verschiedenen einfachen > Test-Programme, wie "Hello World", erzeugen lassen. Der passt dann zum > zugehörigen GAS. Was meinst Du mit Testprogramm "Hello World"? Von C rede ich nicht. Es geht um Assembler. gas kennt mein System momentan überhaupt nicht. Ich kenne gas zwar als backend der gcc Compiler. Grüße Christoph
Christoph K. schrieb: > Auch das CP/M68k, das ich damals auch zur Verfügung hatte, > ist nativ nicht mehr da Sogar im Source: http://www.cpm.z80.de/source.html > zumal mir die Hardware fehlt. https://www.crossware.com/m68xxx/Simulator Ob das jedoch der kürzeste Weg ist, ein 68k Programm auf STM32 zum Laufen zu bekommen...
:
Bearbeitet durch User
Habe mit dem 68k noch nicht zu tun gehabt, für andere nutze ich aber gern den AS http://john.ccac.rwth-aachen.de:8000/as/ der kann den 68k unter anderen (Anhang) auch. Ist open source, für unix und (zähneknirschend auch) windows
Michael B. schrieb: > Christoph K. schrieb: >> Auch das CP/M68k, das ich damals auch zur Verfügung hatte, >> ist nativ nicht mehr da > > Sogar im Source: > > http://www.cpm.z80.de/source.html > >> zumal mir die Hardware fehlt. > > https://www.crossware.com/m68xxx/Simulator > > Ob das jedoch der kürzeste Weg ist, ein 68k Programm auf STM32 zum > Laufen zu bekommen... Glaube ich auch eher nicht. Da beschäftigt man sich nur mit Nebenschauplätzen und kommt im eigentlichen Problem nicht weiter. Ich will ja die alte App nicht mehr laufen lassen, sondern das Programm auf die gnu-arm-toolchain umstellen.
Christoph K. schrieb: > Es geht um die Überführung in die as-Syntax. Der as ist ja ein > unverseller Assembler mit verschiedenen backends. Z.B. sagt die man page > -m68000 > sei der Schalter für die 68k-Codegenerierung/Syntax. > Neuere as kennen den Switch aber nicht. Ich finde Seiten im Internet, > die setzen auf binutils-2.2.16 (und nicht höher) auf und benutzen > m68k-coff-as ...weil danach Unix auf M68k langsam ausstarb. Ich habe mir die GCC Crosstools für meine M68K Spielereien auch selber aus den Sourcen hoch gezogen als die moderneren Compiler nur noch Elf Binaries bauen wollten. Gehen tut das also schon... Ich vermute das Du das M86K Programm auf STM32 umsetzen willst und auch Assembler verwenden möchtest (was nicht von vornherein klar ist). Wenn das so wäre würde ich für Beides GAS einsetzen sonst machst Du große Teile der Portierung ein 2. Mal da sich die Pseudo Ops etc wieder ändern würden. сорок две
Christoph K. schrieb: > 68000 ist klar. Aber meine Frage war ja, welchen der 68K Assembler nimmt > man. gas OMG, den, der einem am ehesten zusagt. Du sagst, Du hättes ein UNIX-System, dann nimmt man den, der dort verfügbar ist. Wenn das hochgeheime Unix-System nicht auf 68k basiert, dann wird man wohl oder übel einen Crosscompiler installieren müssen. > Es geht mir nicht um den 68000 Instruktionssatz - ich habe das Original > Motorola Soft Cover Buch aus 1982. Habe das Programm ja selber > geschrieben. In 68k kannte ich mich, und kenne mich vielleicht noch aus. > > Es geht um die Überführung in die as-Syntax. Der as ist ja ein > unverseller Assembler mit verschiedenen backends. Z.B. sagt die man page > -m68000 > sei der Schalter für die 68k-Codegenerierung/Syntax. > Neuere as kennen den Switch aber nicht. Ich finde Seiten im Internet, > die setzen auf binutils-2.2.16 (und nicht höher) auf und benutzen > m68k-coff-as Zuerst solltest Du lernen, wie man sich einen Crosscompiler (und die zugehörigen Tools, wie Assembler und Linker) auf Deinem geheimen Unix-System installiert... > Was meinst Du mit Testprogramm "Hello World"? Von C rede ich nicht. Es > geht um Assembler. Wie lernt man eine neue Sprache? Man hört jemandem zu, der diese spricht. Also kann man sich auch mal angucken, welchen Assembler-Code ein C-Compiler ausspuckt. > gas kennt mein System momentan überhaupt nicht. Ich kenne gas zwar als > backend der gcc Compiler. Das Kommando für den nativen GNU-Assembler ist as. Wenn Dein hochgeheimes UNIX nicht auf der 68k-Familie läuft, dann wird der (g)as nicht 68k sprechen... Hier auf meinem x86_64 Linux gibt es derzeit: as avr-as powerpc-eabivle-as x86_64-w64-mingw32-as arm-none-eabi-as Was meinst Du, wie lustig das Leben wäre, würden die alle nur as heißen... So, und jetzt fragst Du Tante Google ganz lieb danach, wie man auf Deinem Computer einen GCC-Crosscompiler für 68k (der dann auch seinen Assembler mitbringt) installiert... Grüßle Volker
Michael B. schrieb: > Christoph K. schrieb: >> Auch das CP/M68k, das ich damals auch zur Verfügung hatte, >> ist nativ nicht mehr da > > Sogar im Source: > > http://www.cpm.z80.de/source.html > >> zumal mir die Hardware fehlt. > > https://www.crossware.com/m68xxx/Simulator EDIT: Uh, oh, aua. Preisschild. > > Ob das jedoch der kürzeste Weg ist, ein 68k Programm auf STM32 zum > Laufen zu bekommen... Nun ja, hilfreich wäre es schon, wenn man die Funktion des Programms noch mal verifizieren könnte, ehe man mit der Umsetzung beginnt. Und man hätte immer parallel eine Vergleichsmöglichkeit. Werde, jetzt, wo ich den Code übersetzt habe, mir doch mal den Simulator ansehen. Finde da einen Sim68K mit einer grafischen Oberfläche, die nach X11 aussieht, also UNIX. Aber wo gibt es das Produkt?
:
Bearbeitet durch User
Christoph K. schrieb: > Habe das Programm ja selber > geschrieben. Wenn Du die Funktion des Programms kennst, wäre es doch viel einfacher, es auf der neuen Architektur in C zu schreiben. Ich hab auch mal einige Assemblerprogramme auf C umgeschrieben. Sie wurden dadurch schneller und kleiner. Der Hauptgrund war aber die Portierbarkeit und Erweiterbarkeit. Programme müssen eigentlich immer erweitert werden, solange sie benutzt werden.
Peter D. schrieb: > Christoph K. schrieb: >> Habe das Programm ja selber >> geschrieben. > > Wenn Du die Funktion des Programms kennst, wäre es doch viel einfacher, > es auf der neuen Architektur in C zu schreiben. > Ich hab auch mal einige Assemblerprogramme auf C umgeschrieben. Sie > wurden dadurch schneller und kleiner. Der Hauptgrund war aber die > Portierbarkeit und Erweiterbarkeit. Programme müssen eigentlich immer > erweitert werden, solange sie benutzt werden. Die Idee, von Assemblercode auf C zu wechseln, ist zwar nicht grundsätzlich falsch, um nicht zu sagen, oft sogar geraten, weil ein C-compiler samt Optimizer besser in Assembler programmieren kann als ein menschliches Wesen. Bei meinem Programm handelt es sich um 5000 Zeilen Code, die ungefähr 800 Zeilen Assembler für den Kern enthalten. Zusätzlich noch ein in 68k-Assembler geschriebenes Floating-Point Paket von ca. 1000 Zeilen. Letzteres in C umzuschreiben ist nicht sinnvoll. Der Rest ist threaded code. Das Gebilde ist äußerst kompakt geschrieben. Grüße Christoph
:
Bearbeitet durch User
Christoph K. schrieb: [..] > Die Idee, von Assemblercode auf C zu wechseln, ist zwar nicht > grundsätzlich falsch, um nicht zu sagen, oft sogar geraten, weil ein > C-compiler samt Optimizer besser in Assembler programmieren kann als ein > menschliches Wesen. > > Bei meinem Programm handelt es sich um 5000 Zeilen Code, die ungefähr > 800 Zeilen Assembler für den Kern enthalten. Zusätzlich noch ein in > 68k-Assembler geschriebenes Floating-Point Paket von ca. 1000 Zeilen. > Letzteres in C umzuschreiben ist nicht sinnvoll. Es hört sich an als ob Du da ein eigenes OS programmiert hättest..ok. Allerdings stellt sich die Frage in wie fern es sinnvoll ist ein eigenes Floatingpoint Paket für den STM32 aus M68k portieren zu wollen, das ist Zeug das es fix und fertig in Bibliotheken gibt und es wird nicht der ineffizienteste Code sein... сорок две
сорок две schrieb: > Christoph K. schrieb: > [..] ... >> Bei meinem Programm handelt es sich um 5000 Zeilen Code, die ungefähr >> 800 Zeilen Assembler für den Kern enthalten. Zusätzlich noch ein in >> 68k-Assembler geschriebenes Floating-Point Paket von ca. 1000 Zeilen. >> Letzteres in C umzuschreiben ist nicht sinnvoll. > > Es hört sich an als ob Du da ein eigenes OS programmiert hättest..ok. > Allerdings stellt sich die Frage in wie fern es sinnvoll ist ein eigenes > Floatingpoint Paket für den STM32 aus M68k portieren zu wollen, das ist > Zeug das es fix und fertig in Bibliotheken gibt und es wird nicht der > ineffizienteste Code sein... > Ja, das FP-Paket ist auch nicht so wichtig, ehrlich gesagt, oder zumindest sekundär. Das wird man nicht 1:1 portieren können. Da hast Du recht. -- Christoph
Ist denn der 68K ASM-Quellcode in der Motorola Syntax oder der kruden gas Syntax? Was genau willst Du simulieren mit einem 68K Simulator? Die I/Os Deiner HW gibt jener ja nicht her. Singlestep, um Programmpfade zu durchlaufen?
Hausaufgabenhelfer schrieb: > Ist denn der 68K ASM-Quellcode in der Motorola Syntax oder der kruden > gas Syntax? > Was genau willst Du simulieren mit einem 68K Simulator? Die I/Os Deiner > HW gibt jener ja nicht her. Singlestep, um Programmpfade zu durchlaufen? Der ist noch in der Motorola Syntax. Was ich Simulieren will? Das kommt drauf an, was mir der Simulator bietet. Wenn er eine Möglichkeit hat, eine Terminal-Funktion (virtuelles Terminal) nachzubilden, so daß das Programm Ausgaben machen kann und Eingaben empfangen kann, wäre es ganz nützlich. Parallel würde ich gerne den STM32 Code testen. Der könnte natürlich in dem Nucleo Board laufen. Oder gibt's evtl. für die STM32 ARchitektur auch einen Simulator? Übrigens hat ja der STM32F4 eine eigene FPU. Da wäre mein Floating Point Paket ohnehin obsolet.
:
Bearbeitet durch User
Christoph K. schrieb: > Der ist noch in der Motorola Syntax. Du Glücklicher ;-) Von Alan Clements gibts ein 68K Buch (Diskette mit Cross-ASM und Simulator) https://www.amazon.de/68000-Family-Assembly-Language-Engineering/dp/0534932754/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=0534932754&qid=1598025305&sr=8-1 Buch & Disk habe ich hier, aber Disk noch nie benutzt, da ich "native" 68K Assembler nutze.
Moin, Um irgendwelches Zeugs, was auf anderen (als x86) Prozessoren laufen muss, auf einem PC laufen zu lassen, wuerd' ich mal Qemu in den Ring schmeissen. Gruss WK
Hausaufgabenhelfer schrieb: > Christoph K. schrieb: > >> Der ist noch in der Motorola Syntax. > Du Glücklicher ;-) > > Von Alan Clements gibts ein 68K Buch (Diskette mit Cross-ASM und > Simulator) > https://www.amazon.de/68000-Family-Assembly-Language-Engineering/dp/0534932754/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=0534932754&qid=1598025305&sr=8-1 > > Buch & Disk habe ich hier, aber Disk noch nie benutzt, da ich "native" > 68K Assembler nutze. Interessant. Könntest Du mir das Buch mit Diskette "zur Ansicht" schicken? Was für eine Diskette ist es? 3,5". Hatte mein System ja gerade für das Verarbeiten von 5.25" Disketten präpariert. Grüße Christoph
Christoph K. schrieb: > Interessant. Könntest Du mir das Buch mit Diskette "zur Ansicht" > schicken? Ich verleih nix mehr. > Was für eine Diskette ist es? 3,5". Hatte mein System ja gerade für das > Verarbeiten von 5.25" Disketten präpariert. 3.5" (aber sind nur so 180KB) Eventuell hilft aber schon dies hier: http://www.easy68k.com/features.htm https://github.com/BSVC/bsvc
Auch wenn es schon gesagt wurde ist die Umstellung auf C das einzige sinnvolle. Ich musste das schon öfter machen alles (8048 8051) ASM und nicht von mir selbst geschrieben und schlechte Doku. Dann ist es auch relativ egal wo der Code nachher läuft. Die ganzen Hardware Sachen mal ausgenommen, die sind immer anzupassen.
Peter schrieb: > Auch wenn es schon gesagt wurde ist die Umstellung auf C das einzige > sinnvolle. Nein, nein und nochmals nein! Wie kannst Du das so pauschal hier behaupten, was in irgendeinem Falle "das einzig Sinnvolle" sei?
Klar kann man 68k in stm32 ASM um schreiben, das will der TO ja anscheinend machen. Aber wer macht ernsthaft so einen Blödsinn? Gut es gibt Leute die Programme immer in ASM schreiben und sich wundern warum andere einfach mal ihrem Code auf ein anderes System portieren können. Wenn der TO das so will wünsche ich viel Erfolg.
Volker B. schrieb: > Auch die vielen schönen Adressierungsarten des 68k werden Dir viel Spaß > bereiten :-) Weit knackiger als die Adressierungsarten ist, dass der ARM zu wenig Register hat, um eine stressarme 1:1 Umsetzung innerhalb der Register zu ermöglichen. Die haben zwar beide nominell 16 Register, aber beim ARM gehen zusätzlich PC und Link-Register weg, zudem braucht man mindestens 2 freie Register für Temps bei der Umsetzung komplexer Befehle und Adressierungen. Der einfachste quick and dirty Weg könnte drauf rauslaufen, die Dx Register der 68000 mindestens teilweise ins RAM zu legen. Das bremst, ermöglicht aber eine schematische 1:1 Umsetzung. Ein weiterer Knackpunkt kann die Byteadressierung sein, weil big- zu littleendian.
:
Bearbeitet durch User
Christoph K. schrieb: > Da mir die ursprüngliche Plattform - eine PDP-11 mit RT-11 > Betriebssystem und dem (damals in Fortran geschriebenen) Motorola > Crossassembler nicht mehr zur Verfügung steht, Es dürfte PDP-11 Emulatoren geben, die die damalige Kiste weit in den Schatten stellen, und auch so manche Programme aus dieser Ära finden sich in auf Computer-Archäologie spezialisierten Sites.
Wenn's nicht unbedingt die m68k-gcc Toolchain sein muss, würde ich wahrscheinlich einen anderen Assembler benutzen. Den hier, z.B.: http://sun.hasenbraten.de/vasm/ Hintergrund: gas/m68k ist zwar recht leistungsfähig, weicht teilweise aber enorm von der Motorola-Assembler Syntax ab, so dass der Portierungsaufwand recht hoch und - solange man den Code noch nicht verstanden hat - enorm fehleranfällig sein dürfte. vasm dagegen versteht die "zeitgenössische" Syntax weitgehend. Wenn das Ziel aber die Portierung auf eine andere Plattform sein soll, würde ich bei der gnu-Toolchain bleiben und den Aufwand auf mich nehmen. Dann kann man nach und nach einzelne Code-Bestandteile, deren Sinn man verstanden hat, in C übersetzen und (z.B. mit einem der vielen Atari ST Emulatoren) testen, ob's noch so funktioniert wie gedacht. Idealerweise bleibt am Schluss nur noch C-Code übrig, der mit wenig Aufwand auf der Zielplattform zum Laufen gebracht werden kann. Für mich wäre die Frage, ob sich der Aufwand lohnt oder ob's das Programm auf einem der Emulatoren (von mir aus auch QEMU) nicht genauso tut? Falls es mehr als ein Hobbyprojekt sein sollte, auch mal hier vorbeischauen: http://microapl.com/Porting/PortAsm68Kto86.html m68k nach ARM gibt's da nicht, aber m68k nach C können die. Und zwar ziemlich gut...
Falls es doch m68k-gas sein soll, ein paar erste Tips zum Einstieg: gas will %-Zeichen vor den m68k-Registernamen sehen. Man kann ihm das mit der Option --register-prefix-optional abgewöhnen gas akzeptiert weder "*" noch ";" als Kommentarzeichen. Standardmässig nur "|" (was dann aber bedeutet, dass man kein logisches OR mehr hat). Abhilfe erreicht man durch den C-Präprozessor (Dateiendung ".S" statt ".s" und gcc statt gas aufrufen). Dann kann man statt "|" die C++ Kommentarzeichen "//" verwenden. Entsprechend muss (weil man ja den gcc-Treiber benutzt) das obige "--register-prefix-optional" "-Wa,--register-prefix-optional" heissen.
1 | LABEL: equ xxx |
muss in
1 | .equ LABEL, xxx |
umgesetzt werden. Noch was: gas ist ein Ein-Pass-Assembler. "Verkürzte Sprünge" muss man also selber basteln (und wenn's dann doch nicht reicht, auch selber reparieren).
Markus F. schrieb: > Falls es doch m68k-gas sein soll, ein paar erste Tips zum Einstieg: > ... >
1 | > LABEL: equ xxx |
2 | > |
> > muss in > >
1 | > .equ LABEL, xxx |
2 | > |
> umgesetzt werden. > > Noch was: gas ist ein Ein-Pass-Assembler. "Verkürzte Sprünge" muss man > also selber basteln (und wenn's dann doch nicht reicht, auch selber > reparieren). Danke für die Tips. Habe die Source jetzt schon kompiliert bekommen mit dem "asl". Ließ sich relativ leicht umstellen. Für die STM32 Programmierung werde ich bei der gnu toolchain bleiben.
Bitte 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.