mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ASM oder C programmieren?


Autor: Unkown User (Firma: Staubsaugervertreter) (coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi.

In was sollte man kleinere, einfachere Sachen besser programmieren?
Also einfache Sachen die man problemlos auch mit nem TTL Grab und OP's 
machen könnte und die nur aus Bequemlichkeit und wegen geringerem 
Bauteileaufwand mit einem uC gemacht werden.

C oder ASM? Oder beides, also C mit viel Inline-Assembler?

Mit was progrmmiert ihr sowas?

Autor: Marcus B. (raketenfred)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke asm wird nur noch eingesetzt wenn es wirklich benötigt wird, 
wegen geschwindigkeit

ansonsten würde ich eigentlich sagen immer C egal für was
bessere Wartbarkeit etc.

Autor: Andi ... (xaos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C oder gleich C++ damits in der entwicklung schneller geht. asm nimmt 
man im äußersten notfall noch, wenn es wirklich auf die letzte µs 
ankommt (wobei man da dann einfach ne andere hardware nimmt )

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unkown User schrieb:
> C oder ASM? Oder beides, also C mit viel Inline-Assembler?

Das, was Du besser (lernen) kannst.

Assembler und C mixen aber auf keinen Fall, damit erhält man nur die 
Summe der Nachteile von beiden und kaum Vorteile.

Sachen >2kB Binärcode sollte man aber immer in C machen.
In Assembler steigt dann der Aufwand, den Überblick nicht zu verlieren 
und die Programmierzeit unverhältnismäßig stark an.


Peter

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer in einer Sprache fit ist, sollte die nehmen. Wer keine Sprache 
richtig kann, sollte sich zunächst auf eine festlegen, diese dann lernen 
und dann programmieren.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Assembler und C mixen aber auf keinen Fall, damit erhält man nur die
> Summe der Nachteile von beiden und kaum Vorteile.

Hallo Peter,

komisch dass fast alle real existierenden Systeme von der Waschmaschine 
bis zum PC in C UND ASM programmiert sind - deine sicherlich 
überragenden Programmierfähigkeiten müssen offensichtlich unter den 
ITlern erst noch allgemein bekannt werden. Aber, wie man sieht, du 
arbeitest ja dran.

Gruss Reinhard

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Informiere dich erst mal, über wen du da herziehst...

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Informiere dich erst mal, über wen du da herziehst...

Wenn du damit sagen willst, es mangelt mir an Ehrfurcht - ja, genau so 
ist es. Unsinn ist Unsinn, egal von wem. Ich schreibe Software, seit es 
überhaupt programmierbare Systeme gibt, anzubetende Götter sind mir 
bisher nicht begegnet.

Gruss Reinhard

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um die Hardware des µC kennenzulernen ist ASM ideal aber eben 
zeitraubend.

In Sachen portierbarkeit und Übersicht ist C auf jeden Fall zu 
bevorzugen.

Peter Dannegger schrieb:
> Sachen >2kB Binärcode sollte man aber immer in C machen.

Dem schließe ich mich an.
Auf den AVR bezogen:
Tinys mit wenig Speicher (oder ohne SRAM, Tiny11) in ASM, falls die 
Anwendung das zulässt, manche Sachen sind in C eben einfacher zu 
realisieren, obwohl es nur kleine Aufgaben sind.

Autor: Platinenschwenker .. (platinenschwenker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

Ich glaube  Peter Dannegger meinte nur man sollte nicht Assembler und C 
in einem Quelltext mischen, so wie das bei Inline-Assembler Anweisungen 
geschieht. Womöglich habt ihr da nur ein ein wenig aneinander vorbei 
geredet. Ich habe auch schon Sätze gelesen, dass Peter zeitkritische 
Routinen sehr wohl in Assembler schreibt, dort wo es angebracht ist und 
ansonsten in C programmiert.

(kann mich aber auch täuschen ;))

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> komisch dass fast alle real existierenden Systeme von der Waschmaschine
> bis zum PC in C UND ASM programmiert sind

Das erstaunt mich aber sehr.
Ich wüßte keinen Grund, warum man eine Waschmaschine gemischt 
programmieren sollte.
Auch auf dem PC kenne ich keine Applikation, die so programmiert ist.
Und auf meiner Arbeit ist mir sowas auch nicht untergekommen.

Natürlich enthält ein OS auf dem PC Assembler, aber das programmiert man 
ja nicht selber.
Es geht ja hier um die Anwendungsprogrammierung und nicht um ein OS.


Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ein kleine Projekt würde ich auch mit ASM anfangen, dabei lernt man 
die Hardware besser kennen. Wenn man danach C Programmiert wird einem 
schneller bewusst warum man einige Dinge die in C einfach aussehen nicht 
auf einem µC machen wollte. Weil es dafür keine passenen Befehle gibt 
und der Compiler sich etwas einfallen lassen muss. z.b. Divisionen und 
Bit shifts um eine Variabel länge.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andi D. schrieb:
> C oder gleich C++ damits in der entwicklung schneller geht.

C++ würde ich bei Mikrocontrollern vermeiden. Die meisten Aufgaben, die 
die absolvieren müssen, erfordern auch nicht wirklich objektorientierte 
Programmierung. Eher im Gegenteil.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Sachen >2kB Binärcode sollte man aber immer in C machen.

Wo liegt der Unterschied zwischen <2k und >2k?

>In Assembler steigt dann der Aufwand, den Überblick nicht zu verlieren
>und die Programmierzeit unverhältnismäßig stark an.

Ist wohl eine weniger eine Frage des Programmierstils als der 
Programmiersprache. Man kann auch mit C bei 0,5k den Überblick 
verlieren.

MfG Spess

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c++ und objektorierntierte Programmierung muss kein Nachteil sein. Ich 
bin sogar der Meinung, dass man mit strenger OOP viel saubereren Code 
hinlegt, als ohne. Aber: OOP braucht teilweise mehr Resourcen als 
althergebrachte prozedurale Programmierung. Für einen uP ist das eher 
kontraproduktiv.

Man kann in c++ aber auch genauso gut prozedural programmieren, wie in 
klassischem C.

Also: Schau Dir C an, schau Dir ASM an. Nimm das, was dir eher liegt.
Bei mir war es anfangs ASM (auf dem 6502 und Z80, danach 8051). Erst auf 
dem PC bin ich dann an C gekommen und benutzt es mittlerweise auch für 
uP.

Autor: Johnny Voltage (mrwhite)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Reinhard Kern schrieb:
>> komisch dass fast alle real existierenden Systeme von der Waschmaschine
>> bis zum PC in C UND ASM programmiert sind
>
> Das erstaunt mich aber sehr.
> Ich wüßte keinen Grund, warum man eine Waschmaschine gemischt
> programmieren sollte.

Ich auch nicht, hängt wohl vom verbauten Controller ab. Man sollte 
strikt gegen Assembler sein, wo er nicht aus Performance-Gründen 
unabdingbar ist. Grundsätzlich sollte alles so lesbar (und somit 
verständlich und wartbar) wie möglich sein, dafür gibt es Hochsprachen. 
Allerdings bringt C keine Vorteile, wenn man kryptische Abkürzungen oder 
Benennungen benutzt und die strukturellen Elemente der Sprache (im 
weitesten Sinne ist hier Divide & Conquer gemeint) verzichtet. Dann 
schon lieber sauberen Assembler.

> Auch auf dem PC kenne ich keine Applikation, die so programmiert ist.
> Und auf meiner Arbeit ist mir sowas auch nicht untergekommen.

Sieht man selten. Die Sources des Spiels Quake enthielten viel 
Inline-Assembler für die Grafikroutinen. Mit Kommentaren versehen wie 
("We don't know how it works, but it works").

Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP 
oder gar nen NOP-Slide mittels inline Assembler. Bei manchen 
Controllern/Compilern soll sich das sogar positiv auf den Stromverbrauch 
auswirken, weil die in einer Idle-Loop sonst ganz andere Dinge tun.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny Voltage schrieb:
> Sieht man selten. Die Sources des Spiels Quake enthielten viel
> Inline-Assembler für die Grafikroutinen. Mit Kommentaren versehen wie
> ("We don't know how it works, but it works").

Das war vor 15 Jahren. Heutzutage arbeiten vielleicht die Entwickler von 
speziellen Bibliotheken (z.B. zur Physiksimulation) noch mit Assembler, 
aber die Spieleentwickler garantiert nicht mehr. Wenn man heutzutage 
Performance gewinnen will, dann investiert man die Arbeit lieber in 
Vektorisierung und Parallelisierung von Berechnungen, statt mit 
Assembler zu versuchen hier und da mal einen Takt zu sparen.

> Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP
> oder gar nen NOP-Slide mittels inline Assembler.

Wozu?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Platinenschwenker .. schrieb:
> @  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)
>
> Ich glaube  Peter Dannegger meinte nur man sollte nicht Assembler und C
> in einem Quelltext mischen, so wie das bei Inline-Assembler Anweisungen
> geschieht. Womöglich habt ihr da nur ein ein wenig aneinander vorbei
> geredet.

Haben wir keineswegs: meine Meinung ist nach wie vor, dass man 
mathematische Berechnungen besser in C schreibt, Hardwarezugriffe wie 
das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler 
(wird oft HAL genannt, aber das führt jetzt zu weit). Peter hat das für 
totalen Mist erklärt (angeblich vereint das die Nachteile beider 
Methoden). Und das mit der Autorität eines von hier seinen Jüngern 
verehrten Software-Gottes. Tut mir leid, da müsst ihr euer Abendmahl 
schon alleine feiern, I am not convinced. Mehr gibt es dazu auch nicht 
mehr zu sagen.

Von PC-Applikationen war ja sowieso nicht die Rede.

Gruss Reinhard

Autor: Platinenschwenker .. (platinenschwenker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern

Ich hatte das halt so herausgelesen ihn aber da wohl doch falsch 
interpretiert. Macht aber nichts. ;)

Autor: Johnny Voltage (mrwhite)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
>> Ich schreibe in meinen Quelltext in Idle-Loops gerne explizit ein NOP
>
>> oder gar nen NOP-Slide mittels inline Assembler.
>
>
>
> Wozu?

1.) Ich bin gerne sehr explizit. Hast du schonmal aus Versehen einen 
Strichpunkt hinter einem Schleifenkopf vergessen und dann stundenlang 
nach dem Bug gesucht? Auch die Intention ist dann gleich klar aus dem 
Quelltext ersichtlich. Guter Code dokumentiert sich selbst.

