Der spaßigste Assembler

[huha]

Hallo,

vielleicht gibt's hier ja noch eine handvoll Leute, die der Programmierung mit Assembler fröhnen; an diese richtet sich diese Frage.

Welcher Assembler/welche Architektur haltet ihr bzgl. der Programmierung für am Spaßigsten/Interessantesten? Ich würde gern einen interessanten Assembler lernen, aber da es ja tausende Plattformen gibt und dafür ebenfalls tausende Assembler, fällt die Auswahl nicht leicht.
Win32-Assembler mit MASM32 ist nett, fühlt sich aber eher an wie eine Hochsprache ohne Komfort und ist daher vergleichsweise lästig. Also, was bevorzugt ihr, was ist interessant und was einfach spaßig? (Und warum?)

-huha

[del_4901]

SPU Assembler, der Syntax ist schrecklich, es fehlen viele Instruktionen, das Debugging sehr eingeschraenkt, aber wenn man sich damit abgefunden hat, kann man lustige Sachen mit machen.

[Gast]

AVRs 8-Bitter machen mit Assembler auch viel Spaß.

[Gast]

Pain-in-the-Ass: MAXQ2000 von Maxim. Nur ein OPcode ;)
Guter Support in Deutschland, nicht schlecht: AVR
Schön und schlank, aber nicht sooo verbreitet: MSP430
Didaktisch wertvoll, aber alt: 68k
Umfangreich: ARM
Sinnvoll (bis auf wenige Ausnahmen): C *SCNR*
Wirklich interessant und Leistungsfähig aber exotisch: Propeller von Parallax (oder so)

Eine ganz entscheidende Frage: Soll es in HW sein oder reicht ein Simulator? Wenn ersteres, dann wegen guter Verfügbarkeit einen AVR nehmen. Die größeren Sachen tut man sich eigentlich selten in Assembler an. Aus persönlicher ARM-Erfahrung: Nur für den nötigsten Startup-Code und zeitkritische Interrupts.

[DraconiX]

Jep... AVR... ohne Frage ;) Mit nem RISC machts halt gleich doppelt so viel "Spaß" :freak:

Ne feine Sache, bin da auch gerade drüber, auf nem AVR Atmega32. Aber selbst da ist ASM eigentlich totaler Overkill will man größere / gröbere Projekte machen. Ist man aber an extremst schnelle Zugriffe gebunden kommt man selbst mit ner Hochsprache über Inline Asembler nicht drumrum. (Wie bei mir momentan, bau mir nen Logikanalyzer)

[DraconiX]

Nu ja gut.. damit kommt dann das (TEST auf dem LCD - Wobei der ASM Code für die LCD_Init grad net parat ist...).:


_main:
LDI 27, 255
OUT 93, 27
LDI 27, 0
OUT 94, 27
IN 28, 93
IN 29, 94
SBIW 28, 5
OUT 93, 28
OUT 94, 29
ADIW 28, 1
CALL _Lcd_Init+0

L_main0:
LDI 27, 84
STD Y+0, 27
LDI 27, 101
STD Y+1, 27
LDI 27, 115
STD Y+2, 27
LDI 27, 116
STD Y+3, 27
LDI 27, 0
STD Y+4, 27
MOVW 16, 28
PUSH 17
PUSH 16
LDI 27, 1
PUSH 27
LDI 27, 1
PUSH 27
CALL _Lcd_Out+0
IN 26, 93
IN 27, 94
ADIW 26, 4
OUT 93, 26
OUT 94, 27

LDI 18, 41
LDI 17, 150
LDI 16, 128
DEC 16
BRNE $-1
DEC 17
BRNE $-3
DEC 18
BRNE $-5
JMP L_main0
L_end_main:
JMP L_end_main

http://www.abload.de/img/100_1285kj5g.jpg

[Wuzel]

