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?
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
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.
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?
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:> 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.
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
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.
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.
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.
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.
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.
... 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.
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.
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:
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.
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.
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.
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.
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.
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 MSP430HAT 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.
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:> ...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…