2.) Ich hatte mal (evtl. falsch) gehört, dass sich das positiv auf den 
Stromverbrauch auswirkt. Nach weiterer Recherche habe ich jedoch jetzt 
nur herausgefunden, dass es sich, zumindest beim x86, um den HLT und 
nicht um den NOP Befehl handelt. Bei Win95 / 98 lief der Prozessor in 
der Idle-Loop nämlich ständig unter Vollast. Könnte mir allerdings schon 
vorstellen, dass der NOP Befehl energetisch günstiger ist.

Reinhard Kern schrieb:
> Hardwarezugriffe wie
>
> ... das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler
>
> (wird oft HAL genannt, aber das führt jetzt zu weit).

Welchen Grund gibt es, das zu tun? Für die Wartbarkeit ist es Gift, 
verschiedene Codes in den gleichen Dateien zu mischen.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> meine Meinung ist nach wie vor, dass man mathematische Berechnungen
> besser in C schreibt,

Klar, dieser Meinung bin ich auch.

> Hardwarezugriffe wie das Auslesen eines empfangenen Bytes aus einem
> UART dagegen in Assembler

Wieso denn das? Das geht doch in C mindestens genauso gut. Da schreibe
ich (für einen AVR) einfach
  byte = UDR;
In Inline-Assembler würde die gleiche Anweisung etwa so aussehen:
  __asm("in %0,%1" : "=r" (byte) : "I"  (_SFR_IO_ADDR(UDR)));
Noch etwas aufwendiger wird es, wenn man dafür eine Assemblerfunktion in
einer eigenen Quelldatei schreibt.

Nicht dass ich das Mischen von C und Assembler verdammen würde, aber die
Fälle, wo dies sinnvoll ist, sind meiner Meinung nach recht rar gesät.
Man sollte sich auf jeden Fall alle drei Möglichkeiten offen halten:

- reines C:                 für fast alles

- C und Assembler gemischt: für einige wenige zeitkritische Anwendungen

- reiner Assembler:         falls C vom µC nicht unterstützt wird oder
                            Programmspeicherverbrauch ein entscheidendes
                            Kriterium ist

Für reine Hobbyanwendungen wählt man natürlich immer diejenige der drei
Alternativen, die am meisten Spaß macht :)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny Voltage schrieb:
> 1.) Ich bin gerne sehr explizit. Hast du schonmal aus Versehen einen
> Strichpunkt hinter einem Schleifenkopf vergessen und dann stundenlang
> nach dem Bug gesucht? Auch die Intention ist dann gleich klar aus dem
> Quelltext ersichtlich. Guter Code dokumentiert sich selbst.

Würde diesen Zweck ein {} nicht besser als ein __asm("nop") erfüllen?

> Nach weiterer Recherche habe ich jedoch jetzt nur herausgefunden, dass
> es sich, zumindest beim x86, um den HLT und nicht um den NOP Befehl
> handelt.

Ja, der HLT-Befehl hält den Prozessor tatsächlich an (ähnlich dem
Idle-Modus bei Mikrocontrollern). Mit einem NOP spart man vielleicht
deswegen etwas Strom, weil dabei die ALU nicht aktiv wird, aber das
dürfte fast vernachlässigbar sein.

Bei längeren Idle-Loops wird man sowieso überlegen, ob man nicht besser
den Controller schlafen legt und durch einen Interrupt wecken lässt. Das
spart dann tatsächlich Strom.

Autor: Johnny Voltage (mrwhite)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Ja, der HLT-Befehl hält den Prozessor tatsächlich an (ähnlich dem
>
> Idle-Modus bei Mikrocontrollern). Mit einem NOP spart man vielleicht
>
> deswegen etwas Strom, weil dabei die ALU nicht aktiv wird, aber das
>
> dürfte fast vernachlässigbar sein.

Und ob der NOP energetisch günstiger ist, er gilt sogar als Referenzmaß 
für die verwendete Energie bei Instruktionen (basierend auf MSP430):

http://www.eecs.harvard.edu/emnets/papers/laneEmnets06.pdf

Da gehts um Low-Power Compilation!

Yalu X. schrieb:
> Bei längeren Idle-Loops wird man sowieso überlegen, ob man nicht besser
>
> den Controller schlafen legt und durch einen Interrupt wecken lässt. Das
>
> spart dann tatsächlich Strom.

Das ist natürlich wahr!

Yalu X. schrieb:
> Würde diesen Zweck ein {} nicht besser als ein __asm("nop") erfüllen?

Ich finde die explizite Version besser als die implizite. Dann gibt es 
an der Intention keinen Zweifel.

