mikrocontroller.net

Forum: Offtopic Warum quälen sich so viele Hobbyprojekte noch mit ASM-Code ab?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Dl1... (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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 Moderator
Autor: DC (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: ~Mercedes~  . (lolita)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: spess53 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi

>Warum quälen sich so viele Hobbyprojekte noch mit ASM-Code ab?

Weil man Zeit hat und es Spass macht.

MfG Spess

Autor: Klaus R. (klara)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex D. (allu)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
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 ...

Autor: Jan H. (j_hansen)
Datum:

Bewertung
-16 lesenswert
nicht lesenswert
Dl1... schrieb:
> Amateurfunkbereich

Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;)

Autor: Apollo M. (Firma: @home) (majortom)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
... 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!

Autor: spess53 (Gast)
Datum:

Bewertung
12 lesenswert
nicht lesenswert
Hi

>Weil das alles alte Knacker sind die arbeiten wie anno 1976 ;)

Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik 
haben.

MfG Spess

Autor: Apollo M. (Firma: @home) (majortom)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Alex D. (allu)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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 ...

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Käfer (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Assembler? How quaint!

Heutzutage entwickelt man nur noch so:

https://en.m.wikipedia.org/wiki/Mbed

Autor: Ryzen-PC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..

;)

Autor: spess53 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Arno K. (Firma: advanced microsystems) (radiosonde)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Beitrag #5927375 wurde von einem Moderator gelöscht.
Autor: Steffen I. (echo)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Manfred (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: hinz (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Apollo M. (Firma: @home) (majortom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Apollo M. (Firma: @home) (majortom)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
spess53 schrieb:
> Wen interessiert das?

gute frage!

wahrscheinlich jene, die glauben das ein zitronenfalter zitronen faltet 
- sprich die angepassten, gleichgemachten, ...

Autor: Käfer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DC schrieb:
> Schließlich ist die
> Definition von Hobby, mit dem größtmöglichen Aufwand den geringsten
> Nutzen zu erwirtschaften

Schwachsinn.

Autor: Jemand (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Wolfgang (Gast)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Aaron (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> 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.
Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
spess53 schrieb:
> Weil die jungen Knacker keine Ahnung von richtiger Amateurfunktechnik
> haben.

Es gibt keine jungen Knacker. Das sind höchstens junge Kacker ;-)

Autor: Walter K. (walter_k488)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
„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!

Autor: H-G S. (haenschen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Le X. (lex_91)
Datum:

Bewertung
8 lesenswert
nicht lesenswert
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"...).

Autor: Thomas O. (kosmos)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Martin V. (oldmax)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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).

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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:
  push r16
  push r17
  ; mache was
  pop r16
  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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Ja, aufgeblasener Befehlssatzmit Redundanz ohne Ende. Nein Danke.

Darf man fragen, wieviel 1000 Stunden ASM-Erfahrung du auf dem Buckel 
hast?

Autor: Andreas K. (andreas_k209)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:-)

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Peter D. (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
 
LD R7, [0x1234] 
INC R7 
LD [0x1234], R7 

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.

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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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…

Autor: Egon D. (egon_d)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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…

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Gibt es denn schon was Anderes als Assembler?

http://www.wolfgangrobel.de/sbc/kim1.htm

SCNR...

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Ganz einfach: x' ist die Ableitung (das Derivat) von x.

Wir sind hier nicht bei Analysis…

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
>> Ganz einfach: x' ist die Ableitung (das Derivat) von x.
> Wir sind hier nicht bei Analysis…

...und auch nicht bei Darwin.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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…

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.