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
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
wie meinst du das ? Gibt es eine Möglichkeit mit dem Atmel Studio den ESP8266 in Assembler zu programmieren ? Was ist die Extensa GCC ?
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.
Beitrag #6507441 wurde von einem Moderator gelöscht.
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.
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
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 ?
> 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
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.
:
Bearbeitet durch User
Michael S. schrieb: > gibt es noch andere vergleichbar einfache ? Sicher, zum Beispiel PIC und zahlreiche Serien die auf dem 8051 basieren.
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?
Michael S. schrieb: > oder > gibt es noch andere vergleichbar einfache ? Kennst Du Google? Wen willst Du hier eigentlich veralbern :-)
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
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.
ä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.
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.
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? ;-)
doch ich habe in diesem Forum schon jede Menge nützliche Anregungen bekommen.
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.
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.
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!
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. ;-)
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.
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.
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.
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!
Stefan ⛄ F. schrieb: > Du hast das oben so geschrieben, als würdest du jemand dazu animieren > wollen, Ich schrieb doch, mein Tutorial...
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.
:
Bearbeitet durch User
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.
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.
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...
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.
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!
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.
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.
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?
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.
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.
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.
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).
:
Bearbeitet durch User
(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.
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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?
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.
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.
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?
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 ...).
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".
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.