mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Assembler oder C


Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich programmiere den 80c535 seit längerem in Assembler! Ist der Umstieg
auf C vorteilhaft, oder ist Assembler vorzuziehen?

(PS: Mit C kenn ich mich auch recht gut aus)

Gruß der Jense

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jense

ist ein bisschen Ansichtssache. ich meine, solange du nur ein paar Bits
manipulierst, ist Assembler gut. Anspruchsvoll wirds, wenn Du anfängst
jenseits von Integer zu rechnen. Oder wenn Du IF-Then Else-Strukturen
brauhst, oder wenn allgemein dein Programm komplex wird, dann st C
einfacher  und übersichtlicher - und das ohne daß man sich anstrengen
muß. Mit Assembler geht das natürlcih auch, aber float in Assembler,
oder bloß Teilen - das nervt unter Assembler - mich zumindest.

Gerhard

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin wirklich bei jeder Aufgabe mit dem 8051 bisher um C
herumgekommen (beim M16C ist das was anderes).
Anstelle irgeneine Zahl durch 0,0732421875 zu teilen, fügt man eben 2
Low Bytes an und teilt das ganze durch 4800. Ist nichtnur schneller,
sondern das ganze Programm ist auch kleiner als nur die Float Routinen
für C...
Für 8051 sollte man Assembler verwenden, bei AVR muss man schon besser
überlegen was man verwendet, denn der ist für C optimiert.

Autor: Matthias Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe nicht, warum sich manche Leute immer um C herumdrücken.
Keine professionelle Softwareentwicklung findet in Assembler statt,
höchstens noch ein paar zeitkritische Optimierungen.
C ist nicht schwer zu erlernen und man spart sich solche unnötigen
Verrenkungen wie "low bytes anfügen und dann durch 4800 teilen". Was
soll das? Warum sollte man sich das Leben unnötig kompliziert machen,
wenn man von einem C-Compiler solche stumpfsinnigen Aufgaben abnimmt?

"AVR ist für C optimiert, der 8051 nicht". Sowas ist imho absoluter
Schwachsinn und höchstens ein Marketingslogan von Atmel. Die
Codequalität und damit die Ausführungsgeschwindigkeit oder Codegröße
hängt vom Compiler ab - man vergleiche dazu beispielsweise C-Compiler
für 8051 von Keil mit dem freien.
Ich lasse mich in diesem Punkt aber gerne eines besseren belehren, aber
bitte mit Fakten.

Fazit: C lernen lohnt sich auf jeden Fall denn es vereinfacht vieles
und ermöglicht strukturierte und professionelle Softwareentwicklung. In
Assembler programmieren zu können ist aber deswegen keinesfalls unnötig,
denn die Kenntnis trägt maßgeblich zum Verständnis bei. Wer aus Prinzip
dennoch nicht C lernen will ist entweder zu dumm oder ein Ignorant.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>"AVR ist für C optimiert, der 8051 nicht". Sowas ist imho absoluter
>Schwachsinn und höchstens ein Marketingslogan von Atmel. Die
>Codequalität und damit die Ausführungsgeschwindigkeit oder Codegröße
>hängt vom Compiler ab - man vergleiche dazu beispielsweise C-Compiler
>für 8051 von Keil mit dem freien.
>Ich lasse mich in diesem Punkt aber gerne eines besseren belehren,
aber
>bitte mit Fakten.

Schau Dir die Adressierungsarten des AVR an, z.B.:
"Data indirect with displacement"
In Hochsprachen ist es üblich, lokale Variablen zu benutzen. Mit dieser
Adressierungsart kannst Du bequem bis zu 64 Byte an lokalen Variablen
adressieren - ohne irgendwelche Pointer-Berechnungen.

Data indirect with pre-decrement und
data indirect with post-increment
sind weitere Befehle, die Hochsprachencode einfacher machen.

Das trifft natürlich nicht nur auf den AVR zu, der 68000 hat da noch
wesentlich mehr geboten. Und auch nicht nur auf C, sondern auf
Hochsprachen allgemein.