Autor: Eddy Current (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe da folgende Entscheidungskriterien:

Performance
-------------------------
Hinreichend diskutiert. Die Teile einer Anwendung, die eine hohe 
Performance benötigen, bzw. CPU-Zeit sparen müssen, werden in Assembler 
programmiert. Damit meine ich auch Mischen von Assembler und C.

Stückzahl/Kostendruck
-------------------------
Die Programmierung von Routinen in Assembler erlaubt möglicherweise den 
Einsatz eines kleineren Controllers. Das rentiert sich natürlich nur bei 
entsprechender Stückzahl. Beispiele wären z.B. Software-UARTs ("Hilfe, 
ich brauche 8 UARTs!") oder Tonerzeugung ("Hilfe! Ich brauch noch nen 4. 
Timer!), Signalverarbeitung ("33 Bit mit AVR").

Komplexität
-------------------------
Ab einer bestimmten Größe einer Firmware verbietet sich der Einsatz von 
Assembler von alleine, jetzt mal von ein paar Profis abgesehen, die ihre 
ultimative Makrosammlung einfach nicht im Stich lassen können ("Meine 
Makros erlauben Programmierung quasi in Hochsprache!").

Eine Pauschalisierung ist wie immer generell nicht möglich ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Peter hat das für
> totalen Mist erklärt (angeblich vereint das die Nachteile beider
> Methoden).

Ist es auch für einen Anfänger.
Wenn man Assembler und C mixen will, muß man schon fundierte Kenntnisse 
über die Internas des verwendeten Compilers haben und das haben Anfänger 
nunmal nicht. Und deshalb fallen sie dabei regelmäßig auf die Nase. Is 
so.

Hat man aber ne Weile in C programmiert, merkt man schnell, daß man auch 
(nahezu fast) alles in C machen kann ohne Nachteile.

Wenn die Compilerbauer Lib-Funktionen in Assembler schreiben, ist das 
was anderes, die haben ja Ahnung davon.


> Und das mit der Autorität eines von hier seinen Jüngern
> verehrten Software-Gottes.

Das ist Quatsch mit Soße.
Ich halte doch nicht deshalb mit meiner Meinung hinterm Berg, nur weil 
sie jemandem nicht passen könnte. Wenn Du mich für einen Gott hältst, 
ist das allein Dein Bier.
Ich habe das gleiche Recht, meine Meinung zu posten, wie jeder andere.


Peter

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eddy Current schrieb:
> Ich sehe da folgende Entscheidungskriterien:

Eines kommt noch hinzu: Es gibt Konzepte, die in C nicht wirklich gut 
abgebildet werden können.
Beispiel: unterschiedliche Memory Spaces, z.B. X, Y und P Space beim 
DSP56k, wo es wichtig war, die Daten passend auf X und Y Memory zu 
verteilen. Ansatzweise sieht man das beim AVR beim Zugriff auf den 
Program Space.

Bei neueren Prozessoren wird sehr darauf geachtet, dass es ein C 
Compiler leicht mit ihnen hat, aber wer noch eine Architektur aus den 
70'ern verwendet (PIC16 z.B.), der wird eher geneigt sein, das C 
wegzulassen.

fchk

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny Voltage schrieb:
> Und ob der NOP energetisch günstiger ist, er gilt sogar als Referenzmaß
> für die verwendete Energie bei Instruktionen (basierend auf MSP430):

Aber groß ist der Unterschied ja trotzdem nicht. Der verschwenderischste
unter den 1-Zyklus-Befehlen ist nach dem verlinkten Artikel der BIS-Be-
fehl, der 12% mehr Energie als ein NOP braucht. Der in Abfrageschleifen
üblicherweise anzutreffende BIT-Befehl braucht nur 6% mehr als der NOP.
Dieser Geweinn relativiert sich u.a. dadurch, dass ohne den zusätzlichen
NOP in der Schleife diese bei Eintreffen des erwarteten Ereignisses im
Mittel einen halben Taktzyklus früher verlassen werden kann, was der CPU
etwas mehr Zeit für sinnvollere Dinge als Däumchendrehen verschafft.

Und wenn die durch den NOP in der Schleife verschlechterte Reaktionszeit
nicht stört, kann man evtl. auch gleich die Taktfrequenz des Controllers
etwas herunterzusetzen, was mehr Energie spart als der NOP.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ASM-Grundkenntnisse sind auf einem Mikroprozessor Pflicht, finde ich.

Nicht, weil das so toll ist, zehntausend Zeilen ASM zu tippen, sondern 
weil man nur dadurch versteht, warum manche C-Konstrukte ungünstig sind 
(z.B. Schieben auf dem AVR), wozu manchmal ein scheinbar überflüssigs 
'volatile' vonnöten ist und so weiter.

Auch, um mal ein Listing zu untersuchen, wenn plötzlich der 
Programmspeicher überläuft.

Autor: Alfons Möller (alfonsmoeller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin schon sehr über die Tonart hier verwundert.
Wir sind alle erwachsene Leute. Ich bin kein Moderator oder
sonstiges außer Gast in diesem Forum. Dennoch möchte ich mich
vor allem bei Peter Dannegger bedanken. Ich habe hier seinen
Namen gefunden. Den Code über das Herausfinden einer ID. eines
1.Drahtsensors habe ich irgendwann mal, wo weiß ich nicht mehr 
heruntergeladen. Ich habe das Teil auf mehr als 16 Meßstellen
erweitern können. Vielen Dank an Peter!!
Trotzdem, jeder hat eine andere Ansicht und das ist auch gut so!
Wenn ich aber die 1. Frage richtig gelesen habe ging es um ASM oder
C. Ich bin für das Verständnis eines Mikrokontrollers für ASM. Wenn es
um Portabilität geht aber eher für C. Aber Vorsicht ich bin schon seit
der Mondlandung Basic geschädigt.
Alfons.

Autor: Unbeteiligter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Haben wir keineswegs: meine Meinung ist nach wie vor, dass man
> mathematische Berechnungen besser in C schreibt, Hardwarezugriffe wie
> das Auslesen eines empfangenen Bytes aus einem UART dagegen in Assembler

Wenn du wirklich für das Lesen der Bytes aus dem UART Assembler benutzt, 
dann geht das sicherlich, das ist nicht die Frage. Aber warum sollte ich 
dafür Assembler für einsetzten?
Sorry, aber solch ein Quatsch ist mir noch nicht unter gekommen. Da hat 
Assembler nichts zu suchen. Bitte nenne mir einen wirlich vernünftigen 
Grund dafür.

> (wird oft HAL genannt,

Ich kenne bisher keinen HAL, der in Assembler geschrieben ist.
Mit Ausnahme der Interruptbehandlung oder der Taskwechsel bei
einem OS. Und ein paar Embedded OS hab ich schon gesehen. Von 8-Bit
bis 32-Bit. Überall war nur soviel in Assembler, wie notwendig.

Und einen Cortex-M3 bekommt man sogar gänzlich ohne Assembler zu
laufen. Ich meine den Startup-Code. Man braucht im Prinzip keine
Zeile Assembler dafür.

> totalen Mist erklärt (angeblich vereint das die Nachteile beider
> Methoden).

Hat er Recht. Assembler nur dort, wo es anders nicht geht. Entweder
aus Performancegründen (was recht selten ist) oder weil man sich
in 'C' manche Dinge einfach nicht erledigen kann.

> Und das mit der Autorität eines von hier seinen Jüngern
> verehrten Software-Gottes.

Da mußt du dich wohl jetzt an die eigene Nase fassen.

> Tut mir leid, da müsst ihr euer Abendmahl
> schon alleine feiern, I am not convinced.

Me too about you :-)

> Mehr gibt es dazu auch nicht mehr zu sagen.

Nee, stimmt. :-)

Alles auch ein wenig eine Philosophiefrage. Gelle? :-)

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://avr-asm-tutorial.net/avr_de/beginner/Warum.html

Generell würde ich Assembler immer lernen. So lernt man den Controller 
besser kennen. Und wenn man es mal braucht, und sei es nur für einen 
kleine Routine, dann kann man es.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Assembler und C mixen aber auf keinen Fall, damit erhält man nur die
> Summe der Nachteile von beiden und kaum Vorteile.

Gilt natürlich nicht, wenn man ein Betriebssystem entwickelt :-)

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin ein anhänger der these "für jede arbeit ein passendes 
werkzeug..."

sicher kann man z.b. versuchen, für einen garagenzubau den mörtel mit 
einer bohrmaschine, quirl und einzelnen zutaten zu rühren, aber mit 
einer mischmaschine und passender fertigmischung geht das ganze leichter 
und schneller.

genauso verhält es sich - meiner meinung nach - mit programmiersprachen:
in erlang z.b. kann man einen kompletten quicksort (schön lesbar) in 
zwei zeilen schreiben - in C braucht man schon eine weile länger.

ich sehe jedenfalls keinen grund, "spezielle" funktionalitäten als 
assembler-funktionen - in einer eigenen datei gekapselt - zu 
implementieren (auch wenn mir im moment nichts einfällt...)

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel F. schrieb:
> ich bin ein anhänger der these "für jede arbeit ein passendes
> werkzeug..."

