Hallo Besucher, der Thread wurde 4,3k mal aufgerufen und enthält 17 Antworten

letzter Beitrag von bloerr am

Mit welchem Assembler sollte man anfangen, zu lernen?

    Moin moin,


    Also.
    Ich hatte damals n C64 und habe nun wieder einen und war und bin immer wieder
    fasziniert von den Möglichkeiten von Assembler.
    Mein Ziel ist es, ATMEGA32 und ähnliche ICs in Assembler zu programmieren und
    da C64-ähnliche PCs draus zu bauen, also kleine Computer mit wenig Farben, wenig ROM und RAM,
    einfach nur zum Programmieren von Oldschool-SPielen in BASIC und wiederum Assembler, evtl. C.


    Und nun muss ich irgendwo anfangen zu lernen.
    Habe nie Assembler gelernt, womit fängt man an?
    Macht der Anfang auf einem C64 oder 6502 basierenden PC/Konsole Sinn?
    Macht der Einstieg auf der x86 Plattform überhaupt noch Sinn seit den MMX und ISSE ?
    Die Optimierungen dafür sollen ja unprogrammierbar sein für einen Menschen.


    Oder wie fängt man heutzutage an? Direkt mit nem ATMEGA Evo Board?


    Ist vielleicht ein wenig Off-Topic, aber ich habe gelesen, dass sich mehrere C64-User sehr produktiv
    mit dem ATMEGA32 beschäftigen (MMC2IEC)

    Ho bloerr,


    fang am besten mit dem System an auf dem Du hauptsächlich arbeiten möchtest bzw. das dir den meisten Spass macht. Sollte das der Atmega sein, dann hol' Dir ein Evaluation Board (z.B. für 14,99 bei Pollin), Ponyprog für das Flashen und AVRStudio von Atmel, das hat nämlich einen ziemlich guten Simulator für Assembler und C. Im Netz gibt es für die AVRs unzählige Tutorials, die garnichtmal schlecht sind. Bau Dir erstmal was einfaches, z.B. ein Lauflich, einen elektronischen Würfel oder ein "Moodlight". Im Grunde genommen ist das auch nicht viel anders als wenn man am 64'er den userport ansteuert. Doch man kann eine sehr leistungsfähige Entwicklungsumgebung nutzen.


    Es schadet natürlich auch nicht mit 6502 zu starten. Wichtig ist nur dass Du dir eine gute Entwicklungsumgebung suchst und ein Projekt das Spass macht und Dich entsprechend motiviert, denn Du must schon eine ganze Menge Stunden investieren bis du die CPU und die ganzen Opcodes ausreichend beherrschst.


    Ich für meinen Teil habe über die Jahre Assembler auf 6502, Z80, 68000, X86 und diversen Microcontrollern gelernt (in der Reihenfolge). Am besten hat mir dabei immernoch der 68000'er gefallen, denn da hatte man wenige Einschränkungen bei den Registern und Adressierungsarten. Auf dem Amiga hat's besonders viel Spass gemacht der Hardware mit Assembler neue Effekte zu entlocken.


    Viele Grüße,
    Sascha

    8051 + Derivate sind auch ganz gut zum Einstieg. Da hat mans dann etwas leichter wenn man später auf x86 umsteigen möchte, da Intel die gleichen Befehle verwendet hat, beim X86 sinds nur mehr :) . AVR sind aber leichter zu beschaffen, preiswerter und es lässt sich leichter Peripherie dranbasteln. Wichtig ist, daß man hinterher was sieht, sprich... keine Trockenübungen, das hab ich selbst momentan mit VHDL... brech.


    Hier dürftest du für C64 Assemblerprogrammierung guten Support erhalten :D .


    MfG HONI!!

    Zitat

    Am besten hat mir dabei immernoch der 68000'er gefallen, denn da hatte man wenige Einschränkungen bei den Registern und Adressierungsarten.


    Nunja, also ich fand den Intel wegens der HI/LO-Byte Struktur immer 6510 ähnlich.


    Wogegen es der 68000 genau umgekehrt macht.
    Nichts gegen den Motorola, aber warum extra umgekehrt ? Hat da ein Manager aus Frust umentschieden ? :nixwiss:
    "...blabla...Nein! Nicht wie die Intel-Trottel...nein der war mit meinem Weibe im Bett...Nein. Umgekehrt!" :aerger:


    Natürlich ist alles eine Sache der Gewöhnung, aber einige Fehler die man bei der Programmierung beider CPUs macht, hätten doch einfach schon durch die gleiche HiLo-Architektur vermieden werden können.



    LDA #$00
    bzw.
    MOV AX, #$00


    ist doch total easy, weils sogar in dem Falle die gleiche Schreibweise ist.


    Wäre das beim 68000 jetzt auch


    MOVE D0, #00


    und nicht


    MOVE #00, D0


    wäre der Motorola für mich sehr viel netter gewesen.


    Aber wie gesagt, ich hab nix gesagt... :roll:




    Zitat

    und man kann viele sachen wegen dem OS was einem in die quere kommt eh nicht machen.


    Leider. :wand (Da kann aber Intel nix für... :blah!)




    Zitat

    Oder wie fängt man heutzutage an? Direkt mit nem ATMEGA Evo Board?


    Mit nem USER-Port-Board. Mit LEDs. Evtl. auch mit Oszilloskop. Und daraus resultiert dann ReverseEngineering. :bgdev
    Der Atmega interessiert mich auch. Und die PICs. Is' bestimmt cool.



    greetz

    Das sind ja super viele Antworten die mein technisches Verständnis unterstützen :)


    Ich habe mich schon relativ weit eingelesen in C64 Assembler (weiss aber gerade nicht welchen, egal)
    und frage mich nun....
    Wohin schiebe ich den Pointer bei einer x86 CPU? (falsch ausgedrückt? )
    also, die speicheradressen sitzen doch immer woanders,
    je nachdem ob ich jetzt 1x64mb, 2x32mb, sdram, ddram, edoram besitze.
    der athlon 64 beherbergt dann gleich eine northbridge, ist das nicht wesentlich
    komplizierter zu programmieren?
    Und ausserdem habe ich, was auch mein Verdacht war, gelesen:


    Erweiterungen wie MMX und ISSE und 3D NOW! wurden damals hoch angepriesen.
    Diese konnten hoch-komplexe Berechnungen schneller ausführen.
    Aber meiner Erinnerung nach wurden diese Erweiterungen eingeführt, um
    "schlecht" kompilierten Code schneller ausführen zu können.
    Lieg ich da richtig, dass es dementsprechend egal ist, ob ich von C kompiliere oder
    mit fortgeschrittenem Wissen in Assembler programmiere?
    Ausser dass das C Programm nachher vielfach portabler ist?


    Entschuldigt meine Halbweisheiten....Aber solche Fragen haben mich zum C64 gebracht.
    Der ist so übersichtlich, dass ich schon damals als 12 jähriger Verstand, wie sich CPU, ROM und RAM
    miteinander unterhielten.


    Ich denke dass mir dieses technische Verständnis beim Assembler viel hilft.
    Man muss eigentlich nur verstehen, wie der Computer tickt.
    Und was ein BASIC Befehl im Computer alles anrichtet :)


    Und wenn man sich erst mit den PEEKs und POKEs auskennt hat man unterbewusst ja fast
    schon Assembler gelernt :)


    Dennoch,,, gibt es gute Anleitungen im netz, vorzugsweise PDF ? Ich habe hier den INPUT64 Kurs vorliegen,
    denke aber, dass man es NOCH ein wenig verständlicher präsentieren könnte :)
    Nicht, dass ich es nicht verstehe.
    Aber es dauert mir doch manchmal ein wenig zu lang. Und es fehlen Bezüge auf Beispiele oder entsprechende
    BASIC-Befehle.

    Zitat

    Ich denke dass mir dieses technische Verständnis beim Assembler viel hilft.
    Man muss eigentlich nur verstehen, wie der Computer tickt.



    Und genau dieses wird Dir durch Winblöd und Co extrem erschwert, weil es sich einbildet, Dir alles Wissen abnehmen können ZU DÜRFEN !




    Zitat

    also, die speicheradressen sitzen doch immer woanders,


    Ich geh' mal davon aus, dass Du auf den virtuellen Speicher ansprichst ?!



    Du kannst es auch relokatiblen Speicher nennen.
    Ein Programm, welches immer korrekt läuft, egal, in welchen Zellen es sich befindet, ist relokatibel.


    Im Prinzip brauch man freilich keine absoluten Adressen, sondern wie bei den Branches "Abstände relativ zur momentanen Adresse".
    Und diese absoluten Befehle wie z.b. JMP musst Du in relokatiblem Code natürlich vermeiden.
    Oder bei jedem Start das JMP-Target analysieren und je nach Bereich die Sprungadresse ändern.



    Ginge beim C64 auch, ist aber dort unnötig, weil alle Speicherbereiche fest definiert sind.
    VIC ab $d000.......CIA ab $dc00....SID ab $d400....usw.
    Dazwischen Kernel, Basic und RAM.....


    Beim PC ist natürlich die Programmentwicklung "einfacher", weil sich Zellen nicht mehr überschneiden können und 1000 Programmierer am selben Projekt arbeiten können OHNE das Variablen des 'Proggys A' auch in 'Proggy B' benutzt werden und somit Datenmüll im wahrsten Sinne des Wortes vorprogrammiert ist....


    Dafür gehen einige Tricks (leider) nicht mehr, was reine PC-Coder NIE-NIE-NIE verstehen werden !
    Und dies ist gut so.


    Gute Nacht. :zzz:
    (update me...)


    Grettz, Caddy

    Zitat von Caddy6510


    Im Prinzip brauch man freilich keine absoluten Adressen, sondern wie bei den Branches "Abstände relativ zur momentanen Adresse".
    Und diese absoluten Befehle wie z.b. JMP musst Du in relokatiblem Code natürlich vermeiden.
    Oder bei jedem Start das JMP-Target analysieren und je nach Bereich die Sprungadresse ändern.


    Auf dem Amiga regelt man das mit Reloc-Tables, welche sämtliche absolute Adressen relozierbar machen. Da kann man dann programmieren was man will, es ist immer relozierbar.


    Zitat


    Beim PC ist natürlich die Programmentwicklung "einfacher", weil sich Zellen nicht mehr überschneiden können und 1000 Programmierer am selben Projekt arbeiten können OHNE das Variablen des 'Proggys A' auch in 'Proggy B' benutzt werden und somit Datenmüll im wahrsten Sinne des Wortes vorprogrammiert ist....


    Dann mach mal auf dem PC ein Scroller mit Tile-Grafik und Sprites darüber. Das ist auf dem C64 schnell gemacht, auf dem PC hat man schon seitenweise Code, bevor man überhaupt irgendwo einen Pixel setzen darf.

    Zitat von Fröhn


    Auf dem Amiga regelt man das mit Reloc-Tables, welche sämtliche absolute Adressen relozierbar machen. Da kann man dann programmieren was man will, es ist immer relozierbar.


    So nicht ganz richtig, geht nur bei ausführbaren Programmen, die halt den RELOC32 HUNK haben (eben jenen mit den Relocation Offsets). Wenn du wirklich IMMER relozierbaren Code haben willst, kommst du um 100% PC relativen Code nicht herum (oder alternativ eine eigene Reloc Routine die aber sicherlich aufwendiger werden dürfte, als den Code PC relativ zu halten).


    Ich gehöre genau der anderen Fraktion an, ich finde die 680x0 Syntax einfach und logisch, moveq #0,d0 -> source->dest, macht doch total Sinn. Wäre das bei x86 auch so, hätte ich da schon mal einen gewaltigen Störfaktor weniger. :D

    Zitat von StingRay

    Ich gehöre genau der anderen Fraktion an, ich finde die 680x0 Syntax einfach und logisch, moveq #0,d0 -> source->dest, macht doch total Sinn. Wäre das bei x86 auch so, hätte ich da schon mal einen gewaltigen Störfaktor weniger. :D


    Dann nimm doch GNU as, der verwendet die AT&T-Syntax in der zB ein MOV BX,AX zu mov %ax,%bx wird.


    Und um noch eine Architektur in den Topf zu werfen: Ich finde MIPS-Assembler ziemlich hübsch - sehr orthogonal, keine Flags, durchgehende Load-Store-Architektur. Verwendet habe ich es allerdings nur im Simulator im Rahmen einer Uni-Vorlesung (von Kleinkram bis hin zum präemptiven Mini-Multitasking-Kernel).


    Toll, mein Firefox zieht gerade 60-70% CPU (Powerbook G4 867) und der Lüfter musste anspringen. =( Blöde neue Forensoftware...

    Zitat

    Und um noch eine Architektur in den Topf zu werfen: Ich finde MIPS-Assembler ziemlich hübsch - sehr orthogonal, keine Flags, durchgehende Load-Store-Architektur. Verwendet habe ich es allerdings nur im Simulator im Rahmen einer Uni-Vorlesung (von Kleinkram bis hin zum präemptiven Mini-Multitasking-Kernel).


    Mich nerven an dem MIPS die Delay Slots, und wenn man etwas tiefer in die Maschine einsteigen muß (MMU etc.) ist das Ding total unübersichtlich (Table-walk statt statischer MMU-Tabelle, nur so als Stichwort).
    Das Exception-Handling ist meiner Meinung nach auch etwas zu kryptisch.
    Sehr orthogonal ist der auch nicht, da es zum Beispiel BLT (Branch Lower Than) nicht gibt und sich der Assembler mit zwei Befehlen diesen Befehl "zusammenbauen" muß.
    Auch die Festverdrahtung, welche Adressen gecached, welche ungecached und welche per MMU umschaltbar sind, ist mir irgendwie zu statisch.


    Aber der MIPS war auch nie für Assemblerprogramieren gedacht (ist halt eigentlich ein Workstation-Prozesssor). UNIX drauf port, C-Compiler drauf portiert und dann ab dafür.


    Habe beruflich aber leider damit zu tun. Ich kann nur sagen : MIPS - Finger weg !


    Intel andererseits war bisher noch nie gut darin, lesbare Opcodes zu definieren. Man Vergleiche 8080 Syntax mit Z80 (wobei ja - binär gesehen - Z80 eine Obermenge von 8080 Code ist).
    Hätten sie statt "mov" "ld" oder sowas benutzt. wäre alles viel logischer. "mov [ziel],[quelle]" find ich irgendwie hanebüchen. "ld [ziel],[quelle]" macht für mich irgendwie mehr Sinn ...

    Das ist brauchbare Antwort Nummer 2, danke ;)
    Bald sollte mein funktionierendes C64-Board eintreffen,
    Dann brauch ich nur noch nen brauchbaren Assembler und
    los geit das :)
    Spezifikationen fürn User Port sind ja sehr übersichtlich, da
    sollte man schon lustige LEDs mit zum leuchten kriegen.


    Ziel ist es wie gesagt, später (wieviel später ist mir fast egal)
    einen "konkurrenten" zum c64 zu bauen, PS2- Anschluss, Spezielles
    BASIC und Assembler und Anschluss für SD-Card.
    16 Farben, 8 Sprites und Soundprozessor mit 3 Wellenformen und Hüllkurve,
    nicht zwingend mit Filtern. Am besten vom BASIC her weitgehend kompatibel
    zum CBM BASIC 2.0 oder sogar höher.


    Das sollte doch realisierbar sein :)