In einem Assembler Programm für Division auf C ausweichen!

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

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

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

So ich hab mich jetzt mal angemeldet :)

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

@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

> 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.

@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 ...

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

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

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

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!

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

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

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.)

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

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

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.

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!!!!!!

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.html#faq_reg_usage

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.

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.

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.

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.

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.

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. :-))

> 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.

> 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.

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.

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.

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.

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.