Stefan

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan Kleinwort:
Mensch, Du erwähnst tatsächlich den 68000 und machst mich richtig
Wehmütig!
Hatte früher, bevor die PC´s langsam zu reifen begannen, einen Atari ST
mit nen MC 68000.
Für Assembler wirklich ein geiler Prozessor.
Da braucht man wirklich keine Hochsprache wie C wenn man einigermassen
perfekt Assemembler beherscht.
Kartenspiele, Zeichenprogramme und Soundediting in Assembler ohne
Probleme.
Muß natürlich zugeben, das vom TOS schon ein paar Subs verwendet
wurden.
C ist für mich wie Hibräisch.

Gruß
Andi

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"C ist nicht schwer zu erlernen und man spart sich solche unnötigen
Verrenkungen wie "low bytes anfügen und dann durch 4800 teilen". Was
soll das?"

rechenzeit sparen, speicherplatz sparen. floats sind für die meisten
kleinen uC recht unhandlich

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi:
naja, den "echten" 68000 hatte ich nie programmiert, sondern den
68332 (embedded-Version). Natürlich lies der sich auch sehr hübsch in
Assembler programmieren. Aber der Befehlssatz war auch genial für den
C-Compiler, Du konntest in den Assembler-Befehlen richtig einzelne
C-Zeilen erkennen.

@Tobi:
Solche "Verrenkungen" liebe ich auch. Float benutze ich praktisch
nie. Ein kleines bischen abstrahieren, und schon hat man das Problem
mit int gelöst. Das Beispiel von Benedikt fand ich klasse!

Stefan

Autor: Matthias Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Schau Dir die Adressierungsarten des AVR an, z.B.:
"Data indirect with displacement"
In Hochsprachen ist es üblich, lokale Variablen zu benutzen. Mit
dieser
Adressierungsart kannst Du bequem bis zu 64 Byte an lokalen Variablen
adressieren - ohne irgendwelche Pointer-Berechnungen."

Vielleicht existieren beim AVR Adressierungsarten, die den Einsatz von
C favorisieren. Jedoch lasse ich dieses Argument nicht gelten, denn
entscheident ist, was am Ende rauskommt. Wir haben bei uns in der Firma
ein großes Projekt aus professionellem Umfeld (ca. 32KByte Code) sowohl
auf AVR als auch 8051 compiliert. Der Code war jeweils auf den
entsprechenden Controller optimiert (keine ASM-Optimierungen). Der
Unterschied in der Codegröße war minimal und vernachlässigbar.

"rechenzeit sparen, speicherplatz sparen. floats sind für die meisten
kleinen uC recht unhandlich"
Rechenzeit und Speicherplatz sparen ist sicherlich wichtig, jedoch
haben Prinzipien des Softwareengineering Vorrang, z.B:
-Reuse
-Abstraktion
-Modularität
-Information Hiding, um nur einige zu nennen.
Diese Prinzipien sollte jeder gute Programmierer anstreben, und
Assembler macht das ungemein schwerer.
Mit den floats gebe ich Dir recht, die blähen den Code schon ziemlich
auf. Ich habe sie bis jetzt auch immer vermieden, aber nur, wenn es
nicht auf Kosten der Lesbarkeit geht.
Rechenzeit und Speicherplatz wird heutzutage stetig güstiger, die
Entwicklungszeit eines Programmierers zum Glück nicht.

Und um noch ein Argument in den Raum zu werfen: Die Benutzung von C
ermöglicht die Portierung von Code auf fast jedes beliebige Target mit
minimalem Aufwand, bei ASM ist das unmöglich.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vielleicht existieren beim AVR Adressierungsarten, die den Einsatz von
>C favorisieren. Jedoch lasse ich dieses Argument nicht gelten, denn
>entscheident ist, was am Ende rauskommt. Wir haben bei uns in der
Firma
>ein großes Projekt aus professionellem Umfeld (ca. 32KByte Code)
sowohl
>auf AVR als auch 8051 compiliert. Der Code war jeweils auf den
>entsprechenden Controller optimiert (keine ASM-Optimierungen). Der
>Unterschied in der Codegröße war minimal und vernachlässigbar.