Sehr löblich. Dann besorg Dir doch mal das passende Werkzeug zum tippen. 
Auf Deiner Tastatur ist ja offensichtlich die Shift-Taste defekt.

Autor: Troll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha H. schrieb:
> Sehr löblich. Dann besorg Dir doch mal das passende Werkzeug zum tippen.
> Auf Deiner Tastatur ist ja offensichtlich die Shift-Taste defekt.

Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles 
Argument vorbringen, aber über einen Beitrag herziehen, weil da Groß- 
und Kleinschreibung nicht beachtet wurde... Wenn da interpunktion und 
Absätze fehlen würden, könnt ich's ja verstehen, aber auf so einem 
niederen Niveau hier zu posten ist eigentlich meine Aufgabe...

Autor: IchLiebeAssembler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, ich liebe Assembler und werde einen 8-Bitter nicht wieder mit C 
veralbern. Für die Übersichtlichkeit eines Programms ist der 
Programmierer verantwortlich - nicht die Sprache !!!
Einen 8-Bit uC mit C programmieren, ist wie Basic auf dem PC.
Und übrigens ist C schon seit 15 Jahren tot. Da hilft es auch nicht 
weiter, wenn einige Leute nicht loslassen können und sich nicht 
weiterentwickeln.
Für 32-Bit uC muss mann sich leider meist noch C behelfen :-(

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IchLiebeAssembler schrieb:
> Und übrigens ist C schon seit 15 Jahren tot.

Was ist denn grade so angesagt?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IchLiebeAssembler schrieb:
> Für die Übersichtlichkeit eines Programms ist der Programmierer
> verantwortlich - nicht die Sprache !!!

Warum programmierst du dann nicht gleich mit Binärcodes? Wenn du sie
schön anordnest, versteht sicher jeder das Programm ;-)

> Einen 8-Bit uC mit C programmieren, ist wie Basic auf dem PC.

Diesen Vergleich habe ich jetzt überhaupt nicht verstanden.

> Und übrigens ist C schon seit 15 Jahren tot.

Da muss ich die Beerdigung verpasst haben, stand da was in der Zeitung?

> Für 32-Bit uC muss mann sich leider meist noch C behelfen :-(

Wieso? Gibt es denn keine 32-Bit-Assembler?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, wenn man sich mal gut unterhalten möchte stellt man hier einfach 
die
Frage nach C oder Assembler.

Warum gibt es immer wieder Leute, die bereit sind darüber kleinliche 
Diskussionen zu führen?

Man hat doch nicht die Weißheit gepachtet, nur weil man gut in C oder 
Assembler programmieren kann!
Und zu einem besseren Menschen wird man auch nicht, nur weil man in der 
"besseren" Sprache programmieren kann.

Tut mir leid, Aber solche Diskussionen sind einfach nur jedesmal wieder 
aufs neue peinlich.
Jeder von Euch ist gut in dem was er kann. Es gibt keine Gründe, 
jemanden schlecht zu machen, der in einer anderen Sprache gut 
programmieren kann.

Mit vielen Grüßen, Tom.

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom schrieb:
> Tut mir leid, Aber solche Diskussionen sind einfach nur jedesmal wieder
> aufs neue peinlich.

Jaja... immer diese Kindergartenkinder ;))

Ein kleiner Tropfen meiner Meinung:
1. Ich denke C ist ein guter Kompromiss zwischen Performance und 
Lesbarkeit,
2. Ich liebe diese z.T. kryptische Syntax: i -= z++;
3. und den Leuten, die Assembler beherrschen, gebührt mein Respekt!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir (4 Leute) arbeiten zur Zeit an nem ATmega2560. Der eine macht die 
Peripherie, einer das Ethernet, einer das Userinterface und einer die 
Regelung.
Und das klappt erstaunlich gut.
In Assembler stelle ich mir das als ein Ding der Unmöglichkeit vor.


Peter

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fragt mal Dave Jones ;)

Die Sache ist eben ob es einen C-Compiler gibt, bzw einen freien wenn 
man darauf besteht. Letzteres ist bei AVR und ARM mit gcc gegeben, fuer 
8051 taugt SDCC inzwischen gut, bei PIC wird die Sache haarig (gibt 
SDCC-Support aber der scheint noch nicht sehr reif zu sein).

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Meinung dazu:

Immer C, sofern Assembler nicht zwingend notwendig wird (besonders 
zeitkritische Teile). Ansonsten hilft Assembler natürlich ungemein beim 
Verständnis dessen, was in einem Controller so passiert.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
faustian schrieb:
> Die Sache ist eben ob es einen C-Compiler gibt,

Also ich kenne keinen Controller, für den es keinen C-Compiler gibt. Wer 
auf Nummer sicher gehen will lernt C und Assembler.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber ASM ist wirklich so gut wie tot.

Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den 
kompletten Quellcode mit.
Ich habe nirgends, außerm in der Startup-Routine des Prozessors 
irgendwelchen ASM Code gesehen.

Ein guter Compiler erzeugt heute fast immer gleich guten, wenn nicht 
besseren code als ein ASM programmierer ( es muss jemand schon sehr gut 
in ASM sein um das zu toppen).
Ich habe neulich mit einem Freund der wirklich ein extrem guter 
Programmierer (auch ASM, er hat die ersten Soft DVD Dekoder auf dem 
Markt entwickelt) mal getested, was z.B. bei MMX-Programmierung mit 
Handoptimierung rauszuholen ist und wir haben festgestellt, dass der 
Code des Compiler fast nicht  zu verbessern war.

Dazu kommt, dass ein 8-Bitter mit ein paar Registern noch gut zu 
überschauen ist. Sobald aber ein Prozessor einen Cache und eine 
mehrstufige Pipeline mit Branch prediction besitzt, ist der Complier 
fast immer im Vorteil, da er über größere Codeabschnitte optimieren 
kann.

Was die Codegröße angeht, würde ich auch gern mal einen Vergleich 
zwischen C und gutem ASM code sehen wenn man den Compiler auf Größe 
optimieren läßt.

ASM ist für jeden Prozessor irgendwie anders, d.h. man muss immer neu 
lernen bzw. umschalten wenn man mit mehr als einer Prozessorfamilie 
arbeitet.

Auch die Frage nach C++ oder C ist in hinsicht Performance längst 
geklärt, C++ ist genauso schnell als C. Nur in den Anfangszeiten als C++ 
als Präprozessor realsiert war, war C++ langsamer und der Code viel 
Größer.

Die Argumente Übersichtlichkeit wurde schon erwähnt. Wichtiger ist aber 
noch die Wartbarkeit. Sich in ASM Code von jemandem anderen 
einzuarbeiten und zu verstehen was der Urheber erreichen will ist 
ausgesprochen mühsam.

Was natürlich nicht schadet, wenn man ASM LESEN kann, damit man im 
Debugger auch mal überwachen kann was denn Dein code gerade macht.


Wer heute noch in ASM arbeitet macht das entweder weil er dass schon 
seit 20 Jahren macht (das haben wir immer so gemacht) oder weil er es 
halt cool findet ASM zu beherrschen (oder zumindest das glaubt)

Gruß
Tom

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Sorry, aber ASM ist wirklich so gut wie tot.
>
> Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den
> kompletten Quellcode mit.

Wir reden doch hier von 8 Bit Mikrocontrollern, nicht von 32 Bittern 
oder PCs. Und tot wird ASM nie sein, weil das die einzige Sprache ist, 
die ein Controller versteht.

Und an den allmächtigen Compiler, der idealen Code generiert, glaube ich 
nicht. Wenn es wirklich an's Eingemachte geht kommt man mit einem 
Compiler nicht weit. Mit einem Servo Controller bin ich da an die 
Grenzen gestoßen. Ging nur mit ASM weiter.

Und einen Tiny13 würde ich auch nicht in C programmieren

Autor: Michael Roek (mexman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, das ist ja wieder ein prima Glaubenskrieg geworden.... ;-)

Nur um den lieben "Staubsaugervertreter" auch noch meine Meinung wissen 
zu lassen:

Ich mache alles in ASM. Warum?
.... weil ich das(s) schon seit 20 Jahren mache oder weil ich es
halt cool finde ASM zu beherrschen .....

