ESP8266 in Assembler programmieren

[Michael S. (misax)]

hallo;
sind Möglichkeiten bekannt den ESP8266 (ESP-12E) in Assembler zu 
programmieren ?
Also so etwas wie das Atmelstudio für Atmega ist, nur halt für den 
ESP8266 ?
Vielen Dank und viele Grüße

[Stefan F. (stefanus)]

Sicher. Dessen SDK verwendet die Extensa GCC welche auch Assembler 
unterstützt. Ich sehe allerdings keinen sinnvollen Grund, das zu tun.

Das Atmel Studio ist eine Entwicklungsumgebung. Ein geeigenets Pendant 
dazu wäre die Eclipse IDE.

https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/get-started/eclipse-setup.html

[Michael S. (misax)]

wie meinst du das ? Gibt es eine Möglichkeit mit dem Atmel Studio den 
ESP8266 in Assembler zu programmieren ? Was ist die Extensa GCC ?

[Stefan F. (stefanus)]

Michael S. schrieb:
> Gibt es eine Möglichkeit mit dem Atmel Studio den
> ESP8266 in Assembler zu programmieren ?

Nein. Das Atmel Studio eignet sich nur für Atmel Controller.

> Was ist die Extensa GCC ?

Das ist für Extensa Prozessoren vorgesehene Variante der GNU Compiler 
Collection. Der ESP8266 enthält einen Extensa Prozessor von der Firma 
Tensilica.

Kurz gcc-extensa. Sie ist das direkt Pendant zur avr-gcc, die das Atmel 
Studio verwendet. Google doch einfach danach.

[Michael S. (misax)]

Assembler ist einfach ein hobbymäßiges Interesse von mir. Mich 
interessiert einfach wie es geht und ob ich in der Lage bin das zu 
können.
Sind denn die meisten in diesem Forum professionell mit Elektronik 
befasst ? Bei mir ist es reines Hobby. Meine Projekte haben keinen 
praktischen Nutzen.

[Stefan F. (stefanus)]

Michael S. schrieb:
> Assembler ist einfach ein hobbymäßiges Interesse von mir. Mich
> interessiert einfach wie es geht und ob ich in der Lage bin das zu
> können.

Das ist Ok, aber dann mache deine ersten Übungen nicht auf einem 32 Bit 
Boliden mit Betriebssystem. Weil: Da bist du mehr mit der Interaktion 
zum Betriebssystem beschäftigt, als mit Assembler selbst und den I/O 
Registern.

Beim ESP8266 könnte erschwerend hinzu kommen, dass dessen Betriebssystem 
nicht open-source ist, sondern nur als binary mit C-Schnittstellen 
bereitgestellt wird. Die ganze Doku von dem Ding basiert auf 
C-Funktionen. Es gibt keine vollständige Beschreibung der Register.

Fange mal mit einem kleinen 8bit Controller an, den du komplett 
kontrollieren kannst. Zum Beispiel 
http://stefanfrings.de/avr_workshop/index.html

[Michael S. (misax)]

danke für den Hinweis. Die Unterschiede zwischen den Prozessoren muss 
ich auch noch lernen. Mit den ATMEGAs komme ich schon ganz gut zurecht 
aber das scheinen wohl auch die einfachsten zu sein die es so gibt oder 
gibt es noch andere vergleichbar einfache ?

[Olaf (Gast)]

> Das ist Ok, aber dann mache deine ersten Übungen nicht auf einem 32 Bit
> Boliden mit Betriebssystem. Weil: Da bist du mehr mit der Interaktion
> zum Betriebssystem beschäftigt, als mit Assembler selbst und den I/O
> Registern.

Er muss es ja kein Betriebssystem verwenden. Allerdings wuerde ich 
gerade vom 8266 auch abraten weil das erlernte Assemblerwissen kaum 
uebertragbar ist, weil diesen Prozessor wohl sonst kaum einer verwendet. 
Wenn schon dann entweder ARM oder Mips.

Viel wichtiger gerade fuer Anfaenger ist IMHO die Umgebung, also 
Debughardware. Es muss moeglich sein im Singlestep durch den Prozessor 
zu gehen und sich dabei jedesmal die Register anzuschauen. Sonst wird 
man einen sehr harten Weg beschreiten.

Ausserdem darauf achten das man nicht versehentlich einen Controller 
erwischt der Superscalar ist. .-)

Ein weiteres Problem sehe ich darin das heute zurecht keiner mehr 
Assembler programmiert, von sehr exotischen Ausnahmen abgesehen. Man 
braucht zum lernen aber ein gutes Buch das einem die Grundlagen 
erklaert. Ich vermute mal das wird man fuer einen modernen 32Bit 
Controller nicht finden.

