Hallo, kann man generell Sagen wie viel Zeilen Code in 64 kB , 128 kB und 256 kB Flash Rom passen? Gibt es da auch einen Unterschied zwischen den 32 Bit ARM Mikrocontrollern von TI (TM4C) und den 8 Bit Mikrocontrollern von AVR (ATmega8)?
:
Bearbeitet durch User
Ich bin mir sicher, dass wenn man sich etwas Mühe gibt, bekommt man mit wenigen Zeilen, jeden Speicher voll.
42.
Ein AVR mit 8 kB Flash fasst genau 4096 Zeilen AVR ASM Code, wenn man die paar Befehle nicht einsetzt, die ein doppelwort belegen. Weiss gar nicht, warum hier nicht einfach die Antwort auf die Frage gegeben wird und gut ist?
Compilier mal den gleichen Code für unterschiedliche Architekturen und dann mal mit und ohne Optimierung, dann schreib mal in eine Zeile 1000 Befehle mit ; getrennt oder nur einen in je 1000 Zeilen. Dann guck mal wieviele Zeilen ASM Code aus deinem C Code gemacht wurden.
ASM Superprofi schrieb: > Weiss gar nicht, warum hier nicht einfach die Antwort auf die Frage > gegeben wird und gut ist? Weil die Frage Unsinn ist.
ASM Superprofi schrieb: > Ein AVR mit 8 kB Flash fasst genau 8192 Zeilen AVR ASM Code, wenn > man nur NOP verwendet. awsssxddrt
radiostar schrieb: > Weil die Frage Unsinn ist. Unsinn ist die Frage nicht, denn für den Entwickler ist das eine enorm wichtige Frage bei der Auswahl der Hardware. Nur ist die Frage sehr schwer zu beantworten.
Sie ist Unsinn, wenn ich z.B. C nehme kann ich mit einer Zeile (Printf auf ein double) schon einige kB an programmcode durch importLibs generieren. Das gleiche gilt, wenn ich C++ mit dynamsicher Allozierung benutze. Wenn ich statt dessen trivialen Code mit vielen Leerzeilen und/oder Kommentar habe (oder gar Assembler) dann liegt der Verbrauch ganz schnell um mehrere Größenordnungen niedriger.
@Bernd Olsen (predator7) >Hallo, kann man generell Sagen wie viel Zeilen Code in 64 kB , 128 kB >und 256 kB Flash Rom passen? Nein, das kann man nicht, denn es gibt keinen festen Zusammenhang zwischen der Anzahl Codezeilen einer Hochsprache und der daraus entstehenden Binärdatei. Das liegt u.a. daran, daß sich hinter einfachen Anweisungen sehr große Funktionen verbergen können, welche viel Speicherplatz verbrauchen. >Gibt es da auch einen Unterschied zwischen den 32 Bit ARM >Mikrocontrollern von TI (TM4C) und den 8 Bit Mikrocontrollern von AVR >(ATmega8)? Sicher, denn diese haben undterschiedliche CPUs und damit Befehlssätze.
klugscheißerlein schrieb: > radiostar schrieb: >> Weil die Frage Unsinn ist. > > Unsinn ist die Frage nicht, denn für den Entwickler ist das eine enorm > wichtige Frage bei der Auswahl der Hardware. Nur ist die Frage sehr > schwer zu beantworten. Nee die ist simpel zu beantworten. Bringt aber nix weil die eigenetliche Frage: "Passt meine Programm in den uC" nicht beantwortet wird, weil es keine Umrechnung für lines_of_code = F(Problemstellung) gibt. Oder kann einer sagen wieviel lines of code besoielsweise für eine simple Lötstation wie diese braucht? http://www.elv.de/elv-80-w-komfortloetstation-at-80d.html Und welche verkaufsfürdernde Konfortfeatures man einbauen muss um den Absatz zu erhöhen oder Kosten bei der Produktion zu sparen. Und ob dieser Absatzsteiegerung die Kosten für größeren Code rechtfertigt. Oder ob Kosteneinsparung durch Reduzierung Programcode und downgrad auf kleineren µC nicht wieder potentielle Kunden vergrault und so als Schuß ins eigene Knie endet.
Entweder man hat Erfahrungswerte oder man nimmt mal ein Evaluierungs Board mit viel Flash und beschafft sich so Erfahrungswerte. Die Frage ist aber trotzdem Unsinn denn um Sinn zu machen müsste sie genau spezifiziert sein auf CPU, und Programmiersprache wobei als Programmiersprache nur Assembler dafür taugt und wie schon gesagt wurde auch nicht von der Anzahle der möglichen Befehle auf eine Problemlösung zurückgeführt werden kann oder es müssten zuerst Statistiken erstellt werden was die durchschnittliche Programmgröße für bestimmte Programmiersprachen und Aufgaben ist.
Bernd O. schrieb: > Hallo, kann man generell Sagen wie viel Zeilen Code in 64 kB , 128 kB > und 256 kB Flash Rom passen? Ziemlich viele. Bei Briefen haben wir früher mit etwa 2000 Zeichen pro Seite gerechnet. Aber du willst ja vermutlich nicht den Sourcecode im Flash speichern. Falls doch, böte es sich an den Text vorher zu komprimieren.
Hp M. schrieb: > Aber du willst ja vermutlich nicht den Sourcecode im Flash speichern. > Falls doch, böte es sich an den Text vorher zu komprimieren. Und wohin willst du beim AVR den komprimierten code entpacken???
Achso ich vergass, dass hier keiner mehr richtig in Assembler programmiert. Da ist die Frage nämlich banal und einfach zu beantworten.
Hi
>Da ist die Frage nämlich banal und einfach zu beantworten.
Weder banal, noch einfach zu beantworten.
Und ich programmiere noch in Assembler.
MfG Spess
Ich sagte bereits weiter oben, dass man sich auf Befehle beschränken muss, die nur ein Wort belegen. Während man auf call und jmp meistens gut verzichten kann, muss man bei lds und sts jedoch zwei Datenworte einkalkuieren. Alle anderen AVR Befehle kommen mit 2 Byte aus, also banal.
ASM Superprofi schrieb: >> Weder banal, noch einfach zu beantworten. > > Begründung? Kommentare, Labels, nops, Leerzeilen.
ASM Superprofi schrieb: > Achso ich vergass, dass hier keiner mehr richtig in Assembler > programmiert. Da ist die Frage nämlich banal und einfach zu beantworten. Nur wenn jeder Befehl auf dem Prozessor die gleiche Menge an Bytes zur Kodierung benötigt. Es gibt Prozessoren bei denen dies der Fall ist, aber das sind bei weitem nicht alle. Siehe auch: https://en.wikipedia.org/wiki/Instruction_set#Instruction_length
:
Bearbeitet durch User
Hi >Ich sagte bereits weiter oben, dass man sich auf Befehle beschränken >muss, die nur ein Wort belegen. Während man auf call und jmp meistens >gut verzichten kann, muss man bei lds und sts jedoch zwei Datenworte >einkalkuieren. Wenn man nur Spielzeugprogramme, die auf Call und Jmp verzichten können, programmiert, magst du Recht haben. Meine Programme sind im allg. größer. MfG Spess
ASM Superprofi schrieb: > Ich sagte bereits weiter oben, dass man sich auf Befehle beschränken > muss, die nur ein Wort belegen. Während man auf call und jmp meistens > gut verzichten kann, muss man bei lds und sts jedoch zwei Datenworte > einkalkuieren. Alle anderen AVR Befehle kommen mit 2 Byte aus, also > banal. Das ist ja alles schön und richtig - nur, was bringt uns dieses Wissen? Deswegen wissen wir noch lange nicht, ob ein bestimmtes Problem sich mit der angebotenen Speichermenge lösen lässt. Und deshalb meinte ich weiter oben, daß die Frage Unsinn ist.
ASM Superprofi schrieb: > Ein AVR mit 8 kB Flash fasst genau 4096 Zeilen AVR ASM Code, wenn man > die paar Befehle nicht einsetzt, die ein doppelwort belegen. > > Weiss gar nicht, warum hier nicht einfach die Antwort auf die Frage > gegeben wird und gut ist? Er hat aber nicht nur nach AVR gefragt, sondern auch nach ARM. Es bleibt dabei: So wie die Frage gestellt ist, ergibt sie nicht viel Sinn. Einen 32-Bit ARM Mikrocontroller programmiert heutzutage auch praktisch niemand mehr in reinem Assembler. Bei einem kleinen 8-Bitter mag das noch anders aussehen.
ASM Superprofi schrieb: > Achso ich vergass, dass hier keiner mehr richtig in Assembler > programmiert. Da ist die Frage nämlich banal und einfach zu beantworten. Schön, dein Hobby ist also Fragen zu beantworten, die so nie gestellt wurden. Wenig sinnvoll, aber das muss ein Hobby ja auch nicht sein :-) Oder wo stand in der Frage das Wörtchen "Assembler"?
Davon abgesehen gibt es auch Makroassembler, mit denen man in wenig Code viel Flash verbraten kann.
Bernd O. schrieb: > Hallo, kann man generell Sagen wie viel Zeilen Code in 64 kB , 128 kB > und 256 kB Flash Rom passen? Nein ich fange jetzt nicht an Codezeilen zu zählen, aber in meinem NETIO von Pollin mit m1284p stecken 66KB Code aus etlichen *.o Files.
:
Bearbeitet durch User
Der Andere schrieb: > Oder wo stand in der Frage das Wörtchen "Assembler"? Da steht da zwar nicht, aber wenn man gewillt ist der Fragen einen Sinn zuzugestehen dann ist die Schlußfolgerung Lines of code (Code zeilen) = Assembler zwangsläufig. Bei anderen Programmiersprachen macht die Frage nach der Programmspeicherkapazität gemessen in "lines of code" keinen Sinn, weil es keinen festen Umrechnungsfactor zwischen Codezeile (bspw C++) und dem machine-code (in dem das Prog letzlich angespeichert wird), gibt! Bspw. ein einzeiliger Methodenaufruf in einer OOP-Syntax metasiert ruckzuck zu einer wahren POP/PUSH Orgie.
Also mal so als Anhaltpunkt einer Größenordnung, ich hab ein Projekt mit 20.000 Zeilen Code. Dabei sind nur die C-Files berücksichtigt, nicht die Includefiles. Kommentarzeilen und Leerzeilen sind auch rausgerechnet. Bibliotheken habe ich keine drin, auch nicht die C-Runtime - natürlich kann man sich mit Bibliotheken das Binary nahezu beliebig aufblähen. Auf STM32 schmeißt GCC am Ende etwa 128kB an Binärcode raus, optimiert auf Geschwindigkeit, nicht auf Größe. Das eigentliche Image ist noch deutlich größer, aber das sind inkludierte Binärdaten und kein Code. Einige kB kann man noch abziehen, das sind Lookuptabellen, die ja auch Daten und kein Code sind, das sind geschätzt etwa 10kB. Unterm Strich geben also 20.000 Zeilen C-Quelltext dann 118kB Binärcode. Hängt aber auch sehr davon ab, WIE man codiert - ich selber bevorzuge einen Stil mit recht simplen Anweisungen pro Zeile, d.h. ich splitte komplexe Anweisungen lieber auf mehrere Zeilen. Außerdem setze ich die { und } jeweils in eigene Zeilen. Man könnte von meinen Zeilen oftmals auch zwei, drei Zeilen in eine komplexere Zeile gießen, das wäre dann kompakter, aber für meinen Geschmack schlechter lesbar.
ASM Superprofi schrieb: > Achso ich vergass, dass hier keiner mehr richtig in Assembler > programmiert. Auch in Assembler lassen sich mehrere Instruktionen in eine Zeile packen (zumindest beim GNU-Assembler geht das mit "$" als Trennzeichen). Auch in Assembler kann ein Aufruf einer Bibliotheksfunktion (1 CALL- Instruktion) nahezu beliebig langen Bibliothekscode nach sich ziehen. > Da ist die Frage nämlich banal und einfach zu beantworten. Richtig, nämlich folgendermaßen (und das sogar unabhängig von der verwendeten Programmiersprache): Bernd O. schrieb: > Hallo, kann man generell Sagen wie viel Zeilen Code in 64 kB , 128 kB > und 256 kB Flash Rom passen? Nein. > Gibt es da auch einen Unterschied zwischen den 32 Bit ARM > Mikrocontrollern von TI (TM4C) und den 8 Bit Mikrocontrollern von AVR > (ATmega8)? Ja.
klugscheißerlein schrieb: > Unsinn ist die Frage nicht, denn für den Entwickler ist das eine enorm > wichtige Frage bei der Auswahl der Hardware. Unsinn ist es, den Speicherbedarf anhand eines unbekannten und von den Schreibgewohnheiten des Programmierers abhängigen und damit hier im Forum unbekannten Skalierungsfaktors aus der Zeilenzahl des Codes bestimmen zu wollen. Insbesondere, da wenn weder Programmiersprache noch Optimierbarkeit des Codes bekannt sind, sieht es ganz finster mit der Prognose aus.
Hoffen wir mal, dass Ihr Bernd noch nicht ganz vergrault habt... Die Frage wieviel Code in XX Kilobyte Speicher paßt ist schwer zu beantworten, wenn Du in C oder einer anderen Hochsprach entwickelst. In Assembler ist es halbwegs einzuschätzen, weil Du ja sogar GANZ genau weißt, wieviel Platz jede einzelne Codezeile belegt (was jetzt allerdings nicht heißt, dass Du vor Beginn des Projekts wirklich wissen kannst, wieviel Du wirklich brauchen wirst). In C kannst Du relativ viel Logik in relativ wenig Text packen, da ist es schwer bis unmöglich, Dir da jetzt eine sinnvolle Antwort zu geben. Mit der Zeit kriegt der Entwickler halbwegs 'n Gefühl dafür, was er für 'n Prozessor braucht um seinen Code unterzubringen, nur hat das halt mehr mit Erfahrung als mit fixen Werten zu tun. Und selbst da greifst oft genug daneben weil sich da teilweise Überraschungen ergeben. Ich möchte es so ausdrücken: Anfangsprojekte, die die 64k Code sprengen sind sogar in C (und mit dem saumäßig optimierenden AVR Studio) schwer zu erstellen, wenn man nicht irgendwelche Wahnsinnsbibliotheken verwenden will/muss. In ASM sind 64k geradezu unheimlich viel. Man bedenke, dass der C64 grad mal so viel Platz für Programm, Code und Grafik insgesamt hatte.
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.