;-)

Es kommt natuerlich immer auf das System an.
Natuerlich schreibt keine PC Software in Assembler.
(Aber einen Dongle zum umgehen wird ohne ASM Kenntnisse nicht gelingen 
;-)

Aber gerade die ARMs oder PICs sind recht Speicherkritisch und vor allem 
Peripheriekritisch. Da muss ich genau wissen, welches uC-Beinchen gerade 
wir steht und das ist bei jedem Chip auch noch anders.

Das Argument der Mathematik lass ich nicht gelten, denn wenn man 
wirklich das schon "seit 20 Jahren macht", hat man alle notwendigen 
Routinen schon bereitliegen (Wurzeln ziehen, Multiplizieren, 
PID-Regler.....) und bindet sie ein einen - natuerlich relokierbaren - 
Code schnell ein.

Also hoer nicht auf uns alle, es gibt kein Knigge fuer die Wahl der 
Programmiersprache. Schau was Dir besser liegt.



Gruss

Michael

Autor: StaubsaugerVerdreher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herzlichen Glückwunsch, Staubsaugervertreter, Du hast es wieder einmal 
geschafft den alljährlichen C – ASM Thread zu eröffnen. Und natürlich 
gibt es wie immer die komischsten Kommentare...
Übrigens, ich habe auch eine Meinung dazu...

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Troll schrieb:
> Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles
> Argument vorbringen,

Sinnvolle Argumente beim xx. "was ist besser"-Thread, soso. Bereits mit 
der 3. Antwort waren alle objektiven Argumente genannt, an subjektivem 
"mir gefällts aber so besser" oder "me too"-Getröte beteilige ich mich 
nicht. Und - Überraschung - an der Diskussion war und bin ich durchaus 
beteiligt, ich habe nämlich einen Beitrag als Antwort auf einen anderen 
Beitrag geschrieben.

> aber über einen Beitrag herziehen, weil da Groß-
> und Kleinschreibung nicht beachtet wurde...

Du hast nicht verstanden. Oder nicht gelesen. Oder beides.
Also nochmal zum mitschreiben: Zur Kommunikation benötigt man Sprache. 
In unserem Kulturkreis wird selbige aus Groß- und Kleinbuchstaben 
zusammengesetzt. Am PC ist das passende Werkzeug dazu die Tastatur; auf 
der linken Seite davon findet man die Taste um Groß/Klein auszuwählen. 
Und - Achtung, jetzt kommts - D.F. wollte "für jede arbeit ein passendes
werkzeug...", tat's aber dann doch nicht. Paradoxon, ick hör dir 
trapsen.
Du kannst ja mal spasseshalber versuchen beim C-Programmieren oder auch 
nur so auf einem unixoiden System ohne Großbuchstaben auszukommen.

> auf so einem
> niederen Niveau hier zu posten ist eigentlich meine Aufgabe...

Was meinst Du mit "eigentlich"? Du hast doch Deinem Nick alle Ehre 
getan!?

Autor: TrollTroll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[offtopic]
Troll schrieb:
> Herrje... Nicht an der Diskussion beteiligt sein, kein Sinnvolles
> Argument vorbringen, aber über einen Beitrag herziehen, weil da Groß-
> und Kleinschreibung nicht beachtet wurde... Wenn da interpunktion und
> Absätze fehlen würden, könnt ich's ja verstehen, aber auf so einem
> niederen Niveau hier zu posten ist eigentlich meine Aufgabe...

Die Spinnen
Die spinnen

Warum sind füllige Frauen gut zu Vögeln?
Warum sind füllige Frauen gut zu vögeln?

Er hat liebe Genossen.
Er hat Liebe genossen.

Wäre er doch nur Dichter!
Wäre er doch nur dichter!

Sich brüsten und anderem zuwenden.
Sich Brüsten und anderem zuwenden.

Die nackte Sucht zu quälen.
Die Nackte sucht zu quälen.

Sie konnte geschickt Blasen und Glieder behandeln.
Sie konnte geschickt blasen und Glieder behandeln.

Der gefangene Floh.
Der Gefangene floh.

Helft den armen Vögeln.
Helft den Armen vögeln.

Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und
Kleinschreibung wäre nicht wichtig...
[/offtopic]

StaubsaugerVerdreher schrieb:
> Herzlichen Glückwunsch, Staubsaugervertreter, Du hast es wieder einmal
> geschafft den alljährlichen C – ASM Thread zu eröffnen. Und natürlich
> gibt es wie immer die komischsten Kommentare...
> Übrigens, ich habe auch eine Meinung dazu...

Ist mindestens schon der zweite in diesem Jahr.
Beitrag "welche Programmiersprache?"

: Wiederhergestellt durch Admin
Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TrollTroll schrieb:
> Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und
> Kleinschreibung wäre nicht wichtig...

YMMD :D

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TrollTroll schrieb:
> Und da soll es doch tatsächlich Menschen geben, die sagen, die Groß und
> Kleinschreibung wäre nicht wichtig...

Sehr amüsant, aber trotzdem ein schlechtes Argument. Bei gesprochener 
Sprache funktioniert es ja auch ohne Groß- und Kleinsprechung.

Interessant fand ich in dem Zusammenhang die Studie in den Niederlanden, 
die festgestellt hat, dass auch für niederländische Muttersprachler 
niederländische Texte schneller lesbar waren, wenn darin die deutschen 
Regeln für Groß-/Kleinschreibung angewendet wurden (nach 
niederländischen Regeln werden nur Satzanfänge und Eigennamen 
großgeschrieben). Siehe 
http://www.uni-koeln.de/ew-fak/Deutsch/projekte/ko... ab 
Seite 45.

Andreas

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ist ja ein wunderbarer Glaubenskrieg und ehrlich, ich staune da nicht 
schlecht. Zur Erinnerung der Eröffnungsthread:

Unkown User schrieb:
> hi.
>
>
>
> In was sollte man kleinere, einfachere Sachen besser programmieren?
>
> Also einfache Sachen die man problemlos auch mit nem TTL Grab und OP's
>
> machen könnte und die nur aus Bequemlichkeit und wegen geringerem
>
> Bauteileaufwand mit einem uC gemacht werden.
>
>
>
> C oder ASM? Oder beides, also C mit viel Inline-Assembler?
>
>
>
> Mit was progrmmiert ihr sowas?

Ich programmiere sowas in Assembler, weil ich C (noch) nicht kann. Mit 
BASIC sieht's nicht anders aus. Letztlich ist's egal, in welcher Sprache 
programmiert wird, auf's Ergebnis kommt's an. Wenn ich C könnte würd ich 
auch nicht extra Assembler lernen, bloß weil's halt chic ist. Oder 
professionell, oder ... egal. Auch steht vielleicht auch eine 
Anforderung dahinter: klar, ich kann einem Kunden kein Assemblerprogramm 
liefern, wenn er C verlangt und ich michdrauf eingelassen habe. Aber 
solange im Hobbybereich die Pflichtenhefte selbst geschrieben werden, 
ist das eigene Können der Maßstab und nicht die Meinung, das irgendwas 
"tot " ist. Grundlagen sind heutzutage nach wie vor wichtig. Kein Mensch 
käme auf die Idee, die Mathematik als "Tot" zu bezeichnen, bloß weil es 
ja Taschenrechner gibt.
Gruß oldmax

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Sorry, aber ASM ist wirklich so gut wie tot.
>
> Ich habe vor einiger Zeit Win CE Kernels gebaut und MS liefert da den
> kompletten Quellcode mit.
> Ich habe nirgends, außerm in der Startup-Routine des Prozessors
> irgendwelchen ASM Code gesehen.

Das bezweifle ich insofern, als dass irgendwo im Code des 
Betriebssystems sicherlich die Test-and-Set Instruktion oder ihr 
Äquivalent verwendet wird, um zum Beispiel Semaphoren zu implementieren. 
Wie war das doch gleich, TAS bei Motorola, XCHG bei Intel...

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark: Sicher wird es den geben, aber wieviel % des OS ist dass dann? 
Alle Treiber jedenfalls waren pures C

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, ist nur ein kleiner Teil.