Also, von meiner Seite aus - 8051/52 (NXP Lpc).
Es hat auch verdammt lange gedauert, biss es vernünftige c compilierer dafür gab (Keil....), diese sind jedoch noch immer nicht 'optimal'.
Kurzum: Die Asse Hochburg schlechthin :)

[Coda]

SPU Assembler, der Syntax ist schrecklich, es fehlen viele Instruktionen, das Debugging sehr eingeschraenkt, aber wenn man sich damit abgefunden hat, kann man lustige Sachen mit machen.
Ist es echt immer noch so traurig?

Pain-in-the-Ass: MAXQ2000 von Maxim. Nur ein OPcode ;)
Wie nur ein Opcode? Auf der Herstellerseite steht irgendwas von 33 Instructions. Genauer?

[del_4901]

Ist es echt immer noch so traurig?
Also bevor ich den Debugger anwerfe, denke ich lieber nochmal scharf nach oder benutze gute alte printf Ausgaben. Es soll Zeiten gegeben haben, da gab es nichts anderes, oder es hat ewig gedauert. Und handoptimierter Code ist auf Cell eh das A und O.

[Gast]

Zum ASM lernen würd ich auch stark zu nem AVR8 raten. Die DevBoards sind billig, die Softwareumgebung kostenlos, man findet Tonnen an Informationen in Foren, ...

Sonderlich leistungsfähig sind die Dinger dafür halt nicht, selbst den größten XMegas läuft jeder ARM davon.

Dafür hast du einen Haufen Peripherals (A/D- und D/A-Wandler, SPI, COM, TWI, haufenweise Timer, PWM-Generatoren und PWM-Empfänger, ...) mit denen man ohne großen Aufwand sogar halbnützliche Sachen bauen kann - wer will schon nicht per HyperTerminal benachrichtigt werden, wenn die Temperatur draußen unter 0°C fällt ;)

mfg,
zgep

[Gast]

spu oder vfpu von dem mips der psp.

[joe kongo]

Assembler macht Spass ?
Aber auch nur wenn man keine konkreten Ziele vorgegeben bekommt.

[Gast]

Assembler macht Spass ?
Aber auch nur wenn man keine konkreten Ziele vorgegeben bekommt.oft hab ich das ziel schnellst moeglichen code zu schreiben und da bleibt oft nur noch assembler.

[joe kongo]

oft hab ich das ziel schnellst moeglichen code zu schreiben und da bleibt oft nur noch assembler.

In C kannst imO das selbe, alle "Optimierungen" ausschalten und gelegentlich mal den erzeugten Maschinencode überprüfen.

[DraconiX]

Würde ich so nicht unterschreiben... Wenn ich schnellst möglich Werte speichern und auslesen will stoße ich mit C an eine gewisse Grenze, da er die Variable in eine SRAM Adresse schiebt anstatt ausschließlich die Speicherregister des µC zu nehmen (Optimierung zero bis five alles das gleiche) (compiliert für Atmega32) z.b.:

C Code:

int test;

void main() {
test = 1;
}


erzeugtes Assembly:

_main:
LDI 27, 255
OUT 93, 27
LDI 27, 0
OUT 94, 27


LDI 27, 1
STS _test+0, 27
LDI 27, 0
STS _test+1, 27


JMP L_end_main
; end of _main


aber schneller ist:

_main:
LDI 27, 255
LDI 27, 1
JMP L_end_main
; end of _main


Das ist das selbe Programm mit gleichem Ergebniss, außer das der Speicher nicht ins SRAM geschrieben wird, und wenn man mehrere tausend Zeilen C Code hat wird das Suchen nach der richtigen Assembler Stelle, sowie Speicherregister schon sehr nervig.

[joe kongo]

probier mal register int test;

[DraconiX]

Macht er das ;)


_main:
LDI 27, 255
OUT 93, 27
LDI 27, 0
OUT 94, 27

