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.
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.
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.
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.
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.
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.
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.
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
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
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
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.
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... :-)
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, 64kAVR 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...
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.
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.
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 ;-)
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...
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.
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 ;-)
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...
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.
