www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik In einem Assembler Programm für Division auf C ausweichen!


Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sitze seit einigen tagen an einem Projekt welches ich in Assembler 
geschrieben habe und bin nun leider mit der Division mit Kommastellen an 
meine Grenzen gekommen.

Ich habe mir schon Rat geholt und bin zu dem Entschluss gekommen einfach 
eine Subroutine zum Dividieren in C zu schreiben und dann per .include 
in mein Assembler Programm einzufügen.

So nun zu meinem Problem:

Ich besitze leider nur sehr begrenzt Kenntnisse über C und habe keine 
Ahnung wie ich einen Wert der in einem bestimmten Register (bspl. r16) 
des AVR's befindet abfrage. Es muss doch irgendwie möglich sein wenn ich 
die 2 zu dividierenden Werte in meinem Assembler Programm in das 
Arbeitsregister r16 und r17 schreibe sie mit C wieder auszulesen und 
nach der Division wieder in ebend diese Register zu schreiben.

Ich danke im vorraus für jede Hilfe (bin hier schon halb am verzweifeln)

mfg

Jörn

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörn wrote:
> Ich sitze seit einigen tagen an einem Projekt welches ich in Assembler
> geschrieben habe und bin nun leider mit der Division mit Kommastellen an
> meine Grenzen gekommen.

Und was sind das für Grenzen?

Du mußt erstmal sagen, was Du überhaupt willst (Genauigkeit, Stellen, 
Wertebereich).

Division in Assembler ist nicht schwer:

Beitrag "Re: DIVISION 32 BIT / 32BIT Beispiel (Assembler) ATmega8"


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten dürfte es vermutlich einfacher und sinnvoller sein, gleich
alles komplett in C zu schreiben.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe bei meinen projekten bisher immer einen Weg gefunden, im 
Ganzzahlbereich zu bleiben. Eben passend erweitern (möglichst 2er 
Potenzen) und hinterher das Komma passend setzen.

Etwas nervend war bisher der Luftdrucksensor HP03 von Hope RF mir seinen 
ganzen Korrekturwerten...

Mach also mal genauere Angaben zur Rechnerei.

Gruß aus Berlin
Michael

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss eine Strecke die im bereich von 10cm - 10m liegt durch eine 
Geschwindigkeit die im Berreich von 1 km/h - 160 km/h liegt teilen.

Ausgeben muss ich das Ergebnis garnicht! Ich muss nur Intern damit 
weiterrechnen. Am einfachsten währe es doch das in eine C-Routine zu 
verpacken..  Oder? Nur wie gebe ich den Wert eines Registers an meine 
C-Routine weitergegeben?

Vielen dank schonmal für die Schnelle Hilfe!

mfg

Jörn

Autor: Jörn L. (pwn4ge38)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich hab mich jetzt mal angemeldet :)

Um nochmal genauer drauf einzugehen! Ich bräuchte das Ergebnis mit ca 
2-3 Nachkommastellen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hindert dich daran, auch hier mit Festkommazahlen zu rechnen?
Eine Divisionsroutine könntest du dir z.B. aus der AVR-LIBC klauen :-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörn (Gast)

>Ich muss eine Strecke die im bereich von 10cm - 10m liegt durch eine
>Geschwindigkeit die im Berreich von 1 km/h - 160 km/h liegt teilen.

Ja und?

>Ausgeben muss ich das Ergebnis garnicht! Ich muss nur Intern damit
>weiterrechnen. Am einfachsten währe es doch das in eine C-Routine zu
>verpacken..  Oder?

Du denkst reichlich verquer. Was spricht gegen eine normale ASM-Routine?

> Nur wie gebe ich den Wert eines Registers an meine
>C-Routine weitergegeben?

Solche Stunts sind vollkommen sinnlos.

Und wie bereits gesagt, versuch es mal mit Festkommaarithmetik.
16 oder 32 Bit lösen dein Problem ganz leicht.

MfG
Falk

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

Bewertung
0 lesenswert
nicht lesenswert
> Am einfachsten währe es doch das in eine C-Routine zu
> verpacken..  Oder?

Nein, nicht wirklich.
Wenn C, dann muss C das Oberkommando haben. Aus C heraus einige 
Assemblerfunktionen aufzurufen (so es denn unbedingt nötig ist), ist 
kein Problem, aber umgekehrt ist es nicht ganz so einfach.

> Und wie bereits gesagt, versuch es mal mit Festkommaarithmetik.
> 16 oder 32 Bit lösen dein Problem ganz leicht.