;Test.c,3 :: void main() {
;Test.c,4 :: test = 1;
LDI 27, 1
MOV test+0, 27
LDI 27, 0
MOV test+1, 27
;Test.c,5 :: }
L_end_main:
JMP L_end_main
; end of _main

[DraconiX]

Ist ja eigentlich auch nicht sonderlich verwunderlich, "Register" besagt ja nur, das die Speicheradresse (hier im Fall R27) ausschließlich für "test" offengehalten wird. Es heißt nicht das, das der µC ausschließlich mit der Variable im R27 arbeitet. :/

Theoretisch könnte der Compiler es ja wie folg machen, wenn er auf dem "test" rumreitet - mag womöglich auch an dem Compiler von MicroC liegen :/:


_main:
.DEF test = R27
LDI test, 1

L_end_main:
JMP L_end_Main

[Gast]

Das Beispiel ist nicht tauglich. Streng genommen müsste der Compiler NICHTS machen solange test nicht volatile deklariert wird. Register ist ein Relikt! Wenn es unbedingt sein muss gibts für solche Schweinereien wie Variable an Register binden irgendein __attribute__. Bei normalem Anwendungscode ist selbst der mäßig gute avr-gcc mit -O2 oder -Os sicher in der Ausführung schneller als 99% der Assemblerprogrammierer es könnten. Von der Zeit die man zum entwickeln braucht ganz zu schweigen. Außerdem: Profilen, dann optimieren. Und: Algorithmus verbessern ist meist effektiver als zu versuchen, dem Compiler/Optimizer was vorzumachen.
Sorry für OT.

[Gast]

Wie nur ein Opcode? Auf der Herstellerseite steht irgendwas von 33 Instructions. Genauer?

War nicht so ganz ernst gemeint, siehe ;), aber etwas seltsam ist der MAXQ schon...
http://en.wikipedia.org/wiki/One_instruction_set_computer

[DraconiX]

"test" braucht nicht volatile deklariert zu werden, da test in der main beschrieben wird. Auch wenn "test" in einer direkter funktion verwendet wird, benötigt "test" kein volatile atribut. Einzigst wenn "test" in einem interrupt vektor beschrieben wird und in der main ausgelesen wird benötigt der compiler das volatile attribut damit er es nicht verschluckt.

Und eindeutig ist der von MicroC assemblierte Code mit 4 clocks langsamer als der selbe Code welcher nur 1 clock zum beschreiben benötigt. Ich habe mir neulich ein Logikanalyzer gebaut, welcher zum auslesen eines Pins, beschreiben eines Registers und weitergeben an eine Variable gerade mal 3 Clocks benötigt - das hatte kein Compiler geschafft, nicht der AVR-GCC und auch nicht MicroC.

EDIT: Aber richtig ist schon, das es mit ASM recht langwierig ist, eh man zum Ziel kommt.. aber das ist ja nicht sinn und zweck dieses Threads, der TS möchte ja explizit ASM programmieren, warum auch nicht. C, Pascal oder Basic kann jeder Scriptkiddie programmieren - ASM muß man beherschen ;)

[Gast]

was gemeint war (zumindest hab ich es so verstanden) ist, dass das Beispiel sinnlos ist, weil es das gleiche macht wie

_main:
L_end_main:
JMP L_end_main
; end of _main


implementier lieber einen O128-FIR-Filter oder PID-Regler und vergleich dort C-Code vs. ASM-Code. Sind auch absolute Minimalbeispiele, aber WEIT näher an der Realität.

Das einzige wo sich ASM imho wirklich noch auszahlt sind hochfrequente ISRs, dann kann man mit naked ISRs das Sichern aller Register in den Speicher sparen.
Es ist halt einfach zu billig 5c mehr für einen stärkeren µC auszugeben und zu teuer nochmal 10-100k€ in die Entwicklung zu stecken.

mfg,
zgep

[Gast]

