A. K. schrieb: > Und je nach Windows Version ist schon allein die Suche nach diesem > Dialog ziemlich spannend. Gibts da nicht, um diese horrende Bürokratie zu umgehen, einen kleinen asm-Befehl dafür?
Jetzt noch eine CommandLine Einweisung? Ist ja schon klar, dass DOS erst NACH Assembler erfunden wurde. Daher kann Moby das nicht wissen. PATH=%PATH%;<PfadZumGCCfürAVR> Damit ist dies für die aktuelle Console-Sitzung aktiv.
Moby A. schrieb: > Carl D. schrieb: >> Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu >> kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt >> ab. > > Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software > bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-) Jemand, der Assembler wegen Kompaktheit und Klarheit benutzt UND etwas von der Materie versteht (also ein Programmierer), der benutzt normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit wirklich alles in der Hand. Der kann dann auch das Kommando von Yalu einfach aufrufen. Wer das nicht kann, sollte mal ganz klein das lernen anfangen, statt nur heisse Luft zu produzieren. Moby, Du hasts geschafft, dich wird keiner mehr ernst nehmen....einem Schüler hätte man das noch abgenommen, aber einem, der behauptet, seit 20 Jahren zu programmieren..
Yalu X. schrieb: > Speicherverbrauch in Bytes > > Mobys ASM Yalus C > —————————————————————————————————— > Flash 206 158 > SRAM (Stack) 2 2 > —————————————————————————————————— Vielen Dank, Yalu! :-) Und Moby windet sich einmal mehr wie eine Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er aktuell abzieht...
A. K. schrieb: > Robert kam beim Studio 6.2 mit > GCC 4.8.1 auch auf 166 Bytes. Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man denkt. Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen. Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 Bytes. Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196 Bytes. Irgendwelche weiteren Grundinitialisierungen lasse ich mir da nicht zuaddieren weil die in der Praxis ohne Bedeutung sind. Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz drübergeschaut) und des Funktionstests auf realer Hardware hat C damit eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut Listing nicht allzuviele Register verwendet wurden. Schaut also bislang gut aus. Bernhard M. schrieb: > der benutzt > normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine > Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit > wirklich alles in der Hand. Das würde ich als Rückschritt sehen. Das Studio ist schon, bei aller Größe, zumindest bei Assemblerprogrammierung sehr komfortabel und einfach. "In der Hand haben" möchte ich auch nicht tausend C-Compiler Optionen sondern nur meinen Code! Jay W. schrieb: > Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es > die von dir bestätigte Programmspezifikation gibt. Das Programm samt zugehöriger "Projektchen"-Beschreibung gibts weitgehend unverändert seit 5.September. Also theoretisch viel Zeit sich vorzubereiten ;-) Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran gefeilt hat? Das Thema Entwicklungszeit kam in seinem Beitrag auffällig kurz ;-) P. M. schrieb: > Und Moby windet sich einmal mehr wie eine > Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein > Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich > geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er > aktuell abzieht... Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr ohne jedes Compiler-KnowHow zusammen- während Dein und anderer "Experten" KnowHow meist gerade mal für höhnische Kommentare langte ;-) Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das nehm ich mal als Ansporn! Mehr dazu und ggf. zur "Preisverleihung" dann im Laufe des Sonntags!
:
Bearbeitet durch User
nur mal zur Erinnerung, Moby war der Meinung man könne SEINEN optimierten! Code überhaupt nicht in C schlagen.. Moby A. schrieb: > Markus M. schrieb: >> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich >> zurück mit Falschaussagen > > Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt > gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in > gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang > überschaubar und fachlich: nicht vorhanden. auf die Entwicklungszeit rausreden wird auch schwierig: es ist ein Wunder, dass überhaupt jemand sich die Mühe gemacht hat, dieses doch recht unnütze Projekt* nochmal in C zu schreiben (ich hätte nicht damit gerechnet) und niemand weiß wie lange Moby gebraucht hat, für die "fehlerfreie"** Version *Beitrag "Re: Assembler wieder auf dem Weg nach vorn" **es wird ja scheinbar unnötigerweise der ganze Speicher initialisiert, aber die wichtigen Sachen nicht.. erst Yalu hat das korrigiert
:
Bearbeitet durch User
Moby A. schrieb: > Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 > Bytes. Warum?
A. K. schrieb: > Moby A. schrieb: >> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 >> Bytes. > > Warum? Weil Yalu bezüglich Optimierung weiter gedacht hat als Moby, das ist nicht erlaubt!
Moby A. schrieb: > Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das > nehm ich mal als Ansporn! Je schlechter einer ist, desto grösser ist sein Verbesserungspotential. Auf die Steigerungsfähigkeit muss das indes nicht zutreffen. ;-)
Moby A. schrieb: > Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz > drübergeschaut) und des Funktionstests auf realer Hardware hat C damit > eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich > beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut > Listing nicht allzuviele Register verwendet wurden. Schaut also bislang > gut aus. Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu wertendes Ergebnis ansehen.
Speicherverbrauch in Bytes
Mobys ASM Yalus C
——————————————————————————————————
Flash 206 158
SRAM (Stack) 2 2
——————————————————————————————————
Schon gut Moby. Oben stehen die Fakten. Glasklar. Auch dein
unangenehmer, ab vorhersehbarer Versuch, neue Anforderungen
hervorzuzaubern oder Bytes abzuziehen (bei dir) oder hinzuzurechnen (bei
Yalu) ändert daran nichts.
Deine Einlassungen zum Studio sind auch wieder ein Kleinod der
Rabulistik. Gerade wenn man, so wie du, Probleme hat sich ein paar
Konsolenkommandos und Compilerschalter zu merken, ist das Studio im
Vorteil. Es nimmt einem nämlich diese "Bürokratie" ab.
:
Bearbeitet durch User
Jay W. schrieb: > Schon gut Moby. Hey, mach die Diskussion nicht kaputt, in dem Du Moby Dinge vorwirfst, die er mittlerweile selbst eingesehen hat.
Rufus Τ. F. schrieb: > Hey, mach die Diskussion nicht kaputt, in dem Du Moby Dinge vorwirfst, > die er mittlerweile selbst eingesehen hat. Na gut, warten wir den weiteren Verlauf ab. Vielleicht behältst du recht.
Moby A. schrieb: > A. K. schrieb: >> Robert kam beim Studio 6.2 mit >> GCC 4.8.1 auch auf 166 Bytes. > > Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei > AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default > libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man > denkt. > > Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich > auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen. Nur, weil du eine schlechtere Compiler-Version genommen hast als ich? Ich könnte ja andersherum genauso argumentieren, dass ich hier einen ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch einen NOP einfügt. Damit sind bei deinem Code für mich nicht die 216 Bytes, sondern 432 Bytes maßgeblich. In der Spezifikation ist nirgends vorgegeben, welcher C-Compiler zu benutzen ist, d.h. jeder von uns beiden wählt die Tools, die er für richtig hält oder die er auch sonst benutzt. Für mich der GCC 4.7.4 der derzeitige Standard, den ich für alle meine Projekte verwende. Für dich wird er es wahrscheinlich ebenso sein, falls du dich demnächst dazu entschließen solltest, tiefer in C einzusteigen. Im Gegensatz zum IAR-Compiler, der den Code vermutlich noch etwas besser optimiert hätte, ist der GCC sogar frei, so dass du – wie auch jeder andere hier im Forum – die Ergebnisse nachzuvollziehen kannst, ohne dass dir dadurch irgendwelche Kosten entstehen. Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und ich keine Lust auf eine Diskussion darüber habe, werde ich die 8 Bytes eben opfern. Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf deinem PC zu installieren ;-) > Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 > Bytes. Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen unnötig aufgebläht ist? Ich dachte, hier geht es darum, keine wertvollen Ressourcen zu verschwenden. Wenn du dir das nicht zu Herzen nimmst, ist das doch nicht mein Problem, sondern deins, oder? Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und ich keine Lust auf eine Diskussion darüber habe, werde ich eben auch diese Bytes opfern. Es sind aber nicht nicht 16, sondern 18 Bytes, die ich eingespart habe: Die 10 RJMPs in der Vektortabelle minus 1 RJMP, der nötig ist, um im Initialisierungscode den über in Weg liegenden Interrupthandler zu springen, also 9·2 Bytes = 18 Bytes. Das um die vollständige (wenn auch unnütze) Interruptvektortabelle erweiterte Programm habe ich angehängt. > Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196 > Bytes. Das Entfernen der RAM-Initialisierung und des Sleeps ist in Ordnung, weil das ja vorher schon so vereinbart war. > Irgendwelche weiteren Grundinitialisierungen lasse ich mir da nicht > zuaddieren weil die in der Praxis ohne Bedeutung sind. Das ist nicht in Ordnung. Warum sollten wir so einen Pfusch zulassen? Außerdem steht in der von dir bestätigten Spezifikation geschrieben: Moby A. schrieb: >> jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) > > Richtig. Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten 8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert, sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation verstößt. Ich bestehe deswegen darauf, dass du auch bei dir die Summenregister anfangs auf 0 setzt. Wie du das machst, ist mir egal. In meinem obigen Beitrag habe ich dir ja schon verraten, wie du statt mit 8 zusätzlichen Bytes (für 4 CLRs) auch mit nur 6 Bytes auskommen kannst. Die Codegröße deines gemäß der Spezifikation korrigierten Programms beträgt also 202 Bytes Auf Grund massivster Zugeständnisse meinerseits, die in keiner Weise von der Spezifikation gefordert waren, wächst die Codegröße meines Programms von 158 Bytes auf 184 Bytes Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit! Diese Ergebnisse 202 Bytes vs. 184 Bytes sind fix. Sie werden nur noch dann geändert, wenn sich herausstellt, dass eines der Programme fehlerhaft ist oder anderweitig nicht der Spezifikation entspricht. Dann wird dieses Programm von seinem Autor korrigiert und die Größe neu bestimmt.
Moby A. schrieb: > Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir > gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht > erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr > ohne jedes Compiler-KnowHow zusammen Aha. Du gibts also implizit zu, dass es ein Compiler doch besser macht, als der Mensch?
Yalu X. schrieb: > Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich > eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm > mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in > diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D Meine Hochachtung, Yalu!
Jay W. schrieb: > Deine Einlassungen zum Studio sind auch wieder ein Kleinod der > Rabulistik. Welche meinst Du? Jörg W. schrieb: > Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme > zu schimpfen, Wer hat über andere Betriebssysteme geschimpft? Nur weil ich es für ein Unding empfinde, für eine simple C-Compilierung erst ein Linux installieren zu müssen? Robert L. schrieb: > auf die Entwicklungszeit rausreden Nun seht mal nicht alles durch die "Ausreden"-Brille. War ja nur ne Frage. Eine berechtigte allerdings, da mir das Thema Entwicklungszeit ja öfter vorgehalten wurde ;-) A. K. schrieb: > Moby A. schrieb: >> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 >> Bytes. > > Warum? Weil mein Code vielleicht seine Vektortabelle auch behalten hat? Nun seht mal nicht alles durch die "Wer gewinnt" Brille. Mich interessierte in erster Linie die Leistungsfähigkeit von C; zu meinem Glück fand sich jemand der dazu in der Lage war es endlich zu demonstrieren. Manch anderer "Experte" hatte ja selbst in Frage gestellt, daß C für Programme dieser Größenordnung und ohne RAM-Verwendung Erfolg beim Ressourcensparen verspricht ;-) So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will. Rufus Τ. F. schrieb: > Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich > ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu > wertendes Ergebnis ansehen. So schauts aus. Meine Funktionsprüfung auf Hardware gibt nun grünes Licht: Alles funktioniert wie erwartet. Der Zeitablauf ist etwas gedehnter als bei meinem Code (Das genaue Timing ist nicht gleich, z.B. Sync-Pause 20ms länger- Warum?), aber meine fertige Auswerteroutine kam natürlich auch damit klar. So eine separate Taktleitung hat schon was Gutes ;-) Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut vergleichbar macht! Etwas Kontra zu Deinen weiteren Erläuterungen wirst Du nun sicher noch vertragen: Yalu X. schrieb: > Als einzige Vorteile von Assembler gegenüber C bleiben also die simple > Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich > aber leider weder klar definieren noch objektiv messen, weswegen sich > bzgl. dieser Punkte am besten jeder sein eigenes Bild macht. Davon rücke auch nicht ab- aber Du hast Recht, das soll jeder für sich entscheiden und es ist nicht notwendig, dies weitere 1000 Beiträge zu diskutieren. > sum.all /= 8; > > zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu > schreiben, sondern auch besser zu verstehen als ... Natürlich. Auch wenn sich das kryptische in diesem Ausdruck schon andeutet. Daß sich viele Berechnungen so vorhanden in C besser abhandeln lassen hatte ich doch mehrmals betont. > In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die > Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges > davon ginge sicher auch in Assembler ... So ist es. Und zwar das was nötig ist. > Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration ... Solchen Notwendigkeiten bin ich bislang durch vorherige Abklärung der Aufgabenstellung erfolgreich aus dem Weg gegangen ;-) > Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C > obliegt in Assembler die Verwaltung der einzelnen Register und des > Datenspeichers komplett dem Programmierer. Das ist das Wenigste. Mit einem Register-System allemal. Dann ist da auch keine "Buchführung" nötig. 32 Register langen schon eine ganze Weile! Größere Datenmengen können ein Fall für den C-Compiler sein. Im SmartHome fallen die weder an einzelnen Aktor/Sensorknoten noch in kleinen lokalen Steuerungen an. > In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt, > als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar > scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise > einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag > überschrieb: Ja ja sogar der "Meister"... Meist passiert das nur wenn man mal schnell was fürs Forum fertig macht ;-) 99% der Fehlersuche dreht sich aber nicht um solche Trivialitäten. Hatte ich auch schon mal gesagt. > In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz > klar der Compiler zuständig, der auch bei komplexen Programmen nie den > Überblick verliert. Die sogenannten "Buchhaltertätigkeiten" sorgen aber für Ef....- fast hätt ichs ausgesprochen ;-) OK, sogesehen ein Pluspunkt für C. > weil es einfach > viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen > zu müssen Speicherverwaltung ist keine Bürokratie. Die genauen Locations verschiedener Variablen interessieren mich auch nicht, es sein denn, man macht eine RAM Adresse zum Bestandteil des Codes (z.B. bei Erreichen einer bestimmten Pointerposition). Generell muß man das Thema der Hardware-Verwaltung bei AVR nicht so hoch hängen, soviel ist da nicht zu verwalten.
Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2 Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der Funktion locker auch völlig ohne SRAM aus. Nur müsste man dann Mobys Forderungskatalog etwas lockerer interpretieren, indem man zwar die Interrupt-Logik des Timers nutzt, nicht aber die des Prozessors.
A. K. schrieb: > Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2 > Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der > Funktion locker auch völlig ohne SRAM aus. Weniger wäre mir egal gewesen, die Funktion entscheidet. Ohne Verpacken/Kapseln der Funktionalität in einem Interrupt hätte natürlich auch ein Asm-Programm keinen Stack benötigt ;-)
Moby A. schrieb: > Weniger wäre mir egal gewesen, die Funktion entscheidet. Ei gucke da! Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr Flash diese Funktion beeinträchtigt?
A. K. schrieb: > Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr > Flash diese Funktion beeinträchtigt? Eine dumme Frage, A.K. Schließlich ging es um den Vergleich, welche Sprache mit weniger Ressourcen auskommt ;-)
Yalu X. schrieb: > Ich könnte ja andersherum genauso argumentieren, dass ich hier einen > ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch > einen NOP einfügt. Das ist aber jetzt kein elegantes Argument ;-) Ein Assembler übersetzt immer was da steht. Nicht einmal besser oder einmal schlechter.
Moby A. schrieb: > Schließlich ging es um den Vergleich, welche Sprache mit /weniger/ > Ressourcen auskommt ;-) Eben. Die besagte Variante benötigt sogar im RAM weniger Ressourcen. Und nun ist das auf einmal egal?
:
Bearbeitet durch User
Moby A. schrieb: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER > > Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich > was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend > an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut > vergleichbar macht! Mein vorhin schon ausgedrücktes Lob an Moby für diesen Abschluss des Threads sei an dieser Stelle wiederholt.
Moby A. schrieb: > Schließlich ging es um den Vergleich, welche Sprache mit weniger > Ressourcen auskommt ;-) So dumm ist die Frage nicht. Wieviel Prozent belegt das aktuelle Programm von den *sowieso vorhandenen* Ressourcen? Was geschieht mit dem vielen unbenutzten Ressourcen? Welche möglichen Erweiterungen würde in diesem Fall denn Sinn machen? Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die Entwicklung gesteckt? Auch das sind Ressourcen.
Yalu X. schrieb: > Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten > 8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert, > sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation > verstößt. > > Ich bestehe deswegen darauf, Darüber wollen wir nicht streiten. In der Theorie hast Du Recht, für meine Praxis ist das unbedeutend. > Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf > deinem PC zu installieren ;-) Wenn ich das nicht schaffen würde dann sicher eine Menge mehr. Kein Argument für C ;-) > Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen > unnötig aufgebläht ist? Diese sogenannte "Idee" wurde schon in meinem Projektthread angesprochen. Was bereits da steht lädt gleich zur Erweiterung ein ;-) > Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit! Entspann Dich bitte, Mod Yalu. Der Fight der Systeme ist vorbei ;-) Matthias L. schrieb: > Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die > Entwicklung gesteckt? Auch das sind Ressourcen. Darauf werden wir hier keine erschöpfende nachprüfbare Auskunft mehr bekommen... Mein Code entstand bereits im September. An einem Nachmittag ;-)
:
Bearbeitet durch User
Moby A. schrieb: > So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang > mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will. Es hätte wohl normalerweise niemand so als Projekt angefangen. Wenn es mein Projekt wäre, hätte ich: 1) Einen ATtiny25 genommen, wegen der USI, die einem bei der seriellen Kommunikation einen Großteil der Arbeit abnimmt. Hätte außerdem den Vorteil, dass der dortige ADC in der Lage ist, die Versorgungsspannung zu messen, ohne dass man externe Hardware braucht (indem man Vref gegen Vcc als Referenz misst). So kann man noch ein Flag mit durchreichen, dass die Batterie gewechselt werden muss. Ernsthaft mehr Geld kostet das Ding ja sowieso nicht. 2) Die Daten an Bytegrenzen ausgerichtet. Das macht die Sache ringsum viel einfacher, auch wenn man ein paar Bits verschwendet bei der Übertragung, weil man für 10 Bit Analogwert 2 Byte braucht. 3) Eine ordentliche CRC benutzt, mindestens eine 8-Bit-CRC. Da haben Generationen von Ingenieuren einfach schon genug Gedanken reingesteckt, wie man Übertragungsfehler möglichst sicher erkennt, das muss ich nicht ignorieren. Konkreter RAM- und Flash-Verbrauch wäre ohnehin egal, solange alles mit ausreichend Reserve (für Erweiterungen, wobei mehr als 50 % bei beiden auf jeden Fall als „ausreichend“ genügt) in den ATtiny25 passt. Mit diesen Prämissen hätte man das wohl problemlos an einem Abend umgesetzt, einschließlich Funktionstest. Meine Hochachtung an Yalu für seine erwiesene Geduld!
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wenn es mein Projekt wäre, hätte ich: > Eine vernüftiges (fertig entwickeltes) Protokol benutzt, das nicht für jeden Sensor 2 PortPins benutzt. Bei der geforderten Bitrate hätte OneWire auf einen PortPin einige zig Temperaturen messen. Bei Bedarf kann man einen Slave auch in einen ATtiny13 pressen (in C): https://www.tm3d.de/index.php/1-wire-device-mit-avr Und damit könnte man alles was das Moby-Board macht auch tun. Nur eben z.B. direkt an Raspberry anschließbar, Software eingeschlossen. Ja, der Link hat natürlich keine fertige .HEX für M.'s Anforderungen und auf dem Tiny13 ist etwas zu wenig Platz für alle Busfunktionen. Ab Tiny25 ist das dann aber ein vollwertiges OneWire-Device. Und für Temperatur einfach mal einen Ds18b20 an den Bus klemmen ist dann auch drin.
Moby A. schrieb: > Alles funktioniert wie erwartet. Juhu! :) > Der Zeitablauf ist etwas gedehnter als bei meinem Code In meinem Programm wird OCR0A so gesetzt, dass bei der nominellen Oszillatorfrequenz (128 kHz) das Timing exakt stimmt:
1 | OCR0A = 128000 / 64 / 200 - 1 = 9 |
Du hingegen hast OCR0A auf 7 gesetzt, um die Abweichung der tatsächlichen von der nominellen Oszillatorfrequenz auszugleichen. Wenn du die tatsächliche Frequenz kennst und du sie in Zeile 16
1 | #define F_CPU 128000
|
einträgst, berechnet der Compiler automatisch den optimalen Wert für OCR0, und das Timing sollte dann ziemlich genau stimmen. Da jedoch die prozentuale Auflösung des OCR0A-Werts in diesem Bereich recht schlecht ist (es macht einen großen Unterschied, ob man bspw. 9 oder 8 einträgt), kann das Timing immer noch ungenau sein. Aber warum nimmst du statt dem 64:1-Vorteilers nicht einfach den 8:1-Vorteiler (CS2=0, CS1=1, CS0=0)? Dann ist für die Nominalfrequenz OCR0A=79, und die Interruptfrequenz kann in viel feineren Schritten eingestellt werden. Hier sind die entsprechenden Änderungen im Programm (
1 | // OCR0A = (uint8_t)((double)F_CPU / 64 / (2 * F_DATA) + 0.5)-1;
|
2 | OCR0A = (uint8_t)((double)F_CPU / 8 / (2 * F_DATA) + 0.5)-1; |
3 | ^
|
4 | ...
|
5 | // TCCR0B = 1<<CS00 | 1<<CS01;
|
6 | TCCR0B = 0<<CS00 | 1<<CS01; |
7 | ^
|
Wenn du jetzt noch in Zeile 16 die richtige Oszillatorfrequenz einträgst, ist das Timing genauer als ±0,7%. Bei meinem Tiny beträgt die Oszillatorfrequenz fast exakt 120 kHz. Wenn ich diesen Wert ins Programm eintrage und den Vorteiler wie beschrieben auf 8:1 einstelle, messe ich mit dem Oszi einen Datentakt von 100,2 Hz (ideal wären 100,0 Hz). Was will man mehr? Man muss es mit der Kalibrierung aber auch nicht übertreiben, denn die RC-Oszillatorfrequenz ist stark abhängig von der Temperatur und der Versorgungsspannung. > (Das genaue Timing ist nicht gleich, z.B. Sync-Pause 20ms länger- > Warum?) Siehe oben. Außerdem musst du berücksichtigen, dass die Sync-Pause, gemessen von der letzten fallenden Taktflanke vor der Pause bis zur ersten steigende Taktflanke nach der Pause nicht 80 ms, sondern 85 ms betragen muss, da zu den 80 ms Pause ja noch die Low-Phase des letzten Takts (5 ms) hinzukommt.. Moby A. schrieb: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Jetzt bleibt mir aber wirklich die Spucke weg ... Wenn ich ganz ehrlich bin, hätte ich nicht erwartet, dass wir uns in diesem Punkt irgendwann in den nächsten 1000 Jahren einig werden ;-) Offensichtlich bist du doch nicht ganz so sehr der absolut unverrückbare tonnenschwere Betonklotz, für den ich dich gehalten habe. Daumen hoch!
Moby A. schrieb: > Der Fight der Systeme ist vorbei ;-) Es hat nie einen "Fight der Systeme" gegeben. Es hat nur einen Moby gegeben, der stur nicht glauben wollte, was andere schon längst wissen.
Yalu X. schrieb: > Moby A. schrieb: >> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten >> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: >> >> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Ja Moby, das Ergebnis war zu erwarten. Der Kompiler kann beim Compilieren das gesamte Programm optimieren. Du immer nur Deine vorgefertigten Blöcke. Vielleicht macht es ja Sinn, das Du Dir C doch mal in Ruhe ansiehst?
Ich meine, ich hätte den folgenden Beitrag heute Nachmittag schon abgeschickt, habe aber wohl vergessen, auf den "Absenden"-Knopf zu drücken: Moby A. schrieb: > Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran > gefeilt hat? Die Grundversion des C-Programms mit der geforderten Funktionalität hat mich eine gute halbe Stunde gekostet. Diese Version hat allerdings noch RAM für Variablen und die Sicherung von Registern im Interrupthandler benötigt. Zudem war darin noch der Startup-Code der C-Bibliothek enthalten, der mehr tut als im konkreten Fall gefordert und deswegen etwas mehr Flash belegt, als unbedingt nötig. Trotzdem wäre in einem realen Projekt die Softwareentwicklung an dieser Stelle weitgehend abgeschlossen gewesen, da alle Funktionen vollständig implementiert waren, und man wäre direkt zur Testphase übrgegangen. Aber hier ging es ja nicht primär darum, eine lauffähige Anwendung zu entwickeln, sondern deine unsinnigen Zusatzanforderung nach fast völligem Verzicht auf die RAM-Nutzung zu erfüllen. Ich musste nun also versuchen, - sämtliche Variablen (insbesondere auch die globalen) in Register zu bringen, - die in diesem Fall überflüssigen PUSHs und POPs im Interrupthandler zu vermeiden, - den Compiler/Linker dazu zu bringen, den Startup-Code wegzulassen und - diejenigen Teile aus dem Startup-Code, die man trotzdem benötigt, in C nachzuprogrammieren. Das sind alles Dinge, die niemand auf der Welt (außer dir natürlich) tut, weil sie völlig unsinnig sind. Entsprechend findet man im Netz auch kein Howto, in dem das alles in zusammengefasster Form und ready-to-use beschrieben wird. Da ich selber so etwas auch noch nie gemacht habe, musste ich mir die notwendigen Informationen also mühevoll aus mehreren Einzelquellen zusammentragen und immer wieder testen, ob die gewonnenen Erkenntnisse vom Compiler und Linker auch wirklich so umgesetzt werden, wie ich mir das vorgestellt hatte. Das hat etliche Stunden gedauert. So genau weiß ich das nicht, weil ich nicht auf die Uhr geschaut und zwischendurch immer wieder andere Dinge (wie Essen, Einkaufen usw.) getan habe. Schließlich habe ich noch einen kleinen Testaufbau mit dem ATtiny13 zusammengesteckt, um zu sehen, ob die Ausgangssignale bzgl. Timing und den Dateninhalten stimmen. Um die Ausgabe mit der deines Programms vergleichen zu können, habe ich auch dieses auf den Controller geladen und die Signale auf dem Oszi angeschaut. Da ich kein Atmel-Studio habe, musste ich dazu deinen Quellcode erst einmal in die GNU-Assemblersyntax, die von der Atmel-Syntax etwas abweicht, übersetzen. Das hat einschließlich einiger kleiner Fehlerkorrekturen zusammen weitere zwei Stunden gedauert. Die mit Abstand meiste Zeit nahm somit der Wissenserwerb für die "RAM-freie" Programmierung in C in Anspruch. Ich betrachte das mal als persönliche Fortbildungsmaßnahme, die für mich vielleicht irgendwann mal wieder von Nutzen sein wird (auch wenn ich das eher bezweifle ;-)). Auf jeden Fall bin ich jetzt mehr denn je davon beeindruckt, welche Möglichkeiten der GCC für das gezielte Abspecken von Programmcode bietet. Noch vor ein paar Tagen hätte ich es für unwahrscheinlich gehalten, dass man mit dem GCC das Eckmannsche Programm erzeugen kann:
1 | ; Programmanfang an Adresse 0 |
2 | sbi DDRB,1 |
3 | sbi PINB,1 |
4 | ; Programm läuft im unprogrammierten Flash weiter und wird |
5 | ; wiederholt, wenn der Programmzähler am Flash-Ende überläuft |
(Quelle: Beitrag "Re: Assembler wieder auf dem Weg nach vorn") Jetzt weiß ich aber, dass es geht :) Und wenn mal erst einmal gelernt hat, wie diese Fähigkeiten des GCC zu nutzen sind, schreibt man extrem ressourcensparende Programme fast mit der gleichen Leichtigkeit wie gewöhnliche C-Programme, auf jeden Fall aber in viel kürzerer Zeit als mit Assemblerprogrammierung. Wenn wir jetzt – wie damals von Karl Heinz vorgeschlagen – einen Wettbewerb veranstalten würden, bei dem jeder von uns in limitierter Zeit eine vorgegebene µC-Anwendung realisiert und am Ende neben der Fehlerfreiheit der Ressourcenverbrauch bewertet wird, würdest du mit deiner ASM-Programmiererei vermutlich sehr schlecht aussehen :) Bei einer nichttrivialen Anwendung (>> 1KB), zu der dich Karl Heinz herausgefordert hatte, hättest du sowieso keine Chance, aber auch bei einem Mickymaus-Programm, vergleichbar mit dem deines Sensorboards, würde ich dich dank der Produktivität von C und der Fähigkeiten des GCC, kompakten Code zu generieren, ganz sicher schlagen :D Aber das ist inzwischen Schnee von gestern, da du jetzt ja ganz groß in die C-Programmierung einsteigen wirst und damit künftig genauso schnell ressourcensparenden Code entwickeln wirst wie alle anderen. Deswegen ist jetzt schon klar, dass der Wettbewerb nur mit einem Remis enden kann :) Bewundern wir stattdessen lieber den gewaltigen Sprung nach oben, den C in der nächsten Ausgabe des Tiobe-Index machen wird :)
Yalu X. schrieb: > das Eckmannsche Programm ... find ich geil! Klingt fast wie 'Eulersche Zahl' oder 'Satz des Thales' :-)
Yalu X. schrieb: > da du jetzt ja ganz groß in > die C-Programmierung einsteigen wirst Dazu wiegt > der absolut unverrückbare > tonnenschwere Betonklotz jahrelanger Asm-Praxis zu schwer ;-) Du hast Dir aber redlich Mühe gegeben mir einen neuen Weg zu bahnen (mit viel Ressourcenspar-Häppchen als Lockmittel), aber soweit liegen Dein jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun auch nicht auseinander, daß für mich die Gegenrichtung Moby A. schrieb: > Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das > nehm ich mal als Ansporn! nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur Asm-Output ;-) Daß Du meinen Asm Code hier zuweilen korrigiert hast ist doch auch ein Angebot... Außerdem bleibe ich bei Moby A. schrieb: > Das schlimmste ist die unnötige Bürokratie. > Dieser hochgradig umständliche Aufwand. > Das würde ich von der Priorität her fast noch über den gesteigerten > Ressourcenbedarf setzen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur > Asm-Output ;-) Meist Maschinencode.
Moby A. schrieb: > Moby A. schrieb: >> Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das >> nehm ich mal als Ansporn! Nope, genau da liegst du falsch und das versuchen wir dir auch seit rund 2000 Beiträgen zu erklären: Ein Compiler kann Optimierungen machen, die ein Mensch nicht mehr überblicken kann. Das wahre Optimierungspotential liegt nicht bei ein paar kunstvollen Assembler-Kniffen, sondern beim sturen Durchrechnen der Resourcenbelegung, z.B. Cache- oder Registerzuweisung. Und selbst wenn die kunstvollen Assembler-Kniffe etwas bringen: Die kennt und nutzt der Compiler sowieso. Moby, es gibt einfach wirklich nichts, ausser: (a) Ausbildungs-/Spasszwecken (b) Wenn die Instruktionssequenz aus einem ganz konkreten Grund von Hand vorgegeben muss, z.B. "Takte zählen". (c) Bibliotheksfunktionen, die ganz spezifische Hardware-Eigenschaften nutzen soll oder Code-Snippets für die Verwendung innerhalb von Compilern Für generelle Anwendungsentwicklung ohne sehr konkreten Optimierungsdruck ist C um Welten geeigneter.
Ralf G. schrieb: > ... find ich geil! Klingt fast wie 'Eulersche Zahl' oder 'Satz des > Thales' Für so ein legendäres Programm... Ich bin gespannt, wann die Arduino-Fraktion sich daran versucht und der Bootloader sie in den Wahnsinn treibt. mfg.
Moby A. schrieb: > aber soweit liegen Dein > jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun > auch nicht auseinander, daß für mich die Gegenrichtung > [...] > nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur > Asm-Output ;-) War ja klar, dass Du die Unterschiede nun herunterspielst. Ich verstehe nur nicht, warum Du in hunderten von Beiträgen vorher so einen Aufstand geübt und einen so großen Bohei drum gemacht hast. Dass C und ASM sich bei einem Mini-Progrämmchen nicht groß unterscheiden, war von vornherein klar. Egal, ob jetzt C oder ASM bei 200 Byte Code die Nase vorn hat: der Unterschied ist marginal. Das sagst Du ja nun selber. Die eigentlichen Stärken spielt der C-Compiler nämlich erst bei größeren Projekten aus. Dann ist es in jedem Fall wurscht, ob Interruptvektor-Tabellen drin sind oder ob man RAM benutzt. Das kann dann der Compiler wesentlich besser entscheiden als der Mensch. Yalus Klimmzüge bzgl. Mobyischer Einsparungen kann man sich dann schenken und Deine ganzen Argumente bzgl. Ressourcen-Einsparung lösen sich bei C in Luft auf. Der C-Programmierer kann sich voll der eigentlichen Programmier-Aufgabe widmen, der ASM-Programmierer jedoch muss weiterhin all seine Register, Calling Conventions und andere Fallen immer im Auge behalten. Der ASM-Programmierer ist daher doppelt belastet: Er muss sich neben der eigentlichen Programmieraufgabe zusätzlich noch permanent um sein "Werkzeug" kümmern. Bleib ruhig bei ASM. Steht Dir auch besser. P.S. Wegen Deinem permanenten nervösen Augenzwinkern solltest Du mal zum Arzt gehen. ;-)
:
Bearbeitet durch Moderator
Kaum ist man mal ein absoluter Resourcenverschwender (ich habe die
Resource Freizeit am Wochenende mit meiner Freundin auf dem
Weihnachtsmarkt am Bodensee maßlos verschwendet),
schon taucht ein extrem resourcensparendes ce ("C") Programm auf
(welches ich so nicht gedacht hatte dass es - der Unnötigkeit wegen -
gemacht wird):
Yalu hat es bewiesen und deshalb gilt meine absolute Hochachtung Yalu !
Im Übrigen läßt sich Yalus Programm auch mit der AVR-GCC Version 4.8.1
übersetzen (was ich allerdings so dann auch erwartet habe).
Absolute Hochachtung für Yalu !!!
Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch
tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das
unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert).
Respekt !
Ich möchte Yalu auf jeden Fall auch noch meinen Respekt zollen. Ich programmiere schon eine ganze Zeit in c, seltener in asm. Auch beruflich. Dabei bin ich nicht erfolglos, gehöre aber sicher auch nicht zu den allerhellsten Kerzen in der Branche.... Ich finde das ist schon eine wirklich beachtliche Leistung was du gemacht hast. Yalu hat schön gezeigt, was alles Motivation sein kann, Neues zu machen und eine Herausforderung zu lösen. Ein so oft gehörtes Phrasenargument bezüglich asm und c ist ja, dass man in Assembler genau weiß, was der Prozessor gerade macht, keinen Takt verschwendet, jedes Bit gesetzt hat, genau den Überblick über Register etc. pp hat. das ist vermutlich ein Relikt, was sich vor über 30 Jahren gebildet hat und viel zu oft einfach nachgeblökt wird. Es wäre schön, wenn das Ergebnis des Threads helfen könnte, dieses (zumindest von Moby) nicht mehr immer zu hören. Moby, du musst dir halt auch eingestehen, dass du genau DAS in 2000 Posts und vielen Threads gemacht hast: deinen asm Code als den perfekten bitoptimierten Code angepriesen, der deshalb von etwas geschwätzigen wie c nicht "geschlagen" werden kann. Hat sich erledigt. Hast du ja auch auf deine Art gewürdigt. Das Assembler, wie gesagt, im Hobby einfach seiner selbst willen mal Spaß machen kann ist damit nicht widerlegt. Portabel und wie ich meine Praxisrelevant ist die c-Lösung ja nun auch nicht. Ich kann auch verstehen, dass der Einstiegswiderstand bzgl. c groß ist. ABER: es haben dir ja auch echt viele Leute in dem Thread soooo oft versucht rüberzubringen und dich dahingehend zum nachdenken zu bewegen, dass dein Sensor in c genauso gut funktionieren würde, wenn 50 Byte mehr flash und paar Byte ram verbraucht würden. Kein bischen schlechter. Nicht mal weniger erweiterbar - eher mehr. Von daher würde ich es einfach mal wagen, immer auch ein c Projekt anzugehen. Die Moderatoren und einige andere haben hier ja wirklich lange und sachlich diskutiert; die werden sicher auch bei c Fragen helfen. Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen expliziten unsigned-cast, der dem compiler erheblich unter die Arme greift. So wirklich verstehen, warum der nicht selber auf die Idee kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register zuweise tue ich nicht. Aber(!) das ist ja auch wirklich fast immer nicht so dramatisch. Wenn das Programm und die Ressourchenaufteilung wohl überlegt ist, bringt eine Berechnung mit 3 Takten mehr meistens keinen Beinbruch. Bei manchen anderen ist hier direkt wieder der Reflex zum nachtreten zu sehen. Meine Güte: seid Männer! Hier ist kein Schulhof wo gilt: einmal Arsch, immer Arsch. Man kann sich auch streiten und dann in die Kneipe zurückziehen. Sollte man jedenfalls versuchen. Leider weiß ich für mich persönlich jetzt IMMER noch nicht, ob der Moby-Member in Wirklichkeit auch so borniert sein kann, oder ob das eine Menge Selbstdisziplin gefordert hat. ;-) So und mit der Smiley ist doch ein guter Punkt, sich aus dem Thread auszuklinken. Wie schön. Endlich quasi-Konsens. Warum quasi? Das seht ihr in den nächsten 500 Posts.
Clemens M. schrieb: > Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was > mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link > zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen > expliziten unsigned-cast, der dem compiler erheblich unter die Arme > greift. So wirklich verstehen, warum der nicht selber auf die Idee > kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register > zuweise tue ich nicht. Eine einfache Erklärung - ohne in Details zu gehen: In C werden Berechnungen standardmäßig in Integer (int) durchgeführt. Das Problem beim Schieben eines Wertes nach links bzw. rechts ist, dass das Vorzeichen (MSB) dabei immer erhalten bleiben muss. Bei unsigned-Werten, wo das keine Rolle spielt, muss man dem Compiler das dann explizit sagen, denn auf den Typ der Zielvariablen kommts nicht an - vielmehr auf den Typ der Operanden.
Meine Hochachtung gilt Moby: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Das zu schreiben war nach diesem Riesenthread sicher nicht einfach! Für mich steckt die Herausforderung beim Programmieren auch ganz wesentlich in der Konfrontation mit eigenen Fehlern, die unausweichlich in jedem Programm stecken. Nur wer diese erkennt, findet den Bug oder die bessere Lösung beim Refactoring oder dem nächsten Design. Moby, ich denke, hier können Dich mehr verstehen, als Du glaubst. Lange Zeit war meine Einstellung zu C-Compilern ähnlich wie Deine. Früher war der ASM-Output des Compilers deutlich schlechter als handoptimierter Assembler, auch noch bei den ersten gcc-Versionen für den AVR. Aber die Compiler werden immer besser, das Ergebnis hat uns Yalu gezeigt. Früher haben die Schachgroßmeister die Maschine als Konkurrenten gesehen, heute werden sie als Hilfestellung benutzt, um komplexe Lösungen besser zu finden und zu verstehen. Dieser Weg ist auch für uns Programmierer der Richtige. Gruß, Stefan
:
Bearbeitet durch User
Klar, Frank. Das ist mir soweit natürlich bewusst. Ich tendiere wie es aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen und daher habe ich das öfter einfach ausgeblendet. Von daher war der oben genannte thread für mich persönlich gut. Wenn ich mich in Zukunft wundere, warum ein Code ungewöhnlich aussieht, habe ich die Problematik in meinem aktiven Hirn.
Clemens M. schrieb: > Ich tendiere wie es > aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen > und daher habe ich das öfter einfach ausgeblendet. Ja, mich stört es auch, dass man immer wieder daran denken muss. Es gibt andere Sprachen (z.B. Java), in denen man einen "unsigned shift" durch drei Größer-Zeichen - also '>>>' - explizit angeben kann. Schade, dass das in C nicht geht. Ich würde nämlich dann immer '>>>' statt '>>' verwenden, da man einen Shift mit Vorzeichen-Wahrung eher selten braucht.
:
Bearbeitet durch Moderator
Ich glaube, Moby hat einfach ein Problem / Abneigung gegen die Begriffe "Algorithmen" und "Datenstrukturen". Komplexere Algorithmen als nur ein paar Bit-Schubsereien und deutlich komplexere Datenstrukturen als die eines digitalen 8-bit-Eingangs/Ausgangsports sind nun mal das Grundgerüst der meisten heutigen Systeme (nicht nur von Magnetfeld-Steuerungen von Teilchenbeschleunigern, auch "einfachere" Steuerungen - z.B. Quadkopter-Steuerung). Sowas läßt sich halt nur vernünftig in einer abstrahierenden Programmiersprache darstellen, bei der man sich um das klein-klein einzelner Registerbelegungen keinen Kopf mehr zu machen braucht.
Selbst wenn man Yalus 'hackish' Tricks weglässt und per Copy&Paste einfach in AVR Studio 4 'sensorboard.c' kompiliert, ist es immer noch kleiner als der ASM Kram:
1 | Build started 21.12.2015 at 09:52:14 |
2 | avr-gcc -mmcu=attiny13 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT sensorboard.o -MF dep/sensorboard.o.d -c ../sensorboard.c |
3 | avr-gcc -mmcu=attiny13 -Wl,-Map=sensorboard.map sensorboard.o -o sensorboard.elf |
4 | avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature sensorboard.elf sensorboard.hex |
5 | avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex sensorboard.elf sensorboard.eep || exit 0 |
6 | avr-objdump -h -S sensorboard.elf > sensorboard.lss |
7 | |
8 | AVR Memory Usage |
9 | ---------------- |
10 | Device: attiny13 |
11 | |
12 | Program: 184 bytes (18.0% Full) |
13 | (.text + .data + .bootloader) |
14 | |
15 | Data: 0 bytes (0.0% Full) |
16 | (.data + .bss + .noinit) |
17 | |
18 | |
19 | Build succeeded with 0 Warnings... |
Ralph S. schrieb: > Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch > tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das > unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert). Geht mir auch so, ich habs fürs Kompilieren erstmal auskommentiert und aus 'void main3(void)' einfach mal 'int main(void) gemacht - sonst will Studio 4 nicht.
:
Bearbeitet durch User
Matthias S. schrieb: > sonst will Studio 4 nicht Das hat weniger mit Studio 4 zu tun als eher mit dem alten avr-gcc von 2010. Hier eine Kurzanleitung, wie man auch neuere avr-gcc mit Studio 4 nutzen kann: Beitrag "Re: avr-gcc 4.7 für Atmel Studio 4 Windows" Ich persönlich nutze avr-gcc 4.7.2. Für Windows gibts den hier: http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
Frank M. schrieb: > Hier eine Kurzanleitung, wie man auch neuere avr-gcc mit Studio 4 nutzen > kann: > > Beitrag "Re: avr-gcc 4.7 für Atmel Studio 4 Windows" Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der gcc Kompiler sehr zufrieden. Ich habe auch festgestellt, das es für gesparte Bytes im Flash ja gar kein Geld zurückgibt :-) Wimre habe ich hier sogar noch WinAVR von 2010 laufen, das wäre GCC 4.3.3. Würde ich was neueres brauchen für neue MC, dann lasse ich AVR Studio 4 so wie es ist und kippe Atmel Studio 7 oder so mit auf den Rechner.
Jetzt müsste man nur noch klären ob ASM tatsächlich "einfach und selbsterklärend" ist .. @moby avr: hast du anhand dieses selbsterklärenden ASM Code schon festgestellt was der GCC jetzt besser gemacht hat als du? Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Matthias S. schrieb: > Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei > ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der > gcc Kompiler sehr zufrieden. Es gibt aber durchaus noch andere Verbesserungen, z.B. LTO-Support und den neuen Typ "__flash" vs. PROGMEM. Ausserdem ist der Compiler-Output auch ohne Tricksereien besser als der vom avr-gcc 4.3.3.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Auch __int24 und __uint24 kamen m.W. erst mit GCC 4.7. Ja, die sind Kollateralnutzen von __memx, das ja eh 24-Bit Arithmetik braucht. Mit wenig Mehraufwand (z.B. Division, die für Zeigerarithmetik nicht notwendig ist) waren also 24-Bit Typen zu haben.
Moby A. schrieb im Beitrag #4644241:
> http://m.heise.de/newsticker/meldung/Programmiersp...
Geht das jetzt wieder los?
Egal, ob Platz 10 oder Platz 99: 2,28% sind einfach nicht der Rede wert.
Meinetwegen kann dieser Thread dichtgemacht werden.
Logisch. Heute kam grad eine Meldung, dass der Quellcode des Apollo Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler. Soviel Quellcode auf einem Haufen...
A. K. schrieb: > Logisch. Heute kam grad eine Meldung, dass der Quellcode des > Apollo > Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler. Klasse. Gibts auch einen Weg, den Counter von "Assembler" wieder zu drücken? Vielleicht durchstreichen: ̶A̶̶s̶̶s̶̶e̶̶m̶̶b̶̶l̶̶e̶̶r̶
:
Bearbeitet durch Moderator
So also mal wieder in einem Alten vergessenen Thread Rum-stochern :D Egal was die Ststitik sagt, egal was da geschrieben wird. Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt Maschienensprache bzw Assembler. es gibt nur sehr wenige Prozessoren "die von Hause aus" eine Hochsprache verstehen (bsw. Tynibasic). Das heißt Assembler muss auch heute noch Programmiert werden. Unsere Firma bsw programmiert NUR in Assembler, den wir stellen Geräte her an denen Menschenleben hängen, und eine Hochsprache kan unkontrollierte Fehler machen, bsw. Stackoverflow usw. Im weiteren ist eine Hochsprache nie so Hardware nah wie Assembler, den da muss man den uC verstehen. Eine Hochsprache die in einer Hochsprache geschrieben ist ist ja auch nicht das gelbe vom Ei?!? Warum bloss macht auch C++ zuerst Assemblercode ?!? Hmmmm.... Warum schlägt ihr euch gegenseitig fast die Köpe ein ob oder ob nicht? Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) Programmierer] und keiner Geschaft. Aber Unsere Assembler Programmierer tun das und packen auch noch eine Sensorsteuer- und Regel-Software mit rein! Da es immer wieder Neue Prozessoren gibt, wird auch Assembler und Maschinensprache nie aussterben, sonst würden auch keine Kinder mehr auf die Welt kommen die Zuerst in die Schule müssen. Assembler ist die Sprache des Prozessors, und es ist immer besser die Direkte Sprache zu sprechen als sie zuerst von "etwas" übersetzen lassen. Oder Versucht mal im Google Sprache x in Y zu übersetzen was Kommt raus? ...EBEN.. und das obwohl Millionen dafür ausgegeben werden es zu Perfektionieren. und auch genau so verhält es sich bei den Hochsprachen für uC die Compiler oder gar Interpreter sind nie Perfekt. Und ja Windows wurde ja hier im Thread auch angesprochen, Stimmt ist vollständig in mehreren Hochsprachen geschrieben.(ja nicht nur in einer das sieht man deutlich, wenn man den Quellcode analysiert). Und was ist das Resultat? Windows ist "Launisch", Instabil und wird nicht für Livesupport (Geräte an denen Leben hängen) zugelassen....hmmm warum wohl?..... Die Meinung bei uns in der Firma (und übrigens auch bei FDA) ist klar Livesupport, Assembler Only..... So Sorry wenn ich jemandem auf den Slips getreten bin, aber bin auf den Thread aufmerksam geworden weil ich doch Tatsächlich "Assembler" bei Google eingegeben habe, nicht weil ich Software suche, sondern weil bei uns im Betrieb ein Assemblerprogrammierer in Pension geht und wir wieder einen suchen :-D ........
Patrick L. schrieb: > Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache > zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu > kriegen Beitrag "Re: Assembler wieder auf dem Weg nach vorn" q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch besser geworden, der Mensch bleibt bei 1.0 Lies zur Sicherheit auch die anderen 2k Beiträge durch.
Patrick L. schrieb: > Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt > Maschienensprache bzw Assembler. Und zwar Testcases um den Prozessor zu debuggen. Parallel dazu entsteht ein C Compiler, auf Fremdhardware entwickelt, weil man ohne den keinen Prozessor mehr auf den Markt bringen kann, wenn man auf Stückzahlen Wert legt.
Patrick L. schrieb: > Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache > zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu > kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir > suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) > Programmierer] und keiner Geschaft. Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu beschränken.
Gu. F. schrieb: > Patrick L. schrieb: >> Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache >> zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu >> kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir >> suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) >> Programmierer] und keiner Geschaft. > > Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu > beschränken. Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe!
@Operator S. Hallo danke für deinen Interessanten Beitrag :) Operator S. schrieb: > q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch > besser geworden, der Mensch bleibt bei 1.0 > > Lies zur Sicherheit auch die anderen 2k Beiträge durch. Ja das wäre ja Toll, bloß habe ich den Beitrag nicht gefunden, würde mich rein Persönlich Interessieren? aber Trotzdem, ändert nix daran, das es für Livesupport nicht zugelassen ist....... @A. K. Auch dir Danke für dein Beitrag, ist aber nicht ganz richtig, wir haben gerade diesen Monat wieder 2 Hybridprozessoren auf den Markt gebracht, zu denen es (noch) keinen "C" Compiler gibt. das eine ist ein 16 Bit uC das andere ist ein 128Bit DSP... Klar das es irgend wann auch für die meisten, "C" & Co geben wird, aber nicht für alle, von uns auf den Markt gebrachten uC's, gibts Hochsprachen und Trotzdem, Unmengen davon sind weltweit im Einsatz....:) im Bereich Sicherheitstechnik (Livesupport), Lenktechnik, Hochsicherheit's-Verschlüsselungssysteme, und da hat's in den letzten 30 Jahren keine Hochsprache gegeben und wirds wahrscheinlich auch in Zukunft nicht geben, wir Produzieren diese uC's aber immer noch und sie werden auch noch eingesetzt...... die einen Ja da hast du recht, in sehr kleinen Stückzahlen aber es sind auch welche die wir Outgesourct haben (bzw. stellt unser Kunde nun selber her, aber wurde von Unserem Team entwickelt) und die gehen schon in große Stückzahlen rein. Nichts dest do Trotz suchen wir halt Assembler Programmierer..... ...Bist du einer? Interesse? ....:-D Gruß..... Nachtrag: @Cyblord >Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack >in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im >Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für >eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe! Versuch doch mal auf 100nm³ mehr unterzukrigen......dan werden wir es tun, zur Zeit ist aber die Technologie nicht so weit....Schade...Deshalb müssen wir das.....
:
Bearbeitet durch User
> Patrick Linder (Firma: S-C-I DATA GbR) dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem damit haben dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist aber doch genau das gegenteil von: >Assembler wieder auf dem Weg nach vorn
Robert L. schrieb: > > dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem > damit haben ..Das Hoffe ich doch :D GRINS....... > > dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist > aber doch genau das gegenteil von: > >>Assembler wieder auf dem Weg nach vorn Wo du Recht hast, hast du Recht, von Vormarsch kann echt nicht die Rede sein das ist so. (Braucht zu viel Hirnschmalz und Hardwarekenntnis) .....Hehe..... Aber ich sage ja nur, Assembler wird es immer geben solange es neue Prozessoren gibt, deren Sprache Assembler bzw. Maschinensprache ist. Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw. Prozessor nah programmieren muss... Und wäre Windows in Assembler geschrieben würd es vielleicht auch zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch öfters als Win 7 oder gar XP...... Gruß....
Patrick L. schrieb: > (Braucht zu viel Hirnschmalz und Hardwarekenntnis) Hardwarekenntnis brauchst du für hardwarenahe Programmierung immer, da unterscheiden sich andere Sprachen von Assembler gar nicht – zumindest nicht, wenn man die Hardware auch wirklich selbst ansteuert und nicht fertige Bibliotheken dafür nimmt (wie bspw. Bascom oder Arduino etc.). Das wesentliche unterschlägst du: Assemblerprogrammierung braucht vor allem Zeit, und zwar sehr viel mehr als jede höhere Sprache, wenn das Gesamtproblem nicht mehr trivial ist. Das ist doch der wesentliche Grund, warum man es nicht macht, wenn es irgendwie vermeidbar ist. Die entsprechende Software wird dadurch einfach teuer. > Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man Wurde im dir bereits zitierten Beitrag widerlegt. ;-) > damit umgehen kann) und auch zuverlässiger, Das ist ein Trugschluss. Der wesentliche Fehlerfaktor ist ja nicht der Compiler sondern der Mensch, und durch die geringe Codedichte ergibt sich automatisch erstmal eine höhere Fehlerwahrscheinlichkeit bei Lösung des gleichen Problems. > Und wäre Windows in Assembler geschrieben würd es vielleicht auch > zuverlässig laufen Nein: es würde gar kein Windows geben, sondern MS-DOS 32.0.
Patrick L. schrieb: > Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man > damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw. > Prozessor nah programmieren muss... Für ultrakleine Programme mag das ja richtig sein. Aber ab einer bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die Maschine (sprich Compiler) besser optimieren kann als der Mensch (in Assembler). Hier in diesem Thread wurde sogar gezeigt, dass auch kleine Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. > Und wäre Windows in Assembler geschrieben würd es vielleicht auch > zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch > öfters als Win 7 oder gar XP...... Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von Win7 irgendwann im Jahre 2107 gewesen. Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle schon durchgekaut wurden. Vielleicht willst Du aber auch nur provozieren... Moby Version 2.0...
:
Bearbeitet durch Moderator
Frank M. schrieb: > .....Für ultrakleine Programme mag das ja richtig sein. Aber ab einer > bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die > Maschine (sprich Compiler) besser optimieren kann als der Mensch (in > Assembler)....... ...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren Erfahrung nicht teile........ > Hier in diesem Thread wurde sogar gezeigt, dass auch kleine > Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. > .... ....lass ich auch stehen, kommt aber auch da auf das wissen und können des Programmierers an...... > ........ > Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von > Win7 irgendwann im Jahre 2107 gewesen. > .... ....finde, Ist ein bisschen übertrieben, aber da will ich mich nict drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben die in GB Bereich reichen....Wen unser Kunde das will weil FDA das vorschreibt, tun wir das...... > Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein > die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal > komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle > schon durchgekaut wurden. > ..... ...Ohhh sorry, erwähne ich weil ich mich über Windows und über seine Zuverlässigkeit immer wieder ärgere, da aber leider viel Werkzeug das wir haben müssen nur unter Windows laufen :(... ....und....ich habe sehr viel im Thread gelesen ja... aber um so einen Langen Thread durchzulesen fehlt mir die Zeit....Also bitte etwas Toleranz ja in Bezug auf die.... > ... die Nettiquette gebietet es, .... .... irgend wann sind die Threads zu lange...... > Vielleicht willst Du aber auch nur provozieren... ....nein will ich nicht.... Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird und dabei vergessen wird dass es halt doch Vorzüge hat und auch die Mutter aller Programmiersprachen ist den das Kind (der uC) spricht nun mal in den meisten fällen diese Sprache.... Und ändert auch nix daran das speziell wir damit arbeiten müssen weil es nun mal nicht anders geht. Wir haben diese Vorschriften nicht gemacht aber wenn wir liefern wollen müssen wir uns daran halten. Und wenn keiner Assembler Programmieren könnte würde es sehr schlecht um neue Prozessoren stehen den sie so Aufzubauen das sie von Haus aus eine Hochsprache sprechen ist derart aufwendig, das auch wir dieses Projekt eines "C" Prozessors stillgelegt haben. Der Prototyp den wir entwickelt hatten brauchte 10 x soviel Chipfläche wie ein Vergleichbaren Maschinencode basierenden Prozessor. Aber ein Punkt muss ich dir lassen, Unser "C" Prozessor Prototyp ist gut im Factor >100 schneller als jeder andere den wir bis heute entwickelt hatten. Den er kan somit oft Mehrere hundert Befehle in einem Cyclus abarbeiten... Leider kann man Ihn bedingt durch seinen Platzaufwand und Komplexität auf dem Waver nicht bezahlen.. Ca 5 Mio würde er kosten bis er ausgereift ist.... Und deshalb wollen wir auch den Guten Mann der über 30 Jahre bei uns gearbeitet hat auch wieder ersetzen, ....es geht nicht ohne Assembler.... Lieben Gruß
Patrick L. schrieb: > Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird Ach was: keiner hier behandelt den „abschätzig“. Man sollte nur keinen Hype draus machen, genau das hatte der Thread aber mal bezweckt.
Patrick L. schrieb: > wir haben Komplexe Programme in Assembler geschrieben > die in GB Bereich reichen Da wäre doch mal interessant zu erfahren um was es da geht. Erzähl doch mal...
Patrick L. schrieb: > ....finde, Ist ein bisschen übertrieben, aber da will ich mich nict > drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben > die in GB Bereich reichen....Wen unser Kunde das will weil FDA das > vorschreibt, tun wir das...... Ihr würdest wahrscheinlich auch eine Weltumrundung auf Händen und Knien machen wenn euer Kunde das von euch verlangt. Aber dann zu argumentieren dies wäre irgendwie sinnvoll oder gar nicht Wahnsinnig, ist eben lächerlich.
Jörg W. schrieb: > Man sollte nur keinen Hype draus machen, genau das hatte der Thread > aber mal bezweckt. AAARRRG Sorry jetzt wo du es sagst....Grmpf..habe mich doch echt Mitreißen lassen :'(....... ...Das habe ich nicht bemerkt aber es ist so da hast du 10000% Recht..... Hätte wohl lieber einen Neuen Thread aufgemacht so ala .. ....Programmierer in Assembler gesucht..... Grumpf...werde wohl doch langsam ALT..... GRINS Aber denke auch da wär's zur Provokation geworden... weil... Habe Viele Threads, hier im Forum gefunden die mit Assembler zu tun haben aber meistens wird's eine Schlammschlacht, desshalb. Kurz im Google "Assembler Programmierer gesucht" und hier gelandet.... Nochmals Sorry dass ich mich hab Hinreißen lassen.. Hat wohl meine Ehre etwas angekratzt, weil ich seit rund 50 Jahre in Assembler Programmiere.... Gruß....
Hast du eigentlich einen Punkte-Fetisch? Übel zu lesen deine Posts. Kommt das von zu viel Assembler?
das mit dem "windows in ASM" ist schon sehr abenteuerlich.. (das ist ja maximal ein troll verusch) was ich nicht verstehe: wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer) komplett neuem befehlssatz.. ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch "große programme" damit schreiben (wozu auch??) würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen compiler-compiler mit dem neuen befehlssatz beauftragen.. und hätte dann gleich einen riesen Satz an Testroutinen von der letzten CPU die ich entwickelt habe.. (ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit millionenfach verwendetem compiler..?!)
:
Bearbeitet durch User
Hmmm jaahhhhh Punkte sind doch Cool, beim Kommentieren Praktisch, zeigen sie doch im Liesting wo was hingehört. LOL So Von mir aus tippt was ihr wollt, GRINS. der thread ist eindeutig Provokativ, ziht Provokationen an und dient nicht dem Zweck welchen ich gedacht habe.
>weil ich seit rund 50 Jahre in Assembler >Programmiere. und da suchst du JETZT einen Assembler programmieren? besser spät als nie ist ja wie bei der NASA ;-) http://www.heise.de/newsticker/meldung/NASA-sucht-Programmierer-fuer-Voyager-Sonden-2866565.html
Patrick L. schrieb: > der thread [...] dient nicht dem Zweck welchen ich gedacht habe. Korrekt. Wenn Du einen Assembler-Programmierer suchst, kannst Du hier eine Stellenanzeige schalten: https://www.mikrocontroller.net/jobs/info Ein Diskussionsthread wie dieser ist gewiss nicht dafür geeignet.
Patrick L. schrieb: > Aber denke auch da wär's zur Provokation geworden... weil... ...zu diesem Thema schon alles gesagt wurde. Nur noch nicht von jedem. Weil bei diesem Thema immer so lange polarisiert wird, bis keine Seite bereit ist, von ihrer Position abzurücken. Weil es einfach nur nervt, immer wieder das gleiche Zeug rauszukramen. Wie bei den unzähligen Windows/Linux-Debatten. Haben die schon ein einziges Mal zu etwas geführt? Das sind nichts anderes als Trolldebatten.
nur noch schnell: Patrick L. schrieb: > und auch genau so verhält es sich bei den Hochsprachen > für uC die Compiler oder gar Interpreter sind nie Perfekt. warum habt ihr nicht einfach selber den Compiler in ASM geschrieben, dann wäre er Perfekt ;-)
Sorry Robert L. Wir haben wohl gleichzeitig geschrieben war nicht auf dich bezogen. Robert L. schrieb: > das mit dem "windows in ASM" ist schon sehr abenteuerlich.. > (das ist ja maximal ein troll verusch) Hmmm oder eben gewollt vom Threadersteller zu provozieren, hat ja auch wunderbar geklappt. > > was ich nicht verstehe: > > wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer) > komplett neuem befehlssatz.. > ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch > "große programme" damit schreiben (wozu auch??) Weil es nun mal Vorgeschrieben ist, für gewisse Anwendungen den bsw unterstützen sehr viele Hochsprachen oft gewisse gesonderte wirkungsvolle Befehle der CPU Nicht.(Ja und auch ganz besonders in der heutigen Zeit) Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl den "LDIR" befahl nicht nutze, dabei war es eben wie hier eine reine Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu generieren, was die Z80 C compiler damals taten, ist die Software 100x schneller und auch Stackoverflow sicher, wenn interuppts in die Verschiebeschlaufe geraten. Und genau an solchen Sachen setzt wahrscheinlich auch die Vorschrift der FDA an > > > würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen > compiler-compiler mit dem neuen befehlssatz beauftragen.. > muss ich das Verstehen? wie meinst du das? > (ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG > hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit > millionenfach verwendetem compiler..?!) Och Bugs? das haben auch heute noch die meisten CPU's die Errata's der Hersteller sind oft Abenteuerlich GRINS.
Bei Assemblerleuten heißen Schleifen also "Schlaufen". Man lernt ja nie aus.
Patrick L. schrieb: > Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C > Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl > den "LDIR" befahl nicht nutze, Damals - in den 80ern - also ungefähr die 50 Jahre her, seitdem Du bereits in Assembler programmierst, waren die C-Compiler noch ziemlich unterbelichtet. Ein memcpy() in C (was Deinem LDIR in Z80 Assembler gleichkommt) war halt eine Schleife ohne irgendwelche prozessorspezifische Optimierungen. Das hat sich erst mit den 3B-Prozessoren von AT&T geändert, welche solche C-Funktionen wie memcpy() und strcpy() direkt als Assembler-Befehl kannten. > dabei war es eben wie hier eine reine > Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu > generieren, was die Z80 C compiler damals taten, ist die Software 100x > schneller und auch Stackoverflow sicher, wenn interuppts in die > Verschiebeschlaufe geraten. Ein LDIR schützt Dich nicht automatisch gegen Stackoverflow. Da waren Deine Interrupt-Routinen eher nicht sauber genug programmiert bzgl. Register-Rettung.
Lies die anderen 2K Beiträge dann verstehst Du das kaum einer der Meinung ist es gäbe keinen Anwendungsfall für ASM. Einige wenige sind aber der Meinung ASM wäre immer und in jedem Fall überlegen was nun wirklich vollkommener Humbug ist. Die Mehrheit ist nur der Meinung das es eben sehr, sehr wenig Gründe gibt heute noch exzessiv ASM zu verwenden wenn entsprechende Compiler und fortschrittliche CPUs zur Verfügung stehen um auch damit sicherheitsrelevante Software zu schreiben. Das alles von Dir beschriebene in 2K Flash + 128B Ram zu bekommen ist wahrlich eine Heroische Tat und ich werde Eure ASM Coder lobend in meinem Nachtgebet erwähnen. Im Regelfall halte ich aber einen anderen Controller für die bessere Wahl.
Frank M. schrieb: > welche solche C-Funktionen wie > memcpy() und strcpy() direkt als Assembler-Befehl kannten. Bloss um dann festzustellen, dass solche Funktionen explizit ausprogrammiert und optimiert oft schneller sind, als eventuell vorhandenen Prozessorbefehle fürs Speicherschaufeln.
Wahrheiten hängen ja zuweilen daran, wer es sagt... Solche aktuellen Meldungen renommierter Fachmedien sprechen jedenfalls nicht gerade von einem furiosen Asm-Niedergang: http://www.elektroniknet.de/markt-technik/embedded/assembler-boomt-134158.html http://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Assembler-stabil-Go-im-Aufwind-3458803.html Frank M. schrieb: > Hier in diesem Thread wurde sogar gezeigt, dass auch kleine > Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. Mit einem gewissen C-Know-How, das hat auch nicht jeder! In https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C stellst Du ja für zumindest mal für die Anwendung Bootloader selber fest: "Jedoch sind diese Bootloader allesamt in Assembler realisiert, denn nur hier hat der Programmierer alle Freiheiten, die er braucht, um die Speicherverwaltung im SRAM (und auch im Flash) selbst zu kontrollieren. C (hier im speziellen avr-gcc) ermöglicht es eigentlich nicht, ohne größere Klimmzüge einen Bootloader für ATtinys zu programmieren" oder "Da ein in Assembler geschriebener Bootloader in der Regel viel weniger Speicherplatz benötigt und daher effizienter auf einem kleinen µC ist als ein in C programmierter Bootloader, ist dieser Artikel eher akademischer Natur" So ist es. Dieses Ansinnen bleibt von Natur aus meist akademisch :)
Christian M. schrieb: > In > https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C > stellst Du ja für zumindest mal für die Anwendung Bootloader selber > fest: > [...] Diese Vorgehensweise, Bruchstücke, die nur in einem sehr speziellen Fall gelten (nämlich Bootloader für ATTiny) zu verallgemeinern, kommt mir sehr sehr bekannt vor - und zwar nicht gerade im angenehmen Sinne. Schon für ATmegas gilt diese Aussage nicht mehr. Hier wäre C ganz klar mein Favorit für einen Bootloader. Und das nicht, weil mehr Flash/RAM zur Verfügung steht, sondern weil hier der Bootloader eine eigene Interrupt-Vektor-Tabelle und einen geschützten Bootloader-Bereich hat. Genau diese Problematik macht es einem C-Programmierer schwer, einen Bootloader spziell für ATTinys in C zu formulieren. Das steht auch so klar in dem zitierten Artikel. Dein Argument ist nicht verallgemeinerbar. Und daher hinfällig.
Für den Tiny841 habe ich ebenfalls einen Bootloader komplett in C geschrieben.
Wieso wird hier denn wieder diskutiert? Dachte alles sei geklärt, sogar Moby musste damals seine Niederlage eingestehen (was er immerhin auch tat!). Assembler mag für Nischenanwendungen oder Hobby interessant sein, das wars aber auch. Alles was irgendwie kommerziell ist wird schon nicht mehr in ASM gemacht, von kleinsten Codestellen (z.B. startup-Code) abgesehen. Das ASM nicht total verschwindet ist der Technik und Historie geschuldet: Prozessoren "sprechen" erstmal nur Assembler. Deswegen wird er auch nie verschwinden. 99,5% der Anwender müssen aber damit nicht in Berührung kommen.
Patrick L. schrieb: > ...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren > Erfahrung nicht teile........ Patrick L. schrieb: > weil ich seit rund 50 Jahre in Assembler > Programmiere.... wie die Zeit vergeht
Thread beobachten
Seitenaufteilung abschalten