On Di, 2012-11-06 at 12:11 +0100, Richard Weickelt wrote: > Hi, > > > Dein Patch ist mir syntaktisch zwar nicht ganz klar, aber wahrscheinlich > > ist es sinnvoller die Basisinformationen in einem Bitfeld zu vereinen. > > Deine Aussage ist mir semantisch nicht ganz klar. Aber ich habe den Patch > etwas modifziert, sodass er auch mit C++03 kompiliert und sich nur auf den > Scheduler und die Activity beschränkt. RAM-Ersparnis auf dem atmega: 2 Byte > pro Aktivität. Bei 25 Aktivitäten und 1KiB RAM ist das nicht unbedeutend.
Ja ich stimme dir zu, wir sollten oft verwendete Programmteile so klein wie möglich halten. > > Nachvollziehen kann ich nicht, dass es weniger Code produziert. Und da > > Möglicherweise nur weniger Code auf dem atmega, da dort uint16-Zugriffe > generell mehr Code erzeugen als Operationen auf uint8. Enums werden bei > C++03 immer auf mindestens 16Bit Datentypen abgebildet, da lohnt sich die > Verkleinerung bei 8Bit-Architekturen. Ja aber dein Patch hat doch letztlich nichts mehr mit dem Enum zu tun. Da ist doch egal wie gross der Datentyp deines Enumerators ist, da du ihn sowieso auf einen uint8 castest. Ok eventuell bei deinen überladenen Operatoren, aber die werden doch ohnehin übern Jordan davon kompiliert. > > Aber letztlich ist es doch eine Interessante Anforderung, eben Reflex > > auch für wirklich kleine Plattformen verwenden zu können. Ist das > > wirklich so ein verlorener Gedanke oder ist der Aufwand es klein und für > > mehrere Plattformen anbieten zu können abwegig? > > Der Aufwand steigt immer dann immens, wenn man dem Perfektionsnismus fröhnt. > Ich halte es für ein ehrenwertes Ziel, den REFLEX-Kern modellieren zu > wollen, aber wieviel Freizeit würdest Du dafür opfern? Oder siehst Du etwa > einen Weg, Deinen Arbeitgeber dafür zu begeistern? Ehrenwert ist dieses Ziel in jedem Fall, zumal denke ich, dass ein sauber modellierter kleiner Kern, langfristig Aufwand spart. Jedoch mit entsprechender hoher Anfangsinvestition. Mein Arbeitgeber kann dafür nicht begeistert werden, da nur bezahlbare Lösungen im Fokus stehen. Zudem ist der modellierte Teil einfacher verständlich und halb dokumentiert. Jedoch sehe ich derzeit keine Tools, welche diese Anforderungen der Modellierung bringen. Letztlich ist es doch auch nur eine leicht verständliche Abstraktion, welche ohne Codegenerierung nur als formalere Dokumentation angesehen werden kann. Da ist es in der Tat fraglich ob der Aufwand überhaupt rechtens ist. Zumindest hier erscheint es als übereifrig. Jedoch hat die Forschung schon seit längeren Modellierung propagiert. Und meines Erachtens werden sicherheitsrelevante System eben nicht auf der lowlevel Ebene produziert. Weil einfach zu viele Fehler passieren. Zudem können Echtzeitanforderungen bereits im Modell vernichtet werden und nicht erst während des Jungfernfluges. Aber diese tools generieren keinen C++ Code. Da stellt sich die Frage ist C++ nicht vielleicht zu generall purpose als backend. Betrachten wir doch nurmal die Anzahl der Seiten des Standards. Die C++ Abhängigkeit ist derzeit der Killer. Wir können nur hoffen, dass der gcc weiterhin so gut und qualitativ hochwertig entwickelt wird. Beispiel 8051, da wird nie ein Reflexsystem laufen können. Aber was ist denn letztlich ein Reflexsystem. Eigentlich doch nur ein Bunch von Komponenten welche ereignisgesteuert im Zusammenhang eine echtzeitfähige Anwendung beschreiben. Der Vorteil von Ereignisgetriebenen Konzepten wird erst jetzt von der IT-Community verstanden, das zeigt der Hype um nodejs. Skaliert einfach besser und verbraucht nicht sinnlos Ressourcen. Bleibt noch der Punkt der Echtzeitfähigkeit. Wir behaupten das Reflex ein echtzeitfähiges Betriebssystem sei. Ein Betriebssystem kann aber nie alleine Echtzeitfähig sein. Es ist die echtzeitfähige Anwendung, die es ermöglicht. Das sagt auch der Name. Realtime Eventflow Executive. Jedoch behaupten wir es nur und können es nicht beweisen. Ich habe jedenfalls noch nie einen Beweis mit Reflex gesehen. Also, stellt sich die Frage, wollen wir an der Echtzeitfähigkeit festhalten, oder wollen wir es weiterhin behaupten wir seien es, nutzen es aber selbst nirgens. Ich sehe, dass gerade im Kern erst einmal Struktur und vor allem Einigkeit notwendig ist. Zuvor jedoch sollten gemeinsame Ziele definiert werden. Mit der derzeitigen Implementierung ist man zwar mehr oder weniger produktiv, aber sie entspricht keinster Weise den Versprechungen. Nichteinmal die verschiedenen Ports sind einheitlich implementiert. Die Aktivitäten sind eigentlich nur als Funktoren einsetzbar, Interrupts plagen sich mit den Powermanageable Abfall herum der in 90% der Fälle leer ist, wir können keine statischen Libraries kompilieren, da wir im Kern Abhängigkeiten zur Anwendung haben (getApplication), Die Ports müssen vor jeder Verwendung durch den Benutzer überprüft werden ob sie nicht doch null sind, obwohl man dies durch ein einfaches Nullobjekt lösen kann, was bereits gezeigt wurde. Die Codebasis hat so viele Stämme (trunk), dass sogar derzeit nicht ersichtlich ist, wo denn nun entwickelt wird. Wir haben keine Dokumentation, kein einheitliches Konzept keine Struktur keinen Plan keine Führung keine Community und somit keine Zukunft. Wir sollten aufwachen! -- mit freundlichem Gruß, Sören Höckner