avr-gcc macht das draus:
00000054 <main>:
54: 81 e0 ldi r24, 0x01 ; 1
56: 80 93 60 00 sts 0x0060, r24
5a: 08 95 ret

[DraconiX]

Komisch, bei mir macht AVR-GCC das hier - (etwas gekürzt, der AVR GCC Assembly in der .lss Datei ist ja grausig) - btw... wieso beschreibt er zwei register und zwei speicherstellen?!:


00000092 <main>:
92: 81 e0 ldi r24, 0x01 ; 1
94: 90 e0 ldi r25, 0x00 ; 0
96: 90 93 61 00 sts 0x0061, r25
9a: 80 93 60 00 sts 0x0060, r24
a2: 08 95 ret

[Gast]

ich hab n char genommen und kein int ;) sonst kommst mit deinem einen Befehl auch nicht weit.

das mit dem volatile ist halb richtig. natürlich muss der compiler dafür sorgen, dass die letzte zuweisung gilt. alles andere geht aber flöten.

[DraconiX]

Aso ja klar... int ist ja 2 byte groß... rüchtüüg, :freak:


Jep, das mit volatile ist mir schon klar, aber der Gast meinte halt das der compiler es überhaupt nicht berücksichtigen hätte dürfen, was ja falsch ist, da er ja in der hauptroutine gesetz wird - somit zum programmende ein Wert enthält.

[Gast]

wenn du unbedingt willst, dass der speicher zu programmende den wert enthält, ist deine lösung aber genauso ungültig wie meine. schließlich hast du den wert da ja auch nur im register (und damit an einer stelle wo er keine auswirkungen hat da er ja nicht mehr genutzt wird und nicht von außen gelesen werden kann).

nach c-standard ist natürlich sowieso beides ungültig.

der vom anderen gast gepostete code zeigt jedenfalls für mich mal wieder ziemlich deutlich, dass compiler bis auf wenige spezialsituationen (insbesondere SFUs in DSPs u.a. Prozessoren) inzwischen ebenso guten code produzieren wie ein mensch, meistens eher besseren und vor allem fehlerfreien, selbst bei so kurzen (und damit wie schon gesagt unrealistischen) beispielen ;)

mfg,
zgep

[FeuerHoden]

Nu ja gut.. damit kommt dann das (TEST auf dem LCD - Wobei der ASM Code für die LCD_Init grad net parat ist...).:

Was ist das für ein Devboard, wie heißt das genau, was kostet es und was kann man genau damit machen?

[huha]

Was ist das für ein Devboard, wie heißt das genau, was kostet es und was kann man genau damit machen?

EasyAVR 6 (http://www.mikroe.com/en/tools/easyavr6/). USD 139.

-huha

[DraconiX]

Rüchtüg :D

Ohne gescheites Dev-Board geht es sowieso nicht. Ich kann das EasyAVR für 8 Bit AVR Prozzis nur wärmstens an empfehlen. Extremst flexibel, und wirklich so gut wie alles drauf was man so braucht, ohne lästiges rumlöten wenn man mal schnell nen LCD ansprechen mag. Einzigster Kritikpunkt.: Ich hätte lieber anstatt des COG Displays wieder einen SD/MMC Slot so wie es beim EasyAVR 5 war.

Der USB Progger ist auch extremst schnell unterwegs! Seit dem das Brett bei mir uffn Schreibtisch liegt, liegt das STK500 in der Schublade.

Wen man lieber 64 / 100 Piner progen will, dann greift man zum BigAVR2. Für die TQFP und MLF Prozis die ich dann verlöte habe ich mir einen Adapter für den entsprechenden Sockel für das EasyAVR gebaut.

EDIT: Wobei man sagen muß, bei den 139$ sind die Displays noch nicht mit inbegriffen! Ich habe mein Board mit Displays hier für ca. 180€ gekauft. Es funktioniert aber jedes Display mit Standartcontroller...

[FeuerHoden]

Wie Komplex kann man mit diesen 8bit Chips denn programmieren?

Wenn ich jetzt sagen wir mal ein Verandalicht habe das Abends angehen soll wenn ich am Bewegungssender vorbei laufe aber nur nach 18:00 von April bis November und im Winter dann schon ab 16:00. Und wenn der Bewegungssensor nix meldet soll das Ding von 20:00 - 23:00 zufällig immer mal wieder angehen.

Wäre das für nen Typen der mal vor ein paar Jahren "The Art of Assembly" bis zum Segmentierten Speicher gelesen hat frustarm zu bewerkstelligen?

Und damit wir wieder beim Topic sind: Welcher Assembler bietet sich dafür an? ;)

