DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Programmierung > Assembler/Includes: "unknown mnemonic <funcdef>" | [ - Search - New posts - Register - Login - ] |
-1- | [ - Post reply - ] |
2015-03-19, 18:26 h cgutjahr Posts: 2783 [Administrator] |
Ich versuche etwas m68k-Code mit vasm unter Linux zu assemblieren, das ist mein allererster ASM-Gehversuch auf dem Amiga - bin sonst eher 6502-Fan Der Code beginnt wie folgt (im unter incdir angegebenen Verzeichnis liegt das offizielle 3.9 NDK): code:section Bashii,CODE OPT C-,D+ opt NODEBUG opt p=68000 incdir "/home/christoph/Temp/NDK_3.9/Include/include_i/" include "exec/exec_lib.i" Der Assembler beschwert sich allerdings: code:Was mache ich falsch?$ ./vasm main.s vasm 1.4d (c) in 2002-2009 Volker Barthelmann vasm M68k/CPU32/ColdFire cpu backend 1.1f (c) 2002-2009 Frank Wille vasm motorola syntax module 3.1 (c) 2002-2009 Frank Wille vasm test output module 1.0 (c) 2002 Volker Barthelmann error 2 in line 12 of "exec/exec_lib.i": unknown mnemonic <funcdef> included from line 32 of "main.s" [ - Answer - Quote - Direct link - ] |
2015-03-19, 19:06 h cgutjahr Posts: 2783 [Administrator] |
Geit hat mir weiter geholfen: im 3.9 NDK ist das Macro "FUNDEF" definiert, allerdings ist die Definition in exec/libraries.i auskommentiert. include ich diese Datei und entferne die Asterisks vor der Makro-Definition, kriege ich gleich die nächste Fehlermeldung - merkwürdig. Geit hat mir eine ältere Version von exec/exec.i geschickt, die statt irgendwelche Makros zu verwenden einfach direkt diverse Werte zuweist, Jetzt läuft zumindest der Assembler durch, Allerdings nur bis zu dieser Fehlermeldung: code:fatal error 2035 in line 246 of "glens_code/bullet_hit_routines.s": illegal opcode extension included from line 549 of "main.s" Zeile 246 von bullet_hit-routines.s" sieht so aus: code:moveq.w #1,d2 bsr Change_Block [ - Answer - Quote - Direct link - ] |
2015-03-19, 19:19 h Thore Posts: 2266 User |
"Falsch" ist nicht das richtige Wort, dein Assembler kennt nur nicht das Macro "funcdef". Um zu verstehen, was falsch ist, muss ich bisschen ausholen, wenn Du das nicht wissen willst, les einfach den letzten Abschnitt. Zunächst einmal der Hinweis, dass incdir, include und funcdef keine Assembler-Befehle sind sondern Direktiven, die für das Assembler-Programm (vasm, a68k, phxass,...) sind. Sie erzeugen keine Opcodes. funcdef ist ein Macro einer einfachen Wertezuweisung. Es ersetzt den angegebenen Namen durch ein _LVO<Name> = -<Offset> Eine LVO ist ein Lib-Vector-Offset. Üblicherweise sind sie negativ und fangen üblicherweise bei -30 an, und machen dann 6er Schritte. Jede Library hat seine eigene Offset Tabelle. Jede Lib-Funktion wird in dieser Tabelle addressiert. Beispiel für die Exec Lib, bei Dir sieht das so aus: FUNCDEF Supervisor FUNCDEF ExitIntr FUNCDEF Schedule Wenn das Macro ausgeführt wird, sieht das so aus: _LVOSupervisor EQU -30 _LVOExitIntr EQU -36 _LVOSchedule EQU -42 Das zugehörige Macro wird in exec/funcdef.i definiert: FUNCDEF MACRO *function _LVO1 EQU FUNC_CNT FUNC_CNT SET FUNC_CNT-6 ENDM FUNC_CNT SET 5*-6 Also einfach exec/funcdef.i rein-includen oder Macro definieren (dann aber nicht vergessen, FUNC_CNT am Anfang auf -30 zu setzen) [ - Answer - Quote - Direct link - ] |
2015-03-19, 19:21 h Thore Posts: 2266 User |
moveq kann nicht Word-weise kopieren, sondern nur Byteweise. Daher funktioniert hier das ".w" nicht. Lass das .w einfach weg. [ - Answer - Quote - Direct link - ] |
2015-03-19, 22:24 h cgutjahr Posts: 2783 [Administrator] |
Zitat:Vielen Dank für die ausführliche Antwort. Was Macros sind, ist mir schon klar, ich habe wie gesagt durchaus Erfahrung mit Assemblern und Compilern. Zitat:ein funcdef.i existiert bei mir nicht. Ich hatte heute Mittag bereits mit grep gesucht, das liefert nur Treffer in exec/exec_lib.i (dort wird das Macro benutzt) und in exec/libraries.i, wo es definiert wird - dort ist es allerdings auskommentiert: code:Ist vielleicht das NDK auf os.amigaworld.de lückenhaft? Es macht ja keinen Sinn, Includes zu verteilen die jeder erstmal noch selbst reparieren oder vervollständigen muss...*------ FUNCDEF is used to parse library offset tables. Many applications *------ need a special version of FUNCDEF - you provide your own macro *------ to match your needs. Here is an example: * * FUNCDEF MACRO * _LVO1 EQU FUNC_CNT * FUNC_CNT SET FUNC_CNT-6 * Standard offset-6 bytes each * FUNC_CNT EQU LIB_USERDEF * Skip 4 standard vectors * ENDM Aber wie gesagt, mit Geits exec_lib.i funktioniert es erstmal. Zitat:Ah, danke! Allerdings gibt's den Fall jetzt 70 Mal über sämtliche Codeteile verstreut - werde wohl eine Weile beschäftigt sein Scheinbar kümmert Devpac sich nicht um solche Kleinigkeiten und assembliert einfach weiter. Merkwürdiges Verhalten... [ - Answer - Quote - Direct link - ] |
2015-03-19, 22:59 h cgutjahr Posts: 2783 [Administrator] |
Hm, bin gerade dabei die zahlreichen Fehler zu beseitigen, die der Assembler meldet. Das hier verstehe ich nicht:code:error 2029 in line 1602 of "glens_code/alien_intelligence.s": branch destination out of range included from line 560 of "main.s" Zeile 1601ff sehen so aus: code:Mal abgesehen davon, dass der Code so keinen Sinn macht: ich gehe mal davon aus, dass beq.s für "branch on equal.short" steht - wie um Himmels willen kann das "out of range" sein?tst.w Wind_Change beq.s Dont_Change_Speed Dont_Change_Speed cmp.w #6,Wind_Counter bge.s No_Need_To_Slow_Wind [ - Answer - Quote - Direct link - ] |
2015-03-20, 08:31 h thomas Posts: 7718 User |
@cgutjahr: Ein normaler Branch hat einen 16bit-Offset von der aktuellen Position zum Sprungziel. Mit .s verkürzt sich der Offset auf 8 Bits. D.h. dein Sprungziel (vermutlich No_Need_To_Slow_Wind) ist weiter als +127 bzw -128 Bytes von der aktuellen Position im Code entfernt. -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Answer - Quote - Direct link - ] |
2015-03-20, 14:13 h cgutjahr Posts: 2783 [Administrator] |
Zitat:Ja, so hatte ich beq.s interpretiert. Aber die vom Compiler monierte Zeile 1602 ist das hier: code:und das Sprungziel folgt direkt eine Zeile darunter... Der String "Dont_Change_Speed" taucht laut grep im ganzen Tree nur in diesem Dokument, in den beiden direkt aufeinander folgenden Zeilen auf.beq.s Dont_Change_Speed [ - Answer - Quote - Direct link - ] |
2015-03-20, 14:45 h thomas Posts: 7718 User |
Vielleicht wird der Spezialfall Offset=0 von vasm nicht korrekt behandelt. Oder Offset=0 ist tatsächlich ungültig. So gut kenne ich mich mit den 68k-Feinheiten nicht aus. -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Answer - Quote - Direct link - ] |
2015-03-20, 18:51 h jolo Posts: 110 User |
Ist illegal. Wird trotzdem von manchen Assemblern auf Source-Code-Basis akzeptiert, jedoch beim Übersetzen in ein "NOP" gewandelt. [ - Answer - Quote - Direct link - ] |
2015-03-21, 15:59 h cgutjahr Posts: 2783 [Administrator] |
Bingo! Der Offset war das Problem, ich hab die drei Stellen auskommentiert und ein einwandfrei funktionierendes Binary assembliert Herzlichen Dank euch allen. Allerdings würde mich schon noch interessieren, was es mit dem 3.9 NDK auf sich hat - es kann ja nicht sein, dass die Includes im AUslieferungszustand erstmal nicht benutzbar sind - also entweder habe ich einen Schritt übersehen, oder irgendetwas stimmt mit dem Archiv nicht, oder? [ - Answer - Quote - Direct link - ] |
2015-03-21, 17:33 h Thore Posts: 2266 User |
Die Includes sind benutzbar für die meisten Compiler bzw Assemblierer (ich benutz nun das Wort Assemblierer, um Verwirrung mit "Assembler" an sich zu vermeiden) Der vasm hat ein paar Eigenheiten, die eben die anderen nicht haben. Dafür sind andere etwas zu tolerant in Fehler, wobei man sich schlechte Dinge angewöhnen kann. Die Includes können daher auch nicht für alle gerecht gemacht werden, schon allein weil es den vasm so noch nicht gab, als die erstellt wurden. Auf a68k, phxass und anderen damaligen Standard Assemblern hatte ich nie Probleme. [ - Answer - Quote - Direct link - ] |
2015-03-21, 20:15 h jolo Posts: 110 User |
Zu jedem kommerziellen Assembler damaliger Zeit wurden die passenden, sprich Assembler spezifischen LVO-Dateien ("nnn/nnn_lib.i") mitgeliefert, und die Datei "funcdef.i" geflissentlich ignoriert (anbei, diese Datei ist sowieso Assembler spezifisch und eigentlich nur für "exec/exec_lib.i" erdacht). Liegt darin begründet, dass LVOs nicht zwingend aneinanderhängend in der passsenden "FD"-Datei (also der Beschreibungsdatei zu einer Shared-Bibliothek) angegeben werden müssen, sondern ein Schlüsselwort Verwendung finden kann, um einen privaten Library-Vector-Offset zu deklarieren, der keinen gültigen Namen hat. Zudem kann man in den neueren (1991?) "SFD"-Dateien auch Einträge komplett übergehen, die damit dann gänzlich ohne Bezeichner sind. Da das Makro FUNCDEF aber zwingend reguläre Bezeichner braucht, jedoch private Bezeichner ungültig und unschön sind, ist das FUNCDEF-Makro nicht wirklich passend. Zudem kostet das FUNCDEF-Makro Zeit, um die entsprechenden Offsets zu berechnen, so dass man sich auch noch aus Geschwindigkeitsgründen dafür entschieden hat, direkt die LVOs anzugeben ohne den Umweg über das FUNCDEF-Makro zu nehmen. Zudem waren die von Commodore Amiga publizierten SDKs nicht für alle verfügbaren Assembler passend und mussten dementsprechend sowieso nachgebessert werden, warum also nicht gleich die LVOs direkt hinein schreiben? Zusammenfassung: "funcdef.i" ist Assembler spezifisch. "funcdef.i" ist nur erdacht für "exec/exec_lib.i", die anderen LVOs sollten nach Willen von Commodore Amiga beim Linken der "amiga.lib" entnommen werden. "funcdef.i" ist unschön, weil private Bezeichner Verwendung finden. "funcdef.i" ist zeitaufwändig, weil Berechnungen durchgeführt werden müssen. Gegenmaßnahme: Ersatzlos streichen und aus der Devpac-Entwicklungsumgebung die "nnn/nnn_lib.i"-Dateien klauen. :-) [ - Answer - Quote - Direct link - ] |
2015-03-21, 20:44 h Thore Posts: 2266 User |
Jupp schließ ich mich an. Die Funcdefs waren ein Versuch, die _LVO Equations zu vereinfachen. Aber stattdessen verwirrts nur Ich include übrigens nur bei größeren Projekten. Bei kleineren schreib ich die LVOs raus, das assembliert schneller und es bleibt übersichtlich. Oft schreib ich auch das Offset direkt in den Code rein und mach ein Kommentar, welche Funktion es ist, z.B.: move.l $4,a6 lea dosname(pc),a1 jsr -408(a6) ; Open Lib tst.l d0 beq .errordos move.l d0,dosbase ... [ - Answer - Quote - Direct link - ] |
2015-03-23, 16:16 h woop Posts: 67 User |
Ich bevorzuge die Methode die LVOs aus der amiga.lib oder der small.lib zu linken:code:XREF _LVOGetMsg doSomething: [...] ; use exec.library movea.l _SysBase,a6 jsr _LVOGetMsg(a6) [...] end Nachteile: * Man muss immer linken * zusätzliche XREF-Zeile für jede verwendete Funktion Vorteile: * Im Sinne der Erfinder * Zusätzliche Linkzeiten fallen schon auf kleineren Systemen kaum ins Gewicht * sehr kompatibel unter den verschiedenen Assemblern * keine Fehler durch verwechselte oder falsche Offsets [ - Answer - Quote - Direct link - ] |
2015-03-24, 10:50 h geit Posts: 332 [Former member] |
Ich habe damals Jahrelang mit DevPac programmiert und mir mit List LFormat einen Quellkode erstellt, der alle header includiert. Diese header habe ich dann einmalig zu einem Headerklumpen assembliert. Den habe ich dann einfach in den Settings eingetragen und brauchte in meinen Quellen weder etwas includen noch etwas einfügen. Das Assemblieren dauerte immer gleich lang (1 Sekunde oder so für das Laden der Header), weil nicht ständig nach den selben Dateien auf der Platte gesucht wurde und nur einmal 370 KB (OS3) bis 470 KB (OS3.9) geladen wurden. Man kann keine includes vergessen und wenn ein Fehler auftritt hat man sich vertippt und nicht ein include vergessen. Das habe ich für jede OS Version der includes gemacht, um einfach wechseln zu können, wenn ich spezielle Versionen für ältere Systeme gebaut habe, [ - Answer - Quote - Direct link - ] |
2015-03-24, 16:33 h Holger Posts: 8116 User |
@geit: Das war ja die Spezialität des DevPac, die header in eine vorübersetzte Form bringen zu können (.gs files, wenn ich mich richtig erinnere). Da hat das Einbinden sämtlicher Header deutlich weniger als eine Sekunde gedauert. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
-1- | [ - Post reply - ] |
amiga-news.de Forum > Programmierung > Assembler/Includes: "unknown mnemonic <funcdef>" | [ - Search - New posts - Register - Login - ] |
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |