Vorweg, ich bin kein Gegner von Assembler-Programmierung. Ich finde nur die sollte dann eingesetzt werden, wenn es nötig wird. Gerade im Amateurfunkbereich gibt es einige Projekte, da quält sich die "Projektleitung" wochenlang mit der ASM Implementierung einer grafische Benutzerschnittstelle ab, während die Sache in einer Hochsprache relativ zackig durchkodiert ist. Da werden für neue Projekte Controller ausgesucht, die fast schon obsolet sind und es muss bei jeder Funktion mit dem Flachspeicher gehaushaltet werden. Funktionalität wird deshalb auf ein Minimum zurückgefahren damit es in den Speicher passt. Eine Computersteuerung eines Funktionsmoduls wird natürlich mit RS232 und bestenfalls einem rudimentären Terminalprogramm umgesetzt. Für 50 Cent mehr hätte man ja gleich einen aktuellen Controller mit einem vielfachen an Speicher bekommen, inklusive zeitgemäßer USB Schnittstelle für die Computersteuerung. Eine Benutzerschnittstelle auf einem TFT wäre in einer Hochsprache, sogar mit fertigen Grafiklibs möglich, aber nee man fängt an jedes Bit zu zählen und erfindet das Rad neu. Warum tuen sich die Leute, vornehmlich älterer Genese, soetwas an? Ich finde es ja toll das sich auch ältere Bastler immer stärker mit Mikrokontollern beschäftigen, aber warum sind viele von denen so drauf und nehmen den kleinsten Baustein den es gibt und schreiben wochenlang am ASM-Code für eine nicht zeitkritische Funktion, die man in einer Hochsprache in wenigen Minuten umgesetzt hätte?
:
Verschoben durch User
weil es Hobby ist und vielleicht Spass macht. Schließlich ist die Definition von Hobby, mit dem größtmöglichen Aufwand den geringsten Nutzen zu erwirtschaften
Aus prinzipiellen Gründen? Weil sie ihren "alten Controller" gut kennen? Weil sie Assembler können, Rust aber neu lernen müssen? [edit Mod: politischen Krams gelöscht] mfg
:
Bearbeitet durch Moderator
Hi
>Warum quälen sich so viele Hobbyprojekte noch mit ASM-Code ab?
Weil man Zeit hat und es Spass macht.
MfG Spess
Dl1... schrieb: > Gerade im > Amateurfunkbereich gibt es einige Projekte, da quält sich die > "Projektleitung" wochenlang mit der ASM Implementierung einer grafische > Benutzerschnittstelle ab, während die Sache in einer Hochsprache relativ > zackig durchkodiert ist. Die haben eben Zeit. mfg Klaus
Dl1... schrieb: > Warum tun sich die Leute, vornehmlich älterer Genese, soetwas an? Weil sie noch Assembler können und auch die Hardware von modernen Mikrocontrollern verstehen und benutzen können ...
... weil rumspielen im intellekt spass macht und herausfordernd ist und natürlich besser ist als nur glotze schauen. z.b. gibt es ein forum, wo gewetteifert wird, wer in asm den effektivsten/ elegantesten/schnellsten/kleinsten code auf einer ziel hw hinbekommt. also ähnlich geil wie lego, eisenbahn, ... schach spielen. oder was machen wir hier? warten auf godot!
Hi
>Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;)
Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik
haben.
MfG Spess
spess53 schrieb: > Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik du meinst sicher keine ahnung von vielen haben und besonders keine ahnung von dem haben, von dem sie keine ahnung haben! wer seinen code nicht x-mal neu schreibt hat keine ahnung von seinen code.
Jan H. schrieb: > Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;) Wieso glaubst du das? Weiterlernen hängt nicht vom Alter ab, sondern vom Spass an der Elektronik und deren neuen Möglichkeiten ... Um nicht ein alter Knacker zu werden hilft nur eins, vorher zu sterben. Aber das wünsche ich niemanden. Vielleicht erinnerst du dich in vielen Jahren noch mal an deinen Text von heute ...
Dl1... schrieb: > Warum tuen sich die Leute, vornehmlich älterer Genese, soetwas an? Ja die Jugend. Ich nehme mal an, dass du Student bist/warst und die Möglichkeit hattest, das da zu lernen. Was Studenten haben, ist viel, viel Zeit. Dazu noch Kommilitonen oder Profs, die man fragen kann. Aber wenn man das nicht hatte und im Beruf steht und Familie hat, wird es schwer im kleinen Kämmerlein eine neue Sprache zu lernen. Zu meiner Zeit gab es noch kein C oder BASIC. Wir haben da mit Algol u.ä. rumgemacht. Für bissl Lauflicht Blinki Blinki reicht Assembler aus. Module für LCD oder USB gibt es sicher auch in Ass. Man muß das Rad ja nicht neu erfinden. Zur Not Bascom. Meine C Versuche sind am Aufwand/Nutzen gescheitert.
Beitrag #5927359 wurde von einem Moderator gelöscht.
michael_ schrieb: > Zu meiner Zeit gab es noch kein C oder BASIC. > Wir haben da mit Algol u.ä. rumgemacht. Du Ärmster. Zu meiner Zeit war (u.a.) GFA BASIC .. ;)
Hi >du meinst sicher keine ahnung von vielen haben und besonders keine >ahnung von dem haben, von dem sie keine ahnung haben! Sprich das erst mal ins Reine. MfB Spess
spess53 schrieb: > Hi > >>Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;) > > Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik > haben. > > MfG Spess Halte ich so für eine typische freche Aussage, wie man es halt so kennt. Was soll denn bitte "richtige" Amateurfunktechnik sein? Ist eine Bake welche in C statt ASM programmiert wurde keine "richtige" Bake?
Beitrag #5927375 wurde von einem Moderator gelöscht.
Die Frage ist durchaus sinnvoll. Würde schätzen es liegt am Alte Leute-Masochismus die dir was vom Apollo-Computer erzählen und nicht mit den Minusbewertungen geizen. Haben ja sogar MajorTom hier der sicherlich Schaltungen mit Operationsverstärkern baut, während er dafür von einem noch älteren Elektroniker gerüffelt würde, ob er denn zu blöd sei Transistoren richtig zu verwenden.
michael_ schrieb: > Zu meiner Zeit gab es noch kein C oder BASIC. > Wir haben da mit Algol u.ä. rumgemacht. Meine ersten Mikroprozessor /-controlleranwendungen waren in Assembler, Hochsprache war da noch nicht anwendbar. Nach einer (selbst layouteten) Europakarte mit 6502 samt Peripherie hatte ich ein Board für 68HC805 im PLCC, was etwa so groß wie ein Arduino-Uno ist und damit diverse Dinge gemacht, sowohl in der Firma als auch Privat. Aufgrund einer Umorientierung war dann beruflich viele Jahre nichts mehr mit Hardware. > Für bissl Lauflicht Blinki Blinki reicht Assembler aus. Auch für mehr, aber habe ich das heute noch nötig? > Meine C Versuche sind am Aufwand/Nutzen gescheitert. Als ich vor ein paar Jahren hobbymäßig wieder einen µC brauchte, die Entscheidung: Den alten Kram wieder her, Material hätte ich ja genug? Nee, ich habe mir einen Uno geholt und mal losgestochert, so wirklich schwer war das nicht, sich damit zurechtzufinden.
spess53 schrieb: > Hi > >>Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;) > > Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik > haben. Knallfunkensender...
Hi
>Heutzutage entwickelt man nur noch so:
Wen interessiert das? Selbst Apple hat 500 Anlagen von uns gekauft in
denen ein Assemblemlerprogramm von mir läuft. Ich hoffe du bist auch so
erfolgreich.
MfG Spess
warum macht eigentlich fahrrad fahren, joggging oder gutes essen spass, ist doch voll old school?! oder warum bildung wenn ausbildung doch auch reicht, ist doch eh das selbe oder?
Also ich nehme meistens einen Tiny10, weil ich selten so viele Funktionen brauche. Wenn ich mit "drüber streicheln" erreichen könnte, dass er das macht, was er machen soll, dann würde ich das sofort machen. Auch gut zureden wäre schön. Aber die Programme müssen nun mal da rein und da nimmt man vorzugsweise das was man schon kann oder auch schon Teile davon fertig hat. Ein Beispiel ist meine "Kühlbox" für meine Fritzbox. Da habe ich einen Atmega328 gekommen, obwohl der Tiny10 gereicht hätte, aber da konnte ich ein Arduino Program aus den Anfangszeiten, mit wenigen Änderungen, so übernehmen und war mit dem Programm in 10 Minuten (oder kürzer) fertig. Sieht natürlich albern aus, die Platine. Ein Ausgang für den Lüfter, ein für den Piepser und ein DS18B20. Ungefähr der achtfache Preis gegenüber eines Tiny10, aber ob 26 Cent oder 2 Euro spielen in dem Zusammenhang gar keine Rolle.
spess53 schrieb: > Wen interessiert das? gute frage! wahrscheinlich jene, die glauben das ein zitronenfalter zitronen faltet - sprich die angepassten, gleichgemachten, ...
spess53 schrieb: > Hi > >>Heutzutage entwickelt man nur noch so: > > Wen interessiert das? Selbst Apple hat 500 Anlagen von uns gekauft in > denen ein Assemblemlerprogramm von mir läuft. Ich hoffe du bist auch so > erfolgreich. > > MfG Spess Zügle mal die Pferde! War doch nur etwas provokatorisch gemeint. Ich hatte übrigens heute sogar eine Vorführung von embed auf einer Nucleo Bord. Das stellt sogar Arduino in Abkapselung noch in den Schatten. DHCP Ethernet, USB - eine Kleinigkeit. Man muß kaum einen Finger rühren. Von wegen Dekadenz im Programmieren:-) Was soll ich dazu sagen? Brrr! Nichts für mich. Da programmiere ich die ARM Peripherie Register lieber selber von Hand und bin für alle Fehler selber verantwortlich. Naja. Mein Bekannter entschuldigte sich auch und meinte, wir nehmen das ja nur zum schnellen Ausprobieren her. Aber trotzdem; es ist möglicherweise ein fortschreitender Trend zur Verflachung des Gewerbes indem man alle Komplexität nach Möglichkeit vertuschen will. Trotzdem finde ich, daß so etwas in engem Rahmen durchaus nützlich sein kann.
Ryzen-PC schrieb: > michael_ schrieb: >> Zu meiner Zeit gab es noch kein C oder BASIC. >> Wir haben da mit Algol u.ä. rumgemacht. > > Du Ärmster. Zu meiner Zeit war (u.a.) GFA BASIC .. Aber du hattest nicht den Genuss, Löcher per Hand ins Lochband zu stanzen oder zuzukleben. Manfred schrieb: >> Für bissl Lauflicht Blinki Blinki reicht Assembler aus. > > Auch für mehr, aber habe ich das heute noch nötig? > >> Meine C Versuche sind am Aufwand/Nutzen gescheitert. > > Als ich vor ein paar Jahren hobbymäßig wieder einen µC brauchte, die > Entscheidung: Den alten Kram wieder her, Material hätte ich ja genug? > > Nee, ich habe mir einen Uno geholt und mal losgestochert, so wirklich > schwer war das nicht, sich damit zurechtzufinden. Deshalb werden in ein paar Jahren die C-Leute belächelt. Ich habe aber für sowas noch BASCOM in Reserve. Für mich habe ich mit Blinki Blinki untertrieben. Vor fast 20 Jahren bin ich da beruflich ausgestiegen. Man muß das mit den Augen von damals sehen. Moby schrieb im Beitrag #5927375: > Dl1... schrieb: >> Warum tuen sich die Leute ... soetwas an? > > Aus dieser Frage spricht vor allem Unkenntnis über die Vorzüge von > Assembler. Man ist da mehr an der Hardware dran. Man soll es aber nicht zu einer Relegion erheben. Immer das richtige Werkzeug für ein Ziel wählen.
Lochband ist ja neumodischer Schnickschnack. Die richtig Harten haben noch Fortran in Lochkarten gestanzt. Und immer schoen mit Zeilennummer falls der Rechenzentrumsfuzzie die noch mal durchgemischt hat.
DC schrieb: > Schließlich ist die > Definition von Hobby, mit dem größtmöglichen Aufwand den geringsten > Nutzen zu erwirtschaften Schwachsinn.
Hallo [Edit Mod: politischen Krams gelöscht] Zur eigentlich Frage: Eventuell um nah an der Hardware des µC zu sein, um keine Black Boxes zu nutzen, weil es Spaß macht, weil der entsprechende µC bis auf die letzte Speicherzelle bekannt ist, weil es etwas hat den µC wirklich zu verstehen, weil man (halt vor allem ältere) noch mit Digitalen Logikgattern ausgewachsen ist und mit diesen die Grundlagen gelernt hat... Und nicht zuletzt weil man halt anders ist und sein will als "alle" anderen und um "die jungen Hüpfer", Forentrolle und OV "Trolle" auch ein wenig zu ärgern... Jemand
:
Bearbeitet durch Moderator
Dl1... schrieb: > Warum tuen sich die Leute, vornehmlich älterer Genese, soetwas an? Deine Frage enthält bereits die Antwort. Nicht jeder, der in den 80er-Jahren mit Mikroprozessoren der ersten Generation groß geworden ist, hat Lust, sich mit immer wieder neuen hippen Frameworks, HAL und Gigabyte fressenden Entwicklungsumgebungen rumzuschlagen. Man muss nicht jeden Aufgabe mit einem 32-Bit Prozessor erschlagen, nur weil man es kann.
Genauso gut kann man sich fragen, warum sich viele im Bereich (Hobby)-PC-Programmierung noch mit C abgeben, wo es doch derzeit viele sehr interessante moderne Sprachen gibt. Ich weiss es nicht. Zugeben muss man aber, dass C-oder Assembler-Programmieren ein wirkliches Verständnis von den Vorgängen im Computer haben -- viele Python- oder Javascript-Programmierer aber nicht.
> Genauso gut kann man sich fragen, warum sich viele im Bereich > (Hobby)-PC-Programmierung noch mit C abgeben, wo es doch derzeit viele > sehr interessante moderne Sprachen gibt. C ist auch in der Industrie noch immer das Maß der Dinge. Andere hippe Sprachen kommen und gehen innerhalb weniger Jahre.
Beitrag #5927495 wurde von einem Moderator gelöscht.
Stefan S. schrieb: > Ich weiss es nicht. Zugeben muss man aber, dass C-oder > Assembler-Programmieren ein wirkliches Verständnis von den Vorgängen im > Computer haben -- viele Python- oder Javascript-Programmierer aber > nicht. Obwohl ich hier wieder eine Lanze brechen muss. Wenn das Programm genau das tut, wofür es sein soll und der Controller funktioniert so, dann kann es vielen völlig egal sein wie die einzelnen Register da gerade arbeiten. Die meisten Autofahrer können kaum einen Reifen wechseln, geschweige denn, dass sie ihren Motor kennen und erst recht nicht was an den verschiedenen CAN Bussen hängt. Da wird es akzeptiert, dass man das Teil nur bedienen kann. Meine persönlichen Ansprüche sind da anders, deshalb habe ich auch dann die Finger von den ST32 gelassen, nachdem ich mit jemandem aus dem Forum einmal damit begonnen hatte.
spess53 schrieb: > Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik > haben. Es gibt keine jungen Knacker. Das sind höchstens junge Kacker ;-)
„Warum quälen sich so viele Hobbyprojekte noch mit ASM-Code ab?“ Weil vermutlich für einige Leute asm code eher verständlich ist, als das objektorientierte Kauderwelsch so mancher Hochsprache!
Assembler kommt mir sogar leichter vor wie C++. Es gibt nur ein paar Lade-, Sprung-, Rotier- usw. -Befehle. Bei C++ dagegen bricht sich mir fast das Hirn bei manchen Ausdrücken und Absätzen - und jährlich kommt Neues hinzu. Assembler hat auch einige Nachteile - es braucht daher unbedingt einen Flussplan mit einer Art Sprungziel-Notation. Auch war C damals am PC sehr ineffizient - man hat schliesslich keinen Low-Level-Zugang an der Kiste. Man konnte aber riesige Formeln für 3D-Grafik-Berechnung zusammentippen - für einen Terrain-Editor hätte es gereicht, für ein tolles Spiel bestimmt nicht.
Es gibt einige wenige Fälle wo Assembler unschlagbar ist.
Diese Fälle sind aber so rar, beim Gros der Assembler-Projekte dürfte
daher eher im Vordergrund stehen:
- es ist mein Hobby, ich mach was ich will und mir Spaß macht
- ich kann nix anderes
Beides sind durchaus legitime Gründe für die Benutzung von Assembler.
Aber dann bitte auch dazu stehen und keine Pseudogründe bemühen ("bei
Hochsprachen hab ich keine volle Kontrolle über den Controller", "mein
toller Algorithmus ist so zeitkritisch und mein Assemblercode so
effizient"...).
hier mal meine Meinung dazu warum ich kein C verwende. Ich muss dazu sagen das ich schon versuche meinen Code möglichst schlank und schnell zu gestalten. 1. Wenn ich mit 8 Bit rechnen will mach ich das einfach, ich muss dem Compiler nicht erst sagen das er bitte nicht zuviel Platz verschwenden soll und da gleich mal 32bit reserviert. 2. Wenn ich viel mit Interrupts arbeite die in sehr kurzen Abständen eintreffen, muss ich nicht erst alle Register pushen/popen obwohl ich diese gar nicht verändere. Hier geht einiges nur durch den Interruptaufruf an Performance verloren. Ich bin mit mit der Interruptroutine schon fertig während das C Programm erst noch die Register sichert. 3. Ich weiß genau wie lange etwas dauert, ohne das mir irgendeine Optimierung meinen Code umwürfelt und ich mich im Nachhinein durch die Listings arbeiten wo wie was gemacht wird. 4. Habe ich es beim desassemblieren viel leichter wenn mein ursprünglicher Code nicht durchgewürfelt wird. Hatte schonmal einen Quellcode durch einen defekten Stick verloren, habe dann den µC ausgelesen und meinen Quellcode wieder erstellen können. C würde mir Vorteile bei Berechnungen bieten, da klatscht man es mehr oder weniger hin. Für mich ist es aber einfach eine Herausforderung die mir Spaß macht. CRC- Berechnungen, Interpolation aus Kennfeldern... einfach und schnell mittels ASM und vor allem das Wissen darum wie etwas funktioniert was heute vielen fehlt und schlechtes Programmieren wird heutzutage einmach mit Rechenleistung erschlagen, was meiner Meinung der falsche Weg ist.
@Thomas du hast noch vergessen das man seinen µC-Typ meist eh nicht wechselt und man genügend Vorlagen über die zeit für die Perifferi gesammelt hat hat man bei C auch aber man hat bei ASM für sich Passende "Libs" die alle das gleiche Muster haben wie sie Benutzt und abgefragt werden, bei C hat man das nur wenn man keine Fremden libs benutzt. Ich Persönlich bin auch Fan von ASM irgendwann klickt man sich seine eigenen Libs ins Projekt und macht nur noch das drumherum und was ein großer vorteil ist, das Debuggen man weis genau wann was wie Passiert ohne das am Quelltext noch großartig was vom Compiler Optimiert wird und man hinterher Stunden mit dem ASM Listing beschäftigt ist. Klar einige Sachen in ASM sind recht schwer aber das kommt dann immer drauf an wofür man seine µCs nutzt aber man kann schon recht viel mit ASM machen Problem sind dann halt Sachen wie USB/Netzwerk aber das war es dann auch schon fast selbst Grafik ist in ASM nicht so das Problem wenn man sich dafür einmal Lösungen erarbeitet hat.
Hi Jan H. schrieb: > Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;) Nun, wer sich durch diesen Text angegriffen fühlt, sollte ihn richtig lesen. Wenn mich nicht alles täuscht, ist da doch ein Smilie oder Emotion angehängt, der auf Ironie hinweist. Also, ich bin auch ein "alter Knacker" und kann (etwas) Assembler und ja, ich programmiere meine Controller damit. Hat jemand was dagegen? Wenn ja, soll er sich ärgern, das ich mir nichts daraus mache. Wenn ich C bräuchte, würd ich es lernen. Why not? Aber ich brauch es nicht (mehr). Nebenbei, ich hab auch schon in Hochsprachen sehr umfangreiche Anwendungen programmiert. Aber wenn ich das alles aufzähle, werden einige nur schmunzeln und andere mich der Prahlerei bezichtigen und das zu Recht. Leute, es ist doch völlig egal, welche Sprache zum Einsatz kommt. Wenn jemand Assembler macht, warum nicht? Und tot wird diese Sprache nie sein, sei es nur für Hochsprachenentwickler, die an bestimmten Aufgaben nur mit Assemblerroutinen weiterkommen. Kein "echter" Programmierer wird sich darüber wundern oder aufregen, das es noch Menschen gibt, die sich für die ein oder andere Programmiersprache interessieren und Assembler ist nun mal eine solche. Meine ersten Computerprogramme enthielten noch Maschinencode, von Hand assemblierte Codeblöcke, weil dadurch Routinen so richtig beschleunigt wurden. Die Generation C20 und Comodore oder gar Sinclair ZX80 kennen das Problem. Also, warum soll ich als alter Knacker nun nicht dieses vorhandene Wissen nutzen? Bin ich deshalb ein ewig Gestriger? Warten wir doch mal 30 Jahre ab und sehen uns an, was von den heutigen C- Experten noch übrig ist. Wer dann noch irgendeine Sprache benutzt, der wird sich auch als alten Knacker bezeichnen lassen müssen, weil programmieren dann vermutlich so einfach ist, das man sagt was man will und irgendetwas führt das dann irgendwo aus. Warum sollte man dann nachdenken, wie das funktioniert? Wozu. Das Ergebnis zählt und solange wir unsere Wünsche äußern können, ist es doch egal wie, Hauptsache sie werden erfüllt. Wie ihr seht, alles Sätze, die heute auch schon benutzt werden. Aber das heute die Weichen für die Zukunft gestellt werden ist euch doch auch klar. Also, dann kommt auch mit den Sprüchen der kommenden Generation klar. So wie ich. Ich werde weiterhin bis zum endgültigen Wegschieben der Tastatur Assemblerprogramme schreiben und jedem helfen, der neugierig bleibt. Und bevor ich eine (negative) Beurteilung für einen Text abgebe, lese ich solange, bis ich sie verstanden habe. In der Regel aber nur einmal. gruß oldmax
Wenn es richtig komplizierte Algorithmen sind, dann lässt man von ASM besser die Finger, denn man verliert dann gar zu schnell den Überblick. Wenn dann auch noch größere Änderungen an bestehendem Code gemacht werden müssen, wirds ganz furchtbar ätzend… Auf der anderen Seite verstehe ich aber auch das Gejaule über die Optimierungen des Compilers nicht. Ich habe lange genug Crashdumps analysiert und weiß ganz gut, was da auf Maschinencode-Ebene so gespielt wird: der Compiler kocht auch nur mit Wasser und wenn man die Tricks, die dort angewandt werden, mal verstandewn hat, dann kann man ASM wirklich und die Verbindung zwischen Maschinencode und C-Quelltext ist nicht mehr all zu schwierig. Nett in ASM zu programmieren sind die MSP430. Die Atmel 8-bitter finde ich da nicht so prickelnd; die Drecksarbeit darf der Compiler machen, wenn es nicht sehr sehr gute Gründe für ASM gibt. Der Inline-Compiler des GCC ist jedenfalls zum abgewöhnen.
Le X. schrieb: > Diese Fälle sind aber so rar, beim Gros der Assembler-Projekte > dürfte daher eher im Vordergrund stehen: > - es ist mein Hobby, ich mach was ich will und mir Spaß macht > - ich kann nix anderes Du hast einen legitimen Grund vergessen: - es ist auf diesem Controller nur in Assembler überhaupt möglich Meinen i8080-Emulator habe ich von avr-gcc nach avr-as portiert (gleiche Struktur). Die Assembler-Implementation ist etwa 20x schneller. Gleiches gilt für das AVR CP/M-Projekt: In C wäre es nicht möglich (Performance), mit einem anderen Controller ebenfalls nicht (minimale Hardware).
S. R. schrieb: > Du hast einen legitimen Grund vergessen: > - es ist auf diesem Controller nur in Assembler überhaupt möglich Nein hab ich nicht. Ich habe gleich in meinem ersten Satz anerkannt dass es manchmal wirklich nur mit Assembler geht: > Es gibt einige wenige Fälle wo Assembler unschlagbar ist. Weiter schrieb ich vom "Gros der Projekte". Du hast hier eine eher sehr spezielle Anwendung mit anscheinend sehr harten Anforderungen bzgl. Timing und CPU-Auslastung. Dafür hast du meinen Respekt, aber es ist doch eher die Ausnahme. Wobei ich mir nicht sicher bin ob dein Szenario nicht auch unter "Hobby soll Spaß machen" oder "Kenne nichts anderes" läuft. Denn auf einem potenteren Controller wär deine Anwendung auch in einer Hochsprache möglich. Aber, wie gesagt, ist ja in Ordnung.
:
Bearbeitet durch User
Uhu U. schrieb: > Nett in ASM zu programmieren sind die MSP430. Naja, das Ding ist nett, aber halt kein echter RISC, eher eine geschrumpfte PDP11. Wer's mag . . . > Die Atmel 8-bitter finde > ich da nicht so prickelnd; Im Gegenteil, das sind Hammerteile, sowas wie 68000 im Mikrocontrollerformat! ROCK IT! Viele Register, RISC, fast alle Befehle nur einen Takt, relativ saubere, überschaubare Befehle. SUPI! > die Drecksarbeit darf der Compiler machen, > wenn es nicht sehr sehr gute Gründe für ASM gibt. Ja sicher, die 1990er sind vorbei. > Der Inline-Compiler > des GCC ist jedenfalls zum abgewöhnen. Du meinst den Inline-Assembler. Naja, er ist zwar sehr leistungsfähig, aber auch recht kryptisch. Ich verstehe bis heute nicht, warum man die diversen handoptimierten Bibliothken, z.B. diese FASLED damit programmiert? Als separate ASM-Datei ist das um WELTEN besser lesbar und deutlich einfacher! https://github.com/FastLED/FastLED
Falk B. schrieb: > Uhu U. schrieb: >> Nett in ASM zu programmieren sind die MSP430. > > Naja, das Ding ist nett, aber halt kein echter RISC, eher eine > geschrumpfte PDP11. Wer's mag . . . Wo doch gerade die RISCs wirklich nicht schön in ASM zu programmieren sind… RISC-Befehlssätze sind für Compiler gebaut. Für ASM-Programmierer sind die eine Strafe. Ja, es ist eine Teilmenge des PDP-11-Maschinenbefehlssatzes - wenns der volle wäre, dann wärs das ASM-Pardies. Das ist überhaupt kein RISC, sondern ein klassischer CISC - aber genau das macht ihn "nett" für ASM-Programmierer.
:
Bearbeitet durch User
Le X. schrieb: > Wobei ich mir nicht sicher bin ob dein Szenario nicht auch > unter "Hobby soll Spaß machen" oder "Kenne nichts anderes" läuft. Das ursprüngliche Projekt ist eher eine Machbarkeitsstudie, die du gern unter Hobby einsortieren kannst. Wie alles, was nicht professionell-beruflich stattfindet. Grundsätzlich ist mir ein AVR sympathischer als z.B. ein Cortex-M3: Gutmütig, genügsam und robust. Einfach mit Hardware zu verknoten und trotzdem recht leistungsfähig. > Denn auf einem potenteren Controller wär deine Anwendung auch in > einer Hochsprache möglich. Sicherlich, aber das ist kein sinnvolles Argument: Man kann immer einen potenteren Controller auf das Problem schmeißen, oder einen FPGA, wenn es nicht ausreicht. Für ein anderes Projekt habe ich den Core (zurück) nach C portiert, ebenfalls Machbarkeitsstudie und Prototyp. Der praktische Einsatz ist definitiv vorgesehen. Grundsätzlich ist mir C lieber als Assembler, egal auf welcher Architektur. In diesem Fall habe ich die ursprüngliche Implementation aber bei 80% abgebrochen, weil absehbar war, dass die Performance bei weitem nicht ausreichen wird. Uhu U. schrieb: > Das ist überhaupt kein RISC, sondern ein klassischer CISC - aber > genau das macht ihn "nett" für ASM-Programmierer. Ich weiß ja nicht. Die letzte Zeit habe ich mich tief mit i80 und i86 befasst und so wirklich angenehm sind die beide nicht. Sicher, man bekommt damit höhere Codedichte hin, aber wirklich Spaß... ich weiß ja nicht. So ein orthogonaler Befehlssatz ohne (oder mit reduzierten) Fallsticke ist angenehmer, sowohl AVR als auch ARMv7-M. Auch RISC-V sieht gut aus, aber den habe ich noch nicht praktisch programmiert.
Ich hab mich auch sehr lange gegen C gesträubt, bis ich mal ein Projekt übernehmen mußte, weil der Kollege gegangen war. Ich hab die nötigen Änderungen an einer Routine gemacht und das Programm funktionierte wie gewünscht, obwohl ich den Hauptteil des Codes noch nicht verstanden hatte. In Assembler wäre das ein Ding der Unmöglichkeit, da müßte man sich komplett reinknien. Ich war auch etwas stolz darauf. Am meisten hat mich aber geärgert, als ich andere Assembler-Programme auf C umgestellt hatte, daß sie schneller und kleiner waren, als meine selbst ausgedachten Libs. Besser lesbar waren sie obendrein. Es ist scho ne Menge an Arbeit, die einem der Compiler abnimmt und damit Fehler vermeidet. Nie mehr mit Push, Pop usw. rumärgern oder mit Datentypen, Offsetberechnungen und Calling-Conventionen. Jeder Assemblerprogrammierer kennt bestimmt folgenden Fehler zur Genüge:
1 | push r16 |
2 | push r17 |
3 | ; mache was |
4 | pop r16 |
5 | pop r17 |
Das muß ich nicht haben. Ich will mich auf die eigentliche Aufgabe konzentrieren können. Ich benutze auch sehr gerne float auf 8-Bittern, weil ich es einfach satt habe, daß meine PID-Regelungen rumspinnen, weil irgendwelche Zwischenrechnungen entweder zu ungenau sind oder überlaufen.
S. R. schrieb: > Ich weiß ja nicht. Die letzte Zeit habe ich mich tief mit i80 und i86 > befasst und so wirklich angenehm sind die beide nicht. Sicher, man > bekommt damit höhere Codedichte hin, aber wirklich Spaß... ich weiß ja > nicht. Bei den x86 zumindest im Real-Mode ist der Befehlssatz extrem asymmetrisch - das macht die Sache wenig erquicklich. In den neueren Speichermodellen ist Intel mehr und mehr von der Asymmetrie abgekommen, das macht die ASM-Programmierung deutlich einfacher. Die PDP-11 hat fast keine Asymmetrien - man kann fast alle Befehle mit beliebigen Registern benutzen. Das kommt der menschlichen Denkweise sehr entgegen. Der Befehlssatz des ehemaligen Konkurrenten des 8086, der Motorola 68000 ist auch sehr symmetrisch, aber er überlebte nicht. Grund: dem Compiler sind die schrägen Befehle des 80x86 schnuppe. Intel machte jede Menge Kompromisse und das störte keinen, aber die Dinger waren billiger zu produzieren.
Hier eine kleine Geschichte von mir wenn es Euch interessiert: Vor einiger Zeit überließ mir meine Firma einen Karton voller alter Steuerplatinen aus den späten 80er Jahren. An sich läßt sich als Hobbyist noch viel mit diesen Bords machen. Anzeige Bords, HW Quadratur Zähler, alles mögliche. Diese Sachen wurden damals von unseren Kunden als Anzeigen in Ölbohranlagen verwendet. Die HW Qualität dieser Bords ist erstklassig. Alle Dokus (CAD) einschließlich Sourcen und (DOS/CP/M) Assembler für NEC uPD78C10 wurden mir auch überlassen da diese Produkte schon seit Ende der 90er Jahre nicht mehr aktuell waren. Nun, was damit machen? Wie sollte das Upcycling aussehen? Ich schaute mir die ASM Sourcen an und machte gleich wieder zu. Die FW ist sehr kompliziert weil als RTOS implementiert. Dann, wieder auf einem MSDOS PC zu werkeln behagte mir auch nicht, oder innen in einer DOSBOX. Auch starb der damalige Entwickler vor zehn Jahren. Es gibt niemand mehr, der noch Bescheid weiß. Naja, vielleicht könnte man den uC modernisieren, dachte ich mir dann. Der 78C10 ist im PLCC68 Gehäuse. Als Ersatz kommen nur 5V Typen in Frage. Nach einigem Suchen stellte es sich heraus, daß ein ATMEGA2560 oder seine kleinere Brüder wie ATMEGA640/1280 praktisch ein direkter Ersatz für den NEC wäre. Da die Bords viele externe Memory mapped Peripherien haben, sollte es ein uC sein mit externen Bus Interface. Ein 32KB SRAM ist auch vorhanden und eine RS485 Schnittstelle. Massenhaft Parallel I/O und dekodierter SPI Bus für bis zu 4 SPI Schaltungen. Bis auf die internen Timer Funktionionen ist gute Kompatibilität da. Ich wählte als Ersatz für die 78C10 Timing Resources, die AVR T0 (OC0A) und T1 HW Pins(IC1A, OC1A/B). Das dürfte ausreichen. Sollte ich so einen Upgrade durchziehen, was soll er können? Hier sind die Rahmenbedingungen: Einsteckbar ICSP und Arduino BL Schnittstellenzugang UC sollte auch ohne extra Arbeit noch mit dem Arduino Ökusystem kompatibel bleiben Programmierbar mit modernen Werkzeugen. Ich entwickelte gestern nun eine vierlagige Einsteckplatine für den ATMEGA2560 im 100-Pin Gehäuse. Auf allen vier Seiten sind 17-pin Pin Headers. In der Bucht fand ich Sockel und Headers mit 1.27mm Abstand der Pins. Die Sockel lassen sich sehr leicht auf die PLCC SMD Pads einlöten. Entfernen des uC ist kein Problem. Ich werde in ein paar Tagen die Adapterplatine machen lassen. Hardware Kostenpunkt, AVR nicht eingeschlossen, ist ungefähr $10. Zum ICSP Zugang ist noch ein 5x2 2mm Wannenstecker vorhanden für den AVR-ISP MK2 oder kompatibel und ein Standard Arduino BL Interface. Damit hat man ausreichend Zugang zu modernen Werkzeugen. Das JTAG Interface ist auf der Hauptboard auch noch zugänglich. Die I2C Pins führte ich auch noch heraus, just in case. Um auf das Thema des Threads zurückzukommen: ASM möchte ich mir für dieses Projekt nicht antun. Da ich schon kompatible FW in C habe die ich anpassen könnte, ist auch die erste Programmierbarung zum Testen keine große Arbeit. Nur muß ich mir zusätzlich noch den Memory Mapped Zugang verschaffen um die externe Memory und HW ansprechen zu können. Schon dekodiert von FE00h ab und extern zugänglich zusätzlich zu den zwei 82C55 sind noch sechs Register Blocks mit 8 Adressen jeweils. Dieser Bereich von FE00-FFFFh ist dem RAM natürlich nicht zugänglich. Das 32KB SRAM fängt bei 8000h an. Die vierlagige LP hat übrigens die Größe einer halben Europakarte. Alles in SMD. Ich werde später berichten wie das Ganze ausgegangen ist. Lächelt bitte nicht zu sehr. Mir macht solche HW wirklich noch Spaß. Nützlich ist das Zeugs auf alle Fälle und es wäre schade gewesen so viel zuverläßige Steuer-HW entsorgen zu müssen. Speziell weil noch alle Dokus komplett in lesbarem CAD Format vorhanden sind. Ein schönes Spielzeug ist es auf alle Fälle. Z.B eine mögliche baldige Anwendung wäre so eine Bord mit einer der schon vorhandenen vierzeiligen LED Anzeige Platine als digitale iGauge Anzeige der XYZ Achsen meiner Fräsmaschine einzusetzen. Ich müßte nur etwas SW dafür erstellen.
Uhu U. schrieb: > Falk B. schrieb: >> Uhu U. schrieb: >>> Nett in ASM zu programmieren sind die MSP430. >> >> Naja, das Ding ist nett, aber halt kein echter RISC, eher eine >> geschrumpfte PDP11. Wer's mag . . . > > Wo doch gerade die RISCs wirklich nicht schön in ASM zu programmieren > sind… RISC-Befehlssätze sind für Compiler gebaut. Für ASM-Programmierer > sind die eine Strafe. So ein Quark. Der AVR geht runter wie Öl. > Ja, es ist eine Teilmenge des PDP-11-Maschinenbefehlssatzes - wenns der > volle wäre, dann wärs das ASM-Pardies. Es wäre Kokolores^3. Die PDP-11 mag ja ihren Platz in der IT-Geschichte haben, der Weisheit letzter Schluss war sie sicher nicht. > Das ist überhaupt kein RISC, > sondern ein klassischer CISC - aber genau das macht ihn "nett" für > ASM-Programmierer. Ja, aufgeblasener Befehlssatzmit Redundanz ohne Ende. Nein Danke.
Falk B. schrieb: > Ja, aufgeblasener Befehlssatzmit Redundanz ohne Ende. Nein Danke. Darf man fragen, wieviel 1000 Stunden ASM-Erfahrung du auf dem Buckel hast?
Manchmal muß man auch über den Tellerrand springen können und wird festgstellen das einiges auch zügiger geht. Ich habe gerade einen Servotester mit MicroPython erstellt - das Board+LCD+touch hatte ich schon einen Weile rumliegen. Die Grundfunktionalität hat keine Minute gebraucht. Ein ATMega mit C wäre noch am compilen und "brennen". Kommt aber halt immer darauf an was man machen möchte. Ich hab noch lange mit Transistoren und Logikbausteinen Dinge gemacht - bis ich die Mikrokontroller entdeckt habe. Das war ein großer Sprung, der mir viel mehr Möglichkeiten eröffnete. Der nächste Sprung war dann die Hochsprachen. Wie sagt man so schön: es schadet nicht jedes Jahr eine neue Sprache zu erkunden. Das MicroPythonuniversion ist schon toll, wobei mir die Spache mit ihren Einrückungen nur bedingt gefällt. So alle Servos durchgetestet, nun kann ich noch länger im Forum abhängen :-)
Falk B. schrieb: > Uhu U. schrieb: >> Falk B. schrieb: >>> Uhu U. schrieb: >>>> Nett in ASM zu programmieren sind die MSP430. >>> >>> Naja, das Ding ist nett, aber halt kein echter RISC, eher eine >>> geschrumpfte PDP11. Wer's mag . . . >> >> Wo doch gerade die RISCs wirklich nicht schön in ASM zu programmieren >> sind… RISC-Befehlssätze sind für Compiler gebaut. Für ASM-Programmierer >> sind die eine Strafe. > > So ein Quark. Der AVR geht runter wie Öl. > >> Ja, es ist eine Teilmenge des PDP-11-Maschinenbefehlssatzes - wenns der >> volle wäre, dann wärs das ASM-Pardies. > > Es wäre Kokolores^3. Die PDP-11 mag ja ihren Platz in der IT-Geschichte > haben, der Weisheit letzter Schluss war sie sicher nicht. > >> Das ist überhaupt kein RISC, >> sondern ein klassischer CISC - aber genau das macht ihn "nett" für >> ASM-Programmierer. > > Ja, aufgeblasener Befehlssatzmit Redundanz ohne Ende. Nein Danke. Falk es muß ja nicht Deinem Geschmack entsprechen, aber Recht hat her eher der Uhu. So kurze Programme für einen Bootloader z.B. wie auf der PDP11 Kriegst Du auf dem AVR nicht hin. Der Code ist hocheffizient, verständlich wenn man sich vor Augen hält, dass Memory damals noch Core war. Der orthogonale Befehlssatz ist ein Feature, man muß es aber auch zu nutzen verstehen. Gruß, Holm
Daß C-Programme oftmals schneller sind und weniger Ressourcen verbrauchen, liegt vor allem daran, daß die Compiler Optimierungstechniken verwenden können, die in Assembler nicht oder nur sehr umständlich anwendbar sind. Z.B. benutzt der Keil C51 die Overlay-Technik. Dazu stellt er einen kompletten Calling-Tree auf und weiß somit, welche Funktionen nie gleichzeitig ausgeführt werden. Für diese kann er dann die gleiche Speicheradresse als lokale Variable vergeben, was eine Menge Push/Pop und SRAM einspart. Zusätzlich merkt er sich, welche Funktion welche Register benutzt. Wird z.B. eine Funktion aufgerufen, die nur R6, R7 verändert, kann der Aufrufer sich Variablen in R4, R5 erhalten, muß sie also nicht sichern. Diese Registeroptimierung erfolgt in weiteren Compilerdurchläufen. Registerzugriffe sind schneller und kürzer als SRAM-Zugriffe. Soll ein Programm schnell und sparsam sein, sollte man daher besser auf C umsteigen.
:
Bearbeitet durch User
Uhu U. schrieb: > In den neueren Speichermodellen ist Intel mehr und mehr von der > Asymmetrie abgekommen, Unfreiwillig allerdings, denn die 64-Bit x86-Architektur, die den bedeutendsten Schritt in diese Richtung darstellt, stammt von AMD. ;-) > Der Befehlssatz des ehemaligen Konkurrenten des 8086, der Motorola 68000 > ist auch sehr symmetrisch, aber er überlebte nicht. Grund: dem Compiler > sind die schrägen Befehle des 80x86 schnuppe. Intel machte jede Menge > Kompromisse und das störte keinen, aber die Dinger waren billiger zu > produzieren. Architekturen mit mehreren unabhängigen Operanden im Speicher sind höllisch schwer zu implementieren, sobald man schneller arbeiten will, als Befehle und Operanden Stück für Stück im Gänsemarsch in etlichen Takten abzuarbeiten. Die PDP11 erlebte das nicht mehr, die VAX allerdings trieb DEC zur Verzweiflung und fast in den Konkurs. 68K hatte das gleiche Problem, ebenso NS32K. x86 Befehle in einem Takt zu dekodieren, erst recht mehrere Befehle pro Takt, ist zwar kein Spass, aber weit einfacher als 68020+, NS32K, VAX. Abhängigkeiten bei Registeroperanden zu erkennen geht deutlich einfacher als bei Speicheroperanden.
:
Bearbeitet durch User
... schrieb: > Lochband ist ja neumodischer Schnickschnack. Anderer Bereich. Die grossen teuren Computer in Firmen hatten Lochkarten. Die kleinen billigen in Labors und bei den Bastlern verwendeten einen Fernschreiber als Terminal, und der konnte Lochstreifen lesen und schreiben. Ausserdem sind Lochstreifen älter. Die ersten Zuses verwendeten sie als Programmspeicher. Nicht aus Papier allerdings, alte Wochenschau-Filmrollen waren billiger.
Falk B. schrieb: > Uhu U. schrieb: >> Nett in ASM zu programmieren sind die MSP430. > > Naja, das Ding ist nett, aber halt kein echter RISC, > [...] ... weil ein "echter" RISC eine Load/Store-Architektur haben muss? Nicht wirklich, oder?!
Peter D. schrieb: > Daß C-Programme oftmals schneller sind und weniger Ressourcen > verbrauchen, liegt vor allem daran, daß die Compiler > Optimierungstechniken verwenden können, die in Assembler nicht oder nur > sehr umständlich anwendbar sind. Ein anderes Beispiel ist die Umsetzung von Switch-Statements. Ein Compiler kann die Verteilung der Werte untersuchen und basierend darauf, der Optimierungsvorgabe Platz/Zeit und der Eigenschaften der verwendeten Prozessorgeneration den effizientesten Weg nutzen. Ein Asm-Programmierer schätzt das aus dem Bauch, wird bei neu hinzukommenden Werten das Verfahren nicht völlig infrage stellen und fliegt beim 100% kompatiblen Nachfolgeprozessor möglicherweise voll auf die Nase, was das Tempo angeht. Kaum ein Asm-Programmierer wird so ein Statement als Entscheidungsbaum implementieren. Das ist bei nicht trivialer Anzahl einfach nur Quälerei, die zudem mit jeder Änderung komplett vor vorne anfängt. Kaum ein Asm-Programmierer gründet die Produktionsversion seines Code auf einer statistischen Untersuchung des Verhaltens des Codes der vorigen Testversion anhand realistischer Testdaten (profiling). Uhu U. schrieb: > der Compiler kocht auch nur mit Wasser und wenn man die Tricks, > die dort angewandt werden, mal verstandewn hat, dann kann man ASM > wirklich und die Verbindung zwischen Maschinencode und C-Quelltext ist > nicht mehr all zu schwierig. Bei den hier beschriebenen Umsetzungen von C Quelltext ist auch für erfahrene Leute nicht unbedingt transparent, was hinten rauskommt.
:
Bearbeitet durch User
Egon D. schrieb: >>> Nett in ASM zu programmieren sind die MSP430. >> >> Naja, das Ding ist nett, aber halt kein echter RISC, >> [...] > > ... weil ein "echter" RISC eine Load/Store-Architektur > haben muss? > > Nicht wirklich, oder?! Es ist nicht leicht, narrensichere Kriterien für RISC vs CISC anzugeben. Die Anzahl Befehle ist es jedenfalls nicht. IBM übersetzte das "C" deshalb in "Cycles" statt "Complexity", denn der Power Befehlssatz war schon vorneweg recht gross, aber von vergleichsweise überschaubarer Laufzeit der Befehle (mit Ausnahmen). Motorola sprang mit dem 68K-Derivat Coldfire auf den RISC Zug auf, in dem sie das "variable length RISC" nannten, obwohl da wirklich nichts dran war, was man so unter RISC verstand. Das war reine Verarsche, ebenso wie Intels Coppermine aus Aluminium, als Antwort auf AMDs Kupfer-Technik. Aber Load/Store-Design könnte man schon als Kriterium nutzen. Ebenso käme die Umsetzung der Befehle in eine einfache Ausführungsweise in Frage. MSP430 ist zwar überschaubar klein, aber aufgrund der potentiell recht vielen Schritte in den Befehlen eher laufzeitkomplex. Architekturen können bisweilen die Zeit wiederspiegeln, aus der sie stammen, und später Probleme bekommen, die einfach nicht im usprünglichen Design vorgesehen waren. 8051 ist für maximal 128 Bytes direkt adressierbares RAM konzipiert, war nie für die Ewigkeit gedacht. Braucht man mehr, wirds spätestes jenseits von 256 Bytes auf ASM-Ebene ziemlich unelegant. Der Compiler kriegts hin, aber schön geht anders. Viele CISCs stammen aus einer Zeit, in der die Cores klein sein mussten, und der Code in recht begrenzte Speicherkapazität passen musste. Was auf Mikrocontroller jener Klasse ebenso zutraf, die durch MSP430 abgedeckt werden sollte. Dessen Erweiterung auf jenseits von 64kB Adressraum wirkt dann aber wie ein recht krampfiger Versuch, die inhärenten Grenzen zu überschreiten. Ebenso stammen CISCs stets aus einem Kontext, in dem Befehle in etlichen Taktzyklen abgearbeitet wurden. Bei Mikrocontrollern im Anwendungsbereich von MSP430 oder Renesas M16C stört das nicht. Beim Prozessor im PC oder Handy hingegen schon. x86 hatte nur überlebt, weil im Markt so viel Geld steckte, dass man dessen inhärente Probleme mit vielen eigentlich überflüssigen Transistoren erschlagen konnte, ohne dabei draufzuzahlen. Heute ist das wieder fast egal, aber für einige Zeit dazwischen war das durchaus ein Thema.
:
Bearbeitet durch User
Peter D. schrieb: > Ich hab mich auch sehr lange gegen C gesträubt, Peter, danke für deinen Beitrag. Hatte schon ernsthaft überlegt im Winter ASM anzufangen. Wenn du das schreibst, dann hat das für mich Gewicht.
F. F. schrieb: > Stefan S. schrieb: >> Ich weiss es nicht. Zugeben muss man aber, dass C-oder >> Assembler-Programmieren ein wirkliches Verständnis von den Vorgängen im >> Computer haben -- viele Python- oder Javascript-Programmierer aber >> nicht. > > Obwohl ich hier wieder eine Lanze brechen muss. > Wenn das Programm genau das tut, wofür es sein soll und der Controller > funktioniert so, dann kann es vielen völlig egal sein wie die einzelnen > Register da gerade arbeiten. Stimmt die Register sind egal. Was nichz egal ist sind Speicheranforderungen und -freigaben. Wenn der Controller 'unendlich' lange arbeiten soll, dann kann Speicherfragmentierung nach einer gewissen Zeit, 1 Tag, oder auch 1 Woche zu Problemen führen. Wenn das egal ist, dann kann man natürlich Sprachen mit automatischer Speicherverwaltung verwenden.
Ich kann nur empfehlen, den Schritt von Assembler nach C zu wagen, es lohnt sich. Und wenn man schon Assemblererfahrung hat, kann man auch schnell mal ins Listing schauen, welchen Code der Compiler für welche Ausdrücke erzeugt. Insbesondere bei Verwendung von Pointern und Structs kann man erkennen, ob der Compiler auch das macht, was man gemeint hat.
Dumdi D. schrieb: > Wenn der Controller 'unendlich' > lange arbeiten soll, dann kann Speicherfragmentierung nach einer > gewissen Zeit, 1 Tag, oder auch 1 Woche zu Problemen führen. Speicherfragmentierung ist in typischen Embedded-Anwendungen kein Thema weil in der Regel keine dynamische Speicherallokierung stattfindet. Im Gegensatz zu interaktiven GUI-Programmen auf dem PC steht beim Gros der Embedded-Anwendung schon vorher genau fest, wieviel Speicher benötigt wird.
Le X. schrieb: > Speicherfragmentierung ist in typischen Embedded-Anwendungen kein Thema > weil in der Regel keine dynamische Speicherallokierung stattfindet. Ja. Ich hatte den Beitrag auf den ich geantwortet habe so verstanden, dass der Beitrag meint konntè man auch in python oder javascript auf dem Controller programmieren.
A. K. schrieb: > Egon D. schrieb: >>>> Nett in ASM zu programmieren sind die MSP430. >>> >>> Naja, das Ding ist nett, aber halt kein echter RISC, >>> [...] >> >> ... weil ein "echter" RISC eine Load/Store-Architektur >> haben muss? >> >> Nicht wirklich, oder?! > > Es ist nicht leicht, narrensichere Kriterien für RISC vs > CISC anzugeben. Das stimmt wohl. Die apodiktische Behauptung der deutschsprachigen Wikipedie, RISC-Architekturen seien GRUNDLEGEND durch ihren Aufbau als Load/Store-Architekturen charakterisiert, halte ich dennoch für abstrus. > Die Anzahl Befehle ist es jedenfalls nicht. IBM übersetzte > das "C" deshalb in "Cycles" statt "Complexity", denn der > Power Befehlssatz war schon vorneweg recht gross, aber > von vergleichsweise überschaubarer Laufzeit der Befehle > (mit Ausnahmen). Naja, der Kernpunkt war meiner Meinung nach die Abkehr vom Modell "Akkumulator plus Spezialregister" und die Hinwendung zu 1. relativ großen Registersätzen aus 2. gleichberechtigten Universalregistern. Das ist nämlich die logische Voraussetzung für 3. einen orthogonalen Befehlssatz. Und nebenbei: Der MSP430 erfüllt alle drei Kriterien. > Aber Load/Store-Design könnte man schon als Kriterium nutzen. Naja, es gab schon "damals" (späte Achziger/frühe Neunziger) Stimmen, die der Meinung waren, die durch eine reine Load/Store-Architektur erzeugte Verschwendung der Speicher- bandbreite sei auf Dauer nicht zu ignorieren. > Ebenso käme die Umsetzung der Befehle in eine einfache > Ausführungsweise in Frage. Ja. > MSP430 ist zwar überschaubar klein, aber aufgrund der > potentiell recht vielen Schritte in den Befehlen eher > laufzeitkomplex. Nicht wirklich. Eine reine Load/Store-Architektur müsste irgend so etwas ausführen:
1 | |
2 | LD R7, [0x1234] |
3 | INC R7 |
4 | LD [0x1234], R7 |
Der MSP430 macht dagegen:
1 | |
2 | INC [0x1234] |
Die Laufzeitkomplexität kommt nicht dadurch zu Stande, dass die interne VERARBEITUNG in vielen Schritten abliefe, sondern dadurch, dass eine "Befehlsfusion" mit vorhergehenden und nachfolgenden Transfer-Operationen möglich ist. Das verringert sowohl die Programmlänge als auch die Laufzeit, wird aber absurderweise als NACHTEIL des MSP430 angesehen, "weil das ja gar nicht wirklich RISC ist". Tatsächlich sagt die Dokumentation, dass man die notwendige Anzahl Taktzyklen für jeden Befehl recht einfach aus der Anzahl der Speichertransfers ausrechnen kann. Die Verarbeitung selbst kostet häufig keinen eigenen Taktzyklus, die passiert nebenbei. > Viele CISCs stammen aus einer Zeit, in der die Cores > klein sein mussten, und der Code in recht begrenzte > Speicherkapazität passen musste. Was auf Mikrocontroller > jener Klasse ebenso zutraf, die durch MSP430 abgedeckt > werden sollte. Naja, "...zutrifft...", würde ich sagen. Präsens. Wir reden ja von Mikrocontrollern und nicht allgemein von Mikroprozessoren. > Dessen Erweiterung auf jenseits von 64kB Adressraum wirkt > dann aber wie ein recht krampfiger Versuch, die inhärenten > Grenzen zu überschreiten. Auf jeden Fall. "Real mode" forever!
Egon D. schrieb: > Naja, der Kernpunkt war meiner Meinung nach die Abkehr vom > Modell "Akkumulator plus Spezialregister" Nope. RISC entstand als Reaktion auf leistungsfähige Architekturen mit Registern und hochkomplexen Register-Speicher und Speicher-Speicher Befehlen, wie IBMs Mainframes, DEC VAX, 68000=>68020 und dergleichen. Die viel Aufwand in eine Komplexität steckten, die nachweislich nur zu einem Bruchteil genutzt wurde. Akku-Architekturen spielten bei der Motivation für die Entwicklung von RISC keinerlei Rolle, in keiner der beiden Entwicklungslinien (Berkeley, IBM). Im relevanten Marktsegment gab es praktisch keine mehr und sowas wie 6502 war bei dieser Betrachtung bedeutungslos. > Naja, es gab schon "damals" (späte Achziger/frühe Neunziger) > Stimmen, die der Meinung waren, die durch eine reine > Load/Store-Architektur erzeugte Verschwendung der Speicher- > bandbreite sei auf Dauer nicht zu ignorieren. Die Code-Bandbreite wuchs etwas, das hatte man auf der Rechnung. Aufkommende Caches erledigten das weitgehend. > Wir reden ja von Mikrocontrollern und nicht allgemein von > Mikroprozessoren. Die RISC/CISC Debatte entstammt der Mikroprozessor-Entwicklung und ist erst viel später ins Mikrocontroller-Segment reingewachsen. Die dabei relevante Thematik der Code-Grösse wurde adressiert, als 32-Bit RISCs in µC Markt auftauchten, durch 16-Bit Befehlscodierungen u.A. bei ARM und MIPS. Dazu gehört auch, dass zu dem Zeitpunkt, zu dem Geräte wie Handys aufkamen, 16-Bitter schnell zu klein waren und es bei 32-Bittern keine grosse Auwahl an sparsamen kleinen Cores gab, die zur Integration in Custom-Chips verfügbar waren. ARM Cores boten dies und waren für jeden unter gleichen Konditionen verfügbar. Ob RISC oder CISC wäre den Firmen egal gewesen, wenn die übrigen Parameter gestimmt hätten.
:
Bearbeitet durch User
Egon D. schrieb: > Der MSP430 macht dagegen: > INC [0x1234] Es ist nicht wichtig, was man kann, sondern was man wirklich benötigt. Und da kann man teilweise die gleichen Argumente nutzen, die die Anfangszeit der RISC/CISC-Frage prägten. Als die Analyse realen Codes ergab, dass Befehle die INC mem zwar Platz sparen, aber bei ausreichend vielen Registern relativ selten genutzt werden. Wichtig ist INC mem daher nur bei Architekturen mit sehr wenig Registern. Also Akku, oder sowas wie die Renesas M16C mit nur 4 Registern.
A. K. schrieb: > Egon D. schrieb: >> Naja, der Kernpunkt war meiner Meinung nach die Abkehr >> vom Modell "Akkumulator plus Spezialregister" > > Nope. RISC entstand als Reaktion auf leistungsfähige > Architekturen mit Registern und hochkomplexen > Register-Speicher und Speicher-Speicher Befehlen, wie > IBMs Mainframes, DEC VAX, 68000=>68020 und dergleichen. > [...] Interessant. Das wusste ich nicht. > Die viel Aufwand in eine Komplexität steckten, die > nachweislich nur zu einem Bruchteil genutzt wurde. Naja, hier sind wir aber wieder beim Punkt "orthogonaler Befehlssatz". Ob ein spezieller Befehl in der Praxis tatsächlich genutzt wird, hängt ja von drei Dingen ab: 1. Der durch ihn erfasste Spezialfall muss oft genug auftreten. 2. Der Compiler muss den Fall mit vernünftigem Aufwand erkennen können. 3. Der Spezialbefehl muss schneller sein als eine wirkungsgleiche Folge einfacherer Befehle -- und zwar nicht nur isoliert betrachtet, sondern im tatsächlichen Programmablauf. Die reine Tatsache, dass ein bestimmter Befehl auch durch eine Sequenz einfacherer Befehle ersetzt werden könnte, ist kein vernünftiges Kriterium -- in diesem Falle dürften RISC-Prozessoren nämlich weder Multiplizieren können noch über bedingte Verarbeitungsbefehle verfügen. Das ist aber offensichtlich unsinnig. > Die Code-Bandbreite wuchs etwas, das hatte man auf der > Rechnung. Aufkommende Caches erledigten das weitgehend. Naja, Caches bewirken aber noch wesentlich mehr. Sie haben z.B. auch zur Folge, dass die Größe des Registersatzes weniger wichtig wird. >> Wir reden ja von Mikrocontrollern und nicht allgemein >> von Mikroprozessoren. > > Die RISC/CISC Debatte entstammt der Mikroprozessor- > Entwicklung und ist erst viel später ins Mikrocontroller- > Segment reingewachsen. Richtig. Genau deswegen ist eine rein formalistische Anwendung dieser Begriffe auf Mikrocontroller ein Anachronismus. Der MSP430 hat, wie viele andere Mikrocontroller auch, keinen Cache. Da der Registersatz zwar eine vernünftige Größe hat, aber auch nicht gerade riesig ist, hat das Thema "Speicherbandbreite" einen anderen Stellenwert als bei Mikroprozessoren mit Cache. Insofern würde ich sagen: Der MSP430 ist soviel "RISC", wie ohne Cache sinnvoll möglich ist.
A. K. schrieb: > Egon D. schrieb: >> Der MSP430 macht dagegen: >> INC [0x1234] > > Es ist nicht wichtig, was man kann, sondern was man > wirklich benötigt. Und da kann man teilweise die > gleichen Argumente nutzen, die die Anfangszeit der > RISC/CISC-Frage prägten. Um Dir in Deinem Stil zu antworten: Die Frage ist nicht, ob man die Argumente nutzen kann, sondern ob sie zutreffen. > Als die Analyse realen Codes ergab, dass Befehle die > INC mem zwar Platz sparen, aber bei ausreichend vielen > Registern relativ selten genutzt werden. Hmm. Zu "relativ selten": Wenn von einem hypothetischen (voll belegten) 16bit-Befehlssatz (mit 65536 Befehlen) alle Befehle gleich oft benutzt werden, dann ist die Wahrscheinlichkeit, dass ein bestimmter Befehl eingesetzt wird, 0.0015%. Befehle, die lediglich mit 0.0015%iger Wahrscheinlichkeit verwendet werden, sollte man doch aus dem Befehlssatz streichen, findest Du nicht? Was ich sagen will: Wichtig ist nicht die Wahrscheinlichkeit, sondern das mit der Wahrscheinlichkeit gewichtete Verhältnis von Aufwand und Nutzen. > Wichtig ist INC mem daher nur bei Architekturen mit sehr > wenig Registern. Also Akku, oder sowas wie die Renesas M16C > mit nur 4 Registern. Das mag sein -- aber daraus kann man im Umkehrschluss nicht folgern, dass "inc [memadr]" auf Architekturen mit mehr Registern (MSP430) unnütz oder gar schädlich wäre. Die Kernfrage ist nämlich: Was gewönne man, wenn der MSP430 "inc [memadr]" NICHT beherrschte? Was wäre besser, wenn er eine reine Load/Store-Architektur hätte? Ich denke, dass die Antwort schlicht "Nichts!" lautet. Die Verarbeitung ist beim MSP430 sowieso fest mit den Speicherzugriffen synchronisiert ist (weil es weder Pipelines noch Caches gibt), daher lässt sich kein GEWINN in der Verarbeitungsgeschwindigkeit erreichen, wenn man die "Fusionsbefehle" weglässt -- man handelt sich nur einen NACHTEIL in der Speicherbandbreite ein. Architekturen mit Cache sind da eine andere Baustelle; dort wurde die enorm gesteigerte Verarbeitungsleistung ja nur dadurch überhaupt möglich, weil die feste synchrone Verzahnung von Verarbeitung und externen Speicherzugriffen AUFGEHOBEN wurde. Das trifft aber auf den MSP430 nicht zu.
A. K. schrieb: > Es ist nicht wichtig, was man kann, sondern was man wirklich > benötigt. Der ASM-Programmierer mag i.a. wohl die msp430-Variante lieber, als die RISC-Befehlsinflation. ASM-Programmierer sind auf der roten Liste und RISC-Architekturen sind für die Programmierung per Compiler optimiert.
Egon D. schrieb: > Insofern würde ich sagen: Der MSP430 ist soviel "RISC", > wie ohne Cache sinnvoll möglich ist. Als die PDP-11 aufkam, war von RISC noch nicht die Rede und der MSP430 ist ein Subset des PDP-11-Befehlssatzes und deswegen auch kein RISC.
Uhu U. schrieb: > Egon D. schrieb: >> Insofern würde ich sagen: Der MSP430 ist soviel "RISC", >> wie ohne Cache sinnvoll möglich ist. > > Als die PDP-11 aufkam, war von RISC noch nicht die Rede > und der MSP430 ist ein Subset des PDP-11-Befehlssatzes > und deswegen auch kein RISC. Warum beteiligst Du Dich, wenn Du auf den Inhalt meiner Argumente sowieso nicht eingehen willst?
Egon D. schrieb: > Warum beteiligst Du Dich, wenn Du auf den Inhalt meiner > Argumente sowieso nicht eingehen willst? Weil sich die Frage ob RISC oder nicht bei der PDP-11 und Derivaten nicht stellt. Dieser Befehlssatz ist für ASM-Programmierung konstruiert und davon handelt der Thread hier…
Uhu U. schrieb: > Egon D. schrieb: >> Warum beteiligst Du Dich, wenn Du auf den Inhalt meiner >> Argumente sowieso nicht eingehen willst? > > Weil sich die Frage ob RISC oder nicht bei der PDP-11 > und Derivaten nicht stellt. Dieser Befehlssatz ist für > ASM-Programmierung konstruiert und davon handelt der > Thread hier… Okay. Du willst also tatsächlich nicht vernünftig mit mir reden, sondern weiterhin arrogant herumpampen. Ich weiss zwar nicht genau, was ich Dir getan habe, aber ich respektiere das. Viel Spaß weiterhin.
Egon D. schrieb: > Du willst also tatsächlich nicht vernünftig mit mir reden, > sondern weiterhin arrogant herumpampen. Was redest du für einen kindischen Quatsch…
Egon D. schrieb: >> Nope. RISC entstand als Reaktion auf leistungsfähige >> Architekturen mit Registern und hochkomplexen >> Register-Speicher und Speicher-Speicher Befehlen, wie >> IBMs Mainframes, DEC VAX, 68000=>68020 und dergleichen. > > Interessant. Das wusste ich nicht. Findest du es passend, bei erklärter Ahnungslosigkeit über die historischen Grundlagen der RISC Philosophie folgendes Urteil abzugeben? Egon D. schrieb: > Die apodiktische Behauptung der deutschsprachigen Wikipedie, > RISC-Architekturen seien GRUNDLEGEND durch ihren Aufbau als > Load/Store-Architekturen charakterisiert, halte ich dennoch > für abstrus. Da hat Uhu recht. Darüber zu diskutieren bringt nichts. Du wirst deinen persönlichen RISC Begriff verteidigen, der wenig mit dem zu tun hat, was der Rest der Welt darunter versteht.
:
Bearbeitet durch User
Egon D. schrieb: > Der MSP430 macht dagegen: > INC [0x1234] > Die Laufzeitkomplexität kommt nicht dadurch zu Stande, dass > die interne VERARBEITUNG in vielen Schritten abliefe, sondern > dadurch, dass eine "Befehlsfusion" mit vorhergehenden und > nachfolgenden Transfer-Operationen möglich ist. Warum sollte das in aktuellen CPUs nicht auch möglich sein? Der Witz ist ja, dass ich das im einen Fall hart in den Befehlssatz codiere und damit dem Decoder zusätzliche Arbeit aufzwinge (weil ich ja komplexe Adressierungsmodi, variable Befehlslängen und viele Befehle habe), während ich das im anderen Fall komplett der Implementierung überlasse. Viele häufig benutzte Befehlskombinationen (z.B. die Kombination "LUI R1, imm12; ADDI R1, R0, imm20" bei RISC-V) lassen sich wunderbar kombinieren. Wenn man komprimierte Befehlssätze unterstellt (z.B. ARM Thumb2 oder RISC-V "C"), dann reicht für viele Fälle bereits ein 32-bittiger Speicherbus aus. Einen variablen Befehlssatz in einem Takt zuverlässig zu decodieren erfordert ziemlichen Aufwand, wenn man nicht einfach die gesamte FSM ausrollen will. Mehrere Befehle aus einem solchen Befehlssatz gleichzeitig decodieren zu wollen wird schwierig, weil man FSMs nicht parallelisieren kann...
S. R. schrieb: > Mehrere Befehle aus einem solchen Befehlssatz > gleichzeitig decodieren zu wollen wird schwierig, weil man FSMs nicht > parallelisieren kann... Ein schneller Befehlsdekoder ist hauptsächlich komplexe Kombinatorik. Parallele Dekodierung hoch variabler Befehle kann beispielsweise so aussehen, dass für jede mögliche Position eines Befehls ein mehr oder weniger kompletter kombinatorischer Dekoder existiert, also beispielsweise 16 Stück in einer Dekoder-Zeile, und anschliessend anhand der Erkenntnis über die Länge der Befehle "links" davon die passenden Ergebnisse per Muxer ausgewählt werden. Das klingt nicht nur nach Aufwand, das ist es auch. Ein Aufwand, der sich in unnötiger Chipfläche und unnötigem Stromverbrauch durch diese hochredundante Logik niederschlägt. Bei fester Befehlslänge entfällt das völlig. Fläche war früher ein Thema, heute nicht mehr, beim Stromverbrauch ist es umgekehrt. Man kann das vereinfachen, indem man nur an der ersten Position komplexe Befehle zulässt, dahinter nurmehr einfache Befehle dekodiert. So hat Intel das ab dem Pentium Pro gehalten, im 4-1-1 Schema mit bis zu 4 Mikroops für den ersten Befehl und je 1 für die beiden weiteren. Andere Vereinfachungen speichern Längeninformation zu den Befehlen im Cache, sei es separat im L1, sei es in den bei Code unnötigen ECC-Bits vom L2.
:
Bearbeitet durch User
Ein klassisches Beispiel dafür, wie man sich sehr schmerzhaft selbst auf die Füsse treten kann, war die 68000 Familie. Bei einer 68000 konnte man anhand des ersten 16-Bit Befehlswortes die Länge ermitteln. Das war einfacher als beim x86 mit seinen Präfixen. Als Motorola allerdings mit der 68020 den Pfad in Richtung VAX einschlug, war mit dem ersten Wort schlimmstenfalls nur klar, wieviele Speicheroperanden folgen werden (bis zu 2), deren Länge nicht im Befehlswort, sondern im jeweils ersten Operandenwort codiert war. Wollte man das in einem Takt dekodieren, hatte man schon innerhalb eines einzigen Befehls den vorhin beschriebenen redundanten Dekoder-Zauber. Die VAX war der unübertroffene Meister der verkehrten Richtung, die ultimative CISC Architektur: Der 1-2 Bytes lange Opcode gab nur preis, wieviele variabel codierte Operanden folgen werden, also ob 1,2,3,4... Jeder bestand aus einem Codebyte, evtl gefolgt von Werten oder Offsets. Eine eigentlich geniale Idee, aber nur, solange man Befehl für Befehl und Operand für Operand Takt um Takt im Gänsemarsch dekodiert. Es war wohl einfacher, 3 x86 Befehle pro Takt zu dekodieren, als einen einzelnen VAX-Befehl, wollte man alle Codierungen erfassen. Ausserdem stellten findige Programmierer fest, dass eine Folge mehrerer einfacher Befehle nicht selten schneller war, als der exakt dafür vorgesehene komplexe Befehl. Die VAX war daher der ultimative Kickstart von RISC, weil fast unmöglich zu beschleunigen. DEC ging beim Versuch fast pleite, wechselte danach auf eine eigene RISC Architektur: Alpha. Hatten Leute eine VAX gelegentlich in Assembler programmiert (recht einfach), war Alpha nur für Compiler gedacht.
:
Bearbeitet durch User
Egon D. schrieb: > Das mag sein -- aber daraus kann man im Umkehrschluss nicht > folgern, dass "inc [memadr]" auf Architekturen mit mehr > Registern (MSP430) unnütz oder gar schädlich wäre. Es ist schädlich, wenn man über die simple Laufzeitstruktur eines MSP430 hinaus geht. INC mem besteht auf mehreren Phasen, die voneinander abhängig sind: temp = load(addr) temp = temp + 1 store(addr) = temp Schreibt man 2 solche Befehle hintereinander temp1 = load(addr1) temp1 = temp1 + 1 store(addr1) = temp1 temp2 = load(addr2) temp2 = temp2 + 1 store(addr2) = temp2 ohne bereits zu out-of-order Implementierung zu wechseln, dann dauert das entsprechend lang. Dröselt man das hingegen in ebendiese Einzelteile auf, dann kann man das verzahnen temp1 = load(addr1) temp2 = load(addr2) temp1 = temp1 + 1 temp2 = temp2 + 1 store(addr1) = temp1 store(addr2) = temp2 und kann damit erheblich Zeit sparen, wenn der Ladevorgang - wie üblich - länger als einen Takt dauert, aber pro Takt ein Ergebnis auswirft (pipelined load). Dann überlappt sich das nämlich erheblich. Auch sowas macht mit einem Compiler deutlich mehr Spass als in Assembler. Zumal sich die Regeln effizienter Verzahnung von einer Implementierung des Prozessorkerns zur nächsten ändern können. Der Asm-Programmierer flucht dann, der Compiler-Nutzer übersetzt einfach neu, mit neuem Optimierungsziel. Und wer meint, das hätte mit Mikrocontrollern nichts zu tun: Der superskalare Cortex M7 (z.B. in manchen STM32) profitiert von einer Verzahnung unabhängiger Befehle.
:
Bearbeitet durch User
A. K. schrieb: > Egon D. schrieb: >>> Nope. RISC entstand als Reaktion auf leistungsfähige >>> Architekturen mit Registern und hochkomplexen >>> Register-Speicher und Speicher-Speicher Befehlen, wie >>> IBMs Mainframes, DEC VAX, 68000=>68020 und dergleichen. >> >> Interessant. Das wusste ich nicht. > > Findest du es passend, bei erklärter Ahnungslosigkeit > über die historischen Grundlagen der RISC Philosophie Mal langsam. Bis jetzt war ich der Meinung, wir hätten nicht über Philosophie und Geschichte, sondern über Prozessor- architektur gesprochen. Ich dachte EIGENTLICH, dass es da etwas weniger subjektiv zugeht -- aber das ist wohl ein Irrtum... > folgendes Urteil abzugeben? > > Egon D. schrieb: >> Die apodiktische Behauptung der deutschsprachigen >> Wikipedie, RISC-Architekturen seien GRUNDLEGEND >> durch ihren Aufbau als Load/Store-Architekturen >> charakterisiert, halte ich dennoch für abstrus. Selbstverständlich halte ich das für passend. Du möchtest doch bitte nicht ERNSTHAFT von mir verlangen, dass ich einem Berufsstand, der das Komplement mit dem Befehl "NEG" und die bitweise Negation mit dem Befehl "CPL" berechnet, IRGEND ETWAS blind glaube? > Da hat Uhu recht. Darüber zu diskutieren bringt nichts. > Du wirst deinen persönlichen RISC Begriff verteidigen, Natürlich. Schließlich ändere ich meine Meinung nicht einfach aufgrund irgendwelcher diffuser Anwürfe und persönlicher Beleidigungen, sondern nur aufgrund von Sachargumenten. > der wenig mit dem zu tun hat, was der Rest der Welt > darunter versteht. Deine Sicht sei Dir unbenommen.
S. R. schrieb: > Egon D. schrieb: >> Der MSP430 macht dagegen: >> INC [0x1234] >> Die Laufzeitkomplexität kommt nicht dadurch zu Stande, dass >> die interne VERARBEITUNG in vielen Schritten abliefe, sondern >> dadurch, dass eine "Befehlsfusion" mit vorhergehenden und >> nachfolgenden Transfer-Operationen möglich ist. > > Warum sollte das in aktuellen CPUs nicht auch möglich sein? ??? Es ging nicht um die Frage, was in aktuellen CPUs möglich ist, sondern darum, ob der MSP430 ein "echter RISC" ist. Ich bin der Meinung: "JA", denn er hat alle wesentlichen Architekturmerkmale, die ein Prozessor ohne Cache überhaupt in Richtung RISC haben kann, nämlich: 1. einen großen Registersatz aus gleichberechtigten Universal- registern, 2. einen orthogonalen Befehlssatz, und -- ich ergänze -- 3. eine ein-Zyklus-Verarbeitung. (Wenn Befehle sechs Taktzyklen dauern, dann hat das AUSSCHLIESSLICH mit dem Speichertransfer zu tun, nicht mit der Verarbeitung.) Die Mehrheitsmeinung hier sagt "Nein", weil RISC-Prozessoren aus historischer Sicht immer eine Load/Store-Architektur hatten -- und die historische Auffassung von RISC ist heilig.
A. K. schrieb: > Egon D. schrieb: >> Das mag sein -- aber daraus kann man im Umkehrschluss nicht >> folgern, dass "inc [memadr]" auf Architekturen mit mehr >> Registern (MSP430) unnütz oder gar schädlich wäre. > > Es ist schädlich, wenn man über die simple Laufzeitstruktur > eines MSP430 hinaus geht. Ja sicher -- aber genau davon rede ich doch: Der MSP430 HAT halt genau diese simple Laufzeitstruktur, und er hat sie nicht, weil die Entwickler Blödmänner waren, sondern weil der Aufwand für eine kompliziertere Struktur GESPART werden sollte! Und wenn mir vorgeworfen wird, ich würde abstruserweise den RISC-Begriff auf Mikrocontroller anwenden: Es war Falk, der geschrieben hat, der MSP430 sei gar kein "echter RISC". Deswegen bleibe ich, sofern nicht noch ein Sachargument gebracht wird, bei meiner Meinung: Für den, der daran festhält, dass ein echter RISC-MikroPROZESSOR eine Load/Store-Architektur (und somit fast sicher einen Cache) haben muss, für den ist der MSP430 kein echter RISC. Als MikroCONTROLLER hat er aber alle Architekturmerkmale, die ein RISC-Prozessor ohne Cache überhaupt haben kann.
Der 8051 war sehr gut für Assembler optimiert. Mit "MOVC A, @A+DPTR" kann man z.B. sehr leicht auf Tabellen zugreifen bzw. mit "JMP @A+DPTR" verzweigen. Und mit den Bitbefehlen "ANL/ORL C, (/)Bit" usw. kann man quasi Logikgleichungen direkt hinschreiben. Auch 8Bit-MUL/DIV sind verfügbar, sowie die Kombibefehle DJNZ, CJNE.
Angehängte Dateien:
-
kim1_09.jpg
310 KB -
kim1_04.jpg
230 KB
Gibt es denn schon was Anderes als Assembler? http://www.wolfgangrobel.de/sbc/kim1.htm SCNR...
Wolfgang R. schrieb: > > http://www.wolfgangrobel.de/sbc/kim1.htm Wirklich schönes Teil. Da kommt Nostalgie auf. Obwohl ich nur einen Ohio Superboard C1P mit schnöden schwarzen Plastik 6502 hatte.
Peter D. schrieb > Soll ein Programm schnell und sparsam sein, sollte man daher besser auf > C umsteigen. Dem kann ich nicht uneingeschränkt zustimmen. Das mag zwar in den meisten Fällen richtig sein, aber ein guter ASM-Programmierer kennt seine Maschine und weiß, was das Programm machen soll. Der Compiler kennt nur die Maschine und kann den Code nach ein paar Regeln optimieren. Für ihn ist erst mal aller Code gleich (wichtig). Gerade wenn man andre CPUs emuliert, ergibt sich meinen Erfahrungen nach ein Geschwindigkeitsfaktor >2 gegenüber dem Compiler, wenn man bei der Assembler-Programmierung sowohl die Eigenheiten der Maschine als auch den Kontext des zu schreibenden Codes im Auge behält. Aber deswegen würde ich auch nicht alles in ASM machen. Jörg
Wolfgang R. schrieb: > Gibt es denn schon was Anderes als Assembler? Auf dem Nachfolger https://en.wikipedia.org/wiki/AIM-65 gab es neben Assembler auch schon ROMs mit BASIC, Forth und einem PL/65-Compiler. 20-stelliger Kassendrucker, 20-stelliges alphanumerisches LED-Display und auf gehts mit Programmieren. Und so war das gedacht: - Programm schreiben, auf Kassettenrecorder #1 speichern. - PL/65 Compiler anwerfen, liest aus #1 und schreibt Asm-Quelltext auf Kassettenrecorder #2. - Assembler anwerfen, der 2x nacheinander von #2 liest und das fertige Programm auf #1 schreibt. - Programm von #1 laden und ausprobieren. - Source von #1 laden und Fehler korrigieren.
Auf einem RISC-Befehlssatz kann ein halbwegs schlauer (Macro-)Assembler durchaus einen CISC-Befehlssatz emulieren - er muss eben die komplexen Befehle in die zugehörige Sequenz von RISC-Befehlen umsetzen. Zumindest ansatzweise wurde das auch schon gemacht - es fällt gerne dann auf, wenn ein Disassembler ins Spiel kommt. Macroassembler gab es zu Zeiten, als überwiegend mit ASM programmiert wurde, sehr clevere. Seit Assembler nur noch benutzt werden, um symbolischen Output eines Compilers in Maschinencode oder ein verschiebliches Format umzusetzen, sind diese Schlauköpfe aber völlig aus der Mode gekommen.
Egon D. schrieb: > Die Mehrheitsmeinung hier sagt "Nein", weil RISC-Prozessoren > aus historischer Sicht immer eine Load/Store-Architektur > hatten -- und die historische Auffassung von RISC ist heilig. Wenn alle Instanzen von X eine Eigenschaft Y haben, während diese Eigenschaft Y woanders nicht vorkommt, dann ist diese Eigenschaft Y eigentlich ein verdammt guter Indikator für X, findest du nicht? Egon D. schrieb: > Es ging nicht um die Frage, was in aktuellen CPUs möglich ist, > sondern darum, ob der MSP430 ein "echter RISC" ist. Ich bin ja der festen Überzeugung, dass diese Frage absoluter Blödsinn und die Antwort irrelevant ist. Die Grenzen sind fließend, ähnlich wie übrigens auch bei "Harvard" vs "von Neumann". Der MSP430 hat Eigenschaften von RISC (kleiner Befehlssatz, reguläres Encoding) und Eigenschaften von CISC (komplexe Adressierungsmodi, kein Load/Store). Damit ist er "weder noch".
S. R. schrieb: > Wenn alle Instanzen von X eine Eigenschaft Y haben, während diese > Eigenschaft Y woanders nicht vorkommt, dann ist diese Eigenschaft Y > eigentlich ein verdammt guter Indikator für X, findest du nicht? Und was wenn alle Instanzen von X', X", … Xn-strich auch die Eigenschaft Y haben?
Uhu U. schrieb: >> Wenn alle Instanzen von X eine Eigenschaft Y haben, während diese >> Eigenschaft Y woanders nicht vorkommt, dann ist diese Eigenschaft Y >> eigentlich ein verdammt guter Indikator für X, findest du nicht? > > Und was wenn alle Instanzen von X', X", … Xn-strich > auch die Eigenschaft Y haben? Dann ist die Eigenschaft Y ein verdammt guter Indikator für "X und dessen Ableitungen". Was willst du mir damit sagen?
S. R. schrieb: > Dann ist die Eigenschaft Y ein verdammt guter Indikator für "X und > dessen Ableitungen". Was willst du mir damit sagen? Wie kommst du darauf? Weißt du, was man in der Evolutionstheorie unter Konvergenz versteht?
S. R. schrieb: > Der MSP430 hat Eigenschaften von RISC (kleiner Befehlssatz, reguläres > Encoding) und Eigenschaften von CISC (komplexe Adressierungsmodi, kein > Load/Store). Ehrlich gesagt ist mir das sowas von egal bei der Auswahl eines MCs. Mich interessiert nur, wie komfortabel die Programmierumgebung (C-Compiler, Programmer, Debugger, Datenblatt) ist und wie groß die Auswahl an Peripherie und der VCC-Bereich ist. Ich bevorzuge MCs, die an bis zu 5V arbeiten können und CAN haben. Die interne Architektur ist mir vollkommen schnurz.
Uhu U. schrieb: >> Dann ist die Eigenschaft Y ein verdammt guter Indikator für "X und >> dessen Ableitungen". Was willst du mir damit sagen? > > Wie kommst du darauf? Ganz einfach: x' ist die Ableitung (das Derivat) von x.
S. R. schrieb: > Ganz einfach: x' ist die Ableitung (das Derivat) von x. Wir sind hier nicht bei Analysis…
Uhu U. schrieb: >> Ganz einfach: x' ist die Ableitung (das Derivat) von x. > Wir sind hier nicht bei Analysis… ...und auch nicht bei Darwin.
S. R. schrieb: > ...und auch nicht bei Darwin. Aber wir sind bei der Taxonomie von Objekten und da sollte man schon wissen, was Konvergenz - in dem Fall einer technischen - Evolution bedeutet. Du hast einfach eine Möglichkeit übersehen und das läßt leider deinen Gedanken scheitern…
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.