[huha]

Wie Komplex kann man mit diesen 8bit Chips denn programmieren?

So komplex du willst. Je nachdem, welches Modell du wählst, hast du eben mehr oder weniger Features. Die Attiny-Serie ist billig, deren Pin-Anzahl, Speichergröße, Featureset und Rechenleistung ist allerdings stark begrenzt; beispielsweise hast du beim Attiny keinen Hardware-Multiplikator. Die Atmegas sind Allrounder, die haben mehr oder minder alles, was man so üblicherweise braucht (auch einen Multiplikator ;)). Die Xmega-Serie hat dann sehr viele lustige und interessante Sachen (DMA, noch mehr Ein- und Ausgänge, massig Speicher etc.).

Wenn ich jetzt sagen wir mal ein Verandalicht habe das Abends angehen soll wenn ich am Bewegungssender vorbei laufe aber nur nach 18:00 von April bis November und im Winter dann schon ab 16:00. Und wenn der Bewegungssensor nix meldet soll das Ding von 20:00 - 23:00 zufällig immer mal wieder angehen.

Ich weiß nicht, wie taktstabil die Teile sind (ggf. brauchst du also eine RTC), aber das dürfte mit sehr wenig Aufwand zu machen sein. Ein Attiny reicht hier sicher.

Wäre das für nen Typen der mal vor ein paar Jahren "The Art of Assembly" bis zum Segmentierten Speicher gelesen hat frustarm zu bewerkstelligen?

Und damit wir wieder beim Topic sind: Welcher Assembler bietet sich dafür an? ;)

Du mußt ja keinen Assembler nehmen, für die AVRs gibt's viele Programmiersprachen. C bietet sich beispielsweise sehr gut an. Wenn du zu viel Geld hast und gern sowas wie rapid prototyping betreibst, kauf dir einfach sowas wie einen Arduino (http://www.arduino.cc) und realisier das Projekt damit. Ist natürlich totaler Overkill und von der Code-Effizienz sicherlich grauenhaft schlecht, dafür gibt's halt Libraries für jeden Scheiß.


Ich will Assembler betreiben, weil mich spaßiger Assembler einfach interessiert; Assembler ist natürlich heutzutage ziemlich tot, aber es gibt ja auch Leute, die Mittelaltermärkte organisieren, warum also nicht? ;)

-huha

[DraconiX]

jep, über solche Sachen wie mit der Lampe lacht sich nen Atmega tot ;) Aber genau für solche Sachen ist er gedacht. Für eine genaue Sekunde ist, wie huha schon sagte ein externer Uhrenquarz pflicht, dazu sind die internen Taktgeber nicht genau genug, ist aber kein Problem. Ich arbeite ebenfalls immer mit externem quarz, hat sich so eingebürgert.