Autor: Bernd Dohl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:
> Bei gesprochener
> Sprache funktioniert es ja auch ohne Groß- und Kleinsprechung.

Natürlich gibts Groß- und Kleinschreibung auch bei gesprochener Sprache.
Mann nennt sie dort nur anders, nämlich "Betonung".

Autor: A. B. (funky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bis auf den post von TrollTroll kann man diesen Thread doch nun mal 
getrost löschen :)

Autor: Alter Sack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> bis auf den post von TrollTroll kann man diesen Thread doch nun mal
> getrost löschen :)

Jaaaa, und meinen bitte auch lassen ;-)

Staubsaugervertreter, Assembler ist nichts für Skriptkiddies, nur etwas 
für gestandene Männer, die noch ihren Code selbst schreiben können.
Das lernt man aber nicht über Nacht - viele C-Spezialisten lernen es 
nie, wie man in den Hilferufen hier im Forum merkt. Ein richtiger 
Assembler-Programmierer schreit nie nach Hilfe, er schaut ins 
Datenblatt.

Und welcher C-Code ist noch nach 5 Jahren brauchbar? Mal ganz davon 
abgesehen, dass der aktuelle Compiler damit nichts mehr anfangen kann.
Das mag für den Consumer-Markt noch angehen, aber wer im privaten 
Bereich nach 5..10 Jahre an einem Projekt etwas änder will, kann sich 
solchen Sch... nicht leisten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alter Sack schrieb:
> Und welcher C-Code ist noch nach 5 Jahren brauchbar?

Ich hab mal in ein älteres Projekt geschaut:
Die älteste Datei ist vom 23.10.1995.
Die letzte Änderung erfolgte am 3.7.2009.

C-Code ist also sehr wohl über viele Jahre wartbar (bisher haben schon 3 
Personen nacheinander daran gewerkelt).

Die Hardware hat sich zwischenzeitlich sogar geändert. Zu Anfang ware es 
ein 8031 mit externem EPROM, SRAM. Jetzt ist es ein 8051 mit internem 
Flash, SRAM und Bootloader.


Peter

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alter Sack schrieb:
> Und welcher C-Code ist noch nach 5 Jahren brauchbar?

Wie jeder erfahrene Programmierer weiß, hat Code allgemein immer nur 
eine sehr kurze Lebensdauer. Deswegen gab es ja auch nie ein Jahr 2000 
Problem :-)

In meinem aktuellen Projekt sind die ältesten C-Files über 10 Jahre alt. 
Und wie man sieht kommen heute noch Änderungen hinzu, und womöglich auch 
in zehn Jahren von heute an noch.

Autor: Kasperle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In 10 Jahren bin ich 70.
Da ändere ich an keinem Code mehr etwas.
Aber, weitermachen, der Fred liest sich sehr gut beim Frühstück.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Alter Sack schrieb:
>> Und welcher C-Code ist noch nach 5 Jahren brauchbar?
>
> Wie jeder erfahrene Programmierer weiß, hat Code allgemein immer nur
> eine sehr kurze Lebensdauer. Deswegen gab es ja auch nie ein Jahr 2000
> Problem :-)
>
> In meinem aktuellen Projekt sind die ältesten C-Files über 10 Jahre alt.
> Und wie man sieht kommen heute noch Änderungen hinzu, und womöglich auch
> in zehn Jahren von heute an noch.

Ich biete 20 Jahre für "meine" Anwendung; allerdings brauche ich sie 
schon lange nicht mehr "am Tropf halten" und die verschiedensten OS- und 
Hardware-Wechsel "niederkämpfen" - von Compilerwechseln ganz zu 
schwerigen.

So, das war mein "Frühstücksei".
Bernhard

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alter Sack schrieb:
> Assembler ist nichts für Skriptkiddies, nur etwas
> für gestandene Männer, die noch ihren Code selbst schreiben können.

Und so einer (und Chuck Norris) isst auch keinen Honig, der kaut 
Bienen...

IM Privatbereich darf doch jeder machen, was er will. Die einen lernen 
Telefonbücher auswendig, andere sammeln Kronkorken, und manche 
programieren halt Assembler.

Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns' 
denn Spaß macht, so what?

Oliver

Autor: Alles neu macht der Juli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> C-Code ist also sehr wohl über viele Jahre wartbar (bisher haben schon 3
> Personen nacheinander daran gewerkelt).

In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht 
bei neuer Hardware mit neuen Möglichkeiten. Alter Code ist doch meist 
nur zum Reinschauen und Kopfschütteln.

Alter Sack, Du bist wohl wie Linus Torvalds, der schreibt auch seine 
langsamen Gerätetreiber selbst (als echter Mann). Dies allerdings mehr 
in Macros als in C.

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Oliver schrieb:
> Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns'
>
> denn Spaß macht, so what?
Das kann ich so nicht stehen lassen......
1. Man lernt was ( was auch immer)
2. Du sagst es selbst, es macht Spaß (kein sinnvoller Nutzen ?)
3. Es kurbelt die Wirtschaft an (Hersteller wollen auch leben....)
Wenn ich noch ein wenig nachdenen würde, ich käme auf reichlich 
sinnvolle Nutzen.
Was redet ihr hier eigentlich ? Ist euch noch klar, was die Startfrage 
war ? Kleinere , einfachere Sachen..... Nicht on  Betriebssystemen, 
Waschmaschinen oder gar eine Motorsteuerelektronik ist hier die Rede. 
Die Antwort ist lediglich, das was du schon kannst oder bereit bist zu 
lernen. Es ist fraglich, ob bei Null-Start C schneller begriffen wird, 
als ein Assembler. Und wenn bereits vorbelastet, dann ist Assembler auch 
kein Problem.
Gruß oldmax