Oder aber: mach gleich alles in C (wobei Festkommaarithmetik immer noch 
eine gute Idee ist)
Das wurde aber schon mal weiter oben gesagt.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viele Wege führen nach Rom, deshalb hier ein (!) Beispiel, wie es geht:

Problem:                 3456,432d : 65,32d = ?
alles mal 1000:          3456432d : 65320d = ?
in Hex-Wert wandeln:     34BDB0h : FF28h = ?
in Assembler dividieren: = 34h
in Dezimalwert wandeln:  = 52d
durch 1000 dividieren:   = 0,052d

In Assembler ist dieser Weg garnicht mal so schwer, zumal Du sicherlich 
weißt, mit wieviel Stellen Du jeweils zu rechnen hast.

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@C.T.

in deinem Rechenbeispiel ist noch ein (gedanklicher) Fehler drin.

a*1000 dividiert durch b*1000 , da kürzt sich der Multiplikationsfaktor 
"*1000" fröhlich weg, und das Ergebnis braucht dann nicht mehr irgwndwie 
durch 1000 dividiert werden. Kann man aber leicht auch im Kopf 
nachrechnen, daß 3400 dividiert durch 65 keinen Wert mit 0,0irgendwas 
ergeben sollte ...

Allerdings ist das tatsächliche Ergebnis (52,91....) eher nahe bei 53 
dezimal, also gewisse Rundungsfehler treten da schon auf ...

Autor: Jörn L. (pwn4ge38)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich danke euch vielmals für die Hilfe! Ich werde mich gleich am 
Montag mal ransetzten und gucken ob ich es hinkriege :)

Ansonsten weis ich ja wo ich fragen kann :P

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Wegstaben Verbuchsler

Du hast vollkommen recht, mein Gedankenfehler ist wirklich ausgesprochen 
doof.

Die Genauigkeit kann ich aber leicht steigern, indem ich z.B. vorweg mit 
10.000 statt mit 1.000 multipliziere. Ich muß mich halt entscheiden, ob 
ich lieber mit größeren Zahlen rechne, oder auf Genauigkeit verzichte. 
Die Entscheidung hängt aber von der Applikation ab.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

statt 1000 besser 1024, statt 10000 besser 8192 oder 16384 nehmen.
Warum? Durch 256 heißt ja nur, das untere Byte des Ergebnisses 
wegwerfen,
Der Rest sind dann auch nur Shift-Operationen.
10er Potenzen sind da merklich unhandlicher und letztlich ändern sich 
nur die Rundungsfehler etwas.

Die zweite Frage, die inklar bleibt, ist ja, in welchem Format er bisher 
zu den Werten gekommen. In welchem Format liegen Weg und Geschwindigkeit 
vor?
Welche Auflösung haben die Werte?

Gruß aus Berlin
Michael

Autor: Jörn L. (pwn4ge38)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Weg liegt in 'dm' vor und die Geschwindigkeit in 'km/h' der große 
Unterschied der 2 Variablen ist meine größte Sorge!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmier es doch in C und kopier dann den enstandenen Assembler Teil 
aus dem List file in deine Assembler Datei.

Ansonsten spricht auch nichts dagegen eine C Funktion zu schreiben und 
diese aus dem Assembler aufzurufen. Es kommt dann auf die Calling 
Convention des Compilers an in welchen Registern du die Parameter an die 
Funktion übergeben musst bzw. den Return Wert bekommst.

Autor: Jörn L. (pwn4ge38)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok da kommen wir dem ganzen ja schon näher :)

Was für eine Calling Convention? genau diese Register brauche ich !!!!
Ich arbeite mit AVR Studio und WinAVR für C!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörn L. wrote:
> ok da kommen wir dem ganzen ja schon näher :)
>
> Was für eine Calling Convention? genau diese Register brauche ich !!!!
> Ich arbeite mit AVR Studio und WinAVR für C!
Beides irrelevant... Die Calling-Convention hängt vom GCC ab, der hinter 
WinAVR steht :-)

Ich glaub übrigens immer noch, dass es einfacher wäre, einen Rahmen in C 
zu schreiben und dann die benötigten Partien aus dem Listfile zu klauen.

Autor: Marcus Müller (marcus67)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das funktioniert so nicht (wurde oben auch schon mehrmals gesagt).

Die Anwendung aus dem C-Compiler braucht ein genau definiertes 
Environment mit Registerinitialisierung usw. U.u. werden auch wieder 
Subroutinen aufgerufen ... Eine einzelne Routine da rauszureißen 
funktioniert so überhaupt nicht.

