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
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
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
So ich hab mich jetzt mal angemeldet :) Um nochmal genauer drauf einzugehen! Ich bräuchte das Ergebnis mit ca 2-3 Nachkommastellen.
Was hindert dich daran, auch hier mit Festkommazahlen zu rechnen? Eine Divisionsroutine könntest du dir z.B. aus der AVR-LIBC klauen :-)
@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.
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.
@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
@ 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.
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!
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.
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!
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.
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
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.
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
Oki, das ist in den allermeisten Fällen ein Milcherzeugnis :-]
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
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.
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
Hi >Jeder C-Compiler generiert schnelleren, kleineren Code als 99 % aller >Assemblerprogrammierer Träum weiter! MfG Spess
>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.
>>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.
> 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.
>Ähnliches findest Du auch bei anderen Herstellern, wie z.B. bei >Microchip. War auch nur beispielhaft gemeint!
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: > 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.
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.
> 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.
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.
@ Jörg Wunsch Das mag daran liegen, daß manche besser diskutieren als programmieren können.
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.
> 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).
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. :-))
> :-))
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.
> 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.
@ 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!
> 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.
@ 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.
> 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.
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.
> 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.
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.
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.........
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.