Ansonsten sei noch erwaehnt das man natuerlich auch eine C-Umgebung 
verwenden kann und darin auch Assembler programmieren kann.

Ich hab das zum Beispiel hier gemacht: (das File taskerA.s)
Beitrag "Neuer Multitasker Olix"

Man kann sich also z.B fuer irgendeinen ARM einen moeglichst kleine 
Beispielsooftware besorgen die nicht mehr macht als mit einer LED zu 
blinken, idealerweise ohne den ganzen Libaryverbloedungskack und dann 
programmiert man seine eigenen Sachen dazu in Assembler. Das geht ja 
sogar als Einschub in C wenn man nur mal eine Funktion in Assembler 
machen will.

Aber ein vernuenftiges Buch ist alles! Im Internet rumlesen bringt nicht 
viel weil dort halbgescheite dreiviertelwissen verbreiten.

Olaf

[(prx) A. K. (prx)]

Michael S. schrieb:
> gibt es noch andere vergleichbar einfache ?

Die Architektur von TIs MSP430 ist sehr einfach gehalten und für 
Assembler-Programmierung sehr gut geeignet. Renesas' R8C ist etwas 
unfangreicher, aber ebenfalls noch simpel zu programmieren. Wenn du 
jedoch in der Einfachheit die Herausforderung suchst, dann schau dir 
Maxims MAXQ2000 an.

[Stefan F. (stefanus)]

Michael S. schrieb:
> gibt es noch andere vergleichbar einfache ?

Sicher, zum Beispiel PIC und zahlreiche Serien die auf dem 8051 
basieren.

[Mth (Gast)]

Michael S. schrieb:
> Mich interessiert einfach wie es geht und ob ich in der Lage bin das zu
> können.

Bei deinen Fragen kannst du es sicher nicht. Bzw was heißt können? 
Binärcode hochladen? ARM Befehle abtippen?

[Ein Freund (Gast)]

Michael S. schrieb:
> oder
> gibt es noch andere vergleichbar einfache ?

Kennst Du Google? Wen willst Du hier eigentlich veralbern :-)

[Michael S. (misax)]

Ich bedanke mich für die vielen konstruktiven Antworten auf meine Frage. 
Ich habe wieder viel gelernt und neue Anregungen wie ich mit meinem 
neuen Hobby weitermachen kann. Die paar negativen Antworten stören mich 
nicht weiter, weiss ich doch dass es überall Leute gibt denen es nicht 
um die eigentliche Sache geht sondern die ihre Zeit gerne damit 
verbringen sich "drumherum" zu vergnügen.
Tatsächlich war mir der so grosse Unterschied zwischen 8bit und 32bit 
Prozessoren so nicht klar. Ich dachte das sei nur ein quantitativer 
Unterschied aber mir wird immer bewusster dass die ATMEL Prozessoren 
tatsächlich schön übersichtlich und ideal für Einsteiger sind.
Jetzt habe ich mittlerweile mein erstes STM32 Nucleo Board und sehe so 
langsam vor lauter Bäumen den Wald nicht mehr.
:-)
Google ist so eine Sache. Erstens das meiste in Englisch; zweitens viele 
Foren-Antworten wo dann seitenweise gar nicht auf die eigentliche Frage 
eingegangen wird, drittens zum Teil widersprüchliche oder unklare 
Aussagen.
Bitte nicht böse sein wenn ich eine Zeitlang noch Anfängerfragen stelle. 
Es muss ja nur der reingucken der will, wird ja keiner gezwungen. Und 
wie heisst es bei Günter Jauch immer: Bitte nur drücken (antworten), wer 
es wirklich weiss.
Vielen Dank

[Stefan F. (stefanus)]

Michael S. schrieb:
> Erstens das meiste in Englisch

Daran führt bei diesem Fachbereich ohnehin kein Weg vorbei. Wenn du 
Schwierigkeiten mit englisch hast und nicht bereit bist, daran 
schleunigst zu arbeiten, dann suche dir besser ein anderes Fach.

Ich kann mir gut vorstellen, dass das für Teenager schwierig ist. Als 
ich mit Elektronik begann, braucht man noch kein Englisch. Es gab sogar 
tolle Mikrocontroller von Siemens, die bestens auf deutsch dokumentiert 
waren. Aber das ist Vergangenheit.

[Michael S. (misax)]

äh... ich bin kein Teenager. Ich bin 59.
Englisch kann ich zwar aber grade wenn es um Nuancen geht ist es 
manchmal schwer zu verstehen.

[Michael S. (misax)]

Ich hab in den 80er Jahren den Commodore 64 in Maschinensprache 
programmiert aber direkt mit den elektronischen Bauteilen herumhantieren 
ist (interessantes) Neuland für mich.

[(prx) A. K. (prx)]

Michael S. schrieb:
> Englisch kann ich zwar aber grade wenn es um Nuancen geht ist es
> manchmal schwer zu verstehen.

Die technische Seite der Branche zeichnet sich nicht unbedingt durch 
stark nuancierte Nutzung der englischen Sprache aus.

Michael S. schrieb:
> wo dann seitenweise gar nicht auf die eigentliche Frage
> eingegangen wird, drittens zum Teil widersprüchliche oder unklare
> Aussagen.

Ob das in diesem Forum wirklich besser ist? ;-)

[Michael S. (misax)]

doch ich habe in diesem Forum schon jede Menge nützliche Anregungen 
bekommen.

[Ein Freund (Gast)]

Michael S. schrieb:
> Erstens das meiste in Englisch; zweitens viele
> Foren-Antworten wo dann seitenweise gar nicht auf die eigentliche Frage
> eingegangen wird, drittens zum Teil widersprüchliche oder unklare
> Aussagen.

Der 3. "Haupt-" Treffer bei Google mit "ESP8266 Assembler" als 
Suchkriterium verweist auf

http://stefanfrings.de/esp8266/

In Deutsch, sehr ausführlich beschrieben und mit guten weiteren Links. 
(Nein, ich bin kein Fan von ihm :-) )

Davon abgesehen gibt es mittlerweile Übersetzungsfunktionen  bei 
Browsern die schon recht gut sind.

Aber klar, "Schwarmintelligenz" (wenn ich das Wort lese bekomme ich 
schon Pickel) ist viel bequemer.

[c-hater (Gast)]

Michael S. schrieb:

> Englisch kann ich zwar aber grade wenn es um Nuancen geht ist es
> manchmal schwer zu verstehen.

Ach watt. Womit du es hier zu tun hast, ist das sog. 
"Datenblatt-Englisch". Das ist sehr viel einfacher gestrickt als die 
englische Umgangssprache, sehr viel formaler und mit eng abgegrenzten 
Bedeutungen der einzelnen Formulierungen.

Der Unterschied ist in etwa so, als wenn du etwa eine DIN mit der 
deutschen Umgangssprache vergleichst. So eine DIN läßt sich erstmal ganz 
beschissen lesen, selbst (oder gerade?) wenn man deutscher 
Muttersprachler ist. Das relativiert sich aber sehr bald, wenn man genug 
von diesem Kram gelesen hat. Man trifft auf nur recht wenige, immer 
wiederkehrende Formulierungen.

Man muss also nur die Bedeutung dieser wiederkehrenden Formulierungen 
lernen und natürlich die verwendeten Fachausdrücke. An letzterem führt 
leider kein Weg vorbei, egal ob DIN-Deutsch oder DB-Englisch.

Da es bei den Fachausdrücken selber durchaus mal Bedeutungs-Diskrepanzen 
geben kann, enthält praktisch jedes ernstzunehmende DB einen Katalog der 
in ihm verwendeten, die man bei Verständnisschwierigkeiten als Referenz 
benutzen kann.

[Gunnar F. (gufi36)]

Hi Michael,
ich verstehe Deine Argumente gut, denn ich habe genauso angefangen.
Verwendete den at89c51ed2 mit Asem5113    als kostenlose „IDE“, mit 
Notepad++ geht das recht komfortabel.
Programmiert ISP mit Atmel Flip und simuliert mit einer uralten Software 
Simu51 o.ä.
Damit lernte ich Assembler und den Controller kennen, der ja der Urvater 
vieler moderner ist.
Als ich aber 12bit A/D Werte skalieren musste (Dreisatzrechnung!) wuchs 
der Wunsch nach C-Programmierung in mir.

Und später wenn Du auch embedded-C lernst, schadet das Wissen zu 
Assembler definitiv nicht!
Viel Spaß und Erfolg!

[Stefan F. (stefanus)]

Michael S. schrieb:
> ich bin kein Teenager. Ich bin 59.

Oh, sorry. War nicht böse gemeint.

[(prx) A. K. (prx)]

c-hater schrieb:
> Ach watt. Womit du es hier zu tun hast, ist das sog.
> "Datenblatt-Englisch". Das ist sehr viel einfacher gestrickt als die
> englische Umgangssprache, sehr viel formaler und mit eng abgegrenzten
> Bedeutungen der einzelnen Formulierungen.

Wenn man lange genug sein Englisch vorwiegend in der Branche 
praktiziert, riskiert man eher, eine Art IT/Elektronik-Dialekt zu 
entwickeln. Also fachbezogene Begriffe und Ausdrucksformen auch in 
anderen nicht gänzlichen passenden Bereichen anzuwenden. ;-)