Das ist so, als würde man versuchen unter LINUX die NTFS 
Filesystemroutinen einer Windows Installation anzusprechen.

Gruß, Marcus

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcus Müller wrote:
> Das funktioniert so nicht (wurde oben auch schon mehrmals gesagt).
Und ob das funktioniert. Natürlich ist da etwas Handarbeit angesagt, 
aber die zugrunde liegenden Routinen kann man übernehmen.

Autor: Marcus Müller (marcus67)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. wrote:
> Marcus Müller wrote:
>> Das funktioniert so nicht (wurde oben auch schon mehrmals gesagt).
> Und ob das funktioniert. Natürlich ist da etwas Handarbeit angesagt,
> aber die zugrunde liegenden Routinen kann man übernehmen.

Da haben wir uns durch die Reihenfolge der Beiträge falsch verstanden - 
ich bezog mich darauf, "einfach" eine Routine aus einem C Programm in 
Assembler aufzurufen.

Gruß, Marcus

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oki, das ist in den allermeisten Fällen ein Milcherzeugnis :-]

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. wrote:

> Und ob das funktioniert. Natürlich ist da etwas Handarbeit angesagt,
> aber die zugrunde liegenden Routinen kann man übernehmen.

Der wesentliche Teil davon wird aber aus der libgcc.a oder libc.a
zu benutzen sein.

Ich bin immer noch nicht davon überzeugt, dass der Ansatz in dieser
Richtung sinnvoll ist.  Es müsste schon ziemlich dringende Gründe
geben, die den Aufwand rechtfertigen, es so herum anzugehen statt
erstmal alles in C zu schreiben und dann ggf. einzelne Funktionen
mit der Hand in Assembler optimiert ,,nachzulegen''.  (Meist ist das
aber gar nicht nötig, da das C-Programm allein gut genug ist.)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir wissen ja immer noch nicht, was er überhaupt will.
D.h. ob die Operanden und das Ergebnis 8, 16 oder 32 Bit, signed, 
unsigned, Festkomma oder Float sein sollen. Genauigkeit, Wertebereich 
wäre auch wichtig.

Daher ist alles bisher nur reine Spekulation.


Peter

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum Assembler ????

Bis auf einige wenige spezielle Funktionen die auf direkte 
Registerzugriffe angewiesen sind. zb manipulation des PC ( 
ProgrammCounter) ist es absolut unnötig in Assembler zu programmieren.

Jeder C-Compiler generiert schnelleren, kleineren Code als 99 % aller 
Assemblerprogrammierer.

Autor: Olli R. (omr) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph wrote:
> Warum Assembler ????

Wahrscheinlich hat er eine undokumentierte Assembler-Altlast geerbt, und 
ihm fehlt der Durchblick.

Anders kann ich seine Beratungsresistenz nicht interpretieren.

Olli

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Jeder C-Compiler generiert schnelleren, kleineren Code als 99 % aller
>Assemblerprogrammierer

Träum weiter!

MfG Spess

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jeder C-Compiler generiert schnelleren, kleineren Code als 99 % aller
>Assemblerprogrammierer

... und die Erde ist eine Scheibe!

Ich habe mir schon öfters den von C-Compilern generierten Code 
angeschaut. Teilweise wird ganz schöner Murks erzeugt, der vom Optimum 
doch sehr weit entfernt ist.

Autor: walle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Jeder C-Compiler generiert schnelleren, kleineren Code als 99 % aller
>>Assemblerprogrammierer

>... und die Erde ist eine Scheibe!

>Ich habe mir schon öfters den von C-Compilern generierten Code
>angeschaut. Teilweise wird ganz schöner Murks erzeugt, der vom Optimum
>doch sehr weit entfernt ist.

Japp, v.a. in Bereichen, wo es um Multiplikation / Division geht.

Von ARM werden sogar spezielle Routinen in Assembler angeboten, weil sie 
optimaler sind als C-Code.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Von ARM werden sogar spezielle Routinen in Assembler angeboten, weil sie
> optimaler sind als C-Code.

Ähnliches findest Du auch bei anderen Herstellern, wie z.B. bei 
Microchip.

Autor: walle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ähnliches findest Du auch bei anderen Herstellern, wie z.B. bei
>Microchip.

War auch nur beispielhaft gemeint!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
walle wrote:

> Von ARM werden sogar spezielle Routinen in Assembler angeboten, weil sie
> optimaler sind als C-Code.

