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!
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
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.
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?
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
;-)
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!
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 (
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:> 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 ;-)
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. ;-)
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
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.
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:
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.
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.
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̶
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> kriegenBeitrag "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.....
> 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...
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ß....
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..?!)
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.
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.
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.htmlhttp://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Assembler-stabil-Go-im-Aufwind-3458803.htmlFrank 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.
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