|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > 68K Assembler | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
10.12.2010, 00:02 Uhr fisch08 Posts: 692 Nutzer |
Hallo, zur Erinnerung an alte Zeiten wollte ich mal wieder ein wenig in 68k Assembler programmieren. Mein Amiga (2000er) hat OS 3.9... Welchen Assembler kann man denn da nehmen? Früher (TM) hatte ich den Devpac Assembler, aber den habe ich nur in der 1.2er Version, etwas moderner darf es schon sein. Gibt es einen guten Freeware Assembler? Oder aber: Welche Lösung gäbe es denn für die Programmierung auf z.B. Linux Systemen und anschließender Portierung auf einen richtigen Amiga (oder Emulator)? Gruß Fisch08 -- Um den Spamfilter zu umgehen: Bei direkter Antwort per Mail bitte "[Amiga]" ins Subject: Nur so 100%ige Garantie, dass man nicht im Filter landet! [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 01:36 Uhr wawa Posts: 314 Nutzer |
@fisch08: kenn mich mit asm nicht aus, aber vasm soll gut sein und ist vermutlich als einzige platformübergreifend. dazu gibt es nen disassembler, falls vonnöten: adis. und auch nen c compiler desselben authors: vbcc. alles wird recht hoch gelobt, habe aber selbst nur wenig erfahrung mit vbcc und eine stunde mit adis und vasm, kann daher nicht viel sagen. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 09:58 Uhr Thore Posts: 2266 Nutzer |
PhxAss find ich sehr gut, der kann auch verschiedene Prozessoren und Optimierungen. Außerdem linkt er bei bedarf selbst (was z.B. der a68k nicht macht, und man blink zusätzlich braucht) Die vxxx (vasm,...) Reihe hab ich noch nicht getestet aber scheint als kenne er mehrere Prozessortypen. Hört sich interessant an, aber wie gesagt, keine Erfahrungswerte. Portable Programme kannst Du z.B. mit gcc machen, wenn du die ixemul verwendest, kannst sogar die Pfadnamen auf Linux-Style lassen. Ich empfehl dazu eine GeekGadgets Installation auf dem Amiga [ Dieser Beitrag wurde von Thore am 10.12.2010 um 09:59 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 12:08 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was heißt "moderner"? Im Sinne einer IDE? Da fällt mir außer Devpac eigentlich nichts ein. Alle anderen Assembler sind Kommandozeilentools. Bzw. auf der nostalgischen Ebene gibt es noch einige Assembler, die mit einem hardkodierten Texteditor versehen sind, deren Komfort selbst gegen die Kombination von "ed" und einem Kommandozeilenassembler alt aussieht. Zitat:Nun, bei vasm bekommt man immer wieder etwas von einer Weiterentwicklung mit, letzte Meldung: http://www.amiga-news.de/de/news/AN-2010-12-00011-DE.html Zitat:Da lautet die Antwort wiederum vasm. Hier gibt es lauter Binaries für diverse Host/Target Kombinationen: http://sun.hasenbraten.de/vasm/index.php?view=binaries Allerdings sind einige nicht auf dem aktuellsten Stand. Da müsstest Du für die aktuellste Version den Source Code selbst übersetzen. Zitat:Ich glaub, die Syntax des gas weicht erheblich von der von anderen Amiga Assemblern gewohnten ab. Und portabel sind da trotzdem nur die C Programme, nicht die Assemblerprogramme. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 12:47 Uhr DieterG Posts: 164 Nutzer |
Ich mag den ASM-Pro, ist eine der weiterentwicklungen des ur-Amiga-Assemblers Seka. Und ja, er hat einen integrierten Editor, der gewöhnungsbedürftig ist, aber dann schnell und zuverlässig das tut, was er soll, und vor allem bei sehr langen Sourcecodes, wo die meisten Editoren nur noch Gurus produzieren läuft dieser. Er hat auch modererne Features, wie z.B. Sysntax-Highlighting. kommt bald eine aktuallisierte version von raus. Und wem der editor nicht gefällt, der kann ja auch seinen persönlichen liebling nehmen, und asmpro nur zum assemblieren benutzen. Vom debugging her und seinen fähigkeiten kommt an den ASm-Pro hächstens noch der ASMONE dran, auch ein Seka-Clone. Der kann z.B. auch PPC-Code erzeugen, aber der Editor ist echt nervig und zudem stürzt der zumindest bei mir unter OS4.1 immer nur ab. vasm ist zwar gut, kann aber mit vielen üblichen Macros nicht umgehen, also eher was für kleinere Projekte. Devpac ist nicht mehr zu empfehlen. Es gab auch noch andere, wie Maxxon-ASM, die einfach überaltert sind, damit würde ich mich garnicht erst abgeben. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 13:50 Uhr jolo Posts: 110 Nutzer |
@DieterG: Das mit den Makros musst Du mir mal erklären!  Inwiefern ist 'vasm' inkompatibel zur Motorola Spezifikation bezüglich Makros? Denn nur diese offizielle Spezifikation wird von 'vasm' unterstützt. Die halbgare, von K-Seka eingeführte Syntax wird nicht und wurde von keinem anderen Assembler als K-Seka und deren Klone unterstützt. Der de facto Standard und die Referenz für die Assemblerprogrammierung unter AmigaOS war Devpac 3.x; dieser Assembler hielt sich strikt an die von Motorola festgeschriebene Syntax - und das Gleiche gilt für 'vasm'. Das gerade 'vasm' nur für kleine Projekte sinnvoll erscheint, ist nicht ganz Dein Ernst, oder? Wenn es rein um Hardwarebanging geht kann man gut auf K-Seka und Klone zurückgreifen; wird man aber offiziellen Quellen folgen - und systemkonforme Programme oder Funktionsmodule erstellen wollen, greift man gewöhnlich auf Include-Dateien zurück, die noch zu Commodore-Amigas Zeiten erstellt wurden und hundertprozentig der Motorola Spezifikation unterliegen, und meine persönliche Erfahrung mit K-Seka und Klonen ist, dass eben jenes es sind, die Probleme damit haben. Welchen Assembler man verwendet, hängt zum Großteil vom persönlichen Geschmack und Einsatzbereich ab. Ich persönlich bevorzuge Devpac und 'vasm, wobei 'vasm' seinesgleichen derzeit sucht, oder kannst Du mir irgendeinen Assembler nennen, der außer 'vasm' als Cross-Assembler verwendbar wäre? 'gas' hat seine eigene Syntax wie Holger schon geschrieben hat und scheidet damit aus. Zudem läuft 'vasm' auch ohne irgendwelche Tricks unter anderen Betriebssystemen (keine UNIX-nachgebildete Umgebung von Nöten oder einen AmigaOS kompatiblen 68k-Emulator), sei es nun Atari OS, BSD, Linux, MacOS oder Windows. Komischerweise haben wir dank Frank Wille mit 'vasm' einen aktuellen Assembler der noch dazu gepflegt wird und verschiedenste Architekturen unterstützt, sei es nun CPUs oder Betriebssysteme, aber bei Hobby-Programmierern hält sich nach wie vor noch das Gerücht, dass ein K-Seka Klon kompatibler wäre, was ich jetzt mal ins Reich der Märchen verbanne. Wie gesagt, Du magst ASM-Pro, ich mag 'vasm', aber solche Behauptungen wie: "...also eher was für kleinere Projekte" kann ich einfach nicht stehen lassen. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 14:30 Uhr Thore Posts: 2266 Nutzer |
> Ich glaub, die Syntax des gas weicht erheblich von der von anderen Amiga Assemblern gewohnten ab. Richtig, ich hätte hier "als C/C++-Compiler" hinzuschreiben müssen, das gcc umfasst ja mehrere Compiler. Ich war nicht genau genug. Mit Assembler portierbar zu sein ist schwierig bis unmöglich. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2010, 16:06 Uhr AGSzabo Posts: 1663 Nutzer |
Ich verwende EUAE unter linux zum amiga-entwickeln und darauf dann phxass. viel spass ^^ -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2010, 00:01 Uhr DieterG Posts: 164 Nutzer |
@Jolo: Ich habe nie behauptet, vasm hält sich nicht an den Motorola-standard. Und selbst der wurde ja schon in der Zeit der weiterentwicklung vom 68000 zu höheren Prozessoren von Motorola selbst geändert:-) Die Frage ist doch, muss man sich daran halten, wenn er an vielen Stellen verbesserungsbedürftig ist, oder muss man diese schwächen hinnehmen ? Zum vasm: versuch mal einer der vielen ASM-Sourcecodes vom Aminet mit diesem ohne Modifikation zu assemblieren, bei den meisten wird das scheitern. Ich habe das probiert, ausser vielen auf den ersten Blick sinnlosen Fehlermeldungen des vasm kam dabei nie was raus. Man muss anhand der fehlermeldungen noch schwer raten, was er eigentlich zu meckern hat, und findet dann oftmals heraus, das es an macros liegt, die man so in vasm garnicht nachbilden kann. Das Hauptproblem des vasm scheint zu sein, das er sowas wie "lokale Labels" nicht unterstützt, was bedeutet jeder verwendete Label ist auch in der Symboltable enthalten und darf nur einmal verwendet werden, somit muss z.b. jeder loop anders heissen, das erschwert alles. Zudem hat er die C-typischen Nachteile alle übernommen, was auch nicht Motorolastandard ist. Und was nützt mir das strikte halten an den Motorolastandard, wenn ich doch verscheidene Plattformen als ziel unterstütze ? Nicht alle Prozessoren sind von Motorola ! Also wie gesagt, für kleinere Projekt ist der vasm durchaus geeignet, aber bei grösseren ist schon allein die labelbennenung oder das fehlen eines internen versions oder datummacros nervig. Eben wie in C, muss man alles extern selber machen, der ASM-Pro z.B.unterstützt einen da viel besser. Und ich hatte auch noch keine Schwierigkeiten Includes einzubinden oder zu linken oder was auch immer. Was ich aber eigentlich sagen wollte, für einen der sich relativ neu wieder mit dem Thema 68k-Assembler beschäftigen will, sind schon allein die meisten alten Bücher, Kurse, Anleitungen und Beispielcodes besser auf einem Sekaclone nachzuvollziehen, da diese meistens älter sind, und es da einfach noch kein vasm gab. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2010, 08:48 Uhr hansfaust Posts: 56 Nutzer |
@fisch08: Wenn es um AMIGA (!) Programme geht und nicht "nur" um einen 68k Assembler: SNMA Assembler Der ist schnell, kann Makros und ein Linker wird nicht benötigt, da er auch gleich ausführbare Programme erzeugen kann. Nachteil: Geht nicht so gut für große Programme, da er sehr speicherintensiv arbeitet. Gut, wenn man schnell "mal 'was" in Assembler schreiben will. Barfly Assembler Entwicklungsumgebung Ralph Schmidt hat sein Assembler-Entwicklungspaket als Giftware herausgebracht. Enthält alles nötige, inclusive Werkzeuge zum debuggen. Ist auf dem AMIGA im Moment wohl mit das Beste, was man kriegen kann für Assembler-Programmierung. -- BarsnPipes der beste Multimedia-MIDI-sequencer der jemals für den AMIGA gemacht wurde [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2010, 11:31 Uhr Polluks Posts: 105 Nutzer |
@Thore: Noch genauer: Die GCC (GNU Compiler Collection) umfasst mehrere Compiler, beispielsweise den gcc.  -- Pegasos II G4, MorphOS 2.6 Power Mac G3 [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2010, 19:47 Uhr jolo Posts: 110 Nutzer |
@DieterG:Zitat: Du stellst aber Behauptungen auf, die so missverständlich formuliert wurden, dass ich zu Schlussfolgerungen kommen muss, die rein gar nicht Deinen Aussagen entsprechen. Zitat: Hättest Du geschrieben, dass ASM-Pro Makros erlaubt, die weit über das hinaus gehen was Motorola spezifiziert hat sowie von anderen Assemblern erst gar nicht unterstützt werden, so dass man nur die K-Seka-Klone benutzen kann, um solch verfasste Quellcodes zu übersetzen, hätte ich bestimmt nicht nachgefragt. Zitat: Nee, nur erweitert, bedingt durch die 68020 Adressierungen wie Du weißt. Zitat: Innerhalb von Makros? LabelName@ Entspricht somit der offiziellen Motorola m68k Notation. Oder innerhalb des Quellcodes auf Dateiebene? n$ Auch offiziell... Es geht auch in neueren 'vasm' Versionen mittels: .LabelNamen was aber nur eine Devpac Variante ist aber von anderen Assemblern abgekupfert wurde. Wie definieren die K-Seka-Klone lokale Bezeichner, dass 'vasm' sie nicht handhaben kann (darf?)? Zitat: Da magst Du Recht haben, die Frage die sich mir aber stellt ist, ob es an 'vasm' oder am Autor des betreffenden Quellcodes liegt, der *nicht* die offizielle Schreibweise benutzte. Ich habe selber K-Seka, C-Seka sowie MasterSeka Ende der 1980er und Anfangs der 1990er Jahre verwandt, bis ich Anfang 1991 sporadisch Devpac 2 benutzte um Vollendends in 1992 auf Devpac 3 umstieg. Dass meine damaligen Quellcodes nicht mehr von Devpac akzeptiert wurden, lag nicht an Devpac 2/3 sondern an (den) K-Seka (-Klonen). Dafür habe ich dann einen Konverter geschrieben, der den K-Seka Syntax, inklusive Makro-Schreibweise, in die offizielle Motorola Syntax umwandelt. Lange Rede, schwacher Sinn: Es gibt eine offizielle Norm an die man sich halten sollte, wenn man sicherstellen will, dass ein Quellcode von verschiedenen Assemblern akzeptiert wird. Verwendet man spezielle Merkmale eines Assemblers, sollte man nicht dem Autor des fremden Assembler Unterlassung/Nachlässigkeit unterstellen, sondern sich selber fragen, ob man zwingend solche Besonderheiten nutzen muss, wenn man seine Quellcodes offen legt. Wenn ich Dich richtig verstanden habe, so lassen sich viele Assembler Quellcodes die im Aminet freigegeben wurden nicht mittels 'vasm' assemblieren, weil sie auf einen bestimmten Assembler zugeschnitten sind. Deshalb aber 'vasm' als nicht kompatibel abzustufen halte ich für arg unfair dargestellt (gelinde gesagt).  Zitat: Dir ist schon klar, dass 'vasm' von Dr. Volker Barthelmann ins Leben gerufen wurde, um einen portablen Assembler für verschiedene Hosts und Targets für seinen C-Compiler zu erhalten, und sich nicht nur auf m68k beschränken zu müssen. Soweit ich weiß, benutzte er anfangs Frank Willes PhxAss (m68k Assembler) und PhxLink (AmigaDOS Linker). Erst nachdem sich Frank Wille 'vasm' angenommen hat wurde aus 'vasm' ein universeller, Standards entsprechender und vielseitiger Assembler, wobei 'vasmm68k-mot' (der m68k vasm) nach wie vor noch in der Lage sein muss, den von 'vbcc' erstellten Code zu übersetzen, was nicht zuletzt ein gewisses Maß an Abwärtskompatibilität (Altlast!) zu PhxAss beinhaltet. Nichtsdestotrotz kann man ( zumindest ich ) klaglos Devpac erstellte Quellcodes mit 'vasmm68k-mot' übersetzen.Zitat: Kannst Du mir mitteilen, was Du damit meinst? 1) Was sind verschiedene Plattformen für Dich? 2) Welche Auswirkungen auf die Syntax hat eine in Linzenz gefertige 680x0 CPU? Irgendwie verstehe ich Dich nicht so ganz. Zitat: Erstens, in C ist es einfacher gelöst, einfach '__DATE__' spezifizieren. Zweitens hat es je nach Geschmack mehr Vor- oder Nachteile, wenn eine automatische Versionskontrolle ausgeführt wird. Ich persönlich mag überhaupt keine automatische Versionsänderung ohne meine explizite Angabe. Wie gesagt, andere mögen es, aber eben nicht jeder. Drittens, ob ein Assembler für größere oder kleinere Projekte von Vorteil ist, liegt bestimmt nicht an solchen Details, sondern ob der Assembler imstande ist, in einer akzeptablen Zeit den Quellcode zu übersetzen. Bei größeren Projekten wird man sowieso mehrere Module schreiben, die man anschließend 'linkt' und nur die veränderten Dateien neu assemblieren. Da 'vasm' sowohl direkt ausführbaren Code also auch linkbaren Code generieren kann als auch die Übersetzungszeiten akzeptabel sind, kann 'vasm' sowohl für kleinere als auch für große Projekte verwenden. Anbei: Wäre ich tippfaul, so würde ich für kleine Projekte einen Assembler mit IDE vorziehen, weil dies bequemer für mich wäre, als über die Kommandozeile den Assembler aufzurufen. Erst bei größeren Projekten geht es sowieso nicht mehr ohne den Umweg über die Kommandozeile um ein Skript oder ein 'makefile' aufzurufen, da meines Wissens nach keine Assembler-IDE eine 'Make'-Umgebung nachbildet. Zitat: Aber es gab eine Norm, dem der MetaComCo Assembler voll entsprach, und dieser wurde dem Entwicklerpaket beigefügt, bzw. man konnte diesen nachbestellen (Kickstart 1.1/Kickstart 1.2). K-Seka hatte eine sehr große Fan-Gemeinde bei den Hobby-Programmierern, die ohne das Betriebssystem auskamen, nicht zuletzt wegen seiner rasanten Assemblierungsgeschwindigkeit. Leider entsprach er weder den Motorola Spezifikationen noch bot er einen Link-Modus an, was ihn für größere Projekte disqualifizierte. Erst mit den Klonen kam sowas wie Kompatibilität auf. Leider erbten diese Klone aber auch die schlechten Eigenschaften, z.B. 'blk' statt 'dcb' oder 'An,bd' anstatt 'bd,An'. Ich habe mehrere 68k Assembler Bücher hier, aber nur eines benutzt den K-Seka Syntax, und zwar jenes, welches ohne das Betriebssystem die Hardware direkt anspricht, zudem kann ich die Quelltexte dieses Buches keinem empfehlen, da alle möglichen Optimierungsmöglichkeiten außer Acht gelassen wurden sowie mittels 'clr.w' Hardwareregister gelöscht wurden, wobei jeder weiß, dass das unter einer 68000er fatale Folgen hat, weil ja auch ein Read-Zyklus vor dem Löschen durchgeführt wird. Bei Nur-Schreibregister wird's dann bunt... Um es kurz zu machen: Über die Güte eines Quellcodes sagt der verwendete Assembler nichts aus. Um meine Sichtweise der Dinge mal darzulegen: Ich habe nichts gegen die Verwendung von Assembler XYZ einzuwenden, jedem das seine, was ich aber nicht stehenlassen will, sind Behauptungen, bei denen Ursache und Wirkung meinem Erachten nach vertauscht werden. Werden spezielle Charakteristiken eines Assemblers verwendet, darf man nicht mokieren, dass der betreffende Quellcode sich nur mit diesem Assembler übersetzen lässt. Z.B. erlauben Devpac und 'vasm' das Weglassen des Semikolons vor Kommentaren; andere Assembler erlauben es nicht. Will man seinen Quellcode veröffentlichen, sollte man die Notation verwenden, die alle Assembler verstehen, demnach sollte man das Semikolon verwenden. Hier einfach behaupten, dass andere Assembler nicht kompatibel genug wären, wäre zu kurz gegriffen. Bevor ich in der Vergangenheit Quellcodes, die mit Devpac erstellt wurden offen gelegt habe, wurde mittels PhxAss und SNMA gegengeprüft, ob sie sich unverändert assemblieren ließen. Andere hätten auf die gleiche Idee kommen können und somit anderen viel Arbeit erspart. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2010, 20:22 Uhr fisch08 Posts: 692 Nutzer |
@AGSzabo: Hast du ein paar Hinweise zu deiner verwendeten Konfiguration? Ein kleines "Hello world.asm" Demo? -- Um den Spamfilter zu umgehen: Bei direkter Antwort per Mail bitte "[Amiga]" ins Subject: Nur so 100%ige Garantie, dass man nicht im Filter landet! [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2010, 10:10 Uhr AGSzabo Posts: 1663 Nutzer |
@fisch08: Configuration von phxass? Das ist nur eine Kommandozeile, ich suche es Dir nacher heraus wenn du willst. Ich habe kein hello world, aber die sourcen von meinem GUI-system. wäre das was? daraus kann man ersehen wie die inlcudes funktionieren und es sind batch dateien dabei zum assemblieren, aus denen hervor geht wie die kommandozeile dazu lautet: http://www.psi5.com/~silva/afilter/#ox (auf "download new version" clicken) -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2010, 18:37 Uhr Der_Wanderer Posts: 1229 Nutzer |
Für Anfänger wäre evtl. auch Amiblitz3 zu empfehlen. Dort gibt es eine grafische IDE, einen Source Level Debugger, auch unter WinuAE kann man Memory Hits anzeigen lassen etc. Und wenn man zu faul ist, kann AB3 das "drumherum" machen und man konzentiert sich auf seine Routine. Beispiel: code:MOVE.l #3,D0 MOVE.l #7,D1 ADD.l D1,D0 MOVE.l D0,result.l@(A5) NPrint "Ergebnis: ",result End Das Prog würde 3+7=10 ausrechnen, in die Basic Variable result schreiben und auf der Console ausgeben. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 13:08 Uhr Thore Posts: 2266 Nutzer |
welchen Assembler verwendet AmiBlitz denn? PhxAss? (Ich entnehme dem Code daß es Inline Assembler Code ist) [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 13:14 Uhr Thore Posts: 2266 Nutzer |
Ein Hello World ist easy gemacht:Assembler code:_LVOOpenLibrary EQU -552 _LVOCloseLibrary EQU -414 _LVOOutput EQU -60 _LVOWrite EQU -48 start: move.l 4,a6 ; ExecBase holen lea dosname(pc),a1 ; Dosname Adresse laden moveq #0,d0 ; Version egal jsr _LVOOpenLibrary(a6) tst.l d0 beq.s error move.l d0,a6 ; Dosbase nach a6 lea text(pc),a0 ; Text Adresse laden move.l a0,d2 move.l #13,d3 ; Textlength holen jsr _LVOOutput(a6) ; Output handle holen move.l d0,d1 jsr _LVOWrite(a6) ; schreiben move.l a6,a1 move.l 4,a6 jsr _LVOCloseLibrary(a6) ; Aufräumen error: moveq #0,d0 rts ;Und weg dosname: dc.b 'dos.library',0 text: dc.b 'Hello World!',13, 10,0 Für Fehler da untested bitte Korrektur [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 17:53 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich glaube, Output() ist eine AOS2.0 Funktion, daher ist "Version egal" beim Öffnen der dos.library falsch. Wenn man eh AOS2.0 benutzt, kann man auch gleich PutS() (iirc) benutzen und das Programm somit vereinfachen. Ansonsten sieht's auf den ersten Blick korrekt aus, aber um schlechte Gewohnheiten von vornherein zu vermeiden, sollte man aus dem ersten move.l 4,a6 gleich ein move.l 4.w,a6 machen und das Ergebnis bei Bedarf in einem Register oder, wenn nicht genug frei sind, in einer lokalen Variablen speichern, anstatt erneut auf die absolute Adresse 4 zuzugreifen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 17:56 Uhr Thore Posts: 2266 Nutzer |
Ne Output gibts auch auf 1.3. Damit holt man sich das Output Handle des Shell Fensters. Klar gehts auch mit PutS oder RawDoFmt und weiteren Spielereien, aber das ist ja nur ein Demo von vielen Er wollt nur ein hello world Programm und hier ist eins.[ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 18:22 Uhr Holger Posts: 8116 Nutzer |
Zitat:Kann sein, dass ich dadurch auf die falsche Fährt gelockt wurde, weil ältere Beispielprogramme den Output-Handle immer direkt aus der Prozessstruktur ausgelesen haben. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2010, 19:34 Uhr jolo Posts: 110 Nutzer |
@Holger:Zitat: Ja, das kommt mir auch sehr bekannt vor, aber ich meine es war nicht mittels der Prozess-Struktur sondern anhand der Global-Vector-Table, die vom BCPL-DOS jedem Prozess zugänglich gemacht wurde. Hieß das Ding wirklich so? Ich kann mich nicht mehr genau erinnern. Jedenfalls waren die 20 Funktionen des BCPL-DOS, die als API nach außen geführt wurden, nur eine kleine Menge verglichen mit den Funktionen, die man über die Global-Vector-Table erreichen konnte. Mit OS 1.4 (beta 2.0), wurden dann diese Funktionen nach außen gelegt, und man musste nicht mehr Assembler benutzen, um diese Funktionen zu benutzen (sie benutzten nicht die herkömmlichen Register, z.B. wurde D1 als Rückgaberegister benutzt und nicht D0 sowie diese komischen Offsets als Einsprungadressen). Ist aber schon Ewigkeiten her, dass man diese benutze (Mitte der 1980er Jahre), auch weil mit jeder Neuerung des DOS die Tabellenoffsets sich änderten (nur nicht zwischen Kickstart v33 und v34). @fisch08: Habe eine kleine Demo auf "www.amimedic.de" hochgeladen (HelloWorldGUI). Es ist assemblierbar mit 'vasm', PhxAss und Devpac. Kommandozeilenaufrufe sind im Quelltext abgebildet. Grüße [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > 68K Assembler | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|