Mein Aufwendigstes Projekt bis dato war ein Überwachungsgerät für eine Flugzeuganhänger. Welcher konstant die Temperatur und Luftfeuchte (SHT11 Two-Wire-Serial) misst, über einer wählbaren Grenze zwei Lüfter für eine bestimmte Zeit in Betrieb nimmt, sowie diese Werte auf einer SD Karte protokolliert. Dazu noch eine Strom- sowie Spannungsüberwachung via ADC für ein Solarpanel und eine Batterie, welcher sowohl ins positive und negative misst, ebenfalls mit speicherung der Daten auf diese SD Karte - um eine tiefentladung der Batterie zu verhindern wird ab einer bestimmten grenzen die lüfter nicht mehr in betrieb genommen und der µC in einen Ruhemodus geschickt - nur alle 5min wieder zum protokollieren aufgeweckt. Betrieben wird es mit einem 2x16 LCD und eingestellt wird alles mit einem Druck-/Drehimpulsgeber - was eine Sache für sich selber ist :freak:

Mit einem Atmega8 kann man sich sogar eigene Webserver bauen.

Und wie huha richtig sagte, um sowas effizient zu proggen bleibt einem nur eine hochsprache wie C, Pascal oder Basic übrig. Aber Assembler sollte man immer wieder mal für kleine Sachen nutzen, man sollte es als halt immer noch ein wenig am leben halten - wäre schade drum :/

Der Atmega versteht so um die 130 Befehle.

[huha]

Man kann's natürlich auch in Assembler programmieren, wenn man lustig ist; aber die C-Compiler sind wohl ziemlich gut, so daß man dies nicht muß wie bei anderen Microcontrollern, um irgendwas halbwegs Sinnvolles hinzukriegen.

-huha

[FeuerHoden]

Danke für die Antworten :)

Ich würds schon gern in Assembler machen weil ich 1. die Sprache "Sexy" finde und 2. wissen will was die Maschine genau tut.

Ich finde das oben gezigte Devboard extrem Cool, einfach weil man daran sieht was alles möglich ist. Auch wenns nur eine Spielerei ist, 139$ für so ein Board finde ich sehr OK um ein neues Hobby zu beginnen. Angst macht mir nur die Programmierung weil ich bisher mit keiner Programmiersprache wirklich warm geworden bin und es nie über die ersten Tutorials hinaus gebracht habe.

Es ist wirklich nur als Spielerei gedacht und wegen dem Egofaktor etwas 'eigenes' funktionierendes zustande gebracht zu haben und so ünnötige Sachen wie einen kleinen Touchscreen als Lichtschalter :D

[DraconiX]

Ebend... viel Hilfe von, aber zugegebenermaßen hochnäßigen, Profis bekommst du übrigens bei mikrocontroller.net - bei denen findest du auch extremst viele Tutorials in Assembler sowie AVR-GCC.

[huha]

Oh, wenn wir schon mal dabei sind, hier noch eine illustre kleine Frage zu den AVRs.
Die kleinen haben DebugWire, die großen JTAG. Das Dragon-Programmiergerät von Atmel hat wohl auch entsprechende Anschlüsse dafür; kann ich damit einen Debugger öffnen und (wie vom PC bekannt) beispielsweise die Assembler-Programme auf dem Microcontroller schrittweise ablaufen lassen und mir direkt die Registerinhalte anschauen?

Falls das mit so einem günstigen Gerät wie dem Dragon möglich wäre, dann steht bald fest, mit was ich mich beschäftige ;)

-huha

[DraconiX]

Jep... funktioniert so. Was ich beim Dragon noch nicht durchschaut habe ist A: Wie er sich bei einer ADC Wandlung verhält und warum er das Programm nochmal in seinen eigenen internen SRAM lädt, ich selber habe noch nie "Hardwaredebugt". Mit dieser Frage bist du wahrscheinlich im µC Forum besser aufgehoben.

[ilPatrino]

Danke für die Antworten :)

Ich würds schon gern in Assembler machen weil ich 1. die Sprache "Sexy" finde und 2. wissen will was die Maschine genau tut.