Es wird immer Projekte geben, die die Vorteile der einen (oder anderen)
Architektur besser nutzen. Wobei die Codegrösse für mich den kleinsten
Faktor darstellt.
Allerdings finde ich es bei der AVR-Architektur klar erkennbar, dass
die Entwickler die Codeerzeugung durch Compiler im Blick hatten. Manche
Befehls- oder Adressierungsarten findet man eben kaum in
Assemblerprogrammen, dafür umso mehr im Output des Compilers. Insofern
finde ich es kein reines Marketing-Argument von Atmel.

Bei float fallen mir immer die Leute ein, die AD-Ergebnisse in float
umwandeln, weil sie natürlich auch die mV ausgeben wollen.

Im Übrigen sind wir uns (denke ich) so ziemlich einer Meinung. Am
liebsten programmiere ich in C und schaue ab und zu im
Assembler-Output, was der Compiler da gebastelt hat.

Was noch hinzu kommt bei den Vorteilen in Hochsprache: bei sinnvoller
Wahl der Variablennamen ist C-Code geradezu selbsterklärend -
jedenfalls im Vergleich zu Assembler.

Stefan

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin ganz deiner Meinung. Ich kann keinen verstehen, der auf reiner
Assemblerprogrammierung besteht, es sei denn, er ist reiner Hobbyist
mit unbegrenzt vorhandendener Zeit und einem gewissen Zwang zur
Selbstkasteiung.
Bei etwas komplizierteren Programmen schätze ich das
Entwicklungszeitverhältnis Assembler/Hochsprache auf min. 10:1 (bei
PICs eher 20:1 :-).
Weitere Riesenpluspunkte für C und Konsorten: die
Lesbarkeit/Wartbarkeit und Fehlersuche.
Ich konzentriere mich lieber auf das eigentliche Programmierproblem,
als mir ständig über Adressierung, Stack und Bibliotheken zusätzlich
den Kopf zu zerbrechen.
Argument Speicherplatz: ab einer bestimmten Grösse des Programms hat
auch da Assembler keinen Vorteil mehr, durch Optimierungen des
Compilers können Bytes freigeschaufelt werden, die man in Assembler
entweder gar nicht sieht oder das Programm zu einem totalen Chaos
werden lassen, an das man, wenn es denn einmal laufen sollte, am besten
nie wieder rangeht. Ebenso ist die RAM-Nutzung meist besser (lokale
Variablen).
Argument Laufzeit: mit einem gewaltigen Einsatz an Denk- und
Fleissarbeit ist manchmal was möglich in Assembler, meist aber auf
Kosten einer ordentlichen Programmstruktur. Ausserdem sind nie alle
Programmteile so zeitkritisch, dass es sich nur mit allen möglichen
Programmiertricks lösen lässt (wenn doch: falschen Prozessor gewählt)

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie erlebe ich ein Deja-vu (schreibt man das so? Nie franz.
gelernt...). Die Frage wurde doch schon öfters behandelt.