Autor: Martin Vogel (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
so jetzt hoffentlich fehlerfrei, man ist mir das peinlich.....
Oliver schrieb:
> Das alles hat keinerlei sinvollen Nutzen, ist aber Hobby, und wenns'
>
> denn Spaß macht, so what?
Das kann ich so nicht stehen lassen......
1. Man lernt was ( was auch immer)
2. Du sagst es selbst, es macht Spaß (kein sinnvoller Nutzen ?)
3. Es kurbelt die Wirtschaft an (Hersteller wollen auch leben....)
Wenn ich noch ein wenig nachdenken würde, ich käme auf reichlich
sinnvolle Nutzen.
Was redet ihr hier eigentlich ? Ist euch noch klar, was die Startfrage
war ? Kleinere , einfachere Sachen..... Nicht von  Betriebssystemen,
Waschmaschinen oder gar Motorsteuerelektronik ist hier die Rede.
Die Antwort ist lediglich: "das was du schon kannst oder bereit bist zu
lernen". Es ist fraglich, ob bei Null-Start C schneller begriffen wird,
als ein Assembler. Und wenn bereits vorbelastet, dann ist Assembler auch
kein Problem.
Gruß oldmax

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles neu macht der Juli schrieb:
> In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht
> bei neuer Hardware mit neuen Möglichkeiten.

Deine Kunden zahlen Dir alle paar Jahre die komplette Neuentwicklung der 
Software? Du Glücklicher, Du hast eine Gelddruckmaschine.
Viel Spass und langes Gelingen.

Ach ja, den Sarkasmus darfst Du auch gerne kostenlos behalten.

Da nich für,
Micha

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles neu macht der Juli schrieb:
> In diesem Fall hätte ich aber den Code schon lange erneuert, erst recht
> bei neuer Hardware mit neuen Möglichkeiten. Alter Code ist doch meist
> nur zum Reinschauen und Kopfschütteln.

Nein, ist er nicht.

Ich bin auch nicht der Original-Autor, sondern habe nur Erweiterungen 
hinzugefügt. Und das ging ganz gut.
Ich hab mir nur die Stellen angeschaut, wo ich die Änderungen machen 
mußte.

Eine komplette Erneuerung wäre viel zu aufwendig. Dann müßte man ja den 
ganzen Code analysieren.
Daher ist die neue Hardware auch kompatibel, nur eben weniger Chips und 
von außen updatebar.


Peter

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin moin,

mal als Anmerkung:

Ich baue ein med. Behandlungsgerät, so eine Art "Blutwaschmaschine". 
Diese wird von 2 MC Typ 80386 gesteuert und überwacht. Die beiden MCs 
arbeiten als Master-Slave und sind nach TÜV-Vorgaben in ASM 
programmiert. Nur so ist sichergestellt, das gleiche Funktionen auf 
unterschiedlichen Wegen zum (hoffendlich) selben Ergebnis kommen. Bei 
unterschiedlichen Ergebnissen stoppt das System.
Hochsprachen sind hier nicht brauchbar.

Mit Gruß
Pieter

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pieter schrieb:
> Die beiden MCs
> arbeiten als Master-Slave und sind nach TÜV-Vorgaben in ASM
> programmiert.

Na ob man damit glücklich wird...
Je komplexer die Software, um so weniger ist Assembler als einzige im 
Projekt zu verwendende Sprache sinnvoll. Ab einer gewissen Komplexität 
schießt man sich mit einer solchen Anforderung doch selbst in den Fuß 
(autsch), was Wartbarkeit und Erweiterbarkeit betrifft.

Außerdem will mir die Logik nicht so recht einleuchten, wonach bei einer 
Fahrzeugsteuerung Hochsprachen okay sind (da sterben bei einer 
Fehlfunktion womöglich etliche Leute auf einmal, in einem voll besetzten 
Zug vielleicht sogar ein paar Hundert) und bei einer Maschine, die 
maximal an einem Menschen gleichzeitig Schaden anrichtet, soll es dann 
nicht okay sein... das verstehe wer will? Okay, Zug fahren ist nicht das 
Gleiche wie Dialyse, aber trotzdem nicht so wirklich konsequent das 
Ganze.

Autor: A. B. (funky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist sicherlich der Regelfall, das der Otto-Normal Forumsteilnehmer 
seine zusammengebastelten Geräte durch den TÜV bringen muss. Also 
eindeutig pro Assembler ;)

Soll ja jeder machen wie er denkt, aber ich würde mir freiwillig kein 
Assembler antun.
Wer zu Hause am Code rumfuhrwerkt kann das ja machen wie er mag und wie 
er damit zurecht kommt...aber wer mit mehreren Leuten (2 reichen schon) 
an Software rumschraubt und dabei freiwillig auf Assembler zurückgreift 
muss masochistischer Veranlagt sein als ich es je sein werde.
Und wer sich schonmal durch alten C-Code anderer Menschen wühlen durfte 
kann mir nicht erzählen, dass er das lieber mit AssemblerQuellcode 
machen würde?!?!!?

Genauso wie ich es auch für sehr Zweifelhaft halte, dass ein
a = b + c;
schwerer zu durchschauen sein soll als ein Wust aus movs & adds usw.

Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird, 
liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen 
unterm Schreibtisch :)

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AlterSach schrieb:
> Und welcher C-Code ist noch nach 5 Jahren brauchbar?

Hmm, fast alle unter Linux verwendeten Programme ?
Die meisten stammen doch aus den 70gern.
Das beginnt schon mit VI, ohne den nix ediert werden kann.
In meinen kommerziellen Programmen sind auch Teile drin, die
ich selbst vor über 25 Jahren geschrieben habe. Man muss nicht
jedesmal alles neu entwickeln, wenn man vorher sinnvolles getan
hat, wenn man nicht so blöd ist, mittendrin die Sprache zu
wechseln (von Pascal nach C nach Java...).


PeDa schrieb:
> Die Hardware hat sich zwischenzeitlich sogar geändert.

Du lieferst gleich die Gegenargumente zu deiner eigenen Denkweise:
8031 und 8051 verwenden denselben Assemblercode, es hätte deinem
Code also mitnichten geschadet, gleich in Assembler fomuliert
worde zu sein.
Euer C ist mitnichten portabel, wenn es zuweisungen der Art
PORTC=0xFF
verwendet (und vieles andere)

Jedes C-Programm enthält Asseblerstücke, nämlich zumindet den 
Präambelcode-der main aufruft, und meist grosse Teile der 
Standardbibliothek. Es spielt dabei keine Rolle, ob er von dir selbst 
oder vom Hersteller geschrieben wurde, es zeigt sich nur, auf welche 
einfacheren Teile der Programmierung du dich beschränkst. Aber deine 
Auffassung, der C und Asselbler mischt wäre blöd, ist Humbug.
Wenn man ernsthaft programmiert, wird man Asselber benötigen, z.B. in 
Interruptfunktionen und ähnlich schnellem. Klar kann man versuchen, 
ineffizient compilierten C-Code einfach durch einen uC der 2 Nummern 
grösser ist zu beschleunigen, kosteneffektiv ist das aber nicht (und 
manchmal reicht's trotzdem nicht).
Dennoch bietet es sich nicht an, mehr als 1k Code in Asselber zu 
formulieren, da kriegt man ja sonst eine Krise. Vor allem beim Microchip 
PIC, aber da kriegen auch die Compiler eine Krise.

Pieter schrieb:
> 80386 ... in ASM

Ach du liebe Scheisse. Der 80386 ist nun einerseits steinalt, über 25 
Jahre, und andererseits kein uC. Sicher kann man ihn auch in Assembler 
programmieren, aber ab bestimmter Codegrösse geht da die Übersicht 
verloren, das ist also sicher unsicherer als in einer Hochsprache. 
Selbst im Flugzeugnavigationsumfeld darf man compilieren, man guckt halt 
hinterher in den erzeugten Assemblercode. Wartet also bloss, bis euch 
eine klügere Konkurrenzfirma mit viel geringeren 
Softwareerstellungskosten vom Markt fegt.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird,
> liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen
> unterm Schreibtisch :)

LOL :-)

¡Vamos a España!

Autor: Frederik Krämer (n0ll4k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Naja, während in Villa Bajo noch über ASM-Quellcodes gebrütet wird,
> liegt man in Villa Rriba nach getaner C-Programmierarbeit schon besoffen
> unterm Schreibtisch :)

YMMD !

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Euer C ist mitnichten portabel, wenn es zuweisungen der Art
> PORTC=0xFF
> verwendet (und vieles andere)

Keine Angst, enthält er nicht.
Ich hab ja schon in Assembler EQU benutzt und daher in C dann 
selbstverständlich #define. Magische Zahlen im Code sind mir ein Greuel.

Ein Umstieg von 8051 auf AVR wäre auch prinzipiell möglich gewesen und 
dabei den Großteil des Codes zu behalten.
Allerdings benutzt das 8051-Programm Interruptprioritäten und das wäre 
ein Problem geworden. Im Nachhinein gesehen, wäre mir auch der 
I2C-Multimaster-Bug der AVRs auf die Füße gefallen.
Nur nen moderneren 8051 zu nehmen, war daher auch eine 
Risiko-Minimierung.


Peter

