Wie ich ihn kenne, hat er gleich nen guten Rat zur Hand. Er ist uebrigens ein Wanderer zwischen den Welten, immer ein Vierteljahr in der "alten" Welt und dann wieder ein Vierteljahr in den USA. Sein dortiges Anwesen kann man sich ansehen, wenn man auf seiner Homepage auf die gelbe Blume oberhalb der Stuhllehne klickt. Dann sieht man das Haus und auch seine "Menagerie".
A propos, was gibt es denn neues vom vierbeinigen Familienmitglied. Du hattest da mal ein Bild gezeigt. Ich mag Labradore, unsere Huendin ist jetzt schon ueber 5200 Tage alt. Bis auf fast voelligen Verlust des Gehoers kerngesund.
Ja, aber der unbedarfte Programmierer benutzt eben erstmal gerne was zur Verfuegung steht (wenn es ihm auf abstrakter Ebene sinnvoll erscheint).
Da bin ich ganz anderer Meinung. Was man von Hand programmiert, das sieht man. Das eingebaute Zeug ist ploetzlich da weil man irgendein Sprachfeature benutzt hat, da gibt es sicher genug Programmierer die da unbewusst Zeug reinziehen das sie - wenn sie es ausgebreitet sehen koennten - niemals genommen haetten (und auch nicht so oder aehnlich nachgebaut haetten).
Das bestaetigt doch aber zumindest meine anfaengliche Aussage (dass Codegroesse bzw. Performance und Sprache in der Praxis eben schon zusammenhaengen) wenn auch mit anderer Begruendung.
Und du findest das verwunderlich? Man interessiert sich halt mehr fuer das eine oder das andere, Hard- und Software sind halt doch ziemlich verschiedene Gebiete. Deswegen passen C++ und MC auch IMHO nicht so gut zusammen. Der PC-Programmierer will sich nicht auf dieses "unabstrakte" Niveau herablassen und der Hardwareentwickler will nicht jedes simple, ueberschaubare Problem per Abstraktion unnoetig "aufblasen".
Das ist IMHO offensichtlich: Sie haben eben andere Interessen und genau deswegen nicht Informatik studiert.
Genau das ist der Punkt.
Ich unterstelle mal, dass da oft die Rules fuer C++ auf dem PC 1:1 uebernommen werden.
Auch auf dem 8bitter sind Interrupthandler teilweise ein Problem. Manchmal will man die ganz simplen einfach in Assembler schreiben weil der Compiler sie nicht wirklich gut hinbekommt (zuviele Register "pushed" beispielsweise).
Ich wuerde das so sehen.
Das waere sicher interessant, wir werden so aber IMHO nur beweisen was im best case moeglich ist. Veroeffentlicht werden wird ja sicher nur, was gut gelungen ist. Wer wird hier schon oeffentlich belegen wollen, dass er etwas nicht kann ... die Abgruende der Praxis werden wir deswegen eher nicht zu sehen bekommen ;-)
Und er ist wohl mit Greyhound Rescue aktiv. Sehr schoen, diese geplagten Tiere brauchen ein zuhause.
Sie wartet immer noch auf ihre Therapy Dog Pruefung, schwer einen Termin zu bekommen. Erst dann darf meine Frau mit ihr allein in Altenheime und Krankenhaeuser. Aber sie ist schon fleissig mit dabei, in einer Gruppe, dann darf sie. In der Buecherei lesen ihr Kinder vor, denn man hat festgestellt dass sie dann schneller lesen lernen. Hunde kritisieren nicht rum. Lustig war als ein ganz kleines Kind fragte, ob denn die Huendin mal die erste Seite vorlesen koenne, hielt ihr das Buechlein hin und dann kamen die ueblichen Labrador Stirnrunzeln ...
Old Rottie ist beinahe 13 Jahre alt und heute morgen musste ich ihm zum Gassi einige Stufen runter helfen, denn es war vereist.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Das stimmt so nicht mehr. Der eigene Export wird mittlerweile recht gut wieder importiert. Wenn man aber selber LaTeX-Code in ein LyX-Dokument einfügt, kann man den Re-Import immer noch einfach außer Tritt bringen.
Richtig ist, daß LyX kein LaTeX-Editor ist (und auch nicht sein will). Das native Format hat mit LaTeX nichts zu tun, LaTeX ist nur ein Backend. Daher wird es immer Beispiele geben, für die ein Export-Import-Zyklus nicht 100% funktionert.
Nein, die Sichtweise ist meines Wissens nach immer noch dieselbe. LaTeX ist eines von mehreren Formaten, die importiert werden können, das funktioniert nur mittlerweile besser.
Dein Wissensstand ist veraltet. ReLyX (ein unwartbares perl-Skript, das hauptsächlich aus regulären Ausdrücken bestand) wurde 2003 durch tex2lyx ersetzt, ein etwas weniger unwartbares C++-Programm, das nur noch wenige regexes enthält, und zumindest ein bißchen versucht, das TeX-Modell abzubilden. Es weiß auch von den LyX-Interna, soweit es das muß.
Gerade heute wieder ein paar ms Bootzeit und ein paar dutzend kByte Code gespart, indem ich aus einigen Headerfiles das '#include ' rausgeworfen habe.
Der Header stellt eben nicht nur die Stream-Bibliotheken zur Verfügung. Dafür gibt's '#include ' und '#include '. Vielmehr definiert das Ding auch noch ein statisches Objekt, dessen Konstruktor dafür sorgt, dass die C++-Stream-Bibliothek rechtzeitig initialisiert wird. In Summe hatten wir dieses Objekt dann über Header-Abhängigkeiten ein paar hundert Mal im Code. Inzwischen sind's nur noch ein paar dutzend.
Ich find's ja deswegen gut, weil ich mir zwar die Hände an Hardware- Registern schmutzig machen kann, aber nicht überall muss. Manchmal soll ein String einfach nur ein std::string sein, aber manchmal kanns auch nicht genug dreckige Bitfummelei sein.
Im Prinzip ist die Regel ja auch gar nicht so dumm. Ohne diese Regel hast du gerne mal Fünfzigzeiler im Header, die dir deinen Code aufblasen. Das ist genau wieder so eine Sache, wo nicht jeder dran denkt.
Wenn's nicht wirklich auf den allerletzten Takt ankommt, braucht man jenseits der einfacheren Getter eigentlich keine inline-Funktionen. Die blasen bloß den Code auf. Und ich hab zumindest schon öfter von Code gehört, der den Controllerspeicher sprengt, als von Code, der auf einem eigentlich angemessenen Controller zu langsam läuft.
Also aufgrund eines anderen Programmiersprachenthreads hier in dse hab ich ja vor einiger Zeit mal einen Lisp-Interpreter in C zusammen- geschoben, der IIRC bei unter 5k gelandet ist :-)
Der 8051 hat mehrere Registerbänke, die dafür da sind, dass man eben nicht erst alle Register beim Eintritt in eine ISR sichern muss. Bei anderen Architekturen (z. B. AVR) gibt es das jedoch nicht.
Ja, das ist ein ehemaliger "Rennhund", der ausgesondert wurde. Er hat mir erzaehlt, dass Greyhounds per Gesetz nicht zu den Hunden gezaehlt werden und wenn sie nicht mehr von Nutzen sind, in die Wueste geschickt werden als Schakalfutter. Stimmt das?
Gibt es Bilder?
Hege und pflege ihn. Es ist ein Segen, wenn ein Hund so alt wird. Unser voriger, genannt Hatch, ist vor gut zwei Jahren umgekippt. Diagnose: Epilepsie. War leider nichts mehr zu machen. Wir waren alle total fertig, dann hat unser Sohn uns "was neues" angebracht.
Das kann ich mir nicht vorstellen, aber sie fristen ein trauriges Dasein. Deshalb nehmen hier viele Leute welche auf. Ist schoen zu sehen wenn sie dann ab und zu nochmal auf dem Golfplatz bei uns in der Siedlung "Vollgas" geben.
Ja, aber da sind die Sproesslinge anderer Leute drauf, sollte nicht ohne Genehmigung der Eltern ins Internet. Deshalb per PM.
Schoen, ist so eine seltener Fall mit einem blauen und einem braunen Auge. Da gibt es bei uns nur wenige.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Hach ja. Berner Sennenhund. Die 8-jährige Tochter meiner Bruders hätte soooo gern einen eigenen. Zur Zeit darf sie den der Nachbarin Gassi führen, was ja eigentlich optimal ist: keine wirkliche Verpfichtung, but all the fun.
Ziemlich feiges Viech übrigens, ich habe 3 Tage demonstratives Wohlverhalten gebraucht, bis ich sie überhaupt anfassen durfte, am besten flach auf dem Boden liegend (ich, nicht die Bernerin Paula) Geschweige denn die Nachbarin.
Gruß, Gerhard
a far cry from C and C++, or OnT, .... aber so ist das am dse-Stammtisch.
Wenn der Compiler schon nicht weiß, was gebunden werden soll, dann wird der Linker es auch nicht mehr ändern. Weak Symbols dienen dazu, daß später "harte" Symbole drüber gelinkt werden können. Damit hat man die Möglichkeit Funktionen selbst zu schreiben, die auch in der Library sind. Mit einer Optimierung hat das aber so gar nichts zu tun.
Templates generieren nur dann Code, wenn sie verwendet werden. Eine spätere Optimierung entfällt.
Irgendwie hab ich den Eindruck, wir reden nicht über das gleiche Problem.
Wer keine locals verwendet wird auch keinen Code dafür bekommen.
Bisher bin ich ganz gut ohne RTTI ausgekommen. Und was nun richtig oder falsch ist, kann ich nicht beurteilen, aber ich werde nicht alle C++ Features in C von Hand programmieren wollen. Und die Features die ich typischer Weise benutzen kosten nicht mehr, als wenn ich sie von Hand implementiere. Abgesehen davon, daß die meisten Libs sehr viel besser optimiert sind, als mein Code in angemessener Zeit jemals sein könnte.
Es geht nicht nur um das (sinnlose) Parsing zur Laufzeit, sondern auch um die dadurch unbeabsichtigt mit eingebundenen Libs wie z.B. floating point.
Ich finde es verwunderlich, wenn Leute, die in dieser Form zu wenig Ahnung haben, dafür bezahlt werden, Software zu schreiben. Eine uC zu porgrammieren hat nach meiner Meinung weniger was mit Hard- als denn mit Software zu tun. Warum machen in so vielen Firmen die "nur Hardwerker" den Job? Wie gesagt, meine Erfahrung ist halt, daß es nur wenig gute Programmierer unter den Leuten gibt, die aus der Hardware-Ecke kommen.
Und warum machen sie dann den Job? :-)
Nein, noch viel schlimmer. Es werden die unbegründeten aber sehr weit verbreiteten Vorurteile hergenommen, die sich um das Thema Embedded und C++ ranken und daraus werden dann Richtlinien in völliger Ahnungslosigkeit erstellt. Natürlich dann noch gemischt mit den auch auf PC's schlechten Coding Guidelines. Denn egal ob embedded oder riesen PC: Schlechte Guidelines führen auf jeder Plattform zu ineffizientem Code, nur auf dem PC kann man sich das ggf. leisten oder es wird gar nicht bemerkt.
Da danken wir mal dem gcc :-) Solange die ISR komplett in einer Datei steht, pusht der auch nur das, was nötig ist :-) Aber wehe man ruft 'ne Funktion in einem anderen Modul auf...
Doch doch, die Abgründe sehe ich seit Jahren täglich :-)
Na ja, aber der best case sollte doch die Entscheidungsgrundlage sein. Denn die Frage war ja, ob es gut/sinnvoll/vorteilhaft ist auch auf embedded in C++ zu schreiben. Natürlich kann man nun sagen, nein, weil die wenigsten Leute wissen, was in C++ wirklich passiert, sollte man es lassen und die "unzureichend Erfahrenen" besser auf die PC Plattform verbannen, weil dort die Porgrammierfehler tolerierbarer sind. Aber das ist ja nach meiner Meinung nicht die Antwort auf die Frage.
Wie auch immer, es wäre sicherlich für alle Programmierer mal ganz hilfreich mal auf embedded zu programmieren, damit sie sich konkret mit dem was sie tun mal ganzheitlich auseinander setzen müssen. Das würde das Gefühl für Resourcen sicherlich schärfen und hätte dann auch auf dem PC Vorteile.
Gute Idee... Es kann nicht schaden, den Gegenstand seiner Arbeit möglichst gut zu kennen.
Ich kenne "Programmierer", die mich als unfähig angesehen haben, weil ich zugegeben hatte, manchmal statt "malloc()" nur statische Arrays zu verwenden und meistens bestenfalls ASCII zu unterstützen.
Es sind aber auch wirklich zwei paar Schuhe ob man mit QTdesigner in 5 Minuten ein Programm(Skelett) mit etlichen MB Speicherbedarf zusammenklickt oder Stunden tippt, bis das erste kB gefüllt ist.
Am Tue, 23 Feb 2010 20:34:09 +0100 schrieb Klaus Rudolph:
Weil die 'nur Softwerker' ihn wahrscheinlich auch nicht viel besser hinbekommen.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
Ich habe schon immer gepredigt, daß es sehr hilfreich ist, wenn der Softwerker zumindest Ahnung von den Internas der Prozessoren hat und sich auch mal den Assemblercode ansehen kann. OK, Intel-Technologie war in der Hinsicht schon immer zum abgewöhnen. :-)
Vor allem auch ein Alptraum zum Zyklenzählen. Ich erinnere mich dunkel an den Pentiumnachfolger (P6 oder so?) mit seinen RISC-Instruktionen etc. Die Handbücher haben Hinweise darauf gegeben, wie man die Ausführungszeiten erraten könne. Eine Krankheit war, daß die Blockinstruktionen so schlecht in die Architektur integriert waren, daß man meist schneller war, den Speicher händisch in einer Schleife zu bewegen, wenn man die Kommandos in der richtigen Reihenfolge gegeben hat, um die Pipelines dichtzuhalten.
MIPS ist auch krank: "Microprocessor without interlocking pipeline stages": super Idee: Pipelines blockieren sich nicht, bei richtiger Schachtelung der Befehle hat man schon Arithmetik für die nächste Verarbeitung in der Kette, während man noch auf alte zugreifen kann. Wenn es nicht gebraucht wird, NOPs, und man ist auch nicht langsamer als vorher. Der Compiler wird es richten.
Und dann bringen sie binärkompatible Nachfolgeprozessoren raus mit längeren Pipelines, die Prozessoren mit kürzeren Pipelines mittels Interlocking aufwendig simulieren.
Am Wed, 24 Feb 2010 08:56:36 +0100 schrieb Bernd Laengerich:
Auf dieser hardwarenahen Ebene auf jeden Fall.
Er sieht dann auch dass die Compiler schon recht ordentliche Arbeit machen und wo es lohnt vielleicht doch selbst Hand anzulegen.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
Man darf das IMHO die Software-only Leute nicht machen lassen, die neigen dazu die Hardware als BlackBox sehen zu wollen die man angeblich nicht verstehen muesse ... das kann nur schiefgehen.
Weil der Kunde eine pragmatische (sprich funktionierende) Loesung haben will, und die auch noch schnell und billig. Mit einer auf dem Papier optimalen Loesung, die er zu spaet und zu einem Mondpreis bekommt wird er nicht gluecklich.
Nebenbei ist es an der Tagesordnung, dass solche Firmware auf frisch entwickelter, oft noch fehlerhafter Hardware getestet werden muss. Der Software-only Entwickler kann dann oft nicht beurteilen ob der Absturz seine Schuld ist oder ein Hardware-Bug und der Hardware-only Entwickler bekommt kein qualifiziertes Feedback um seine Schaltung zu debuggen. Die Hard- und Softwareleute schieben sich am Ende gegenseitig die Schuld zu wenn der Zeitplan aus dem Ruder laeuft und das Produkt kostet letztlich das doppelte und wird nicht rechtzeitig fertig.
Weil Programmieren auch vielen HW-Entwicklern Spass macht auch wenn sie nicht "God of C++" sind :-) Wer will schon den ganzen Tag lang immer das gleiche machen? Oder weil man sich in den Code den einem ein professioneller "Softie" schreibt erst einarbeiten muesste, pflegen tut man das Zeug ja nachher oft selbst.
Man gibt i.d.R. nur nach extern was man selbst nicht hinbekommt, schon aus Kostengruenden. Es ist einfach meistens "gut genug" wenn man es selbst macht bzw. das Preis/Leistungsverhaeltnis stimmt. Die Realitaet ist auch nicht schwarz/weiss, es gibt nicht nur perfekte und total verhunzte Software. Manchmal ist auch schon vorher klar, dass man beim naechsten Redesign vieles anders machen muss oder der Kunde dieses Modul gar nicht mehr brauchen wird ... da will dieser dann natuerlich kein Geld fuer akademische Perfektion verschwenden.
Genau, da ist eben auch ineffizienter Code gut genug (und deswegen Standard). Nimmt man halt die doppelte CPU-Power und es geht doch - kostet ja quasi nichts. Den Bloat kann jeder auf seinem PC bewundern, mal eben mit einem LabView-Button das Aequivalent von 100 MCs in die Knie zwingen ;-)
Auch ohne Funktionsaufruf erzeugt er gerne mal Bloat. Als Beispiel habe ich folgende ISR an AVR-GCC 4.2 verfuettert:
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.