Ich würde es auch so sehen: Assembler als Hobby, C für den Profi.
Allerdings gibt es böse Zungen, die behaupten, C sei nur ein
Makroassembler ;)
Es geht im Profibereich vor allem darum, daß ein Programm auch nach
Jahren noch für einen neuen Mitarbeiter lesbar ist. Aber das ist keine
Frage der Programmiersprache, sondern des Programmierstils und der
Dokumentation. Mal eine Frage an die Profis: Wenn ihr euch ein ca. 5
Jahre altes Programm anschaut, steigt ihr da sofort durch? Bezweifle
ich.
Man kann sowohl in C als auch in Assembler gut strukturierte oder aber
auch unübersichtliche Programme schreiben.
Ich persönlich sehe es als Hobby, brauche keine Floats, meine Programme
sind sehr klein, ergo: Assembler. Bei größeren Projekten würde ich
wahrscheinlich auch irgendwann den Einsatz einer Hochsprache einsehen,
dann aber eher Basic, als C. Warum? Die vielfach hochgelobte
Portierbarkeit kann man bei µC doch vergessen. Wenn man ein Programm,
das PWM, UART und (Hardware-)TWI benutzt, vom Atmel auf z.B. einen
MCS-51 oder einen M16C portieren will, muß man alles, was mit
Hardwareansteuerung zu tun hat, umschreiben. Da kann mans auch gleich
mit einem anderen Basic-Dialekt versuchen.

Schaut mal rein, sehr aufschlußreich:
http://www.kuro5hin.org/story/2004/2/7/144019/8872

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe schon mehrmals ein Programm in C und in Assembler für den 8051
geschrieben.
In C war das Programm fast immer zu groß für den Speicher (vor allem
wenn man den AT89C2051 mit 2k Flash verwendet.)
Der 8051 ist so leicht in Assembler zu programmieren, da macht es wenig
Sinn C zu verwenden, vor allem da der Controller nicht gerade der
schnellste ist. Rechnet man da mit float, dann kann man sich über 100
Rechenoperationen pro Sekunde freuen und sich über die 1,5k float
Routinen ärgern, während die Integer Berechnung gerade mal etwa
100Bytes braucht und in etwa 1ms gelöst ist (für eine 64bit/64bit
Division)
Bei Controllern macht Assembler dagegen wenig Sinn, wenn man auch nicht
ganz drum rum kommt. So muss die StartUp Datei in Assembler geschrieben
werden. Außerdem ist es sinnvoll einige Routinen in Assembler zu
schreiben (z.B. um den Flash zu programmieren.)

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, um 2k Code vollzukriegen, in dem wohl jeder 2.Befehl die Hardware
anspricht, macht es wenig Sinn, einen Compiler anzuwerfen.

Für (fast) jedes Problem gibt es eben eine oder mehrere gute Lösungen -
aber eben nicht eine gute Lösung für alle Probleme.

Wäre ja auch schrecklich, genauso, wie wenn das ganze Jahr über die
Sonne scheinen würde, oder alternativ das ganze Jahr über regnen
würde. Oder wenn es nur Meschen mit blauer Hautfarbe gäbe ...

Stefan

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan,

>>Ich lasse mich in diesem Punkt aber gerne eines besseren belehren,
aber
>>bitte mit Fakten.

>Schau Dir die Adressierungsarten des AVR an, z.B.:
>"Data indirect with displacement"

Du hast die Frage nicht verstanden.
Matthias meinte praktische Beispiele und keine Theorien über
Adressierungsarten.

Und da kann ich ihm nur zustimmen, Meine C Programme auf dem 8051 sind
auch generell kleiner als auf dem AVR und manchmal sogar kleiner als
Assembler auf dem AVR.

In Steuerungsaufgaben geht es nunmal vorrangig um Statemaschinen und
Bitmanipulationen (z.B. Portpins togglen) und nicht möglichst große
Mengen an SRAM zu ver(sch)wenden.


Zum Thema:

Ich würde es an der Programmgröße festmachen:
Bis 2kB (8051) bzw. 4kB (AVR) ist Assembler noch gut beherrschbar.

Darüber hinaus verliert man leicht den Überblick und kann Fehler
machen. Da bedeutet die automatische Variablenverwaltung von C eine
sehr mächtige Erleichterung und deshalb sind C Programmer schneller
geschrieben und fehlersicherer.

Und das C Programme portabel sind, ist auch eine große Zeitersparnis.
Ich teste z.B. viele Routinen im guten alten Borland-C auf ihre
funktionale Richtigkeit.


