Die neueste Lachnummer aus dem Gruselkabinett Objekt-Orientierter Hochsprachen-Programmierung: Das neue OS fürs Internet der Dinge, an dem Google gerade arbeitet, benötigt "gerade" mal 32-64 MB RAM. Es läuft lt. Google sogar auf Geräten, die "kein Display besitzen und nur eine geringe Leistung vorweisen". Jeder, der mal eine eigene Steuerung- ob ohne oder selbst mit Display- entworfen hat muß sich doch da veräppelt vorkommen. http://www.golem.de/news/google-i-o-spezielles-google-betriebssystem-fuer-internet-der-dinge-1505-114197.html Daß noch nicht jede Hoffung auf effiziente Programmierung in der Industrie verloren ist beweisen wenigstens die Chinesen: http://www.computerbase.de/2015-05/internet-der-dinge-huawei-kuendigt-10-kbyte-grosses-liteos-an/ Noch ein paar Schritte weiter in die richtige Richtung geht Menuet-OS: http://www.heise.de/newsticker/meldung/Mini-Betriebssystem-Assembler-OS-MenuetOS-1-0-ist-fertig-2661214.html
Vermutlich soll das OS eben nicht nur als dumme Node in einem smarten System auftreten sondern auch selbst smarte Aufgaben uebernehmen. Zum Beispiel Sprach oder Gestenerkennung wie bei den Nest Geraeten. Fuer dumme Nodes ist jegliches Betriebssystem unnoetig, die stellen ja eh nur Sensoren und Aktoren mit Bus Anbindung dar.
Moby schrieb: > Noch ein paar Schritte weiter in die richtige Richtung geht Menuet-OS: > http://www.heise.de/newsticker/meldung/Mini-Betriebssystem-Assembler-OS-MenuetOS-1-0-ist-fertig-2661214.html DAS soll die richtige Richtung sein? Alles klar. Vor 20 Jahren war noch alles besser oder? Takte zaehlen ist einfach nicht mehr noetig weil die entsprechende Leistung verfuegbar ist.
Guest schrieb: > Takte zaehlen ist einfach nicht mehr noetig weil die > entsprechende Leistung verfuegbar ist. Hier ging es zunächst mal nicht um die Takte, sondern den exorbitanten Speicherverbrauch... Die massive Beschleunigung der Software durch Assembler-realisierte effiziente Softwarearchitekturen der direkten, kurzen internen Wege ist da "nur" ein zweiter, willkommener Zusatzeffekt. Entsprechende Leistung ist zwar da, auch weil OOP diese in endloser Aufwärtsspirale beständig einfordert. Doch wäre sie eben softwaretechnisch nicht nötig. Leistung produziert Komplexität, Kosten und Stromverbrauch.
Guest schrieb: > Takte zaehlen ist einfach nicht mehr noetig weil die > entsprechende Leistung verfuegbar ist. Takte zählt heute der Compiler.
Moby schrieb: > as neue OS fürs Internet der Dinge, an dem > Google gerade arbeitet, benötigt "gerade" mal 32-64 MB RAM. IPV6, REST & SOAP, SSL, WIFI, usw. braucht halt Platz.
Butser schrieb: > Guest schrieb: >> Takte zaehlen ist einfach nicht mehr noetig weil die >> entsprechende Leistung verfuegbar ist. > > Takte zählt heute der Compiler. Genauso wie er die Registerbelegung und, bei Prozzessoren jenseits des AVRs, auch Pipline und Co im Auge hat. Moby AVR schrieb im Beitrag #4138215: > Entsprechende Leistung > ist zwar da, auch weil OOP diese in endloser Aufwärtsspirale beständig > einfordert. Schon wieder deine OOP Vorurteile. Das hat nichts, aber auch gar nichts mit OOP zu tun. Sauberes OOP mit C++ liefert mindestens so effizienten Code wie ASM handgefrickel. Wenn überhaupt mit den total dynamischen Skriptsprachen, diese brauche wirklich mehr Leistung und vor allem RAM als ein AVR liefert. Moby schrieb: > Noch ein paar Schritte weiter in die richtige Richtung geht Menuet-OS: > > http://www.heise.de/newsticker/meldung/Mini-Betriebssystem-Assembler-OS-MenuetOS-1-0-ist-fertig-2661214.html Das Betriebssystem läuft jetzt nach Jahren der Entwicklung auf Rechnern ohne ACPI. Aber immerhin voll 386 mit VGA kompatibel. Vielleicht ist die volle klassische BIOS Unterstützung fertig, wenn UEFI auch schon wieder abgelöst wird. Ein super Beispiel warum ASM Programmierung der beste Weg ist, ein Projekt NICHT fertig zu bekommen.
MQTT. Das wurde wohl für Ölpiplines entwickelt.
Scelumbro schrieb: > Schon wieder deine OOP Vorurteile. Das hat nichts, aber auch gar nichts > mit OOP zu tun. Sauberes OOP mit C++ liefert mindestens so effizienten > Code wie ASM handgefrickel. Asm-Handgefrickel -> Menuet-OS OOP -> Windows Welches OS braucht mal eben 20,30GB auf der Platte und welches passt auf eine Diskette? Der Verweis auf Windows(programme) ist die beste Lupe die ich Dir bieten kann, um den Speicherwahnsinn von OOP sichtbar zu machen. In GBytes bemessene Bequemlichkeit der Programmierung. Wär der Support von Asm über die Jahre nicht so eingeschlafen müsste die entsprechende Programmerstellung zeitlich nicht so aufwändig sein. Doch der Aufwand trägt Früchte: Schlank und schnell. Die Hardware-Anforderungen an ein System könnten gnadenlos zusammengestrichen werden. Butser schrieb: > IPV6, REST & SOAP, SSL, WIFI, usw. braucht halt Platz. 32-64 MB? Hast Du eine Vorstellung wieviel Speiche das eigentlich ist? Aber in OOP Hochsprache lässt sich das ja locker belegen... Verrückt.
#include <popcorn_interface> #include <popcorn_salted_implementation> #include <popcorn_factory> ....
Moby schrieb: > Schlank und schnell. Die Hardware-Anforderungen an ein > System könnten gnadenlos zusammengestrichen werden. Schauen wir mal wie schnell und schlank Menuet verglichen mit Win 8 noch ist, wenn es den gleichen Funktionsumfang, gleichen die Treiberunterstützung, die Sicherheit und die Abwärtskompatibilität zu mehr als 10 Jahren Vorgängern hat. Solange noch ACPI fehlt, gibt es keinen Vergleich. Zurzeit ist das eine bessere ASM Demo - das die jetzt schön schlank ist, ist kein Wunder. Der selbe Funktionsumfang in C oder C++ wäre genauso schön schlank und schnell. Moby schrieb: > OOP -> Windows Seit wann ist Windows in einer OOP Sprache geschrieben? Oder ist alles jenseits von ASM für dich OOP?
> Seit wann ist Windows in einer OOP Sprache geschrieben?
Das reine System (Kernel & Umgebung) war mal reines C (und passte
bekanntlich auf eine Handvoll Disketten)... Das hat sich längst
geändert- und für die enthaltenen Anwendungen allemal.
Erschreckend, für wie normal manch einer diese gigabyteweise
Verschwendung heute hält. Vermutlich nichts anderes mehr kennengelernt,
was?
Moby schrieb: > Das reine System (Kernel & Umgebung) war mal reines C (und passte > bekanntlich auf eine Handvoll Disketten)... Das hat sich längst > geändert- und für die enthaltenen Anwendungen allemal. > Erschreckend, für wie normal manch einer diese gigabyteweise > Verschwendung heute hält. Vermutlich nichts anderes mehr kennengelernt, > was? Was glaubst du eigentlich was diese Gigabytes denn konkret sind? Alles Maschinenbefehle, oder auch Datenbanken, Übersetzungen und Grafikdateien? Und von dem wirklichen Programmcode, glaubst du die Compiler haben da Milliarden NOPs reingeschrieben nur um den Code aufzublasen? Oder kann es sein das der Code da durchaus was sinnvolles tut? Menuet ist eine hübsche Techdemo, aber wieviele neue Linuxkernelversionen gibt es noch für 30 verschiedenen Plattformen bis Menuet endlich auf einem modernen x86 läuft? Läuft den zumindest schon Atmel Studio für deine AVRs?
Und welchen Sinn hat es Speicherplatz einzusparen? Speicherplatz kostet doch eh nichts mehr, und lieber macht der Entwickler noch nen Testlauf extra, bevor er auch nur 5 Minuten darauf verwendet Platz einzusparen. Mal ganz davon abgesehen dass es Wahrscheinlich mehr Platz einspaaren würde -Os anstatt -O2 zu verwenden, aber dann geht halt die Prozessorauslastung hoch und die Leute mosern wieder. Was wirklich Platz wegnimmt ist genau das was die Leute wollen: das System soll jeden erdenklichen Treiber dabeihaben, mein neues 7.2 USB headset muss ja beim Einstecken funktionieren, 3592 Sprachen müssen auswählbar sein, kann ja niemanden zugemutet werden Englisch zu lernen, eine Anwendung für jeden Schmarn muss beim OS dabei sein, hübsche Bilder, Animationen und Sounds brauchts auch noch, und jetzt darf das ganze Zeug nichtmal mehr Speicherplatz belegen? Übrigens: Gromacs wurde in der aktuellen Version auf OOP (C++) umgeschrieben, und das ist Software an der Leute mit viel Ahnung jahrelang sitzen und versuchen jedes tröpfchen Performance Rauszuholen, die werden schon ihren Grund gehabt haben.
Christian V. schrieb: > Und welchen Sinn hat es Speicherplatz einzusparen? Verdient so eine Frage etwa eine Antwort? > eine Anwendung für jeden Schmarn muss beim OS dabei sein... Das kommt überflüssigerweise noch dazu. > versuchen jedes tröpfchen Performance Rauszuholen, ... das im Rahmen von OOP möglich ist ;-) Scelumbro schrieb: > Läuft den zumindest schon > Atmel Studio für deine AVRs? Natürlich nicht. Da hast Du ja gleich DAS Beispiel eines aufgeblasenen OOP Monstrums gebracht! Der helle Wahnsinn wie das unter Windows flitzt ;-)
Grundsätzlich hat Google ja 2 Möglichkeiten: 1) Ein kleines lightweight OS das auf kleinen MCUs wie CM3/CM4 mit ein wenig SRAM und ohne MMU läuft. 2) Ein möglichst schlankes Linux das auf ARM9/11/Cortex-A5+ etc. läuft und eine MMU braucht. Ich bin eigtl. von Anfang an davon ausgegangen, dass Google Option 2 wählt, weil 1) ein sicherheits- und wartungstechnischer Albtraum ist. Ein OS bei dem ein einziger buffer overflow remote code execution mit allen Rechten erlaubt kann sich vielleicht ein kleiner Wald- und Wiesenhersteller erlauben, der einen "nur in geschützten Netzen benutzen!"-Warnzettel beilegt, aber nicht Google. Da muss auch ein SSL-stack mit rein und remote updates für einen längeren Zeitraum.
Leute, Wale füttern bringt nichts. Die fressen nur Grill, während anderen eben solcher zur Makrele oder zum Tun verdichtet besser mundet.
Moby AVR schrieb im Beitrag #4142432: >> Und welchen Sinn hat es Speicherplatz einzusparen? > > Verdient so eine Frage etwa eine Antwort? Ja bitte. Speicherplatz ist nur eine Optimierungsdimension neben Performance, Features und Entwicklungszeit
Speicher kann man eben als einziges der aufgezählten Dinge in die Hand nehmen. Und er muß schon deshalb gespart werden, weil es ihn nicht "wie Sabd am Meer" gibt. Woraus war der nochmal? ;-))
Scelumbro schrieb: > Moby AVR schrieb im Beitrag #4142432: >>> Und welchen Sinn hat es Speicherplatz einzusparen? >> >> Verdient so eine Frage etwa eine Antwort? > > Ja bitte. Speicherplatz ist nur eine Optimierungsdimension neben > Performance ... sollte also demzufolge optimiert und nicht via OOP verbraten werden. Und was den Entwicklungszeitvorteil angeht hatte ich mich weiter oben schon geäußert. Im übrigen enthält Windows sogar, man höre und staune, gewisse Asm-Anteile. Warum wohl, wenn sich angeblich in OOP oder auch nur in purem C die gleiche Performance erzielen lässt ??? Ich leg Dir nochmal obigen Link zum 10K China-OS ans Herz, dann weißt Du wo meine Messlatte für ein realisierbares, sparsames IoT OS liegt, nicht dieser Brillo Krampf. Im Speicherbedarf wieder nur so eine Orgie Ohne Performance...
Guest schrieb: > Für dumme Nodes ist jegliches Betriebssystem unnoetig, die stellen > ja eh nur Sensoren und Aktoren mit Bus Anbindung dar. Das marktfähige IoT wird wohl früher oder später genau darauf hinauslaufen. BigData Messwertverarbeitung/Auswertung auf Servern im Netz. Das macht dann jedes heute entwickelte IoT-OS höchstens zu einer Übergangslösung.
:
Bearbeitet durch User
Moby AVR schrieb im Beitrag #4142636: > Ich leg Dir nochmal obigen Link zum 10K China-OS ans Herz, > dann weißt Du wo meine Messlatte für ein realisierbares, sparsames IoT > OS liegt, nicht dieser Brillo Krampf. Im Speicherbedarf wieder nur so > eine Orgie Ohne Performance... 10kb mit IPv6 und vor allem dem ganzen Satz nötiger modernder Crypto? Nicht mal mit handpoliertem, unportablem ASM. Moby AVR schrieb im Beitrag #4142636: > Im übrigen enthält Windows sogar, man höre und staune, > gewisse Asm-Anteile. Warum wohl, wenn sich angeblich in OOP oder auch > nur in purem C die gleiche Performance erzielen lässt ??? Genauso wie Linux, aber nicht aus Performance gründen, sondern weil bestimmte Lowlevel Sachen mit dem Compiler nicht zugänglich waren. Moby AVR schrieb im Beitrag #4142636: > ... sollte also demzufolge optimiert und nicht via OOP verbraten werden Nochmal für dich: Der Windowskern ist in C geschrieben. Und du hast immer noch nicht erläutert wie OOP Speicherplatz verschwendet. Wird aber auch schwer für jemanden der noch nicht einmal weiss was OOP bedeutet, geschweige den was waa moderne Compiler leisten.
Das Problem ist nicht Speicher oder welche Sprache man verwendet. Das Problem ist die Komplexität. Mehr Komplexität führt zu mehr Fehlern und somit zu mehr Sicherheitslücken. Komplexität hinter Bibliotheken zu verstecken bring in aller Regel wenig. Das man das sogar mit OOP machen kann zeigt MirageOS http://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_saal_2_-_201412271245_-_trustworthy_secure_modular_operating_system_engineering_-_hannes_-_david_kaloper.html#video Aber Google wird da sicherlich viel falsch machen weil die mit Android schon gezeigt haben dass sie nicht wissen wie man ein Problem möglichst einfach löst.
Wenn man ein kompaktes Betriebssystem will kann man auch FreeRTOS nehmen. Moby schrieb: > Noch ein paar Schritte weiter in die richtige Richtung geht Menuet-OS: x86 für Embedded? Nur wenn man zugleich noch mit dem Prozessor heizen muss :-P
Wobei FreeRTOS scheiss inperformant ist... Ich frage mich seit jahren warum der STM32 (vor allem die mit sdram interface) nie einen linux-port bekommen haben... für energy-micro gäbe es ja einen.... und warum nicht intel für embedded... http://de.wikipedia.org/wiki/Intel_Quark 73
:
Bearbeitet durch User
Hans Wilhelm schrieb: > Wobei FreeRTOS scheiss inperformant ist... Das kommt halt immer auf die Anwendung an. Wenn man z.B. nur mit geringer Rate irgendwelche Messwerte schicken will und dafür relativ einfach TCP/IP bekommt reicht das ja. Wenn man in Echtzeit eine Regelung laufen lassen will, muss man sich vielleicht nach was anderem umsehem. Man muss halt immer wissen, was man will. Es gilt immer: "There is no such thing as free lunch" ;-)
Bastler schrieb: > weil es ihn nicht "wie > Sabd am Meer" gibt. Woraus war der nochmal? ;-)) Silizium, das ist Sand am Meer und zudem das zweithäufigste Material in der Erdkruste.
Das Problem ist, dass es kostenmässig eine große Lücke zwischen 2 MByte und 32 Mbyte gibt. 2 MByte kann man noch gut auf einem Chip in Logikstrukturen integrieren, darüber braucht es externen Speicher (der natürlich als SIP realisiert werden kann). Wenn man schon externen Speicher hat, ist es ziemlich egal, ob man 16, 32, 64 oder 128 MByte hat. Da man das, was Google vor hat, nicht in 2 Mbyte hinbekommt, können Sie es auch gleich richtig machen und von 32 MByte ausgehen. Man darf ja nicht vergessen, dass Google kein Interesse an einem simplen Schalter hat, der über TCP/IP am Netz angebunden ist. Die wollen rege Kommunikation, Steuerung, Datenerfassung, selbstlernende Systeme, etc. Idealerweise sollte das natürlich alles über Google Server laufen. Der vernetzte Kühlschrank, der das Bier selbst bestellt, ist für Google durchaus ein Traum, wenn die Bestellung über Google Server läuft und man vom Händler eine Provision dafür bekommt. Aber das wird eben nichts mit 2 Mbyte Speicher. Und die eigentliche Idee ist doch, dass der Kühlschrankhersteller ein Google Betriebssystem kostenlos verwendet, welches dann Google voreingestellt hat. Gruss Axel
:
Bearbeitet durch User
moep schrieb: > x86 für Embedded? Nur wenn man zugleich noch mit dem Prozessor heizen > muss Menuet empfielt auch nicht x86 für Embedded, sondern Assembler für geringen Speicherbedarf und höchste Performance ;-) Scelumbro schrieb: > Und du hast > immer noch nicht erläutert wie OOP Speicherplatz verschwendet. Daran verschwende ich keinen Gedanken. Das zeigt die Praxis. Ausreichend. Scelumbro schrieb: > sondern weil > bestimmte Lowlevel Sachen mit dem Compiler nicht zugänglich waren. Süß. Soso.
Moby AVR schrieb im Beitrag #4143213: > Scelumbro schrieb: >> Und du hast >> immer noch nicht erläutert wie OOP Speicherplatz verschwendet. > > Daran verschwende ich keinen Gedanken. > Das zeigt die Praxis. Ausreichend. Ein einfaches "keine Ahnung" hätte auch gereicht.
SiO2 schrieb: > Ein einfaches "keine Ahnung" hätte auch gereicht. Ich ahne allenfalls, daß OOP stets viel mehr Ressourcen als nötig pachtet und dessen Abstraktionen einfach ihren Preis haben. Und ich ahne, daß viele Programmierer mit den Möglichkeiten von OOP überfordert sind was kein Wunder bei dieser Komplexität ist. Im übrigen entscheidet was hinten, nämlich in der Praxis gigabyteweise und träge herauskommt. Das schlägt alle wilden Theorien ;-(
Blödsinn! Alles was du zur compilezeit auflösen kannst macht 0 overhead - der rest wird selbst in ASM nicht besser... wenn du eine vererbte klasse mit einer virtuellen funktion hast dann wirds auch nicht besser wenn du stattdessen einen struct mit einem function-pointer hast. Ich nutzte selbst am AVR zu 99% c++. Das Kompilat ist nicht größer wie in einer C implementierung, nur ich bin oft schneller (weniger Code-Zeilen) am Ziel. Nur wir John Carmak schon so schön geschrieben hat "... I sort of "slid into C++" by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it." Man muss eben wissen was man tut... aber das macht C nicht "einfach" oder "besser" zum Einsteigen... es ist ANDERS und hat ähnliche/die selben Probleme! 73
Moby AVR schrieb im Beitrag #4143288: > SiO2 schrieb: >> Ein einfaches "keine Ahnung" hätte auch gereicht. > > Ich ahne allenfalls, daß OOP stets viel mehr Ressourcen als nötig > pachtet und dessen Abstraktionen einfach ihren Preis haben. Und ich > ahne, daß viele Programmierer mit den Möglichkeiten von OOP überfordert > sind was kein Wunder bei dieser Komplexität ist. Moby, du hast also keine Ahnung, bist noch nicht einmal bereit den Output eines C/C++ Kompilers auf deinen vermuteten Bloat zu untersuchen.Du schuldest uns immer noch den Beweis für den angeblichen OOP-Bloat genauso wie für die ASM Überlegenheit. Das einzige was du vorweist sind deine Gefühle, die auf Unkenntnis basieren. Moby AVR schrieb im Beitrag #4143288: > Im übrigen entscheidet > was hinten, nämlich in der Praxis gigabyteweise und träge herauskommt. > Das schlägt alle wilden Theorien ;-( MACH ES BESSER. Reimplementiere eine beliebige, bekannte und weit genutzte Software in ASM und beweise uns alle die Vorteile, was Wartbarkeit, Erweiterbarkeit, Performance, Größe und Portabilität angeht. Und nein - Menuet-OS ist keine Alternative sondern eine Techdemo, die nicht mit einem richtigen Betriebssystem vergleichbar ist - sie läuft ja nicht einmal auf modernen Rechnern.
@ Scelumbro Du kannst Dich gerne endlos weiter theoretisch sträuben- die Praxis belehrt eines besseren ;-) Das sagt Dir schon jeder Laie, der die Entwicklung des letzten Jahrzehnts verfolgt hat. > MACH ES BESSER Aha. Du nimmst also die Tatsache, daß die Softwarelandschaft ist wie sie ist als Beweis, daß sie nicht besser zu programmieren wäre. Bestrebungen wie ein reines Asm-OS sollten Dir eigentlich zu denken geben. > Und nein - Menuet-OS ist keine Alternative sondern eine > Techdemo, die nicht mit einem richtigen Betriebssystem vergleichbar ist > - sie läuft ja nicht einmal auf modernen Rechnern. Setz Dich mal mit den Machern in Verbindung, die werden Dir was von Demo erzählen. Und Asm ist nicht ohne Grund gewählt- aber von dessen Vorteilen fehlt Dir offensichtlich jede Vorstellung. Deine Lösung: Ignorieren. Ok, das habe ich nun verstanden.
Zitat aus den FAQ:
Dieses Spezielle Gerät arbeitet nicht
Für die Maus gibt es die alt + Pfeil-Tasten + Leertaste Kombination.
Ich habe nur diesen einen Computer und alles läuft hier. Du kannst
deinen eigenen Treiber/Patch schreiben und/oder mir die Info senden.
Und wie es eine Tech-Demo ist...
Das "Problem" warum heute alles soooo "langsam" und "riesig" ist, ist
schlicht und ergreifend, dass jeder 3d-Schatten, Kompatibilität vom
Word-Processor zurück zu Word 6.0 und natürlich auch den verrücktesten
video-codec erwartet.
Im übrigen schau dir an was z.B. der GCC so alles optimiert... das
schaffst du NIE und in ASM... habe da gerade so ein Stück software bei
dem's auf Speed ankommt... Auf das loop-unrolling das der gcc sich
überlegt hat wär ich nie gekommen... Hab die takte gezählt! Aber das ist
halt so wenn der compiler x87, MMX, SSE, SSE2 SSE3 und AVX gleichzeitig
nutzen kann...
Außderdem gibt es noch wesentlich mehr "OSe" die in ASM geschrieben
wurden/werde: http://wiki.osdev.org/Projects
Aber gut KolobriOS (32-bit Menuet-OS) mach auf seiner Homepage Werbung
damit, dass man einen 100$ PC (anscheinend eine eBox-3350MX... das ist
ein 933MHz Vortex86MX also ein 486er) in 10sec bootet.
Zugegebenermaßen nett, aber schau dann mal das an:
http://www.makelinux.com/emb/fastboot/omap
demnach ist also ein 720MHz Cortex A8 mit einem gebloateten, in C
geschriebenen OS um einen faktor 33(!) schneller... interessant
du wirst sicher sagen, dass da kein Fenstermanager rennt... X allein
startet bei mir <1s...sollte sich also in den restlichen 9.7s auf auf
dieser saulangsamen plattform ausgehen ;)
73
fast vergessen... das image das auf dem beagleboard (nicht bone und schon garnicht bone-black!) hat auch 1.5MB ;) 73
Moby schrieb: > Du kannst Dich gerne endlos weiter theoretisch sträuben- die Praxis > belehrt eines besseren ;-) > Das sagt Dir schon jeder Laie, der die Entwicklung des letzten > Jahrzehnts verfolgt hat. Welche Praxis belehrt mich eines besseren? Dein Gefühl das Software zu gross ist? Dein Gefühl gegenüber "OOP" Software (eigentlich C Programmen) verglichen mit deinem Gefühl dass das entsprechende ASM Derivat x Mal schneller läuft und weniger Speicher braucht? Natürlich existiert kein entsprechendes ASM Derivat, sonst könnte man ja vergleichen. Hans schrieb: > Zugegebenermaßen nett, aber schau dann mal das an: > http://www.makelinux.com/emb/fastboot/omap > > demnach ist also ein 720MHz Cortex A8 mit einem gebloateten, in C > geschriebenen OS um einen faktor 33(!) schneller... interessant Schönes Beispiel für "gebloatetes OOP" ;) Hans schrieb: > Das "Problem" warum heute alles soooo "langsam" und "riesig" ist, ist > schlicht und ergreifend, dass jeder 3d-Schatten, Kompatibilität vom > Word-Processor zurück zu Word 6.0 und natürlich auch den verrücktesten > video-codec erwartet. Richtig. Dazu in X-Sprachen und erweiterbar mit Addons, Plugins und wie sie alle heissen. Hilfedateien am besten mit Video und Sprachausgabe.
Scelumbro schrieb: > Welche Praxis belehrt mich eines besseren? Um Dir mal auf die Sprünge zu helfen: Schon ein Win-Programm das gar nichts tut braucht 8KB... Da kriegt man ja fast das ganze China-OS unter ;-) Schon klar, daß sich diese Verschwendung in richtigen Programmen schnell potenziert. Der Anwender nimmt das mangels Alternative hin, der Programmierer in mir hat dafür nur Verachtung übrig ;-(
Axel Laufenberg schrieb: > Das Problem ist, dass es kostenmässig eine große Lücke zwischen 2 MByte > und 32 Mbyte gibt. 2 MByte kann man noch gut auf einem Chip in > Logikstrukturen integrieren, darüber braucht es externen Speicher (der > natürlich als SIP realisiert werden kann). Wenn man schon externen > Speicher hat, ist es ziemlich egal, ob man 16, 32, 64 oder 128 MByte > hat. > > Da man das, was Google vor hat, nicht in 2 Mbyte hinbekommt, können Sie > es auch gleich richtig machen und von 32 MByte ausgehen. Die Chiphersteller basteln ja gerade am DRAM welches direkt auf Logik Dies draufgesetzt wird. (3D Stacking oder so ähnlich) Damit wird der Aufwand und Preis für solche Lösungen weiter sinken. Ein fullblown Linux in einem niedrigpoligen xQFP auf zwei Lagen rückt damit in Schlagweite :-)
Moby schrieb: > Um Dir mal auf die Sprünge zu helfen: > Schon ein Win-Programm das gar nichts tut braucht 8KB... > Da kriegt man ja fast das ganze China-OS unter ;-) > Schon klar, daß sich diese Verschwendung in richtigen Programmen > schnell potenziert. Der Anwender nimmt das mangels Alternative > hin, der Programmierer in mir hat dafür nur Verachtung übrig ;-( Und wie gross ist das entaprechende ASM Programm?
Scelumbro schrieb: > Und wie gross ist das entaprechende ASM Programm? Das ruft im Prinzip mit einer Handvoll parametrierter Funktionsaufrufe ohnehin nur entsprechend vorhandene OS-Funktionalität auf. Sowas sollte, zumindest in diesem einfachen Fall, in <100 Bytes erledigt sein. Nicht so bei OOP Windows und dessen OOP Anwendersoftware... Da gibts erstmal allerhand OOP Krempel und wer weiß was zu initialisieren ;-(
Ein Windows-Programm besteht aus mindestens 2 Speicherbereichen. Code und Daten/Stack. Letzteres eher getrennt, also 3 Bereiche. Jeder Bereich besteht aus Speicherseiten zu je 4096 Byte. Also kann unter 8(/12)k garnichts gehen. Selbst wenn man nur wenige Byte je Bereich tatsächlich benutzt. Dann braucht man je min. eine Page für's anhängen von DLL's. Die sparen in Summe viel ein da nicht jeder Prozess eigene Kopien gemeinsamen Codes braucht. Man macht diese gern umfangreich, weil dadurch der Verwaltungsaufwand sinkt. Nur wenn dann jemand im Tasknanager die Größe des virtuellen Adressraums eines Prozesses sieht und keinen Schimmer hat, was das ist, dann erschrickt er. Dann sind diese min. 2 Pages auch die Größe der EXE, und schon braucht das "OOP"-Betriebssystem Windows für leere Programm 8k. Mein Mega644 braucht je Programm und mehr als eines kann der nicht, 64k. Die nicht benutzten Kilobyte lassen sich nämlich nicht ausbauen und anderweitig nutzen. Etwas absurd betrachtet, aber in sofern ganz auf Moby's Linie.
Hans schrieb: > Ich nutzte selbst am AVR zu 99% c++. ... und stets größere AVRs als eigentlich nötig ;-)
Moby schrieb: > Hans schrieb: >> Ich nutzte selbst am AVR zu 99% c++. > > ... und stets größere AVRs als eigentlich nötig ;-) Dafür ist er aber auch 99x schneller fertig als jemand, der die gleiche Komplexität in ASM umsetzt. Wen wird der Chef mehr mögen... :-)
:
Bearbeitet durch User
Bastler schrieb: > Ein Windows-Programm besteht aus ...sehr viel mehr, als für den konkreten Fall wirklich nötig. Komplexe Bloatware pur. Aber danke für die ausführliche Bestätigung. Bastler schrieb: > Mein Mega644 braucht je Programm und mehr als eines kann der nicht, 64k AVR ist jetzt mit Multitasking-Windows auf Mehrkern-CPU auch nicht wirklich vergleichbar;-) Im Prinzip braucht es ja nicht mehr als ein Programm für eine Anwendung. In Asm ist dabei genaue Umsetzung der benötigten Funktionalität mit genau dem nötigen Speicher möglich, meist mit direktem=effizientem Hardwarezugriff- das gilt für jede Plattform. Menuet wird sich ob der komplex zerfaserten PC-Plattform deshalb vermutlich auf konkrete Hardware beschränken müssen. Das ist aber nicht der Mangel von Asm, sondern der Mangel jahrzehntelang wuchernder PC-Hardware= KompatibelAberTrotzdemImmerLeistungsfähigerSeinWollen Krankheit. Klaus H. schrieb: > Dafür ist er aber auch 99x schneller fertig als jemand, > der die gleiche Komplexität in ASM umsetzt. > Wen wird der Chef mehr mögen... :-) Ja Klaus. Höchste Performance bei geringstem Speichereinsatz gibts nicht umsonst. Das fordert Hirnschmalz und das dauert. Es könnte aber sehr viel schneller gehen, wäre die Basis dafür bereitet. Asm-Betriebssysteme mit fertigen, optimalen Funktionen für homogene, standardisierte Hardware. Aber das Leben ist kein Wunschkonzert, ich weiß ;-(
Es hat keine Sinn. Wie heißt es schön: "der Klügere gibt nach". (Hoffentlich kann sich noch jemand an PC's erinnern, wenn das ASM-Desktop-OS fertig ist.)
Bastler schrieb: > wenn das > ASM-Desktop-OS fertig ist ... ist mir als Anwender ehrlichgesagt auch wurscht. Entscheidend ist: Da gibt es noch die kleinen 8-Bitter, die sich in Asm wunderbar für Steuerungen aller Art im Smart Home beherrschen lassen. Da hat Brillo echt die Brille auf ;-)
Bevor man sich ueber Komplexitaet, Performance und Speicherverbrauch
unterhaelt, sollte man sich ueber die Designziele unterhalten. Was
brauch ich denn genau ?
- Multiuser ? eher nicht. Dh die Benutzer Rechte und
deren Verwaltung auch nicht. Ein Filelock genuegt.
- Plug und Play Netzwerk Hardware ? Nein. auch nicht.
Die Konfiguration wird beim Linken angegeben. Dh
eine Hardware Abstraction Layer dafuer brauchts
auch nicht.
- GUI ? Natuerlich auch nicht. Dh der ganze Grafikteil
fliegt raus.
Benoetigt werden.
Netzwerk als Ethernet, Wifi, Bluetooth, Zigbee, Serial ...
Massenspeicher als SDCard, ...
Hardware als I/O pins, SPI, Timer, ...
aber nicht fuer plug und play hardware, sondern je nach
Vorhandensein zulinkbar.
Was noch?
Eine HAL ist verbesserbar. Aus einer seriellen Schnittstelle
ein Blockdevice zu machen ist nicht besoonders clever...
:
Bearbeitet durch User
Moby schrieb: > Bastler schrieb: >> wenn das >> ASM-Desktop-OS fertig ist > > ... ist mir als Anwender ehrlichgesagt auch wurscht. > Entscheidend ist: Da gibt es noch die kleinen 8-Bitter, die sich in Asm > wunderbar für Steuerungen aller Art im Smart Home beherrschen lassen. > Da hat Brillo echt die Brille auf ;-) Im Grunde gibst du also zu das ASM für größere Projekte wie Desktopbetriebssysteme nicht die richtige Wahl ist. Weil die Entwicklung eines solchen Systems verglichen mit der Entwicklung in einer Hochsprache um Größenordnungen langsamer ist. Im Gegensatz dazu bekommt man natürlich ein winzigen 8-Bitter mit ASM in endlicher Zeit voll - für Projekte in der Größenordnung Kühlschrankthermometer - ab heute mit sogar mit IoT.
Jetzt Nicht schrieb: > - GUI ? Natuerlich auch nicht. Dh der ganze Grafikteil > fliegt raus. Am IoT Kühlschrank ein kleiner Touchscreen um das Inventar und die Einkaufsliste zu verwalten. > Was noch? Crypto. Macht einen guten Teil des Aufwands aus. Einigen macht es vielleicht nichts aus wenn der IoT Kühlschrank die Einkaufslisten unverschlüsselt durchs Netz schickt. Anderen schon.
Scelumbro schrieb: > Im Grunde gibst du also zu das ASM für größere Projekte wie > Desktopbetriebssysteme nicht die richtige Wahl ist. Wenn Du Menuet schon als Technikdemo abwertest dann lass Dir wenigstens davon demonstrieren, welche Funktionalität und welche Performance sich in Asm auf dem Platz einer Diskette codieren lässt ;-)
Scelumbro schrieb: > Am IoT Kühlschrank ein kleiner Touchscreen um das Inventar und die > Einkaufsliste zu verwalten. Klingt doch ganz nach OOP: Administrativer Aufwand > Funktioneller Aufwand. Wo würdest Du denn noch überall Displays platzieren? IoT soll durch Automatisierung vereinfachen, nicht die Bürokratie in die Höhe treiben.
Anstelle eines Displays, welches sowieso bald kaputt ist, haett ich lieber einen kleinen webserver fuer die Bedienung drauf. Dann macht man die Verwaltung eben mit einem Tablet. Bei IoT sollte man bedenken, dass die Lebensdaueransprueche sich gewaltig von consumerprodukten unterscheiden. Ein Kuehlschrank muss mindestens 10 Jahre halten, eher, 15-20 Jahre. Und das IoT darauf eben auch, sonst ist IoT tot bevor's begonnen hat.
:
Bearbeitet durch User
Woher kommt eigentlich das Märchen, dass OOP mehr Speicher verbraucht? Ich habe schon eine komplette Menüsteuerung in OOP auf einem Atmega88 implementiert incl. Vererbung und Polymorpie (virtuelle Methoden). Natürlich sollte man sich überlegen, ob man Klassen der STL auf einem µC benutzt. Diese wollen gern mal dynamischen Speicher allokieren.
Er wills nicht verstehen.... OOP heißt nicht automatisch mehr speicher und ASM heißt weder schnell noch klein. selbst ein AVR hat quasi OOP in sich drinnen... Jump-Table für interrupts, daten und programm-code getrennt... alles irgendwie grundlagen vom OOP gedanken... BTW wie oben geschrieben geht auf eine diskette auch noch linux mit busybox drauf! Das kann dann wesentlich mehr wie deine Tech-Demo! DamnSmallLinux braucht um die 50MB... dann hat man aber auch ein system mit dem man arbeiten kann... web-server, office, mp3-player,... dafür halt keine 32bit 256x256 pixel icons und der gleichen... wie gesagt OOP macht NICHTS größer als es sein muss. Moby schrieb: > Hans schrieb: >> Ich nutzte selbst am AVR zu 99% c++. > > ... und stets größere AVRs als eigentlich nötig ;-) Das bezweifle ich... das c++ kompilat mit seinen 394bytes passt wunderbar selbst in einen tiny13a. Nachdem ich auf den Strom (einstellbar!) regle, bei Überspannung oder übertemperatur abschalte, den (Felher-)Status per LED ausgebe und zumindest einen PWM pin brauch, gehts nicht kleiner... Naja, bleib ruhig in deiner engen kleinen engstirnigen welt...
Jetzt Nicht schrieb: > Anstelle eines Displays, welches sowieso bald kaputt ist, haett > ich > lieber einen kleinen webserver fuer die Bedienung drauf. Dann macht man > die Verwaltung eben mit einem Tablet. > Bei IoT sollte man bedenken, dass die Lebensdaueransprueche sich > gewaltig von consumerprodukten unterscheiden. Ein Kuehlschrank muss > mindestens 10 Jahre halten, eher, 15-20 Jahre. Und das IoT darauf eben > auch, sonst ist IoT tot bevor's begonnen hat. Ich glaub ja persöhnlich, dass innerhalb der 20 Jahre eher der interne Webserver inkompatibel wird, als ein hochwertiger Touchscreen kaputt geht.
Scelumbro schrieb: > Ich glaub ja persöhnlich, dass innerhalb der 20 Jahre eher der interne > Webserver inkompatibel wird, Das glaube ich nicht. Selbst die Webserver aus der Steinzeit des Internets sind noch zu allen neueren Browsern kompatibel. Für die unterschiedliche Hardware braucht man teilweise entsprechende Umsetzer (Token Ring => Ethernet, Koaxkabel=>normales Netzwerkkabel...) Ich vermute, dass es zuerst die Hintergrundbeleuchtung des Touchscreens erwischen wird. Sicherheit und Geschwindigkeit entsprechen allerdings nicht mehr den heutigen Ansprüchen.
Schreiber schrieb: > Das glaube ich nicht. Selbst die Webserver aus der Steinzeit des > Internets sind noch zu allen neueren Browsern kompatibel. Für die > unterschiedliche Hardware braucht man teilweise entsprechende Umsetzer > (Token Ring => Ethernet, Koaxkabel=>normales Netzwerkkabel...) > > Ich vermute, dass es zuerst die Hintergrundbeleuchtung des Touchscreens > erwischen wird. > > Sicherheit und Geschwindigkeit entsprechen allerdings nicht mehr den > heutigen Ansprüchen. Wenn der Kühlschrank sich, was sehr wahrscheinlich ist, nicht über Ethernet sondern über WLAN verbindet gibts schnell mal probleme. Schneller als man denkt ist z.B. WPA2 unsicher. Wenn aber weiter seinen smarten Kühlschrank nutzen will (vom Hersteller gibts spätenstens nach einem halben Jahr keine Updates mehr) muss man weiterhin ein WPA2 gesichertes Netzwerk laufen lassen. Bis dann ein Hacker das Netzwerk knackt und über den Kühlschrank eine Tonne Milch bestellt.
Hans Wilhelm schrieb: > Das kann dann wesentlich mehr wie deine Tech-Demo! Was zu beweisen wäre... Hans Wilhelm schrieb: > Das bezweifle ich... das c++ kompilat mit seinen 394bytes passt > wunderbar selbst in einen tiny13a. Das kann ja jeder behaupten. Zeig mal die Funktionalität. Dann kann man mal abschätzen, was sich mit Asm noch sparen lässt, damits vielleicht in einen Tiny5 passt ;-) Hans Wilhelm schrieb: > Naja, bleib ruhig in deiner engen kleinen engstirnigen welt... Wenn engstirnig meint, mit engen Platzverhältnissen auszukommen und sich eng an dem zu orientieren, was die App wirklich an Code und Administration erfordert dann gerne! Andreas Richter schrieb: > Ich habe schon eine komplette Menüsteuerung in OOP auf einem Atmega88 > implementiert Super. Wenns Spaß macht.... Also möglich ist das. Unbestritten. Nur fehlt der Vergleich zur Asm-Lösung. Scelumbro schrieb: > Bis dann ein Hacker das Netzwerk > knackt und über den Kühlschrank eine Tonne Milch bestellt. Dumme Jungen Scherze! Was hätte der Hacker davon? Die Kühlschrank-Bestellung einer Tonne Milch ist sicher alles andere als plausibel.
Moby schrieb: > Scelumbro schrieb: >> Bis dann ein Hacker das Netzwerk >> knackt und über den Kühlschrank eine Tonne Milch bestellt. > > Dumme Jungen Scherze! > Was hätte der Hacker davon? > Die Kühlschrank-Bestellung einer Tonne Milch ist sicher alles andere als > plausibel. Dann nutzt er halt den schwachen Teil, weil veraltet verschlüsselt, des Wlans um hinter der Routerfirewall in dein Heimnetzwerk einzudringen und Daten abzugreifen und Rechner zu kompromittieren. Wenn dein Smarthome bis dahin auch noch ein smartes Wlanschloss oder Wlanfensteröffner zusammen mit smarter Anwesenheitserkennung hat, kann er dir gleich die Bude leerräumen. Moby schrieb: > Andreas Richter schrieb: >> Ich habe schon eine komplette Menüsteuerung in OOP auf einem Atmega88 >> implementiert > > Super. Wenns Spaß macht.... Also möglich ist das. Unbestritten. > Nur fehlt der Vergleich zur Asm-Lösung. Einerseits forderst du immer die ASM Lösung, bist aber selbst nicht in der Lage für irgendein komplexeres Programm eine vollständige ASM Lösung als vergleich hinsichtlich Speicherverbrauch und Performance anzubieten. Zeig mal was komplexeres von dir, sag wie lange du daran rumgefrickelt hast! Vielleicht erbarmt sich ja jemand und macht dann schnell das entsprchende Programm in C.
OOP ist ein konzept, deshalb hat es nichts mit dem Speicherverbrauch zu tun. Wichtig ist die Art der Programmiersprache. Damit meine ich nicht ob es Objektorientiert, prozedural, oder sogar asm ist. Damit meine ich ob es eine compilerbasierte (c,c++,delphi,...), compreter basierte (java mit seiner vm), eine interpretersprache (python, perl,...), oder echt lowlevel (asm, binar direct im hexeditor,...) ist. Interpreter und compreter sprachen werden nie ganz an die mögliche performance der anderen herankommen. In asm kann man die perfekte lösung schreiben, wenn man alle 2^x optimierungen kennt. In compilerbasierten sprachen ist es vom wissen der compilerbauer und dessen verwender abhängig. Beide varianten können die andere übertreffen, da keine einen perfekten Programmierer besitzen kann. Aber bis man in asm ein guter optimizer ist dauert es länger, als in c zu lernen auf malloc zu verzichten.
Moby schrieb: > Hans Wilhelm schrieb: >> Das kann dann wesentlich mehr wie deine Tech-Demo! > > Was zu beweisen wäre... > > Hans Wilhelm schrieb: >> Das bezweifle ich... das c++ kompilat mit seinen 394bytes passt >> wunderbar selbst in einen tiny13a. > > Das kann ja jeder behaupten. Zeig mal die Funktionalität. Dann kann man > mal abschätzen, was sich mit Asm noch sparen lässt, damits vielleicht in > einen Tiny5 passt ;-) > > Hans Wilhelm schrieb: >> Naja, bleib ruhig in deiner engen kleinen engstirnigen welt... > > Wenn engstirnig meint, mit engen Platzverhältnissen auszukommen und sich > eng an dem zu orientieren, was die App wirklich an Code und > Administration erfordert dann gerne! > > Andreas Richter schrieb: >> Ich habe schon eine komplette Menüsteuerung in OOP auf einem Atmega88 >> implementiert > > Super. Wenns Spaß macht.... Also möglich ist das. Unbestritten. > Nur fehlt der Vergleich zur Asm-Lösung. > > Scelumbro schrieb: >> Bis dann ein Hacker das Netzwerk >> knackt und über den Kühlschrank eine Tonne Milch bestellt. > > Dumme Jungen Scherze! > Was hätte der Hacker davon? > Die Kühlschrank-Bestellung einer Tonne Milch ist sicher alles andere als > plausibel. Ist dir eigentlich klar, dass OOP und ASM zwei total unterschiedliche dinge sind? Man kann ohne probleme OOP auch in ASM machen. Genausogut kann ich in c++ prozedurial wie typischerweise in ASM schreiben... Beispiel findet sich z.B. hier: http://www.drdobbs.com/embedded-systems/object-oriented-programming-in-assembly/184408319 Das problem ist einfach, dass du vielleicht (aber auch nur vielleicht) auf einem kleinen Tiny den code in etwa so effizient hinbekommst wie wenn ein moderner Compiler ihn generiert. Und da auch nur wenn er in 1k instruktionen passt. Mein Beispiel oben sollte nur verdeutlichen, das man problemlos auch auf einem winzigen Tiny c++ verwenden kann. Der Tiny5 geht leider nicht weil zu wenige pins... Aber wie der letzte poster dir schon sagen wollte, OOP ist ein konzept und damit an keine programmiersprache gebunden! Der vorteil von einer modernen Programmiersprache und einem modernen Compiler ist einfach, dass du in der Programmiersprache tatsächlich beschreibst was du eigentlich haben willst und der compiler dann daraus für die Zielarchitektur den optimalen code generiert. Auf einem AVR mag es noch halbwegs gehen schnellen code per hand zu generieren, wenn man aber beispielsweise einen ARM vor sich hat, bei dem jedes Derivat unterschiedliche cache-größen haben kann, dann bezweifle ich, dass du für genau diesen einen typ optimales loop-unrolling usw in ASM hinbekommst. Dafür gibts compiler und die wissen das (siehe -mtune parameter beim GCC). Übrigends heißt schnell nicht notwendigerweise klein! -Ofast ist normalerweise etwas größer (vom binary her) als -Os jedoch meiner erfahrung nach zwischen 20% und 500% schneller (AVX instruktionen sind am x86 eben vom byte-code länger aber können halt 4 floats parallel bearbeiten... auch kurze loops sind schneller erledigt wenn unrolled statt zum anfang springt). Genausoweinig ist ein alter 8bit billiger wie ein moderner 32bitter... (beispielsweise stm32f030 vs. mega88) Naja jeder wie er will. 73
Daniel A. schrieb: > OOP ist ein konzept, deshalb hat es nichts mit dem Speicherverbrauch zu > tun. Wollen wir doch erstens einmal festhalten, daß die Masse heutiger Software, ob für Windows, Linux und sehr wahrscheinlich auch dieses ominöse Brillo objektorientiert programmiert daherkommt und diese Programme zweitens oft sehr viel Speicher und RAM als früher erfordern. Halten wir drittens mal und selbstverständlicherweise fest, daß es die Ursache dieses Hungers in der Software selbst zu suchen sein muß. Nicht jedes hat nämlich massig Multimedia dabei. Wenn OOP als Konzept auch nicht unmittelbar Speicherbedarf begründet, so doch zumindest mittelbar. Eben nicht theoretisch, sondern ganz praktisch, indem da zuallererst Verwaltungsbedarf kreiert wird: - Als Code zum Beispiel Konstruktoren und Destruktoren - Als Daten zum Beispiel Objektpointer, Methodenverweise u.ä. Unnützer RAM-Verbrauch entsteht dann außerdem durch: - Übermäßige Allokierung von Speicher (man hat's ja) - Redundanz von Daten in Objekten - Nie genutzte Daten und Methoden in Objekten Schließlich sind nicht mehr referenzierbare Daten (Memory-Leaks) und die Notwendigkeit von weiteren Verwaltungs-Konstruktionen wie dem Garbage-Collektor (der schon wieder Speicher und Performance frisst) das letzte Eingeständnis, daß der Programmierer sein System und den Ressourcenbedarf schon nicht mehr vollständig unter Kontrolle hat. Oder haben kann, da mit OOP eine Komplexität Einzug gehalten hat die ihresgleichen sucht (und so ebenfalls ganz mittelbar durch weniger "fähige" Programmierung Speicher fordert). Was Speicherbedarf und Performance anbetrifft mag zwar theoretisch die Möglichkeit bestehen, sich (gekonntem) Asm anzunähern- das aber nur auf Kosten bücherfüllender, sich permanent erweiternder Konstruktions-Vielfalt, diverser Kniffe und hochabstrakter gedanklicher Winkelzüge. Asm ist da simpel und direkt- und hält zur genauen Planung der vorhandenen Ressourcen an! Daniel A. schrieb: > In asm kann man die perfekte lösung schreiben, wenn > man alle 2^x optimierungen kennt. Nein. Die muß man nicht kennen. Kennen sollte man für ein praktikables, nichtsdestotrotz hochperformantes und speichersparendes Ergebnis aber seinen Controller und wie man dessen Möglichkeiten bestmöglich nutzt. Ein ernstzunehmendes Argument ist natürlich das Know-How der Compilerbauer Hans schrieb: > wenn der compiler x87, MMX, SSE, SSE2 SSE3 und AVX gleichzeitig > nutzen kann Stattdessen könnte mir der Controllerhersteller aber auch gleich fertige Asm-Routinen für typische Aufgaben und Berechnungen liefern! Scelumbro schrieb: > Vielleicht erbarmt sich ja jemand... Am Erbarmen ist es bei mir jedenfalls nicht gescheitert, als ich dem Thread Beitrag "C++ auf einem MC, wie geht das?" eine (leider gelöschte) reine Asm-Lösung für ein einfaches Problem lieferte, an dem sich die Protagonisten der hohen OOP-Kunst monatelang die abstrakten Zähne ausbissen und bei dem bis heute nichts handfest Nutzbares bei rum gekommen ist (siehe Anhang). > und macht dann schnell das > entsprchende Programm in C. Auf gehts, Scelumbro! 266 Code-Bytes + 6 RAM gilt es zu unterbieten ;-)
Moby schrieb: > Wenn OOP als Konzept auch nicht unmittelbar Speicherbedarf begründet, so > doch zumindest mittelbar. Eben nicht theoretisch, sondern ganz > praktisch, indem da zuallererst Verwaltungsbedarf kreiert wird: > - Als Code zum Beispiel Konstruktoren und Destruktoren In OOP heißt es Konstruktor, prozedural heißt es init() > - Als Daten zum Beispiel Objektpointer, Methodenverweise u.ä. Was auch immer "Methodenverweise" sind. Unter C++ ist jederzeit klar wann Pointer zum Einsatz kommen. Wenn man diese Situationen vermeidet, gibts auch keine "Objektpointer". Sondern nur Methoden die auf Daten zugreifen - genauso wie in ASM Unterprogramme. Moby schrieb: > Schließlich sind nicht mehr referenzierbare Daten (Memory-Leaks) und die > Notwendigkeit von weiteren Verwaltungs-Konstruktionen wie dem > Garbage-Collektor (der schon wieder Speicher und Performance frisst) das > letzte Eingeständnis, daß der Programmierer sein System und den > Ressourcenbedarf schon nicht mehr vollständig unter Kontrolle hat. In C++ gibts keinen Garbage Collector, und wenn ein Programmierer nicht programmieren kann, gibts halt Memory-Leaks. Auch in ASM kann man mit falscher Programmierung schlechten Code erzeugen und Speicherinhalte verlieren. > Oder > haben kann, da mit OOP eine Komplexität Einzug gehalten hat die > ihresgleichen sucht (und so ebenfalls ganz mittelbar durch weniger > "fähige" Programmierung Speicher fordert). Was Speicherbedarf und > Performance anbetrifft mag zwar theoretisch die Möglichkeit bestehen, > sich (gekonntem) Asm anzunähern- das aber nur auf Kosten > bücherfüllender, sich permanent erweiternder Konstruktions-Vielfalt, > diverser Kniffe und hochabstrakter gedanklicher Winkelzüge. > Asm ist da simpel und direkt- und hält zur genauen Planung der > vorhandenen Ressourcen an! Ja - diese Bücher handeln vom Compilerbau. Viele tausend Softwareexperten haben sie gelesen, verstanden und Wunderwerke wie den GCC entwickelt. Man kann auf diese gesammelte, geballte Know-How der Compilerbauer zugreifen oder das Rad Tag für Tag immer wieder neu erfinden. Erfindest du auch Bohrmaschine und Säge jedes Mal neu?
Scelumbro schrieb: > Zeig mal was komplexeres von dir, sag wie lange du daran rumgefrickelt > hast! Moby schrieb: >> und macht dann schnell das >> entsprchende Programm in C. > > Auf gehts, Scelumbro! > 266 Code-Bytes + 6 RAM gilt es zu unterbieten ;-) Wenn das für dich ein komplexes Programm ist, verstehe ich deine Vorliebe für ASM. Du bist schlicht mit richtigem Programmieren überfordert.
Scelumbro schrieb: > Auch in ASM kann man mit > falscher Programmierung schlechten Code erzeugen und Speicherinhalte > verlieren. In Asm kann man prinzipiell alles was möglich ist. Asm-Programmierer, die ihren Controller aus der Westentasche kennen werden jedoch selten schlechten Code schreiben und schon gar keine Speicherinhalte verlieren. Asm ist geradezu darauf angelegt gut zu sein- und (knappe) Ressourcen hütet der Programmierer wie seinen Augapfel ;-) Scelumbro schrieb: > oder das Rad Tag für Tag immer wieder neu > erfinden Warum sollte man das? Lassen sich in Asm nicht etwa genauso umfangreiche Libs und Funktionssammlungen anlegen? Wichtig wäre aber, bei 'seiner' vorab gründlich ausgesuchten Controllerauswahl zu bleiben. Dann allerdings kann man auch das Maximale aus der Hardware herausholen! Ganz anders als portabler 0-8-15 C-Code oder noch hardwarefernere OOP.
Scelumbro schrieb: > Du bist schlicht mit richtigem Programmieren > überfordert. Das nehme ich auch für Dein Verständnis von Asm an ;-)
Vielleicht sollte sich der TE mal die Mühe machen, zu untersuchen wie der Compiler einen Aufruf einer statischen oder einer virtuellen Methode und den Zugriff auf Membervariablen umsetzt. Dann könnte er vielleicht noch was in Bezug auf (effektive) Assemblerprogrammierung dazulernen.
Andreas Richter schrieb: > dazulernen ...kann man immer! Nur mit "richtigem Programmieren" im Sinne eines maßlosen, unkontrollierbaren Verheizens von Ressourcen tu ich mich doch etwas schwer ;-)
Schönes Beispiel zum Thema "OS for IoT". Jetzt noch die restlichen 30.000 Zeilen nachreichen, dann ist der M328 einigermaßen gefüllt.
Bastler schrieb: > Schönes Beispiel zum Thema "OS for IoT" Ein Beispiel für Scelumbro. Auf große Töne folgt schnell Schweigen im Walde. Ganz offensichtlich ist es schon zu komplex ;-)
Moby schrieb: > Wenn OOP als Konzept auch nicht unmittelbar Speicherbedarf begründet, so > doch zumindest mittelbar. Eben nicht theoretisch, sondern ganz > praktisch, indem da zuallererst Verwaltungsbedarf kreiert wird: > - Als Code zum Beispiel Konstruktoren und Destruktoren > - Als Daten zum Beispiel Objektpointer, Methodenverweise u.ä. Stimmt nicht. Wenn das Objekt nicht dynamisch instanziert wird und du nicht vererbst gibt's KEINEN unterschied zu globalen variablen + funktionen die irgendwas damit machen... der code wird schlicht "schöner". > Unnützer RAM-Verbrauch entsteht dann außerdem durch: > - Übermäßige Allokierung von Speicher (man hat's ja) > - Redundanz von Daten in Objekten > - Nie genutzte Daten und Methoden in Objekten wieso? wird eine funktion/variablen (im allgemeinen heißt sowas meist "symbol") nicht verwendet wird sich auch nicht mitgelinkt... Speicher wird allokiert wenn ich dynamisch speicher brauche. Wenn der Compiler schon weiß wieviel ich brauche wird genau diese Menge reserviert. passta > > Schließlich sind nicht mehr referenzierbare Daten (Memory-Leaks) und die > Notwendigkeit von weiteren Verwaltungs-Konstruktionen wie dem > Garbage-Collektor (der schon wieder Speicher und Performance frisst) das > letzte Eingeständnis, daß der Programmierer sein System und den > Ressourcenbedarf schon nicht mehr vollständig unter Kontrolle hat. Oder > haben kann, da mit OOP eine Komplexität Einzug gehalten hat die > ihresgleichen sucht (und so ebenfalls ganz mittelbar durch weniger > "fähige" Programmierung Speicher fordert). Was Speicherbedarf und > Performance anbetrifft mag zwar theoretisch die Möglichkeit bestehen, > sich (gekonntem) Asm anzunähern- das aber nur auf Kosten > bücherfüllender, sich permanent erweiternder Konstruktions-Vielfalt, > diverser Kniffe und hochabstrakter gedanklicher Winkelzüge. > Asm ist da simpel und direkt- und hält zur genauen Planung der > vorhandenen Ressourcen an! > Memory-Leakes sind PROGRAMMFEHLER! Garbage-Collektoren sind hin und wieder sinnvoll wenn sich z.B. ein Objekt selbst vernichten kann und das passieren soll/muss wen die CPU gerade frei ist. > Hans schrieb: >> wenn der compiler x87, MMX, SSE, SSE2 SSE3 und AVX gleichzeitig >> nutzen kann > > Stattdessen könnte mir der Controllerhersteller aber auch gleich fertige > Asm-Routinen für typische Aufgaben und Berechnungen liefern! > für typische konstrukte gibts built-in functions oder intrinsics die genau das sind, wenns aber nicht typisch ist, dann macht der compiler einen besseren job. > Scelumbro schrieb: >> Vielleicht erbarmt sich ja jemand... > > Am Erbarmen ist es bei mir jedenfalls nicht gescheitert, als ich dem > Thread > Beitrag "C++ auf einem MC, wie geht das?" > eine (leider gelöschte) reine Asm-Lösung für ein einfaches Problem > lieferte, an dem sich die Protagonisten der hohen OOP-Kunst monatelang > die abstrakten Zähne ausbissen und bei dem bis heute nichts handfest > Nutzbares bei rum gekommen ist (siehe Anhang). > >> und macht dann schnell das >> entsprchende Programm in C. > > Auf gehts, Scelumbro! > 266 Code-Bytes + 6 RAM gilt es zu unterbieten ;-) Ich habe den Thread kurz Durchforstet... bei deinem Motor-Beispiel war der C-Code ja 2 Instrutionen kleiner... hmmm Übrigends, bei den vielen registern am AVR wunderts mich dass du überhaupt ram verwendest... 133 Instruktionen und alle 32 Register voll? read-modify-write ist doch krass ineffizient ;P Schick mir dein ASM teil als PM... mal schaun ob ich mir neben arbeit und uni noch für den Spass zeit freischaufeln kann... wobei du in dem von dir zitierten Thread schon einige Beispiele für kleinen code sind.. 73
Hans schrieb: > enn das Objekt nicht dynamisch instanziert wird und du nicht vererbst > gibt's KEINEN unterschied zu globalen variablen + funktionen die > irgendwas damit machen... > > der code wird schlicht "schöner". Mach dir keine Mühe. Moby versteht schlicht nicht was ein Compiler ist und was dieser kann und macht. Ich persönlich glaube in seinem Kopf sind Compiler und Interpreter dasselbe. Genauso wie OOP und C. Und OOP und Windows ... Hans schrieb: > Ich habe den Thread kurz Durchforstet... bei deinem Motor-Beispiel war > der C-Code ja 2 Instrutionen kleiner... hmmm > > Übrigends, bei den vielen registern am AVR wunderts mich dass du > überhaupt ram verwendest... 133 Instruktionen und alle 32 Register voll? > read-modify-write ist doch krass ineffizient ;P Den Code hat er wahrscheinlich irgendwo kopiert. Und dann war es ihm nicht mehr möglich sein Konzept eines maximal Hardware optimierten Programms umzusetzen. Moby schrieb: > In Asm ist dabei genaue Umsetzung der benötigten Funktionalität mit > genau dem nötigen Speicher möglich, meist mit direktem=effizientem > Hardwarezugriff- das gilt für jede Plattform.
Scelumbro schrieb: > Mach dir keine Mühe. Moby versteht schlicht nicht was ein Compiler ist > und was dieser kann und macht. Mehr als Du von Asm ganz sicher... > Den Code hat er wahrscheinlich irgendwo kopiert. Bestimmt. Ist für so einen Kenner wie Dich auch die bequemste Erklärung- kann ich doch verstehen ;-) Hans schrieb: > passta Nix passta... GB Verbräuche in Flash und RAM, das straft Euch doch Lügen. Wie diese Verschwendung sich nun auch immer genau zusammensetzt, meine Vermutungen sehe ich da jedenfalls noch nicht ganz aus der Welt. > Garbage-Collektoren sind hin und wieder sinnvoll wenn sich z.B. ein > Objekt selbst vernichten kann und das passieren soll/muss wen die CPU Sinnvoller ist es, sein System vollständig selbst unter Kontrolle zu haben und sich diese Dienste sparen zu können. > für typische konstrukte gibts built-in functions oder intrinsics die > genau das sind, wenns aber nicht typisch ist, dann macht der compiler > einen besseren job. Sicher. Das gibt es alles. Genauso wäre aber ein OS auf Asm-Basis vorstellbar, siehe Menuet u.a. Compiler mögen Arbeit und Zeit sparen. Passgenau, schnellstmöglich, mit geringstem Platzbedarf und richtig angewandt macht Asm in Handarbeit den besten Job. Ein Haus noch ganz aus Ziegel, keines aus großformatigen Fertigelementen! Aber schon klar, ein waschechter Hochsprachler will das nicht glauben - glaube ich ;-) > Übrigends, bei den vielen registern am AVR wunderts mich dass du > überhaupt ram verwendest... 133 Instruktionen und alle 32 Register voll? > read-modify-write ist doch krass ineffizient ;P Die Register nutzt man sinnvollerweise besser für andere Aufgaben! Was Du da im Interrupt findest ist ein universell verwendbares und für sich unabhängiges Modul - vielleicht als Teil eines viel größeren Programms? Ich sagte doch schon, Asm hat was mit Effizienz und Sparsamkeit zu tun... > Schick mir dein ASM teil als PM... mal schaun ob ich mir neben arbeit > und uni noch für den Spass zeit freischaufeln kann... Das kannst Du hier schlicht runterladen, das ist ein vollständiges Programm. Und wieso Zeit freischaufeln? In OOP ist die Aufgabe todsicher ein Klacks...
:
Bearbeitet durch User
Don Moby und sein K(r)ampf gegen die Gigabytemühlen. Und er reitet auf seinem geliebten ATTiny der Sonne entgegen. Neben im sein ergebener Assembler Sancho Pansa.
Bastler schrieb: > sein ergebener Assembler Das hast Du schön gesagt. Darauf ist Verlass. Alles unter eigener Kontrolle!
Sorry, aber mit deinem Beispiel-Code ist alles gesagt. So übersichtlich und mit wunderschönen Konstanten versehen. Es gibt auch in der (Atmel-)ASM-Welt Files mit Konstante für alle SFR-Bits. Man muß das nicht einfach hinschmieren. Oder wird deine Tastatur anschlagabhängig bezahlt? Wir können uns ja darauf einigen, daß man kleine Probleme so angehen kann. Aber "da draußen" ist leider viel größer.
Bastler schrieb: > Sorry, aber mit deinem Beispiel-Code ist alles gesagt. Tatsächlich? > Es gibt auch in der (Atmel-)ASM-Welt Files mit Konstante für alle > SFR-Bits. Man muß das nicht einfach hinschmieren. Na wenn das Dein einziges Problem ist ?! Das verdunkelt mir den Blick vorwärts der Sonne entgegen nun nicht gerade ;-)
:
Bearbeitet durch User
Was macht Moby eigentlich wenn sich die ARM's weiter durchsetzen und AVR mehr und mehr obsolet wird?
Ich gebs auf.... Moby deine Beispiele wurde im anderen thread unterboten. Du widersprichst dich auch noch selbst... Effizient wären nur Register bevor sie unbenützt sind... spart Speicher und Zeit. Naja... Um abschließend noch etwas öl ins Feuer zu gießen, das langsamste Interpreter Programm kann ein hochoptimiertes asm programm outperformen wenn die algorithmen besser sind... Daher lass ich das takt-zählen dem Compiler und verschwände meine Zeit im algorithmendesign... 73
Assembler? wie ineffizient ist das denn? Das braucht ja so Speicherplatz verschwenden Programme wie Assembler, die für die Übersetzung in Maschinensprache wahnsinnig viel Leistung verschwenden (vor allem so welche, die in bösem C geschrieben wurden wie NASM). Daher sollten alle Programmierer nur Maschinencode schreiben und den direkt in den Speicher schreiben. Warten muss sowas eh niemand, Menschen machen ja keine Fehler :) #Ironie off Jetzt mal im Ernst: Es wird schon Gründe gegeben haben, wieso schon in den 50ern Fortran entwickelt wurde (das sogar interpretiert wurde), um nicht mehr Assembler schreiben zu müssen... Und danach COBOL und später C und C++ oder Python oder unzählige andere Sprachen. Die wären ja gar nicht nötig gewesen, wenn Assembler !!der!! einzig wahre Weg wäre...
Das ist wie mit dem Geisterfahrer: Einer? Millionen Hochsprachenverblendete :-)
Hans schrieb: > Ich gebs auf.... Moby deine Beispiele wurde im anderen thread > unterboten. > Das ist auch besser so ;) Der Junge ist für Argumente so oder so nicht zugänglich und im Thread "[ASM] Unbenutzte Symbole entfernen", wo es um Wissen zu Assembler ging, war natürlich kein Pieps von ihm zu hören...
Andreas Richter schrieb: > Was macht Moby eigentlich wenn sich die ARM's weiter durchsetzen > und AVR mehr und mehr obsolet wird? Nun, wer das Thema über die Jahre verfolgt kennt diese amüsante These ;-) Hans schrieb: > Ich gebs auf.... Moby deine Beispiele wurde im anderen thread > unterboten. Da ist mit dieser Funktionalität nix unterboten. > Du widersprichst dich auch noch selbst... Effizient wären nur Register > bevor sie unbenützt sind... spart Speicher und Zeit. Du denkst zu kurz. Das ganze Programm nützt diese schnelle Speichermöglichkeit schon ganz aus. Registerspeicher und verwendeter Programm/Datenspeicher (sparen-> nächstkleineres MC-Derivat) sind eben verschiedene Paar Schuhe. > Naja... Um abschließend noch etwas öl ins Feuer zu gießen, das > langsamste Interpreter Programm kann ein hochoptimiertes asm programm > outperformen wenn die algorithmen besser sind... Was bringt Dich zu der Vermutung, daß ein guter Algorithmus nicht in Asm zu realisieren wäre? Der gelingt damit prinzipiell sogar besser, da der Programmierer die Feinheiten der Hardware optimal in kürzestem Code ausnutzen kann. Ein Asm-Programmierer kennt sich mit der Hardware-Basis in der Regel sowieso besser aus, während der OOPler meist ohne viel Bodenkontakt in abstrakten Höhen schwebt und gar nicht mehr vollständig in der Hand hat, was seine meist fremderstellten Codebausteine so alles an Programm-und Datenspeicherbedarf fabrizieren.
maschinencode schrieb: > Die wären ja gar nicht nötig gewesen, wenn Assembler !!der!! einzig > wahre Weg wäre... Ich bin durchaus nicht so einfältig zu glauben, daß es einzig wahre Wege gäbe. Die Wege mögen gar so vielfältig sein wie die Anwendungen selbst. Nur, wenn Betriebssysteme wie Brillo und noch übler Windows diesen alles in den Schatten stellenden Speicherverbrauch produzieren muß schon die Frage erlaubt sein, was sich diese von effizient programmierten Asm-Systemen abschauen können. Führ Dir die Links im Eingangsposting nochmal zu Gemüte! Bastler schrieb: > Das ist wie mit dem Geisterfahrer: Einer? Millionen > Hochsprachenverblendete :-) Verblendung? Na ja ich tät mich zu dieser Übertreibung jetzt nicht hinreißen lassen. Was man aber feststellen kann ist, daß etwas mehr Grundlagen in Asm manch einem recht gut täten :-)
Hans-Georg Lehnard schrieb: > Der Junge ist für Argumente so oder so nicht > zugänglich und im Thread "[ASM] Unbenutzte Symbole entfernen", wo es um > Wissen zu Assembler ging, war natürlich kein Pieps von ihm zu hören... Der Junge leistet mit seiner viele Jahre langen Asm-Praxis einfach hartnäckig Widerstand. So schwer ist das bei vielen Argumenten aus der herabschauenden OOP-Kaste auch gar nicht. Das OOP Haus steht dafür zuoft auf schwammigem Untergrund ;-) Zu jedem Thread kann hier niemand piepsen- ich leiste aber durchaus auch Hilfe und liefere objektive Info (soll das ein Mod bitte hier und jetzt abstreiten ;-)
Widerstand gegen was? Einem "ASM-Kameraden" beim Verstehen von Libs und Linker zu helfen. Vermutlich ist der GNU-Linker nicht in der einzig waren Sprache geschrieben. Außer Gemotze gegen etwas, was der Junge offensichtlich nie verstanden hat, kam bisher nix.
Bastler schrieb: > Gemotze So wie die Intention von Bastler's Beiträgen in jenen recht offen zur Schau getragen wird bekundet nun auch diese Begriffswahl recht freimütig: [ ] Ich verstehe die Vorteile von Asm nicht. [ ] Ich will die Vorteile von Asm nicht verstehen. Vermutlich beides.
Du verstehst anscheinend die massiven Nachteile nicht. Wenn ich muss, kann ich problemlos auch asm Routinen beispielsweise in c++ verwenden. Zu 99,995% der Zeit ist das aber nicht notwendig und sinnvoll. Einen at-tiny mag man noch beherrschen mit den paar opcodes, ein x86 ist ein total anderes Kaliber! Ob 486 oder Core i7-6000 Familie, das ist nur 1 compilerflag und ich bekomme fast optimalen Code. In asm heissts komplett neuschreiben wenn man zb. Von 486-fpu auf die netten vector-extension umstellen will. Da gibts auch kein wenn und aber! Die 19 Millionen (!) lines of Code zeigen eigentlich ziemlich deutlich warum ein asm-Betriebssystem nur eine tech-demo sein kann. Sagen wir vom Kernel ist 1% für dich relevant, dann stehen dir knapp 200.000 code-zeilen x gegenüber... Ich würde schätzen das macht 2millionen asm instruktionen die für jede Prozessor Generation (natürlich auch für jede plattform) optimiert werden müssen ... Nicht handelbar! Das immer größer und langsamer werden hat in meinen Augen andere gründe: - Gute Programmierer (die sich dann auch das passende werkzeug nehmeb) sind seeehr selten - Die Anforderungen haben sich verschoben - Früher würde auf Eingabefehler oft einfach geschissen - Man erwartet dass jede Software mit jeder Version von sich selbst und von der konkurenz Daten austauschen kann. Naja , hetzt bin ich aber endgültig weg...
> >[ ] Ich verstehe die Vorteile von Asm nicht. > >[ ] Ich will die Vorteile von Asm nicht verstehen. [x] Ich kenne auch die Nachteile von ASM aus über 3 Jahrzehnten Tätigkeit, die mich und meine Familie ernährt hat. Wann hat Atmel nochmal die wunderbar kleine Welt des Moby Dick erschaffen? In den 30 Jahren gab's da auch ASM auf Mainframes, da hat man wenigsten seit über 40 Jahren das gleich Programmiermodell. Und jede Zeile bringt auch was ein. Und gab so kleines wie 8048, die μC-8Bit-Version des 4004. Ohne Softwareunterstützung, per Hand-Assembler. Etwas Erfahrung hab ich also schon gesammelt. Irgendwann gab es dann klaubare, später kostenlose Compiler. Wer die nicht mag, ist selber Schuld. ASM verstehen: ja, schreiben müssen: wo geht's hier noch mal zum Auspeischen? (frei nach einem berühmten ,blasphemischen Filem). BTW, Hans hat recht ...
Moby AVR schrieb im Beitrag #4143213: > Daran verschwende ich keinen Gedanken. Wer genug von etwas hat, kann auch mal was verschwenden. Ist wie mit dem RAM.
Martin schrieb: > Wer genug von etwas hat, kann auch mal was verschwenden. Ist wie mit dem > RAM. Ja, das ist sie wohl, die Mentalität die hinter all dem steht ;-( Hans schrieb: > Du verstehst anscheinend die massiven Nachteile nicht. ... die sich zu großen Teilen daraus ergeben, daß die nötigen Grundlagen effektiver Asm Programmierung für größere Systeme nie geschaffen wurden. > Einen at-tiny mag man noch beherrschen mit den paar opcodes, ein x86 ist > ein total anderes Kaliber! Menuet u.a. zeigen doch, daß es möglich und attraktiv ist. Andreas Richter schrieb: > Woher kommt eigentlich das Märchen, dass OOP mehr Speicher > verbraucht? Ok, ich habe dazu einige Vermutungen angestellt, warum man derart aufgeblasenen Speicherbedarf heutiger OOP Produkte sieht. Das Schöne an diesem Forum ist aber, daß auch viele Insider zu Wort kommen die mutmaßlich täglich mit OOP zu tun haben und dem angeblichen Märchen bittere Wahrheit bescheinigen. Mal wild aus einem aktuellen Thread herausgegriffen: Fpga Kuechle schrieb: > Embedded und C++ sind klassischerweise schwer vereinbar, da der > Speicher i Embedded bereich eher klein ist. Außer man verzichtet auf > einige C++ features. Aber dazu benötigz man viel Erfahrung und > Selbstdisziplin. Es ist in C++ einfacher Resourcen zu verschwenden als > in C. In diesem Sinne verabschiede ich mich mal vorerst in die schönste Zeit des Jahres. Happy verschwending- äh programming ;-) Moby.
:
Bearbeitet durch User
Versprochen??
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.