Autor: A. B. (funky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Du lieferst gleich die Gegenargumente zu deiner eigenen Denkweise:
> 8031 und 8051 verwenden denselben Assemblercode, es hätte deinem
> Code also mitnichten geschadet, gleich in Assembler fomuliert
> worde zu sein.
> Euer C ist mitnichten portabel, wenn es zuweisungen der Art
> PORTC=0xFF
> verwendet (und vieles andere)

Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um 
einiges portabler ist als ASM?
Das die ASM Varianten zweier Mikrocontroller kompatibel sind ist ja nun 
nicht der Normalfall.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Aber deine
> Auffassung, der C und Asselbler mischt wäre blöd, ist Humbug.

Hör bitte endlich auf, Aussagen aus dem Kontext zu reißen.
Es ging darum, was man als Anfänger nicht machen sollte.

Der OP hat jedenfalls nicht den Eindruck erweckt, als wäre er mit den 
Compiler-Internas vertraut.

Die Frage Assembler und C zu mixen kommt in der Regel von Umsteigern von 
Assembler auf C und da kann es nur klar heißen: Finger weg!

Es sei denn Du bist gerne schadenfroh, wenn andere tagelang umsonst 
arbeiten.


Peter

Autor: Frank Bär (f-baer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Euer C ist mitnichten portabel, wenn es zuweisungen der Art
> PORTC=0xFF
> verwendet (und vieles andere)

Dass man in C aber auch keine Makros ändern kann... Teufelszeug.
Mit entsprechenden Anpassungen in den Makros ist C-Code 
architekturunabhängig. ASM funktioniert nur auf genau dem µC, für den 
der Code erstellt wurde. Nichtmal bei PICs ist es ohne Weiteres möglich, 
ASM-Code zu portieren, dabei wurde da sehr auf Kompatibilität geachtet.
Für einen ARM-Kern muss man lediglich seine Headerfiles anpassen und die 
Makros entsprechend ändern, neuen Startup-Code dazu und fertig ist der 
Umstieg von ARM7 auf Cortex.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "Java oder C++"
Um mich nicht ständig selber wiederholen zu müssen verweise ich mal auf 
meinen Text in "Java oder C++". Einfach nach Horst suchen, der 2. 
Treffer ist es dann. Wobei ich der Nr.1 auch nicht widersprechen kann.

Autor: StaubsaugerVerdreher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ook!
Würde ich dann auch empfehlen. Hat bestimmt Zukunft - da könnte man den 
Thread noch ewig verlängern...

Wo ist denn eigentlich der Staubsaugervertreter, er hat sich doch noch 
garnicht wieder gemeldet. Ist das dieser Kleine, der von der Seitenlinie 
immer mal wieder Öl ins Feuer gießt?

Autor: Andy -. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Wenn Du keine Zeitkritischen Sachen machen musst und einen neueren Chip 
mit einigermassen genug speicher verwendest so würde ich das in C 
machen.
C braucht etwas mehr einarbeitungs Zeit ist aber überschaubarer als ASM.

Beachte auch das Du Dich in C nicht um Mapping Probleme kümmern musst 
und keine Banken auswählen musst.

Gruss

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um
>einiges portabler ist als ASM?

Auf welchen anderen Controller ist die Initialisierung der z.B. Timer- 
oder ADC-Register eines AVRs portierbar? Oder auf welchen µCs hast du 
die gleichen Interrupts?

MfG Spess

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>Aber du wirst ja wohl nicht bestreiten wollen das C im allgemeinen um
>>einiges portabler ist als ASM?
>
> Auf welchen anderen Controller ist die Initialisierung der z.B. Timer-
> oder ADC-Register eines AVRs portierbar? Oder auf welchen µCs hast du
> die gleichen Interrupts?

Gut, diese Dinge sind klarerweise immer anzupassen.
Aber denk zb bei den AVR daran, dass manche Konfigurationsregister ihre 
Adresse verändert bekommen haben und dann nicht mehr mittels IN/OUT 
erreichbar sind. Ich geb zu, dass man das sicherlich mit Makros auch in 
Assembler portabel hinbekommt, aber damit machst du dann schon den 
ersten Schritt in Richtung 'Hochsprache'-C.

Assembler ist in meinen Augen dann nützlich, wenn man aus den 
Statusflags nutzen ziehen kann. AUch 12 Bit Arithmetik für 
Zwischenergebnisse für 8-Bit Rechnerei mit eingeschränktem Zahlenbereich 
ist nun mal so mit C nicht möglich.
Das das aber den Geschwindigkeitsboost bringt wage ich zu bezweifeln.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Auf welchen anderen Controller ist die Initialisierung der z.B. Timer-
> oder ADC-Register eines AVRs portierbar?

Peripheriezugriffe sind selten portabel, egal welche Programmiersprache
benutzt wird. Mit C sind aber immerhin diejenigen Programmteile, die nur
die CPU nutzen, portabel, mit Assembler nicht einmal diese.

Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und
mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben
werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte
Programme sind auch meist in Assembler genauso gut lesbar wie in C.

Anders sieht es aus, wenn der Controller "intelligente" Dinge tun soll,
also komplizierte Algorithmen abgearbeitet werden. Da freut man sich,
wenn man den implementierten Algorithmus ohne Änderungen auf einen
anderen Controller übertragen kann.

Der weise Programmierer trennt die Algorithmik von den Peripheriezugrif-
fen, so dass bei einer Portiereung sofort klar ist, welche Programmteile
neu geschrieben werden müssen und welche mehr oder weniger unbesehen
übernommen werden können.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

Ich sprech jetzt nur für mich (und dann verzieh ich mich wieder aus 
diesem Thread)

> Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und
> mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben
> werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte
> Programme sind auch meist in Assembler genauso gut lesbar wie in C.

Für mich wird da anders rum ein Schuh draus:
Ich zahl in solchen Fällen in C gegenüber Assembler keinen Penalty und 
selbst wenn, dann ist er so klein, dass ich ihn getrost ignorieren kann.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
>> Bei Anwendungen, wo ein paar Eingänge oder Timer abgefragt werden und
>> mit einfachen logischen Verknüpfungen an die Ausgänge weitergegeben
>> werden, hat C kaum Vorteile bzgl. der Portabilität. Diese Sorte
>> Programme sind auch meist in Assembler genauso gut lesbar wie in C.
>
> Für mich wird da anders rum ein Schuh draus:
> Ich zahl in solchen Fällen in C gegenüber Assembler keinen Penalty und
> selbst wenn, dann ist er so klein, dass ich ihn getrost ignorieren kann.

Das sollte auch kein Aufruf sein, solche Programme nur noch in Assembler
zu schreiben. Es sind aber genau (und nur) diese Programme, wo spess53s
Argument der fehlenden Portabilität uneingeschränkt greift, weswegen
hier Assembler eher sinnvoll ist als bei algorithmischen Anwendungen.
Aber auch hier würde ich Assembler nur dann einsetzen, wenn C wirkliche
Nachteile mit sich bringt (bspw. Schwierigkeiten bei der zyklengenauen
Ausführung), was aber selten der Fall ist. Insofern bin ich mit dir
einer Meinung.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dass man in C aber auch keine Makros ändern kann... Teufelszeug.

Du hast nicht mal verstanden, was das Beispiel zeigt:

Nämlich einen direkten Zugriff auf die Hardware von C aus.

Bei anderer Hardwareverdrahtung, z.B. statt PORTC nun 3 bit auf PortB 
und 5 bit auf PortD (weil die anderen Bits belegt sind), sind 
Programmänderungen unumgänglich. Ebenso wenn ich Werte in 
Timer-Control-Register schreibe (die auf einem anderen Prozessor 
natürlich komplett anders organisiert sind) oder eben sonstwie bits der 
Hardware ändere.

Da helfen dir Macros kaum weiter. Aber schön, daß du geblubbt hast.

Was weiterhilft, ist ein HAL, Hardware Abstraction Layer. Der übrigens 
oft als Interface in C, als Implementation in Assembler geschrieben ist, 
womit man wieder beim Thema ist.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Der übrigens
> oft als Interface in C, als Implementation in Assembler geschrieben ist
> womit man wieder beim Thema ist.

Wobei eine auch kühne Behauptung nicht umbedingt etwas mit der Realität 
zu tun haben muß. Es mag in der großen weiten Welt sicherlich einige 
Programme gteben, die einen HAL in Assembler mit C-Interface haben.

Aber daß das "oft" so ist, oder das überhaupt ein sinnvoller Grund 
existiert, es genau so zu machen, bezweifele ich mal.

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
>> Dass man in C aber auch keine Makros ändern kann... Teufelszeug.
>
> Du hast nicht mal verstanden, was das Beispiel zeigt:

Doch. Ich denke das haben wir schon.

> Nämlich einen direkten Zugriff auf die Hardware von C aus.

Ich seh nur nicht, wie Assembler diese Situation entschärfen könnte

> Was weiterhilft, ist ein HAL, Hardware Abstraction Layer. Der übrigens
> oft als Interface in C, als Implementation in Assembler geschrieben ist,
> womit man wieder beim Thema ist.

Und warum muss der in Assembler geschrieben sein?
Ein HAL hat die Aufgabe, physikalische Geräte in logischen Geräten 
abzubilden. Wiederrum erschliesst sich mir nicht wirklich, inwiefern da 
jetzt Assembler zum Muss wird.


Das Beispiel war einfach nur schlecht gewählt.

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.