Und erst recht, wenn man C kann, spricht überhaupt nichts dagegen,
seinen 8051 in  C zu programmieren. Ich benutze zwar nur den Keil, aber
inzwischen gibt es ja auch viele billigere Alternativen, die auch nicht
wesentlich schlechter sein sollen.


Und float ist auch kein Thema, wenn man nicht platz- oder zeitkritische
Anwendungen hat.
Ich habe z.B. einige Male floats auf dem AT89C2051 verwendet, daß
belegt einmalig etwa 700 Byte, also sind noch 1,3kB für die Anwendung
übrig.


Peter

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gähn ...

>Du hast die Frage nicht verstanden.
Die Frage habe ich sehr wohl verstanden, und wie ich Dich kenne, hast
Du auch meine Antwort verstanden.
Was ich nicht verstehe, ist Dein Posting ... ist da irgendwas, was noch
nicht gesagt, wäre, oder über das wir bedeutend anderer Meinung wären?

Grübel ... Stefan


P.S.:
Noch ein dummes Beispiel für die besagte Adressierungsart, einfach mal
durch gcc schicken und sehen, was rauskommt. Bitte keine Kommentare,
wie sinnvoll dieser Code tatsächlich ist ... er ist rein zum
Compilertesten.

uint32_t test(uint32_t x, uint32_t y, uint32_t z, uint32_t p){
  volatile uint32_t a,b,c,d,e,f,g,h,i,j,k;
  a = x * 2;
  b = y * 3;
  c = p * 5;
  d = x * 6;
  e = y * 7;
  f = z * 8;
  g = x * 9;
  h = y * 10;
  i = z * 11;
  j = x * 12;
  k = y * 13;
  if (p == 1){
    return(a+b+c+e+f+g+h+i+j+k);
  }
  else{
    return(a*b*c);
  }
}

Autor: Matthias Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wäre doch mal eine interessante Sache:

Der Compiler/Assembler-Clash

Jeder versucht, mit seinem Compiler/Assembler den "besten" Code zu
erzeugen. Der Sinn sei jetzt mal dahingestellt...
Dann müssten wir aber noch die Rahmenbedingungen festlegen.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, was sollte es nützen? Man kann keine objektive Bewertung des
Ergebnisses vornehmen. Manchmal zählt einfach nur Zeitersparnis beim
Entwickeln, ein anderes Mal nur die pure Laufzeit, dann wieder
Codegrösse oder RAM-Bedarf. Das wird dann sowas wie ein
CPU-Benchmark...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Bitte keine Kommentare, wie sinnvoll dieser Code tatsächlich ist ...
er ist rein zum Compilertesten."


"Hm, was sollte es nützen? Man kann keine objektive Bewertung des
Ergebnisses vornehmen."

Ganz genau.

Ich will doch meine Anwendungen realisieren.

Und dabei nützen mir irgendwelche praxisfernen Compilertests nicht die
Bohne.

Einfach mal einige reale Anwendungen in C und Assembler auf
verschiedenen µC voll funktionsfähig zu programmieren hat wesentlich
mehr Aussagekraft.


Peter

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil wir gerade dabei sind, wie sieht das eigentlich mit Pascal aus.
Scheint ja eher für AVRs nich so verbreitet zu sein. Aber hat da
eventuell doch schon jemand Erfahrungen, was so die Codeeffizienz
anbelangt?

Gruß
Ingo

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pascal war meine erste Sprache, und manchmal mache ich immer noch etwas
damit. Ist mir eigendlich sehr sympathisch.

Im mc-Bereich sieht es mit Pascal aber meistens schlecht aus. Es gibt
zwar diverse Pascal-Compiler für verschiedene mc. Aber nur bei C kann
man sich wirklich sicher sein, bei einem Plattformwechsel wieder in C
programmieren zu können.

Bei der Code-Effizienz kommt es meiner Meinung nach weniger auf die
Sprache und vielmehr auf die Qualität des Compilers drauf an. Und
natürlich, wie effizient das Programm geschrieben ist.

Stefan

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.