Und ein ordentlicher C-Compiler integriert genau derartige Routinen
in seinen Code...

Die Aussage war übrigens nicht, dass man in Assembler nicht schneller
sein könnte, sondern dass viele Leute, die einfach mal so
Assembler-Code zusammenschreiben, im Durchschnitt insbesondere die
Geschwindigkeit des generierten Codes eines ordentlichen C-Compilers
nicht erreichen -- und das für geschätzte 1000 % des Aufwands (in
der Erstellung und der Pflege des Programms).  Man muss schon
ziemlich viel Erfahrung in Assemblerprogrammierung mitbringen, bevor
man einen ordentlichen Compiler einfach mal so locker überbietet,
und leider darf man einen nicht zu vernachlässigenden Anteil dieser
Erfahrung auf jeder Plattform neu sammeln.  (Es ist nicht so, dass man
in der C-Programmierung komplett plattformunabhängig mit der Lernkuve
wäre, aber der Anteil ist naturgemäß viel geringer.)

Ein alter Spruch lautet: ``Never start optimizing before you have
profiled it.''  Wenn man Assemblerprogrammierung in diesem Sinne unter
`optimizing' zählt, passt das ganz gut: die meisten Probleme lassen
sich in einer höheren Abstraktion als Assembler nicht nur mit geringerem
Aufwand bearbeiten, sondern das Ergebnis erfüllt oft genug nach dem
Debuggen alle Ansprüche sowohl hinsichtlich Abarbeitungsgeschwindigkeit
als auch Codegröße.  Wenn danach das Timing nicht stimmt, muss man
anfangen zu optimieren.  Wenn die Codegröße noch nicht dem Ziel
entspricht, kann man sich überlegen, ob man nun den Aufwand für eine
Optimierung (einschließlich Assemblerversionen) investieren will,
oder ob sich das nicht lohnt, weil der nächst größere Prozessor im
Preis bei weitem nicht so viel ausmacht wie der größere Aufwand, den
man investieren muss.  Für Einzelstücke und Kleinserien wird sich der
Aufwand dabei nur selten lohnen, und erst ab einigen 100000 Stück
braucht man wohl angesichts der Kosten einer Ingenieurstunde drüber
nachdenken, ob man gleich von vornherein in Assembler programmiert,
damit man (u. U.!) mit einem kleineren Prozessor auskommt.

Autor: Jörn L. (pwn4ge38)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendwie hab ich nich umsonst das programm in Assembler 
geschrieben und finde so hirnrissige Antworten wie von Ralph etwas fehl 
am Platz!

Wenn meine Ausbildung nunmal das Programmieren von Assembler beinhaltet 
muss ich deswegen nich auch gleich C beherrschen oder?

Und ich schreibe es jetzt noch einmal!

Danke für die Hilfe!!!!!!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörn L. wrote:
> Wenn meine Ausbildung nunmal das Programmieren von Assembler beinhaltet
> muss ich deswegen nich auch gleich C beherrschen oder?
Nö, aber von Vorteil wäre das allemal. Wie auch immer.

Nochmal zum Mitmeißeln: Die Divisions-Routinen kommen aus der Bibliothek 
des GCC, dort liegen sie in Assembler vor. Die kannst du problemlos 
herauskopieren und einbauen, evtl. ist aber etwas Anpassung nötig.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörn L. wrote:
> Also irgendwie hab ich nich umsonst das programm in Assembler
> geschrieben ...

Wenn du eine ehrliche statt einer höflichen Antwort haben willst:
eigentlich war es umsonst, denn du bekommst es ja noch nicht einmal
fertig gestellt (und der größte Teil der Arbeit steht dir damit
noch bevor: Debuggen und Wartung, die initiale Codierung ist stets
nur ein kleiner Teil des Gesamtaufwandes).

Du hattest uns bislang aber auch die Gründe verschwiegen, warum du
es überhaupt in dieser Form angefasst hast.  Wenn die Assembler-
programmierung zu deiner Ausbildung gehört, hmm, naja, wenn's denn
sein muss (obwohl ich das so herum persönlich für die falsche
Herangehensweise halte), aber eigentlich ist die Aufgabe eine Nummer
zu hoch dann.  Ob du nun eine Division aus einem C-Compiler stibitzt
oder eine fertige Divisionsroutine aus dem Netz nimmst: wirklich
lernen wirst du dabei nicht viel, und um es richtig zu lernen fehlt
dir offenbar die notwendige Zeit im Gesamtprojekt -- hatte ich
eigentlich schon einmal geschrieben, dass Assemblerprojekte den
10fachen Aufwand von Projekten in einer höheren Abstraktionsebene
kosten? :-)  Nicht umsonst freut sich die Industrie, dass es für
alle heutigen Microcontroller gut brauchbare Hochsprachcompiler
gibt.

Wenigstens Gugel solltest du allerdings bedienen lernen, wenn du
da mal "avr-gcc register passing" eintippst, kommst du im dritten
Link auf:

http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna

das dir das ABI von AVR-GCC (sogar auf deutsch) beschreibt.  Das
zugehörige englische Dokument steht in der FAQ der avr-libc:

http://www.nongnu.org/avr-libc/user-manual/FAQ.htm...

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

Bewertung
0 lesenswert
nicht lesenswert
Jörn L. wrote:
> Also irgendwie hab ich nich umsonst das programm in Assembler
> geschrieben und finde so hirnrissige Antworten wie von Ralph etwas fehl
> am Platz!

Erstens kann Ralph nicht wissen, dass du Assembler lernen musst.
Zweitens bin ich mir ziemlich sicher, dass dein Lehrer nicht begeistert 
davon sein wird, wenn du um zu dividieren, eine C-Funktion aufrufst.

Wenn du zu Ausbildungszwecken in Assembler bleiben musst, dann wirst du 
dir auch überlegen und begründen müssen, wie denn Division eigentlich 
funktioniert und wie du das in deinem Programm umgesetzt hast.


Wenn hingegen deine Ausbildung schon vorbei ist (und ich dich jetzt 
falsch verstanden habe), dann wäre das ein perfekter Zeitpunkt um den 
Wechsel von Assembler nach C zu machen. So schwer ist das auch wieder 
nicht und mit dem Assemblervorwissen hast du gegenüber einem 
Programmierneueinsteiger einen enormen Vorteil.

Jeder Mechaniker lernt in seiner Ausbildungszeit mit der Feile 
umzugehen. Und trotzdem spannt er sich ein reales Werkstück in die Fräse 
oder Drehbank ein. Geht einfach schneller und besser als alles mit der 
Feile aus dem Eisen rauszuholen. Es wird Zeit, dass du dich damit 
beschäftigst, wie man mit einer Drehbank arbeitet nachdem du mit einer 
Feile gut umgehen kannst :-)

Zitat von ganz am Anfang
> Ich sitze seit einigen tagen
In C wären aus den Tagen wahrscheinlich Stunden geworden
Wenn du das Ganze jetzt, mit dem Wissen wie es funktioniert, von 
Assembler nach C überträgst, bist du dann eher im Bereich von vielleicht 
1 oder 2 Stunden (weil du dir die C-Syntax erst mal anschauen musst). 
Und da ist die Division schon mit drinn.

Das Setzen von Funktions-Registern und die Bedeutung dessen, was der AVR 
beim Setzen von bestimmten Bits in Registern macht, ist völlig identisch 
zu Assembler, nur dass dir der Compiler die ganze Arbeit über 
Zwischenregister gehen zu müssen, abnimmt. Und der Rest ist in C einfach 
nur angenehmer als in Assembler. Du verwendest einfach Variablen und der 
Compiler kümmert sich im Hintergrund darum, dass er die irgendwie auf 
die Register verteilt. Alles worum du dich noch kümmern musst, ist 
darüber nachzudenken, wieviele Bits du wofür brauchst. Aber ansonsten 
ist es einfach angenehmer

     Zeit = Sekunden + 60 * Minuten + 3600 * Stunden;

schreiben zu können, anstatt da mit einem Haufen Registern rumdoktorn zu 
müssen und sich zu merken, welcher Wert gerade in welchem Register liegt 
und ob man den Wert noch braucht oder nicht.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 1 oder 2 Stunden

In 2 Stunden ist aber auch schon die Division (gemäß obigen Beispiel) in 
Assembler zu schreiben.

Was soll also das Beharren auf C, wenn der Rest des Programms in 
Assembler geschrieben ist? Vieles braucht in Assembler geschrieben auch 
nicht mehr Zeit als in C. Gelegentlich ist es sogar schneller, es in 
Assembler zu schreiben.

Wer in C und Assembler gleichermaßen Fit ist, kann die Vorteilen beider 
Sprachen einsetzen und steckt all die locker in die Tasche, die z.B. nur 
was von C verstehen und um Assembler einen großen Bogen machen. Das hat 
dann auch was mit Wettbewerbsvorteilen bei Projekten zu tun.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:
>> 1 oder 2 Stunden
>
> In 2 Stunden ist aber auch schon die Division (gemäß obigen Beispiel) in
> Assembler zu schreiben.

Ganz offensichtlich nicht, sonst würden wir heute nach 4 Tagen nicht
immer noch drüber diskutieren.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg Wunsch

Das mag daran liegen, daß manche besser diskutieren als programmieren 
können.

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

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:
>> 1 oder 2 Stunden
>
> In 2 Stunden ist aber auch schon die Division (gemäß obigen Beispiel) in
> Assembler zu schreiben.

Mit 1 oder 2 Stunden mein ich das komplette Projekt!
Wenn du in C an einer Division 2 Stunden rumscheisst, dann kannst du dir 
deine Papiere abholen.

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

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:
> @ Jörg Wunsch
>
> Das mag daran liegen, daß manche besser diskutieren als programmieren
> können.

Das liegt eher daran, dass viele eine einfache Division schon vor 
unüberwindbare Hürden steckt. Und es tut mir leid, eine Division ist, 
wenn man das noch nie gemacht hat, in Assembler nun mal nicht so simpel. 
Das seh ich absolut ein. Vor allen Dingen dann, wenn man nicht mit 
uint8_t auskommt.
In C ist es eine Sache auf 3 Sekunden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei die meisten schon mal schriftlich mit Papier und Bleistift im 
Dezimalsystem dividiert haben dürften, oder lernt man sowas in der 
Schule nicht mehr. So arg verschieden ist das nicht.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In C ist es eine Sache auf 3 Sekunden.

+ 3 Tage Fehler suchen, wenn man nicht versteht, wie der Compiler bei 
der Rechnung vorgeht und man immer irgendwelche seltsamen Abweichungen 
hat oder der Mikrocontroller sogar abstürtzt (da z.B. die Division durch 
Null nicht abgefangen wurde).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:
>> In C ist es eine Sache auf 3 Sekunden.
>
> + 3 Tage Fehler suchen, wenn man nicht versteht, wie der Compiler bei
> der Rechnung vorgeht und man immer irgendwelche seltsamen Abweichungen
> hat oder der Mikrocontroller sogar abstürtzt (da z.B. die Division durch
> Null nicht abgefangen wurde).

Klar, Assemblerprogramme sind per definitionem bugfrei. :-))

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> :-))

Wenn ich nicht weiß, wie eine Division vonstatten geht, dann kann mich 
auch ein C-Code gansch schön weit nach hinten schmeißen.

Wenn ich aber weiß, wie dividiert wird und ich zudem C und Assembler 
kann, dann habe ich in beiden Sprachen keine nenneswerten Probleme und 
finde ggf. auch meine Fehler recht schnell.

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

Bewertung
0 lesenswert
nicht lesenswert
> dann kann mich
> auch ein C-Code gansch schön weit nach hinten schmeißen.

Klar kann er das.

Wenn ich nicht weiß was ich tue, ist sogar aus dem Bett steigen 
gefährlich.

Du argumentierst momentan mit den Rücken an der Wand.
Niemand hier bestreitet, dass es sinnvoll ist Assembler zu lernen (auch 
ich nicht). Und trotzdem werden die meisten dieser Befürworter ein 
reales Projekt, sobald absehbar ist, dass es eine bestimmte Größe 
überschreitet (und die ist sehr schnell erreicht) es nicht in Assembler 
implementieren. Der Aufwand steht meistens in keinem Verhältnis zum 
Nutzen. Dafür spart mir aber der höhere Abstraktionsgrad der 
Programmierumgebung eine Unmenge an Fehlern und Problemen ein. Zeit die 
sehr viel sinnvoller eingesetzt werden kann. Und die dir, nebenbei 
gesagt, die wenigsten Auftraggeber bezahlen werden. Wenn deren 
Analytiker sagt "Ein Geschwindigkeitsmessgerät ist ein Timer der im 
Input Capture Mode arbeitet, dazu noch ein bischen rumrechnen und dann 
ab aufs Display, das dauert in C keine 20 Minuten wenn wir das selber 
machen" und du kommst dann mit 4 Tagen, weil du erst lernen musst, wie 
man eine 64 Bit Division macht und 20 Fehler in der Registerbelegung 
gemacht hast, dann wird der dich zum Teufel jagen mit deinem Assembler 
und sich einen Nachwuchs-C-Programmierer holen, der ihm das an einem 
Vormittag macht.
Es interesiert schlicht und ergreifend nämlich niemanden ob deine 
Berechnungsroutine um eine halbe Millisekunde schneller läuft als die 
entsprechende C-Routine, weil sowieso kein Mensch ein Display so schnell 
ablesen kann. Dafür wird er dich aber an der obersten Rahe aufknüpfen, 
wenn du darauf bestehst, dass du die 4 Tage bezahlt haben willst, 
anstatt das ganze in einer Hochsprache in ein paar Stunden gelöst zu 
haben (selbst wenn du in C noch Nachholbedarf hattest)

Wenn jeder Taktzyklus zählt, sieht die Sache anders aus. Aber die 
wenigsten Probleme sind von dieser Sorte.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger

Du scheinst nicht alle Beiträge gelesen zu haben. Ich habe bereits 
erwähnt, daß man sowohl in C, als auch in Assembler fit sein sollte, um 
die Vorteile beider Sprachen nutzen zu können.

Dein Argument, daß C Zeit und Geld einspart, wird in sehr vielen 
Beiträgen immer wieder gebetsmühlenartig wiederholt. Richtiger wird die 
Aussage dadurch trotzdem nicht.

Aus meiner Erfahrung heraus kann ich nur sagen, daß C und Assembler 
sinnvoll zusammen eingesetzt den größten Vorteil bringt!

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

Bewertung
0 lesenswert
nicht lesenswert
> Richtiger wird die Aussage dadurch trotzdem nicht.

Wir können ja mal einen Wettkampf machen.
Jemand stellt ein Problem.
Du schreibst in Assembler, ich in C.

Dann werden wir schnell sehen, ob das Argument, dass eine Hochsprache 
Zeit und Geld spart, sticht oder nicht.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Karl heinz Buchegger

Eines meiner größten Projekte der letzten Zeit war ein 
16-Kanal-Datenverteiler mit NAT-Funktionalität (NAT = Network Address 
Translation). Der Code ist extrem zeitkritisch, funktioniert aber selbst 
in stark gestörten Umgebungen einwandfrei.

Hierbei galt: Gute Nacht C.

Autor: Norgan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich nicht weiß, wie eine Division vonstatten geht, dann kann mich
> auch ein C-Code gansch schön weit nach hinten schmeißen.

Mich schmeißen solche "Argumente" vor Lachen vom Stuhl.

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

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:
> @ Karl heinz Buchegger
>
> Eines meiner größten Projekte der letzten Zeit war ein
> 16-Kanal-Datenverteiler mit NAT-Funktionalität (NAT = Network Address
> Translation). Der Code ist extrem zeitkritisch, funktioniert aber selbst
> in stark gestörten Umgebungen einwandfrei.

Und ich sagte weiter oben schon: Wenn jeder Taktzyklus zählt, sieht die 
Sache anders aus.
Was daran hast du nicht verstanden?

Nochmal: Niemand sagt, dass Assembler keine Berechtigung mehr hat. Das 
hast du falsch verstanden. Das will hier auch niemand propagieren. Nur 
sind die wenigsten Projekte von der Gestalt.

Wenn sich aber in einem Projekt herausstellt, dass ein Teil davon, zb 
eine Division, in C sehr viel einfacher zu lösen wäre, dann muss die 
Frage erlaubt sein, warum man das Ganze nicht gleich in C macht. Und das 
Argument "weil ich nun mal Assembler besser finde" sticht da nicht mehr.

Autor: C.T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nur die wenigsten Projekte sind von der Gestalt.

Du scheinst in einer ganz andern Branche wie ich zu arbeiten. Bei mir 
gilt diese Aussage leider nicht.

Vielleicht solltest Du Deine Aussagen weniger verallgemeinern und Dich 
gelegentlich auch mal umsehen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C.T. wrote:

> Der Code ist extrem zeitkritisch, funktioniert aber selbst
> in stark gestörten Umgebungen einwandfrei.

Hmm, das macht der Netzwerkstack meines BSDs aber seit XX Jahren
ebenfalls.

Aber lass man, wir kommen hier sowieso nicht unter einen Hut mit
unseren Auffassungen, und dem OP hilft das gar nichts.  Der muss
sich nun einfach mal aufraffen, eine der vorgeschlagenen Varianten
zu realisieren.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da mein Post die ganze Diskussion so richitg in Gang gebracht hat, will 
ich auch nochmal was dazu sagen.

Jeder C - Programmierer muss Assembler wenigstens rudimentär 
beherrschen, sonst hat er beim Debuggen verloren, noch bevor er 
angefangen hat.

Einige Dinge müssen in Assembler geschrieben sein, das sind Zugriffe auf 
Register, oder Manipulationen auf tiefster Ebene die von einer 
Hochsprache aus nicht erreichbar sind.

Alles andere solte in einer Hochsprache, egal ob C, C++ , ..... 
geschrieben werden.
Alleine schon aus Gründen der späteren Softwarepflege.
Sieh dir nach einem Jahr mal den alten Code an, du wirts dich wundern 
was du damals für einen sch.... programmiert hast, und der Meinung warst 
das dein Code das beste je geschriebene war.

Kommen wir zu zeitkritischen Vorgängen.
Ist der Vorgang so zeitkritisch das schon auf einzelen Taktzyklen 
geachtet werden muss, ist ein Scheitern schon vorprogrammiert.
Das wird NIE zuverlässig funktionieren.
Das brauch nur ein Inteerupt zur falschen Zeit, eine atomare Instuktion 
mit x Zyklen, oder sonst etwas dazu zukommen, und das ganze Timing 
zerplatzt wie eine Seifenblase.

In diesem Fall hilft nur eins.
Einen µC mit mehr Performance.

Die Reihefolge im Projekt muss sein.
1. Was soll gemacht werden.
2. Wie soll es gemacht werden
3. Was wird dazu benötigt.  ( das ist z.b. Die Auswahl des richtigen µC 
)

und nicht wie bei vielen Projekten
1. Ich hab den µC X
2. Wie bekomme ich den ganzen Krempel jetzt darauf, der µC doch viel zu 
klein.........

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph wrote:

> Jeder C - Programmierer muss Assembler wenigstens rudimentär
> beherrschen, sonst hat er beim Debuggen verloren, noch bevor er
> angefangen hat.

Nö, das stimmt so nicht.

Ich denke, dass 99,9 % der Hochsprachprogrammierer sich ihren
Assemblercode nie ansehen und auch keinen Grund dazu haben.

Wenn du von jedem /Controller/-Programmierer sprichst, ist das
sicher ein anderer Schuh.  Aber auch hier genügt es, wenn er den
Assemblercode seines Prozessors lesen kann, er muss ihn nicht
selbst schreiben können.

> Einige Dinge müssen in Assembler geschrieben sein, das sind Zugriffe auf
> Register,

Sowas macht man als Hochsprachprogrammierer nicht, darum kümmert
sich der Compiler.  (Zumindest, falls Register hier ein CPU-Register
meint.  Falls ein IO-Register gemeint ist, gibt es eigentlich keinen
wirklichen Unterschied zwischen C und Assembler.)

> oder Manipulationen auf tiefster Ebene die von einer
> Hochsprache aus nicht erreichbar sind.

Das beträfe bspw. denjenigen, der ein Betriebssystem schreibt und
die Kontext-Umschaltung machen will.  Das macht man nicht gerade
jeden Tag.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph wrote:

> Jeder C - Programmierer muss Assembler wenigstens rudimentär
> beherrschen, sonst hat er beim Debuggen verloren, noch bevor er
> angefangen hat.

Ich bin der Meinung, dass jeder Softwareentwickler mal Assembler gemacht 
haben soll, weil es das Verstaendnis fuer das Geraet, mit dem er 
arbeitet, verbessert. Es ist auch wesentlich einfacher, Jemandem 
Pointerarithmetik zu vermitteln, der schon Assembler kann und weiss, was 
Speicher und Speicheradressen sind. Aber natuerlich kann man das auch 
ohne Assembler lernen und auch ohne Assembler zu koennen, debuggen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Es ist auch wesentlich einfacher, Jemandem
> Pointerarithmetik zu vermitteln, der schon Assembler kann und weiss, was
> Speicher und Speicheradressen sind.

Die Erfahrung habe ich übrigens komplett gegenteilig gemacht: der
C-Code, den ein paar alte Assemblerhasen geschrieben haben, sah
gruselig aus.  Sie haben nämlich alles erst auf uint8_t * gewandelt,
dort ihre Offsets manuell berechnet, und dann auf die Daten
zugegriffen bzw. die Zeiger passend inkrementiert.  Dass Zeiger in
C in Objektgrößen ,,denken'' statt in Bytes, daran muss sich ein
Assemblerprogrammierer erst gewöhnen.

Eine einigermaßen konkrete Vorstellung davon, wie man den Speicher
eines Prozessors adressiert, ist allerdings für das Verständnis von
Zeigern wirklich hilfreich.

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.