Ich finde das oben gezigte Devboard extrem Cool, einfach weil man daran sieht was alles möglich ist. Auch wenns nur eine Spielerei ist, 139$ für so ein Board finde ich sehr OK um ein neues Hobby zu beginnen. Angst macht mir nur die Programmierung weil ich bisher mit keiner Programmiersprache wirklich warm geworden bin und es nie über die ersten Tutorials hinaus gebracht habe.

Es ist wirklich nur als Spielerei gedacht und wegen dem Egofaktor etwas 'eigenes' funktionierendes zustande gebracht zu haben und so ünnötige Sachen wie einen kleinen Touchscreen als Lichtschalter :D

bei pollin gibts ein abgespecktes spiel-board für imho 15€ - braucht einen seriellen port zum programmieren, ist aber sonst recht brauchbar. nachteil ist, du mußt dir deine zielschaltungen zusammenlöten, da bis auf zwei taster, zwei led und ein serieller port nichts drauf ist und ansonsten alle pins auf flachbandkabel rausgeführt werden. bei mir enden die ports auf 4 mit edding beschrifteten lüsterklemmen - flexibel, billig und für meine hobby-basteleien ausreichend.

als testwiese aber ganz nett...die schaltungen muß ich ja sowieso aufbauen, da kommt mir die freie belegbarkeit eher entgegen.
der ganze kram hat auf einem ikea-küchenbrett seine heimat gefunden :freak:

[DraconiX]

Pollin Board:

Als Bausatz (http://www.pollin.de/shop/dt/MTY5OTgxOTk-/Bausaetze/Diverse/ATMEL_Evaluations_Board_Version_2_0_1_Bausatz.html) für ~15€
Als Fertigboard (http://www.pollin.de/shop/dt/NTI5OTgxOTk-/Bausaetze/Diverse/ATMEL_Evaluations_Board_V2_0_1_Fertigmodul.html) für ~23€

Dazu recht sinvoll:
Eva. Addon Board (http://www.pollin.de/shop/dt/NjQ5OTgxOTk-/Bausaetze/Diverse/Bausatz_ATMEL_Addon_Board_V1_0.html) für umme ~25€

[elianda]

Hmm, um Assembler zu lernen, würde ich zu einem C64 raten. Es ist der bestdokumentierteste Computer den man findet. Der 6502 hat einen übersichtlichen und verständlichen Befehlssatz und es gibt haufenweise kommentierte Beispielprogramme. Tastatur, Grafik, Sound und I/O ist alles dran (selbst wenn man mit dem Emulator startet). Es kostet kein extra Geld.

Ein Großteil der Assembler Befehlssätze aktueller Embedded CPUs geht auf den 6502 bzw. 6800 zurück.

Man muss sich nicht dauernd vorwerfen, dass die gerade geschriebene Assembler Routine als C-Version schneller laufen würde.

[huha]

Zum 6502 dürfte zuhause noch ein wenig Doku rumliegen, zum 6800 sowieso X-D
Berichten zufolge soll der 6502-Assembler ein sehr schöner Assembler sein. Mir stellt sich jedoch eine Frage: Welche Anwendungen gibt es heute noch für 6502-Assembler? Ich will das ja nicht unbedingt nur zum Selbstzweck lernen, sondern auch was Sinnvolles damit machen. Es gab wohl mal eine Microcontroller-Linie, die auf dem 6502 basierte, aber gibt's die immer noch? Kurzum: Was habe ich konkret davon?
Lediglich im und für den Emulator zu programmieren ist irgendwann auch nicht mehr spaßig ;)
Zuhause steht zwar noch ein C64, aber wie krieg ich da die Sachen drauf und runter, und v.a., wie kann ich eine vernünftige Tastatur an das Ding anschließen? Die eingebaute ist ja gräßlich.

Wahrscheinlich wird's aber erstmal (je nach Zeit ;() AVR-Assembler. 6502-Assembler soll ja wie gesagt recht schön sein, mich wunderte schon, daß das erst so spät kommt. ;)

-huha