[Stefan F. (stefanus)]

Ein Freund schrieb:
> Der 3. "Haupt-" Treffer bei Google mit "ESP8266 Assembler" als
> Suchkriterium verweist auf
>
> http://stefanfrings.de/esp8266/

Das freut mich einerseits (ist meine Seite), aber auf Assembler gehe ich 
da überhaupt gar nicht ein. Komisch, dass Google die Seite trotzdem so 
hoch platziert hat. Das sollte nicht sein. Es sei denn, es gibt nur 2 
passende Treffer.

[Niklas Gürtler (Gast)]

Da ja schon ARM in den Raum gestellt wurde, wäre vielleicht mein 
ARM-ASM-Tutorial interessant. Wenn schon Assembler, ist es wohl am 
sinnvollsten eine verbreitete Architektur zu verwenden, um im 
Mikrocontroller-Bereich ist ARM da weit vorne. Ist auch auf englisch, 
aber da ich ja auch kein Englisch-Muttersprachler bin dürfte es nicht 
allzu kompliziert sein.

[Stefan F. (stefanus)]

Niklas Gürtler schrieb:
> Da ja schon ARM in den Raum gestellt wurde, wäre vielleicht mein
> ARM-ASM-Tutorial interessant.

Ich bin sicher, dass du diesen Gedanken danach ganz schnell wieder 
verwerfen wirst, wenn du dir einen der RAM Befehlssätze im Detail 
anschaust. Ganz besonders das Thema "Adressierung" löst bei mir 
Würge-Reflexe aus.

[Stefan F. (stefanus)]

By the way: wir haben schon ein ARM-ASM Tutorial: 
https://www.mikrocontroller.net/articles/ARM-ASM-Tutorial

Huch, das ist ja von dir Niklas!

Du hast das oben so geschrieben, als würdest du jemand dazu animieren 
wollen, eins zu schreiben. Du bist ja ein Schlingel!

[Niklas Gürtler (Gast)]

Stefan ⛄ F. schrieb:
> Du hast das oben so geschrieben, als würdest du jemand dazu animieren
> wollen,

Ich schrieb doch, mein Tutorial...

[Carl D. (jcw2)]

Michael S. schrieb:
> Ich hab in den 80er Jahren den Commodore 64 in Maschinensprache
> programmiert aber direkt mit den elektronischen Bauteilen herumhantieren
> ist (interessantes) Neuland für mich.

Damals hat man das so gemacht, schlicht weil es nichts anderes gab. Mein 
erstes Auto (mit Stern) hat mich Anfang der 80er weniger gekostet, als 
ein Compiler für irgendwas >Assembler und irgendeine bezahlbare 
Plattform. Erst mit Turbo-Pascal auf CP/M und Z80 hat sich das geändert.

Was hast du seit damals in dem Bereich gemacht. Ich frage rein aus 
Interesse, denn AVR-Assembler-Programme sind ja für die Zeit kein 
extremer Fortschritt. ESP8266-Assembler sollte dank GNU kein Problem 
sein. Der GCC übergibt Files, die mit .S enden direkt an den Assembler 
aus den binutils weiter (wobei du hoffentlich ein OS mit nix/nux am Ende 
benutzt, da funktioniert so Zeug einfacher).
Notfalls kann man sich ein Template vom GCC erzeugen lassen. Interessant 
wäre zu hören, welcher Aufwand der Übergang AVR nach ESP8266 auf der 
Ebene erfordert. Nicht daß ich da keine Vorstellung hätte, aber du 
scheinst jemand zu sein, der das einigermaßen neutral angehen würde.
Ich hatte mir schon mal den Code angesehen, den der Tensilica GCC 
ausgibt und hatte nur minimales Bedürfnis das näher verstehen zu wollen. 
AVR oder noch mehr ARM oder TI430 Assembler ist dagegen eine 
Hochsprache. Manche Chips sind für min. Kosten optimiert und man nimmt 
in Kauf, daß die Schreiber eine Compiler-BackEnds für die Plattform 
graue Haare bekommen.

[Stefan F. (stefanus)]

Niklas Gürtler schrieb:
> Ich schrieb doch, mein Tutorial...

Tatsache. Nicht einmal lesen kann ich richtig.

Jedenfalls finde ich den ARM Befehlssatz sehr kompliziert, würde ich 
keinem Anfänger empfehlen.

[Michael S. (misax)]

hallo Carl;
ich war bis 2002 Organisationsprogrammierer auf Großrechenanlagen in 
COBOL. danach habe ich lange Zeit nicht mehr programmiert bis ich mir 
vor 4 Jahren mein erstes Smartphone kaufte. Da kam mir die Idee selber 
Apps zu entwickeln und schnell war ich beim App Inventor und PHP.
Naja und vor gut einem halben Jahr war ich zufälligerweise auf den 
Calliope mini gestoßen, dann zu Microbit und schließlich dem Arduino. Da 
erinnerte mich an meine alte, längst vergangene Leidenschaft der 
Assemblerprogrammierung (der C64 hatte grade mal 3 Register und war 
hübsch übersichtlich) und bin zum AVR Studio und den diversen 
ATMEL-Prozessoren gelangt.
Jetzt laufen mir die Augen über was es alle mittlerweile gibt. 
Raspberry, adafruit circuit, Lego EV3 und NXT - Wahnsinn.
Mit Elektronik hatte ich mich mal als Jugendlicher in Form eines 
Elektronikbaukastens befasst aber das ist über 40 Jahre her. Damit habe 
ich dann im Zusammenhang mit dem Arduino auch mit angefangen und es ist 
echt eine nette Abwechslung nicht immer nur am Bildschirm zu sitzen und 
zu programmieren sondern auch mal zu löten und zu stecken und Kabel 
zusammenzubasteln.

[c-hater (Gast)]

Gunnar F. schrieb:

> Als ich aber 12bit A/D Werte skalieren musste (Dreisatzrechnung!) wuchs
> der Wunsch nach C-Programmierung in mir.

Wenn das ein Problem war, hattest du nicht wirklich Assembler gelernt.

Gerade bei solchen Sachen kann man in Assembler, frei von irgendwelchen 
fiktiven "Datentypen" sehr effizente Lösungen finden, die in C so nicht 
möglich wären.

Man muss natürlich die binäre Zahlendarstellung verstanden haben und die 
Operationen, die man damit anstellen kann.

Der eigentlich Witz ist aber: diese Kenntnis ist eigentlich auch in C 
unumgänglich, sonst kann man nur Programme schreiben, die höchstens 
zufällig korrekt funktionieren, ansonsten sind sie (zumindest 
potentielle) Sicherheitslücken.

Man muss diesen Scheiß nämlich verstanden haben, um den korrekten dieser 
fiktiven "Datentypen" zu wählen, wenn man sich schon idiotischerweise 
darauf beschränken möchte...

[Carl D. (jcw2)]

Michael S. schrieb:
> hallo Carl;
> ich war bis 2002 Organisationsprogrammierer auf Großrechenanlagen in
> COBOL. danach habe ich lange Zeit nicht mehr programmiert bis ich mir
> vor 4 Jahren mein erstes Smartphone kaufte. Da kam mir die Idee selber
> Apps zu entwickeln und schnell war ich beim App Inventor und PHP.
> Naja und vor gut einem halben Jahr war ich zufälligerweise auf den
> Calliope mini gestoßen, dann zu Microbit und schließlich dem Arduino. Da
> erinnerte mich an meine alte, längst vergangene Leidenschaft der
> Assemblerprogrammierung (der C64 hatte grade mal 3 Register und war
> hübsch übersichtlich) und bin zum AVR Studio und den diversen
> ATMEL-Prozessoren gelangt.
> Jetzt laufen mir die Augen über was es alle mittlerweile gibt.
> Raspberry, adafruit circuit, Lego EV3 und NXT - Wahnsinn.
> Mit Elektronik hatte ich mich mal als Jugendlicher in Form eines
> Elektronikbaukastens befasst aber das ist über 40 Jahre her. Damit habe
> ich dann im Zusammenhang mit dem Arduino auch mit angefangen und es ist
> echt eine nette Abwechslung nicht immer nur am Bildschirm zu sitzen und
> zu programmieren sondern auch mal zu löten und zu stecken und Kabel
> zusammenzubasteln.

Ok, von Alter passen wir zusammen. Auch Mainframes kenn ich, hab die 
aber eher in Assembler bedient. Und einmal einen Fehler in einem 
COBOL-Compiler gefunden, als jemand meinen Code per 
Standard-Call-Convetion von COBOL aus rufen wollte, was der Compiler 
nicht wirklich konnte.
Ich hab das Programmieren nie aufgegeben, lebe immer noch von Sachen, 
die im kommerziellen Umfeld passieren, hab aber Lötkolben und 
Instructionset-Doku nie weggelegt. Seit es dann (kostenlose) Compiler 
für AVR gab, hab ich mich nur noch zum Debuggen und der Frage "hat der 
Compiler mich verstanden" mit Opcodes beschäftigt. Das zahlt sich dann 
aus, wenn plötzlich so was wie der ESP um's Eck kommt. Arduino gefällt 
mir nur bedingt, da vieles sehr suboptimal gebaut wurde, aber beim ESP 
verwende ich nichts anderes. Mal schnell was mit Wifi/Web-Interface 
zusammenbauen geht ruckzuck und per NTP die aktuelle Zeit haben ist da 
schon drin. Und mal beim Debuggen den LX6-24bit-Code anschauen macht 
keinen Spaß. Vielleicht hab ich aber einfach keine Übung.
ARM gefällt mir da viel besser, denn da finde ich vieles, z.B. 
Addressierung immer über Basis-Register und BranchAndLoad, statt 
Returnadresse auf dem Stack, das ich von den ganz dicken Eisen kenne.

[Gunnar F. (gufi36)]

Du hast Recht, ich habe das nie „richtig“ gelernt, sondern 
autodidaktisch. Das erste „richtige“ Projekt war ein Assembler (in 
Maschinensprache!) für den Commodore2001. Damals mit 17, a.D. 1983 in 
der Computer-AG der Schule, gab es auch nicht diese Informationsquellen 
wie heute.
Und ich spreche nicht gegen Assembler! Auf Hardwareebene, z.B. Treiber 
für LCD und A/D Wandler, denke ich in C oft, das hätte ich in Assembler 
schneller geschafft.
Naja, mit Lernen ist man (hoffentlich) nie am Ende!

[c-hater (Gast)]

Gunnar F. schrieb:

> Naja, mit Lernen ist man (hoffentlich) nie am Ende!

Das ist definitiv so. Wenn man meint, man wäre damit durch, ist man 
praktisch schon tot.

[Joachim B. (jar)]

Olaf schrieb:
> Aber ein vernuenftiges Buch ist alles!

definiere "vernünftiges Buch"
Ich hatte mit unvernünftige Bücher über 1000,-DM versenkt, seit dem bin 
ich bei Bücher sehr skeptisch!
Viele Bücher sind nur auf Verkauf getrimmt und wenn dann tiefere Fragen 
auftauchen bleibt man im Regen stehen kauft das nächste usw.

[Niklas G. (erlkoenig)]

Stefan ⛄ F. schrieb:
> Jedenfalls finde ich den ARM Befehlssatz sehr kompliziert, würde ich
> keinem Anfänger empfehlen.

Einem Programmier-Anfänger sollte man Assembler sowieso nicht empfehlen. 
Ich finde es immer wichtig, Programmieren mit Systemen zu lernen, welche 
praktische Relevanz haben und mit denen man auch "richtig" was machen 
kann. Wenn man also Programmieren an sich kann (z.B. mit Python und/oder 
Java angefangen, mit C++ native Programmierung gelernt), kann man mit 
einem verbreiteten Assembler anfangen, z.B. x86 oder eben ARM. Klar sind 
das bei Weitem nicht die einfachsten Assembler-Sprachen, aber dafür gibt 
es große Mengen an Ressourcen und Tools, und man kann auch "richtig" was 
damit anfangen. Gerade x86-Assembler wurde viel im Hobby-Bereich für 
alle möglichen Spielereien verwendet, von der Demo-Szene über Cracks bis 
zu eigenen OSen. Einen exotischen aber einfacheren Assembler würde ich 
nicht empfehlen, weil man sich dann wahrscheinlich letztendlich mehr mit 
den Tools herumschlägt als man bei komplexeren Assemblern mit der 
Sprache selbst.

c-hater schrieb:
> Gerade bei solchen Sachen kann man in Assembler, frei von irgendwelchen
> fiktiven "Datentypen" sehr effizente Lösungen finden, die in C so nicht
> möglich wären.

Hast du dafür ein Beispiel? Was ist ein fiktiver Datentyp, und was ein 
realer?

[c-hater (Gast)]

Niklas G. schrieb:

> Hast du dafür ein Beispiel?

Zwei:
Beitrag "Audio Spektrum Analyzer mit ATtiny85"
Beitrag "Westminster Soundgenerator mit ATtiny85"

Beides Projekte, die in Asm umgesetzt wurden und (u.A.) nur deshalb 
funktionieren, weil bei Berechnungen recht "freizügig" mit Datentypen 
hantiert wird. De facto gibt es keine. Oder auch: sehr viele. Reine 
Frage der Betrachtungsweise.

> Was ist ein fiktiver Datentyp, und was ein
> realer?

Ganz einfach: ein realer Datentyp ist einer, der sich aus der Hardware 
der Zielarchitektur ergibt. Der ganze Rest ist fiktiv.

[Niklas G. (erlkoenig)]

c-hater schrieb:
> Zwei:

Wo finde ich da jetzt konkrete übersichtliche Beispiele für 
Berechnungen, die nur in Assembler gehen?

c-hater schrieb:
> Ganz einfach: ein realer Datentyp ist einer, der sich aus der Hardware
> der Zielarchitektur ergibt. Der ganze Rest ist fiktiv.

Alle digitalen Architekturen können letztlich nur Bits speichern, also 
ist nur ein Bit ein realer Datentyp? In vielen Programmiersprachen 
gibt es einzelne Bits explizit als Datentyp, aber in den meisten 
Assemblern nicht wirklich, eher implizit über die Offsets in 
Shift-Instruktionen.

[c-hater (Gast)]

Niklas G. schrieb:

> Wo finde ich da jetzt konkrete übersichtliche Beispiele für
> Berechnungen, die nur in Assembler gehen?

Sie gehen natürlich nicht nur in Assembler. Sie gehen nur in Assembler 
schnell genug. Weil eben für die konkrete Anwendung sowieso Unwichtiges 
weggelassen wurde.

> Alle digitalen Architekturen können letztlich nur Bits speichern

Nö. Die kleinsten bekannten CPUs können immerhin mit Nibbles hantieren, 
bei den größten heutigen hat man es hingegen u.U. sogar mit Datentypen 
von 256Bit oder mehr zu schaffen. Bei den general purpose CPUs/MCUs 
dürfte derzeit bei 256Bit die Grenze sein.

Wobei die Speicherbreite sowieso nur der eher unwichtige Teil der Sache 
ist, es geht vielmehr hauptsächlich um die Verarbeitungsbreite in den 
verfügbaren Rechenwerken.

[(prx) A. K. (prx)]

c-hater schrieb:
> Bei den general purpose CPUs/MCUs dürfte derzeit bei 256Bit die Grenze sein.

Bei Intel sind es 512.

c-hater schrieb:
> Ganz einfach: ein realer Datentyp ist einer, der sich aus der Hardware
> der Zielarchitektur ergibt.

Was ist eigentlich, wenn die Befehlssatz-Architektur die Bitbreite der 
Hardware offen lässt, sie nirgends festlegt? Und nur die Implementierung 
daraus je nach Modell 16 oder 32 Bits macht (INMOS T212, T414).

[c-hater (Gast)]

(prx) A. K. schrieb:

> Was ist eigentlich, wenn die Befehlssatz-Architektur die Bitbreite der
> Hardware offen lässt, sie nirgends festlegt? Und nur die Implementierung
> daraus je nach Modell 16 oder 32 Bits macht (INMOS T212, T414).

Dann legt es natürlich erst die Implementierung fest, ist doch logisch.

[(prx) A. K. (prx)]

c-hater schrieb:
>> Was ist eigentlich, wenn die Befehlssatz-Architektur die Bitbreite der
>> Hardware offen lässt, sie nirgends festlegt? Und nur die Implementierung
>> daraus je nach Modell 16 oder 32 Bits macht (INMOS T212, T414).
>
> Dann legt es natürlich erst die Implementierung fest, ist doch logisch.

Programmiert man in Assembler oder Binärcode mit realen statt fiktiven 
Datentypen, wenn der Bit für Bit exakt identische Binärcode mal mit 16 
und mal mit 32 Bits rechnet? Eingebettete Konstanten inklusive.

[Niklas G. (erlkoenig)]

c-hater schrieb:
> Sie gehen natürlich nicht nur in Assembler. Sie gehen nur in Assembler
> schnell genug. Weil eben für die konkrete Anwendung sowieso Unwichtiges
> weggelassen wurde.

Interessant, aber immer noch kein Beispiel.

c-hater schrieb:
> Nö. Die kleinsten bekannten CPUs können immerhin mit Nibbles hantieren,
> bei den größten heutigen hat man es hingegen u.U. sogar mit Datentypen
> von 256Bit oder mehr zu schaffen.

Die setzen sich auch nur aus Bits zusammen.

c-hater schrieb:
> es geht vielmehr hauptsächlich um die Verarbeitungsbreite in den
> verfügbaren Rechenwerken.

Und welche zählt jetzt? Gerade x86_64-CPUs können in der ALU eine Reihe 
verschiedener Größen verarbeiten. Was ist mit CPUs, die zwar Befehle für 
z.B. 64bit-Arithmetik haben, diese aber intern als 2x 32bit berechnen?

Und was hat das alles mit der Auswahl der Programmiersprache zu tun?

[Ein Freund (Gast)]

Stefan ⛄ F. schrieb:
> r auf Assembler gehe ich
> da überhaupt gar nicht ein

Merkwürdig:

Möglichkeiten der Programmierung

steht da als Kapitel - warum fehlt Assembler da wohl? Du solltest das ja 
wohl wissen - oder?

[Ein Freund (Gast)]

Aber grundsätzlich dürfte man so ziemlich alles in Assembler 
programmieren können, da jeder (mir bekannte) Compiler Zwischencode in 
Assembler generiert, welcher dann umgesetzt wird.

[Stefan F. (stefanus)]

Ein Freund schrieb:
> warum fehlt Assembler da wohl?

Weil ich es für nicht empfehlenswert halte.

[Ein Freund (Gast)]

Stellt sich nur die Frage nach dem Sinn. Die Assembler-Freaks haben 
natürlich x Makros an der Hand, welche die Programmierung vereinfachen - 
da verschwimmt die Grenze zum Compiler (welcher Art auch immer) aber aus 
meiner Sicht schon leicht. Egal - jeder so, wie er es mag.

[(prx) A. K. (prx)]

Ein Freund schrieb:
> Aber grundsätzlich dürfte man so ziemlich alles in Assembler
> programmieren können

Grundsätzlich kann man auch alles in Maschinencode programmieren. Ganz 
am Anfang der Mikrocomputertechnik standen Boards wie 6502 KIM-1, mit 
denen das nicht anders möglich war. Aber auch hier stellt sich dir 
Frage: warum sollte man?

[Ein Freund (Gast)]

c-hater schrieb:
> Beides Projekte, die in Asm umgesetzt wurden und (u.A.) nur deshalb
> funktionieren, weil bei Berechnungen recht "freizügig" mit Datentypen
> hantiert wird. De facto gibt es keine. Oder auch: sehr viele. Reine
> Frage der Betrachtungsweise.

Na ja - eher weil geschickt mir Registern hantiert wird, was einem 
"normalen" Compiler nicht ganz so leicht fällt (da ganz speziell) und da 
geschickt (Gratulation) mit "2er-Potenzen" umgegangen wird (das geht 
aber auch in C - wenn man weiß wie ...).

[Ein Freund (Gast)]

Carl D. schrieb:
> Und einmal einen Fehler in einem
> COBOL-Compiler gefunden, als jemand meinen Code per
> Standard-Call-Convetion von COBOL aus rufen wollte, was der Compiler
> nicht wirklich konnte.

Erzähl mal aus dem Nähkästchen - ich kenne COBOL noch und bin gespannt 
auf den "Fehler".

[(prx) A. K. (prx)]

Ein Freund schrieb:
> Na ja - eher weil geschickt mir Registern hantiert wird, was einem
> "normalen" Compiler nicht ganz so leicht fällt (da ganz speziell)

Andererseits fällt Registerallokation Compilern mitunter sogar leichter. 
Wenn man davon eigentlich zu wenige hat, der Programmierer nicht drei 
Tage lang um jede Zeile ringt, der Compiler aber die Aktivitätsbereiche 
der Daten besser im Auge hat als der Programmierer.

Erst recht, wenn der schlussendlich real existierende Code auf eine 
Maschine mit etwas anderen Eigenschaften trifft. Beispielsweise wenn 
diverse Latenzen von der ursprünglichen Maschine abweichen und das ganze 
manuelle Tuning teilweise für den Arsch war.

[Carl D. (jcw2)]

Ein Freund schrieb:
> Carl D. schrieb:
>> Und einmal einen Fehler in einem
>> COBOL-Compiler gefunden, als jemand meinen Code per
>> Standard-Call-Convetion von COBOL aus rufen wollte, was der Compiler
>> nicht wirklich konnte.
>
> Erzähl mal aus dem Nähkästchen - ich kenne COBOL noch und bin gespannt
> auf den "Fehler".

Oh, das ist 28 Jahre her, R0 sollte auf einen Block mit der Adressen der 
Parameter zeigen und zeigte aber auf die Adresse des Blocks, also eine 
Indirektion zu viel. Als wir die Kollegen vom Maschinenraum 
informierten, sagten die, das sei bekannt, aber sie hätten den 
Compiler-Patch bisher nicht installiert. Und fragten, ob wir das denn 
wirklich brauchen.
In COBOL selbst hab ich aber nie eine Zeile geschrieben. Ich hatte mir 
die Nische ausgesucht unter BS2000 zwischen einem ERP und einem 
Lagerrechner zu vermitteln. Das wollte sonst keiner machen und ich war 
jung und könnte danach mit Mainframe-CPUs umgehen. Der COBOL-Bug war 
eher Unterstützung zwischendurch. Immerhin war ich dem Fragenden Tage 
voraus und hatte schon gelernt auf Assemblerebene zu debuggen.