Beim sh2a liegt der Unterschied irgendwo beim Faktor 2-3 in der Geschwindigkeit beim dekodieren eines MP3-Frames.
Das bedeutet das der SH7262 mit libmad ohne jede Assembleroptimierung MP3 mit bis zu 256kbit abspielt und bei 320kbit aufgibt. Beim gcc schaffe ich mit Assembleroptimierung (siehe mein anderes Posting)
128kbit, aber bereits bei 192kbit laeuft mein Buffer leer.
Allerdings weiss ich nicht ob der gcc gerade beim sh2a besonders schlecht ist. Vielleicht ist es bei anderen CPUs nicht so schlimm. Immerhin hat der Controller ja eine Reihe von Besonderheiten und ist noch ziemlich neu.
Bei den R8C/M16C, wo ich ebenfalls beide Compiler nutze sind mir so grosse Unterschiede noch nicht aufgefallen. Allerdings habe ich da auch noch nichts programmiert wo es auf jede Millisekunde angekommen ist.
Voraussetzung: Ich habe eine größere Aufgabe zu erledigen. Relativ komplizierte Steuerung, Webserver zur Konfiguration, Datenlogger per Speicherkarte, grafisches Display, evtl. noch ein bisschen USB-Peripherie und was einem sonst noch einfällt.
Das *könnte* ich unter Umständen komplett in einem fetten µC-Programm machen. Ich würde es aber eher so machen, dass ich ein ARM-/MIPS oder gar i386-Board nehme, Linux draufspiele und da programmiere. Ausschließlich das, was ich von der Reaktionszeit damit nicht mehr hinbekomme, lagere ich in einen oder mehrere µCs aus.
Schnellerer Prozessor == halbe Entwicklungszeit? So meinst du das sicher nicht.
Tauschen wir "schnellerer Prozessor" gegen "irgendwas, wo ein fertiges OS samt fertiger Software drauf läuft" ist das die ganze Zeit mein Argument.
Ich kann's aber noch einmal genauer formulieren: "Wenn ich soweit bin, dass ich C auf einem µC verwenden will, weil mir sonst der Code zu verwirrend gerät und mir die Timing-Unsicherheit für 99% des Codes ohnehin nichts ausmacht, sollte ich überlegen, ob ich nicht lieber gleich den µC zum Sklaven eines größeren Prozessors mit OS mache, das ganze komplizierte Zeug auf jenen auslagere, wo ich ganz allgemein mehr fertig entwickelte Software geschenkt bekomme, und in dem µC nur das ganze zeitkritische Zeug (dann wieder in Assembler) mache."
Das nimmt sich meiner Erfahrung nach überhaupt nichts. Ohne Kommentare versteht man weder C-Code noch Assembler nach wenigen Wochen. Vor allem, wenn es wie auf einem µC nur Bitschiebereien sind.
Darin ist C Assembler sowieso nicht unähnlich. Man gewinnt Blöcke, Funktionen und ein paar grundlegende Kontrollstrukturen, erkauft sich das aber durch Initialisierungscode, den man sich nicht anguckt ("geht doch"), Stackjongliererei, die man sich nicht anguckt ("geht doch"), Registerschieberei, die man sich nicht anguckt ("geht doch"), bastelt Interruptroutinen, ohne sich genauere Gedanken über die Interruptlogik dieses Prozessors zu machen ("geht doch"), bastelt mit Timern rum, ohne sich genauere Gedanken über Jitter zu machen ("geht doch") usw usw usw. Die Liste ließe sich fast ewig fortsetzen.
Und wenn's dann nicht geht weil der Stack im Betrieb in die Variablen reinläuft oder drei Interrupts gleichzeitig kamen und sich keiner Gedanken über die Reihenfolge gemacht hat dann kommt man hoffentlich auf die Idee, dass aus der C-Source soviel impliziter Code erzeugt wird, dass man ohne genaueste Kenntnis des Compilers anhand des C-Codes überhaupt nicht verstehen kann, was das Programm nun eigentlich tut.
Beim AVR macht er das vor allem deshalb, weil es gar kein ADDI gibt. ;-) Das haben die Compilerbauer von IAR seinerzeit den Norwegern ausgeredet, nachdem ihnen das CPU-Konzept zum Review vorgelegt worden ist, weil es einem Compiler halt völlig wurscht ist, welchen der beiden Befehle er benutzt ("gefühlsmäßig" kann er ohnehin nicht entscheiden), und weil man auf diese Weise opcodes für wichtigere Dinge frei bekommen hat.
Allerdings ist der "Beweis" für die "schlechte Optimierung" eines Compilers an derart degenerierten Beispielen natürlich immer ganz einfach zu führen. Jeder, der auch nur minimal der Assemblersprache des Prozessors mächtig ist, wäre in der Lage, das bisschen gut überschaubaren Code relativ schnell optimal aufzuschreiben. Interessant wird das erst, wenn die Projekte etwas größer sind und nicht mehr komplett in den Kopf hinein passen. Meine persönliche Schätzung geht dann auf ein Verhältnis im Wartungsaufwand zwischen C und Assembler von 1:10, bei vielleicht maximal 20 % Einsparung an Code und/oder Laufzeit.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Ich programmiere fette Anwendungen auf grossen Controllern. Frueher waren das 68332, mittlerweile ein R32C mit 384kByte Flash und 1MByte extenes Ram. Die Anwendung belegt etwa 80% vom Flash. Da steckt insgesamt 10Jahre Entwicklung drin und so 60-70% des Codes konnte ich vom 68332 auf den R32 mitnehmen. Natuerlich nur weil das nicht Assembler ist. Ein Betriebsystem wie Linux ist nicht akzeptabel weil das die notwendige Hardware zu sehr aufblaeht und beim ahnungslosen Kunden oder Servicetechniker ein grauen ist. Hinzu kommt das die Umweltbedingungen sehr heftig sind. Es gibt natuerlich fertig PCs die das koennen. Die liegen dann bei einigen kEuro und koennen dann noch nichtmal die ganzen Aktoren und Sensoren ansteuern. Ausserdem gibt es Leute die erwarten das sie ihre Geraete einfach ein und ausschalten koennen! Kein booten oder runterfahren. Und wenn es Geraete sind die
24/7 laufen dann ist der Stromverbrauch auch interessant.
Ich bin wirklich Linuxuser der ersten Stunde (seit 0.95a) und es ist privat mein Hauptsystem seit der ersten Version von SLS, aber fuer firmenmaessigen Einsatz wuerde ich mir das sehr gut ueberlegen. Olaf
Und selbst das ist noch zweifelhaft. Nimm mal die Assemblerooptimierung zur Multiplikation die ich hier gerade angefragt habe. Sowas bekommt man natuerlich selber viel besser hin weil man weiss wie die Ergebnisse auszusehen haben. (Wertebereich) Aber wenn man derartige Optimierungen macht und kopiert das dann zwei Jahre spaeter in ein anderes Project rueber, dann kann man heftig auf die Schnauze fallen.
Da kann ich nur zustimmen. Ich habe ziemlich fette Sachen laufen wo haeufig auf Kundenwunsch und gegen Kundengeld Sonderwuensche erfuellt werden und ich in viele Jahre zurueckliegenden Code rumbasteln muss. Da achte ich selbst unter C darauf alles perfekt dokumentiert zu haben. In Assembler einfach nicht vorstellbar.
Ich hab darueber nachgedacht, aber so richtig zu schaetzen weiss man das eigentlich nur wenn man den Assembler-Code sieht wenn man dabei gleichzeitig mit dem Debugger im SingleStep durch den Code geht.
Logisch. Du hast halt vor 10 Jahren so angefangen, weil es damals kaum anders ging, und jetzt bleibst du dabei. Würde ich vermutlich auch. Solange, bis ich das ganze Zeug komplett entsorgen kann.
Wenn das Ding ohnehin ein grafisches Display mit schicker GUI braucht sieht die Welt schon wieder anders aus. Gleiches mit Webserver zur Konfiguration usw. Da können Eigenentwicklungen sehr schmerzhaft sein.
Eine selbstgebastelte Linux-Distributon verlangt dem Techniker und dem Kunden genauso wenig ab. Die Interna bekommt er ja gar nicht zu sehen.
Das ist ein gutes Argument gegen Fertig-PCs, aber nicht gegen irgendein Embedded-Board.
Einfach Ausschalten kann man immer dann, wenn die Dateisysteme normalerweise alle Readonly gemountet sind und von der Anwendung jeweils nur zum schreiben kurz anders gemountet werden. Kann im Einzelfall natürlich trickreich sein, z.B. mit zwei Ständen, die abwechselnd geschrieben werden, so dass mindestens einer grundsätzlich heil bleibt.
Und die Bootzeit liegt bei guten Embedded-Boards bei Und wenn es Geraete
Ja, damit hast du sicher recht. Allerdings schlägt beim Stromverbrauch eher die Peripherie zu. Die CPUs selbst sind meist sparsam.
Das funzt meist besser als alles was man selbst in vernünftiger Zeit zusammenbauen kann.
Schönes Beispiel. Also jedenfalls ein schönes Beispiel dafür, wo wohl niemand (in Worten: keiner) auf die Idee käme, das alternativ komplett in Assembler zu programmieren. Jedenfalls heutzutage. Leider gerade kein Beispiel für eine Programmierung, die der eine in Assembler macht und der andere lieber in C.
In Assembler? Will ich sehen. Klar geht das, aber so bekloppt ist ja nun niemand.
Klar. Aber was hat das mit Anwendungen zu tun, die man durchaus und ohne ernsthafte Probleme in Assembler realisieren könnte, die man aber eben dennoch in C (o.ä.) realisiert, weil der Unterschied in Platz und Performance der Rede nicht wert ist. Davon sprachen wir hier doch.
Nein. Aber mit einem schnelleren Prozessor kannst Du eine Hochsprache einsetzen und sparst darüber Entwicklungszeit.
Eben nicht. Du willst daran ja für die zeitkritischen Sachen µC hängen.
Überlegen kannst Du das natürlich schon. Aber je nachdem, was Du machen willst, ist das dann eben mit Kanonen auf Spatzen geschossen. Die Alternative, Assembler oder gleich 'nen kompletten PC (um das mal etwas zu überspitzen) ist mir denn doch zu simpel.
Das wollte ich damit auch gar nicht sagen. Aber in C kann ich (mit gutem Codegenerator) eine Konstruktion so hinschreiben, wie ich sie meine und der Compiler macht daraus trotzdem eine effizienteren Code. Nimm z.B. eine Multiplikation mit 9 auf einem x86 (mit x>=3). Wenn Dir der Compiler daraus ein lea bastelt, stört Dich das gar nicht. In Assembler mußt Du erstmal überhaupt dran denken und das dann nochmal zusätzlich kommentieren. Und das ist jetzt nur ein banales Beispiel. Solch eine Mimik in der Schleife, die wir hier als Beispiel hatten, wo der Increment nicht an der Stelle passiert, an der man es erwartet, kann man ja durchaus auch durch eine geschickte Optimierung erwischen und damit tatsächlich ein paar Takte sparen. Aber lesen will man sowas nicht mehr. Und nie und nimmer mehr will man das lesen, wenn der Optimierer die Befehle so umsortiert hat, daß die Wartezeiten innerhalb der Ausführungsketten minimiert werden.
Je nun. Zu wissen, was man tut, ist in jedem Fall keine schlechte Idee. Spätestens dann, wenn man ansonsten Gefahr läuft, daß die Sache nicht funktioniert. Das hat aber überhaupt nichts mit der verwendeten Programmiersprache zu tun.
Ich weiß nicht, ob das wirklich ein Vorteil von Assembler ist, daß man sich da in jedem Fall einen Kopf über jeden einzelnen Befehl machen muß, während man das in höheren Programmiersprachen nur in bestimmten Fällen muß. Und daß man sich über das Speicherlayout Gedanken machen muß, das ist nun wirklich nicht assemblerspezifisch. Und auch ein Compiler kann bei Bedarf beim Funktionseintritt prüfen, ob noch genug Platz auf dem Stack ist. Das sagst Du ihm einmal und gut ist's. Beim Assembler mußt Du zumindest an jeden Prozeduranfang ein entsprechendes Macro setzen.
Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.
Genau das sage ich die ganze Zeit. Diesen ganzen Mist will ich weder in Assembler noch in C programmieren. Den gibt es bereits fertig programmiert, und das will ich nutzen können. Und dann ist mit µC recht schnell Ende. Dann brauche ich ohnehin ein Board mit OS. Einen µC brauche ich dann nur noch für die Sachen, die das Board mit OS von der Reaktionszeit her nicht schafft. Und weil ich's in dem Fall *richtig* fix brauche, mache ich die
1..2k an Code für den µC, die dann noch übrig bleiben, in Assembler.
Aber mir wird das jetzt zu mühselig. Ich gebe auf. Ihr habt alle Recht und jeder tue weiterhin, was er für richtig halte. Frohe Weihnacht.
Sie aktuellen P-Versionen der AVRs sind mittlerweile auch recht sparsam, reichen vmtl. als "oder so" fuer viele Anwendungen aus.
Und "richtig" und "falsch" ist hier kein Argument, eine Anwendung die nichts anderes tut ausser Stromsparen ist schliesslich sinnfrei. Sonstige Anforderungen hatte ich aber gar keine genannt.
Micha
--
Irgendwann wird die Welt untergehen und das juengste Gericht kommen,
steht in der Bibel. Aber sicher nicht aufgrund des Fehlens von
Railtaxis ;-)
Joerg in defa
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.