|
|
Forum: Mikrocontroller und Digitale Elektronik Gibt es einen Formelparser für C (Arduino)Da ich mindestens 25 J. kein C programmiert habe, ist einiges in Vergessenheit geraten. Zum Auffrischen der Arbeitsweise der Operatoren würde ich mir eine Art Formelparser wünschen. Gibt es sowas? Wo man z.B. eingibt:
und der Inhalt von a dann angezeigt wird. Natürlich könnte ich das auch über die Arduino IDE machen. Also den Code in den Arduino laden und das Ergebnis auf dem seriellen Monitor anzeigen lassen. Ist aber nicht sehr effizient. Man kann C tatsaechlich auch fuer Windows oder Linux uebersetzen... Unter Linux hast Du den GCC meist direkt an Board, unter Windows kannst Du z.B. MingGW nehmen (auch der GCC). Unter Linux:
Mit cling gibt es einen C++-Interpreter, den man auch interaktiv nutzen kann. Siehe https://cdn.rawgit.com/root-project/cling/master/www/index.html Unter https://hub.mybinder.org/user/quantstack-xeus-cling-hxf21anm/notebooks/notebooks/xcpp.ipynb kann man das auch online ausprobieren. >Zum Auffrischen der Arbeitsweise der Operatoren >würde ich mir eine Art Formelparser wünschen. Gibt es sowas? Es gibt verschiedene: http://jamesgregson.blogspot.com/2012/06/mathematical-expression-parser-in-c.html Hier ein Taschenrechner mit Bit-Operatoren: https://github.com/BTL00/ar_sccalc Ich merke gerade, der zweite Link geht immer gleich kaputt, weil da mal wieder so eine blöde ID drin enthalten ist. Dann so: Auf https://jupyter.org/try gehen und dort "Try Jupyter with C++" anklicken. Vernünftige Taschenrechner wie der von Gnome (Linux) und ich glaube auch Windows 10 unterstützen Formeln in mathematischer Notation. Man könnte auch https://WolframAlpha.com empfehlen. Was für Formeln möchtest du genau berechnen? oder einfach einen Online C Compiler nehmen, manchmal sehr nützlich. https://www.jdoodle.com/c-online-compiler Entweder Online-C (JDoodle, oder sehr schön auch https://tio.run/ für alle möglichen Programmiersprachen), oder was ich gerne mache: Code::Blocks. Ist ne einfache und kompakte IDE für C, die ich nutze, um schnell mal was auszuprobieren, bevor ich es ständig aufn Controller schubsen und mir das Debugging seriell angucken muss. Danke für die Tipps. Hatte leider vergessen zu schreiben, dass ich weder C noch Linux griffbereit installiert habe :( MingGW/GCC ließ sich nicht installieren bzw. die Serververbindung brach beim Download immer wieder ab. Mir fiel gestern dann noch ein, dass es früher im C-Editor so ein Evaluate-Fenster gab. Bei der "nur" 400 MB großen Arduino-DE ein Evaluate-Tool zu vermuten, wäre wohl vermessen. Es gibt natürlich auch keins. Für popelige 400 MB wäre kann man das auch gar nicht verlangen. Doch ihr werdet es nicht glauben. Auf der Festplatte habe ich ein TC gefunden. Alte EXE unter DOS, und hat ein Tool 'Evaluate and Modify'. Damit geht es :-) Wozu die Arduino-DE 400 MB braucht, und doch nix kann, wissen wohl nur die "Profis", die es programmiert haben. TC-EXE ist gerade mal 1234 KB groß. Roth schrieb: > TC-EXE ist gerade mal 1234 KB > groß. Kennt es auch all die hochkomplexen Optimierungs-Algorithmen, welche der bei Arduino integrierte GCC unterstützt? Alle aktuellen Sprachstandards (C++17, C11)? Unterstützt die Plattformen AVR und Cortex-M? Liefert Bibliotheken und Beispiele für alles mögliche mit? Roth schrieb: > Wozu die Arduino-DE 400 MB braucht, und doch nix kann, wissen wohl nur > die "Profis", die es programmiert haben. The Arduino integrated development environment is a cross-platform application that is written in the programming language Java. (Quelle: https://en.wikipedia.org/wiki/Arduino_IDE) merciless Dr. Sommer schrieb: > Kennt es auch all die hochkomplexen Optimierungs-Algorithmen, welche der > bei Arduino integrierte GCC unterstützt? Alle aktuellen Sprachstandards > (C++17, C11)? Unterstützt die Plattformen AVR und Cortex-M? Liefert > Bibliotheken und Beispiele für alles mögliche mit? Wir reden von 400 MB, Megabygte. In Buchstaben: 200.000 vollgeschriebene Schreibmaschinenseiten, Zweihundertausend. Auch Dr. Sommer kann nicht begründen, wozu man soviel Platz braucht, um ein lauffähiges Programm zu erstellen. Auch die Bibliotheken sind nur im Textformat, Text Selbst 1234 KB braucht es bei weitem nicht, um eine lauffähige IDE zu erstellen. Und von 400 MB wollen wir gar nicht reden. Roth schrieb: > Auch Dr. > Sommer kann nicht begründen, wozu man soviel Platz braucht, um ein > lauffähiges Programm zu erstellen. Es erstellt nicht einfach nur ein lauffähiges Programm. Es durchläuft viele komplexe Algorithmen, bindet viele Bibliotheken ein, um ein effizientes lauffähiges Programm zu erstellen. Schau dir einfach mal an, was in einer GCC-Distribution alles so drin ist. Allein die C++ Standard Bibliothek ist nicht so ganz klein. Der ARM-GCC enthält gleich mehrere Varianten der vorkompilierten Bibliotheken für die verschiedenen Architektur-Varianten, das nimmt auch einiges weg. Roth schrieb: > Auch die Bibliotheken sind nur im > Textformat, Text Nein, die sind vorkompiliert (.a). Roth schrieb: > Selbst 1234 KB braucht es bei weitem nicht, um eine lauffähige IDE zu > erstellen. Und von 400 MB wollen wir gar nicht reden. Über "lauffähig" ist die Technik schon lange hinaus. Es gibt da auch so Sonderwünsche wie "Geschwindigkeit". Es steht dir frei, einen anderen Compiler mit weniger Features zu nutzen. In welchem Jahrhundert lebst du noch? Irgendwie hast du da einige Jahrzehnte verpasst... GCC für Windows kannst du z.B, hier finden: https://www.msys2.org Oliver Warum braucht ein langweiliger Compiler 25MB, so schwer kann es doch nicht sein ein wenig Text in Bits und Bytes zu übersetzen? ;-) Sorry für das OT, aber das musste gerade mal sein. Wir haben seinerzeit einen kompletten BASIC-Interpreter mit nur 64 KB im ROM untergebracht. Und dieses BASIC war sogar eins der besten, was je es gab. Locomotive BASIC, da fehlte nichts. Der Zeit weit voraus und sogar interrputfähig. Die komplette Firmware der Maschine, auf der das BASIC lief, war ebenfalls nicht größer als 64 KB - mit allen Service- und Grafikfunktionen. So eine Hochstabellei wie heute gabs nicht, da wurde noch korrekt programmiert. Wer heute 400 MB mit "Bibliotheken und Funktionen" begründet, ist sich der Menge von 400 MB nicht bewusst Dann installiert mal Eclipse. Und das ist "nur" ein besserer Texteditor... Mike R. schrieb: > Warum braucht ein langweiliger Compiler 25MB, so schwer kann es doch > nicht sein ein wenig Text in Bits und Bytes zu übersetzen? ;-) Völlig korrekt. 1/1000, also 25 KB, stemmt diese Anforderung locker. Und zwar egal, wie komplex ein Code ist. Roth schrieb: > Sorry für das OT, aber das musste gerade mal sein. Wir haben seinerzeit > einen kompletten BASIC-Interpreter mit nur 64 KB im ROM untergebracht. Na dann, bau doch mal die Funktionalität des GCC und der C++ Standard Bibliothek in 64kB nach. Melde dich wenn du damit fertig bist (in ca 1000 Jahren) und festgestellt hast dass die 400 MB berechtigt sind. Schau doch einfach mal in den GCC-Ordner, was da so alles ist, und sag was davon überflüssig ist. Neben dem Compiler ist da ja auch noch die JVM, Programmiertool usw. Ja, das ginge kleiner, aber man hat andere Prioritäten gesetzt. Roth schrieb: > Sorry für das OT, aber das musste gerade mal sein. Wir haben seinerzeit > einen kompletten BASIC-Interpreter mit nur 64 KB im ROM untergebracht. > Und dieses BASIC war sogar eins der besten, was je es gab. Locomotive > BASIC, da fehlte nichts. Der Zeit weit voraus und sogar interrputfähig. > Die komplette Firmware der Maschine, auf der das BASIC lief, war > ebenfalls nicht größer als 64 KB - mit allen Service- und > Grafikfunktionen. So eine Hochstabellei wie heute gabs nicht, da wurde > noch korrekt programmiert. Wer heute 400 MB mit "Bibliotheken und > Funktionen" begründet, ist sich der Menge von 400 MB nicht bewusst Sorry für OT: Mir fällt auf, dass die Selbstbeweihräucherung in den Foren zunimmt. Habt ihr so wenig Erfolgserlebnisse, so dass ihr nur noch mit eurer "ruhmreichen" Vergangenheit glänzen könnt? Dr. Sommer schrieb: > Na dann, bau doch mal die Funktionalität des GCC und der C++ Standard > Bibliothek in 64kB nach. Melde dich wenn du damit fertig bist. Das brauche ich nicht, sowas gabs tatsächlich. Die Sourcen für einen C-Compiler finde ich auf die Schnelle nicht. Alternativ für BASIC, und ein vollständiges Betriebssystem (mit Grafikbearbeitung). 128 KB. ftp://ftp.cpcszene.de/pub/Computer/Amstrad_CPC/CPC-Literatur/CPC%20464%2 0INTERN.pdf Kannst dich ja mal einlesen, so lange dauert das nicht ;) Ach ja, und nochmas: Der CPC hatte 8 (acht) bekannte Fehler im Betriebssystem. Keine 8.000, wie man das von M$ gewöhnt ist. Roth schrieb: > Wozu die Arduino-DE 400 MB braucht Wie Dr. Sommer schon schrieb: Da ist ja sehr viel mehr als nur ein schlechter Texteditor bei. Das Zip-File ausgepackt braucht 500MB bei mir. Da ist dann aber auch die ganze Toolchain bei: Compiler fuer AVR und ARM, Tools zum flashen (avrdude fuer AVR und bossac fuer ARM), Beispiele, die ganzen Definitionen fuer die Controller, etc. und der Editor. Der 'example' Ordner sind bei mir schon 5,3MB, 'hardware' sind schon 189MB und der 'java' Ordner sind 207MB. 'libraries' sind nochmal 19MB. Ist zwar kein Formelparser, aber das Atmel Studio (kostenlos) enthaelt einen Simulator. Wenn dir das Atmel Studio nicht zusagt, es gibt auch noch andere Simulatoren, z.B. simavr. Jetzt sind wir ganz weg vom Schuss. Ich wollte das nicht so stehen lassen, dass gute (komplexe) Software den immensen Platzbedarf begründet. Das ist zwar in unseren Köpfen so drin, das ist aber nicht richtig. Alles fing damit an, dass M$ Libs u. DLLs einführte. Ein fertig compilierter CLS-Befehl, sonst nix, ergab dann eine EXE-Datei von 384 KB. brrr, es schütelt mich jetzt noch. Das war vor mehr als 30 Jahren, und ist seitdem nicht besser geworden. Aber wollen wir darüber nicht streiten, es ist so, wie es ist. Danke nochmal für die Tipps. Roth schrieb: > Das brauche ich nicht, sowas gabs tatsächlich. Du vielleicht nicht. Andere Nutzer des GCC schon. Sollen die mehrere Editionen rausbringen? Vollversion und Speicher-Knauser-Version? Roth schrieb: > Die Sourcen für einen C-Compiler finde ich auf die Schnelle nicht. Schau z.B. hier: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/ Roth schrieb: > Alternativ für BASIC, und ein vollständiges Betriebssystem (mit > Grafikbearbeitung). 128 KB. Ein BASIC-Interpreter ist ja auch easy. Es gibt halt Leute, die mächtigere Sprachen benutzen wollen, und GCC unterstützt diese. Unterstützt dieses 128KB-Betriebssystem auch tausende verschiedene Geräte, und die unzählig vielen möglichen Kombinationen daraus? Eine große Anzahl an Netzwerkprotokollen? Diese auch super robust? Integrierte Firewalls? Zig Dateisysteme? Präemptives Multitasking mit ausgefeiltem Scheduler? Optimales Paging? Linux und Windows schon. Roth schrieb: > Ach ja, und nochmas: Der CPC hatte 8 (acht) bekannte Fehler im > Betriebssystem. Keine 8.000, wie man das von M$ gewöhnt ist. Bau mal ein OS mit o.g. Features und so wenig Fehlern, aber nur mit dem begrenzten Budget von "M$". Und der Anzahl an existierenden Programmierern (Achtung: Der Arbeitsmarkt ist leer). Roth schrieb: > Alles fing damit an, dass M$ Libs u. DLLs einführte. Genau, ohne Bibliotheken ist alles viel besser, dann ist der gesamte Code in Zig Programmen dupliziert! Roth schrieb: > Wozu die Arduino-DE 400 MB braucht, und doch nix kann, wissen wohl nur > die "Profis", die es programmiert haben. TC-EXE ist gerade mal 1234 KB > groß. Ich frage mich, warum du die deiner Ansicht nach nutzlosen 400MB nicht längst von deiner Festplatte gelöscht hast. Löschtaste kaputt? Roth schrieb: > Wir haben seinerzeit einen kompletten BASIC-Interpreter mit nur 64 KB > im ROM untergebracht. Dann seid ihr vermutlich "Real Programmers". Was ihr damals geschafft habt, schafft ihr das heute ganz sicher immer noch. Allerdings: Die echten "Real Programmers" haben nicht gemeckert, sondern gemacht. Roth schrieb: > Alles fing damit an, dass M$ Libs u. DLLs einführte. Das ist doch Unsinn. Gerade DLLs werden ja nicht in der Exe verpackt sondern sollen auf dem Zielsystem schon zur gemeinsamen Nutzung vorhanden sein. Die werden erst bei der Ausführung gelinkt (daher das erste D). > Aber wollen wir darüber nicht streiten, es ist so, wie es ist. Keine Sorge. Spaten wie dir sage ich trotzdem immer gerne die Meinung. Streiten würde ich das nicht nennen. :
Bearbeitet durch User
Cyblord -. schrieb: > Das ist doch Unsinn. Gerade DLLs werden ja nicht in der Exe verpackt > sondern sollen auf dem Zielsystem schon zur gemeinsamen Nutzung > vorhanden sein. Die werden erst bei der Ausführung gelinkt (daher das > erste D). Kein Unsinn, sondern völlige Ahnungslosigkeit auf deiner Seite. Die Sourcen wurden vom Compiler in die EXE integriert. Was im übrigen auch die Größe von 384 KB nachweisbar belegt. Cyblord -. schrieb: > Keine Sorge. Spaten wie dir sage ich trotzdem immer gerne die Meinung. Du scheinst noch sehr jung zu sein. Aber sei dir gewiss: Deine Überheblichkeit wird sich noch legen ;-) Roth schrieb: > Cyblord -. schrieb: >> Das ist doch Unsinn. Gerade DLLs werden ja nicht in der Exe verpackt >> sondern sollen auf dem Zielsystem schon zur gemeinsamen Nutzung >> vorhanden sein. Die werden erst bei der Ausführung gelinkt (daher das >> erste D). > Kein Unsinn, sondern völlige Ahnungslosigkeit auf deiner Seite. Die > Sourcen wurden vom Compiler in die EXE integriert. Was im übrigen auch > die Größe von 384 KB nachweisbar belegt. Ist ja deine Entscheidung alle DLLs in die EXE zu integrieren. Du kannst auch gleich das ganze OS in eine EXE mit deiner Anwendung reinpacken. Sinnvoll ist das nicht und läuft dem Konzept einer DLL (und einem OS) auch zuwieder. > Cyblord -. schrieb: >> Keine Sorge. Spaten wie dir sage ich trotzdem immer gerne die Meinung. > Du scheinst noch sehr jung zu sein. Aber sei dir gewiss: Deine > Überheblichkeit wird sich noch legen ;-) Weder Jung noch Überheblich. Aber keine Sorge, Niveau sieht von unten immer aus wie Arroganz. :
Bearbeitet durch User
Roth schrieb: > Kein Unsinn, sondern völlige Ahnungslosigkeit auf deiner Seite. Die > Sourcen wurden vom Compiler in die EXE integriert. Wenn schon vom Linker. Und das gilt natürlich nur für statische Bibliotheken (.lib, .a). Der Sinn von DLL's (Dynamic Link Library) ist es, dass der Code eben nicht integriert ist, sondern zentral in der DLL abgelegt. Die kann man dann auch separat updaten. Warum sonst sind bei Windows jede Menge DLLs dabei, wenn der Inhalt nicht gebraucht würde?! Kannst sie ja mal löschen und schauen was passiert :-) Roth schrieb: > Was im übrigen auch > die Größe von 384 KB nachweisbar belegt. Ein Disassembler Dump würde mehr belegen. Zeig doch mal den Source Code dieser ominösen "zu großen" EXE. Natürlich integriert der Linker gewisse Teile in die .exe, welche aber teilweise nur Umleitungen auf die DLLS sind. Yalu X. schrieb: > Dann seid ihr vermutlich "Real Programmers". Was ihr damals geschafft > habt, schafft ihr das heute ganz sicher immer noch. Assembler gibts heute nicht mehr bzw. wird kaum kaum noch verwendet. Beim Schrauben an alten COBOL-Sourcen setze ich es ab und zu ein, wenn nichts anderes meht geht. Und JA, ich hätte keine Angst, dieses "Schaffen" unter Beweis zu stellen. Roth schrieb: > Und JA, ich hätte keine Angst, dieses "Schaffen" unter Beweis zu > stellen. Man merkt was für ein Experte zu bist. Große Klappe aber wenig Kompetenz wenns um die Sache geht. Peinlich! Dann eben vom Linker :) Dr. Sommer schrieb: > Ein Disassembler Dump würde mehr belegen. Zeig doch mal den Source Code > dieser ominösen "zu großen" EXE. Natürlich integriert der Linker gewisse > Teile in die .exe, welche aber teilweise nur Umleitungen auf die DLLS > sind. Du magst lachen, aber vielleicht habe ich die sogar noch. Habe die Dateien immer auf DVD oder CD gebrannt, wenn ich einen PC geschrottet habe. Ab und zu war das sogar ganz nützlich. Die CLS.EXE suche ich jetzt trotzdem nicht. Kannst sie aber selber auch erzeugen. Wenn meine Erinnerung nicht trügt, aber vermutlich trügt sie doch, konnte man mit Q-BASIC lauffähige EXE-Dateien erzeugen. Wenn nicht Q, dann Nachfolger. Das Ergebnis von "CLS" war dann die für damalige Zeiten riesige Datei...die nur den Bildschirm gelöscht hat, und sonst keine Funktion hatte. Darüber zu "meckern", lass ich mir jedenfalls nicht nehmen. Wer das akzeptiert, tritt jeden Entwickler in den A., der sich mit seiner Arbeit Mühe gibt. Just for fun: Im Anhang ist eine unter x86-Linux ausführbare Datei (ELF) welche einfach nur "Hello World" ausgibt. Sie ist 384 Bytes groß. Sie wurde mit dem GCC Compiler erstellt um zu zeigen dass er auch kleine Dateien produzieren kann. Manuelles Erstellen er ELF-Datei würde noch ein paar Bytes sparen, aber darum ging es nicht. Unter Windows ist das etwas komplizierter weil die Syscalls keine fixen Nummern haben und man die Kernel-DLL importieren muss, geht aber letztlich äquivalent auch so. Natürlich hat die Datei keine Verweise auf die C- oder C++-Standardbibliothek und kann daher deren ganze bequeme Funktionalität nicht nutzen. Dafür bräuchte es eine größere Datei. Roth schrieb: > Das Ergebnis von > "CLS" war dann die für damalige Zeiten riesige Datei...die nur den > Bildschirm gelöscht hat, und sonst keine Funktion hatte. Toll, eine .exe Datei die wahrscheinlich einen ganzen Basic-Interpreter enthält, der einen einzigen Befehl ausführt, der dann das CLS-Programm aufruft. Und das als Maßstab für Overhead nehmen? Wow. Mach das mal in C, das wird viel kleiner. Dann in Assembler, dann wird das bestimmt unter 1KB. Cyblord -. schrieb: > Roth schrieb: >> Und JA, ich hätte keine Angst, dieses "Schaffen" unter Beweis zu >> stellen. > > Man merkt was für ein Experte zu bist. Große Klappe aber wenig Kompetenz > wenns um die Sache geht. Peinlich! Endlich mal Tacheles: die einen zeigen grosse Klappe, die andern haben bereits über 10k Posts alleine in diesem Forum gepostet... Cyblord -. schrieb: > Man merkt was für ein Experte zu bist. Große Klappe aber wenig Kompetenz > wenns um die Sache geht. Peinlich! Nee, du bist peinlich. Große Klappe habe ich - immer gehabt - aber zu meiner "Expertenfähigkeit" halte DU einfach nur die Klappe. Das kannst du, unbekannterweise, gar nicht beurteilen. Und ich vermute, fachlich auch gar nicht nachvollziehen. So, ich bin draußen. Roth schrieb: > aber zu > meiner "Expertenfähigkeit" halte DU einfach nur die Klappe. Das kannst > du, unbekannterweise, gar nicht beurteilen. Ich lese was du zum Thema DLLs und EXE schreibst. Reicht mir. > So, ich bin draußen. Rauschender Abgang des "großen Experten". >Wozu die Arduino-DE 400 MB braucht, und doch nix kann, wissen wohl nur >die "Profis", die es programmiert haben. TC-EXE ist gerade mal 1234 KB >groß. Turbo-C unterstützt auch nur einen Prozessortyp und nicht viele wie die Arduino IDE. Das Packet ist so groß, weil die ganzen Toolchains für die verschiedenen Prozessoren und viele Bibliotheken für verschieden Boards mit geliefert werden. Roth schrieb: > Ein fertig > compilierter CLS-Befehl, sonst nix, ergab dann eine EXE-Datei von 384 > KB. brrr, es schütelt mich jetzt noch. Roth schrieb: > Darüber zu "meckern", lass ich mir jedenfalls nicht nehmen. Wer das > akzeptiert, tritt jeden Entwickler in den A., der sich mit seiner Arbeit > Mühe gibt. Echt absurd, erst Q-Basic zu nehmen, dann zu lästern dass das große ausführbare Dateien produziert und das auf dynamische Bibliotheken zu schieben! Das ist so wie mit einem VW Käfer rückwärts 1m weit zu fahren, zu lästern dass das länger als zu Fuß dauert und die Schuld der Elektromobilität zu geben. Aus Langeweile hab ich mal rumprobiert wie man mit aktuellem Visual C++ eine möglichst kleine .exe produziert. Die angehängte Datei ist 1552 B groß und auf 64bit-Windows ausführbar. Mit manuellen Hex Editor Hacks lässt sich das noch stark reduzieren, aber ich wollte es mit aktuellen Standard-Tools machen. Des weiteren ist eine MathParser.jar angehängt, welche ein simples Java-Programm enthält, mit welchem sich mathematische Audrücke auswerten lassen. Es nutzt die exp4j-Bibliothek. Die miniexe.exe zeigt wenn gestartet eine Meldung an. Bestätigt man diese mit Ja, wird Java gestartet und der MathParser.jar ausgeführt. Man könnte natürlich auch CLS ausführen aber das ist ja langweilig. Damit das funktioniert muss die javaw.exe über den Path auffindbar sein (d.h. die JRE muss auf übliche Art und Weise installiert sein). Zusammen also ein Formelparser und eine Exe auf 48kB. In Java einfach nur um die Java-Hater zu ärgern. Das alles also ein Bruchteil deiner hochprofessionellen CLS.EXE. Der MathParser ist noch dazu auf nahezu allen Plattformen ausführbar und grafisch. Cyblord -. schrieb: > Rauschender Abgang des "großen Experten". Du findest immer Wege, GEGEN irgend jemanden zu sein, der euer "Verständnis" von effizienter Programmierung nicht teilt. So wie ich es, jahrzehntelang, immer wieder bei Kollegen erlebt habe, die für M$ gefrickelt äh programmiert haben. Getroffen und versenkt, gell ^^ ;-) Mich würde mal interessieren wo diese CLS.EXE existieren soll, ich kenne nur die built-in Varianten (COMMAND.COM & Co, bei DOS 6 zähle ich rund 53kb für die ganze .COM, das war dann vor ~25 Jahren)... Das früher die Resourcen effektiver genutzt wurden als heute ist sicherlich richtig aber die Art der Kritik ist unsachlich. Dr. Sommer schrieb: > Echt absurd, erst Q-Basic zu nehmen, dann zu lästern dass das große > ausführbare Dateien produziert und das auf dynamische Bibliotheken zu > schieben! Das war kein Q-Basic. Habs gerade probiert und damit gehts nicht. Es war ein Basic, das compilieren und eigenständige EXE-Dateien erzeugen konnte. Vielleicht QuickBasic? Habe ich aber, im Gegensatz zu GW oder Q, nicht mehr zur Hand. Ist ja auch völlig schnuppe. Schnee von gestern. Wer auf megagroße Applikationen steht, die unheimlich wenig können, soll damit glücklich werden. Ich arbeite damit auch -geht ja nicht anders- aber ich über meine Lippen ganz bestimmt kein Wort der Anerkennung . Klaus Manns schrieb: > Mich würde mal interessieren wo diese CLS.EXE existieren soll, ich kenne > nur die built-in Varianten (COMMAND.COM & Co, bei DOS 6 zähle ich rund > 53kb für die ganze .COM, das war dann vor ~25 Jahren)... Wenn jemand QuickBasic hat, ich habe es nicht mehr, kann msn es ja mal testen. Einfach CLS eingeben und EXE-Datei erzeugen. Hat bei mir ein Koloss der o.g. Größe erzeugt. So dass ich mich lange gefragt habe, was M$ da alles rein gepackt hat.... Heute interessiert sowas niemanden mehr. Die Festplatten waren zu der Zeit aber nur knapp 100 MB groß. Da war das schon viel. Roth schrieb: > So dass ich mich lange gefragt habe, was M$ da alles rein gepackt > hat.... Wahrscheinlich einen kompletten Basic Interpreter. Benutz halt vernünftige Tools wie Visual Studio oder Eclipse, da kommen kleinere Programme raus (s.o.)... Roth schrieb: > Kein Unsinn, sondern völlige Ahnungslosigkeit auf deiner Seite. Die > Sourcen wurden vom Compiler in die EXE integriert. Was im übrigen auch > die Größe von 384 KB nachweisbar belegt. Roth schrieb: > Wenn jemand QuickBasic hat, ich habe es nicht mehr, kann msn es ja mal > testen. Einfach CLS eingeben und EXE-Datei erzeugen. Hat bei mir ein > Koloss der o.g. Größe erzeugt. So dass ich mich lange gefragt habe, was > M$ da alles rein gepackt hat.... Wie Dr. Sommer oben schreibt als ein Paket aus Interpreter und Basic-Source - kaum ernsthaft mit einem echten Kompilat vergleichbar! Ich krieg nur ~ die Hälfte als .EXE raus (was es nicht wirklich besser macht). Trotzdem hinkt der Vergleich. Roth schrieb: > Getroffen und versenkt, gell ^^ Äh irgendwie so gar nicht. Nein. Langsam bekomme ich echtes Mitleid mit dir und das ist bei mir selten. :
Bearbeitet durch User
Ich bin erschüttert. Jemand, der es so drauf hat, hat andererseits Probleme mit logischen Ausdrücken und braucht dafür einen "Rechner". Sowas baut man sich doch an einem Nachmittag... Oder? Und wenn man dann der Arduinogemeinde was gutes tun möchte, baut man es als IDE Plugin. Das dauert dann sicherlich etwas länger. Roth schrieb: > Da ich mindestens 25 J. kein C programmiert habe, ist einiges in > Vergessenheit geraten. Dann wirst du aber noch viel lernen müssen, denn Arduino ist eher C++, als dein verblichenes C. Dr. Sommer schrieb:
> Zusammen also ein Formelparser und eine Exe auf 48kB.
Naja, die Java-Runtime nicht mitzuzählen ist aber nicht die Feine
Englische™ ;-)
>Dann wirst du aber noch viel lernen müssen, denn Arduino ist eher C++, >als dein verblichenes C. Stimmt. Der heutige Programmierstil damit ist deutlich einfacher und für Anfänger geeignet. Das war mit dem "verblichenen" C damals anders. Beispiel? : https://opensource.apple.com/source/groff/groff-39/groff/src/libs/libgroff/itoa.c.auto.html foobar schrieb: > Naja, die Java-Runtime nicht mitzuzählen ist aber nicht die Feine > Englische™ ;-) Die hat eh jeder installiert. Die muss ja auch nur 1x installiert sein. Bei einem C Programm zählt man ja auch nicht den Windows Kernel mit. Wenn du jetzt sagst dass es Leute gibt die das nicht haben... dann kann man das Beispiel auch mit C# machen, das ist technisch sehr ähnlich, und .NET ist bei aktuellen Windows vorinstalliert... >> Naja, die Java-Runtime nicht mitzuzählen ist aber nicht die Feine >> Englische™ ;-) > > Die hat eh jeder installiert. Die muss ja auch nur 1x installiert sein. > Bei einem C Programm zählt man ja auch nicht den Windows Kernel mit. Genau das macht er aber mit dem CLS Beispiel. Klaus Manns schrieb: > Genau das macht er aber mit dem CLS Beispiel. Du meinst, weil er den Basic Interpreter mitzählt? Ja, weil er nicht begriffen hat dass er inklusive ist und mit in die .exe gepackt wird... Die JRE ist auf Windows-Rechnern gewiss verbreiteter als Basic-Interpreter. Mike R. schrieb: > Warum braucht ein langweiliger Compiler 25MB, so schwer kann es doch > nicht sein ein wenig Text in Bits und Bytes zu übersetzen? ;-) Die Zeiten, wo ein kompletter Basic-Interpreter in 8kByte ASM-Code abgehakt ist, sind dank moderner Programmentwicklungsmethoden und sonstiger Fortschritte der Rechnertechnik definitiv vorbei. Das ging vielleicht vor 40 Jahren. Bei einem heutiges Programm wirst du selbst mit dem 1024-fachen Speicherplatz nicht weit kommen. Dr. Sommer schrieb: > Die hat eh jeder installiert. Die muss ja auch nur 1x installiert sein. > Bei einem C Programm zählt man ja auch nicht den Windows Kernel mit. > Wenn du jetzt sagst dass es Leute gibt die das nicht haben... dann kann > man das Beispiel auch mit C# machen, das ist technisch sehr ähnlich, und > .NET ist bei aktuellen Windows vorinstalliert... Die Java Runtime (mit ihren 160MB) ist bei jeder Arduino Installation mit im Paket Damit ist irrelevant, ob die JRE schon auf dem Rechner vorhanden war, ist, oder in welcher Version. Marcus schrieb: > Beispiel? : > https://opensource.apple.com/source/groff/groff-39/groff/src/libs/libgroff/itoa.c.auto.html Was möchtest du mir damit sagen? Dass ein großer Teil des Arduino Core in C geschrieben ist? Durchaus wahr! Allerdings sind nahezu alle Libs in C++ geschrieben. Und die *.ino sind sowieso C++. Damit ist das erste, womit es ein Arduino Anfänger es zu tun bekommt, eben C++. Ich denke schon, dass ein altgedienter C Krieger, nach 25 Jahren Pause, einen schwierigen Start mit C++ haben wird. Ins besondere, wenn er mit einer solchen Einstellung da ran geht... Roth schrieb: > .. über meine Lippen ganz bestimmt kein Wort der Anerkennung . Arduino Fanboy D. schrieb: > Die Java Runtime (mit ihren 160MB) ist bei jeder Arduino Installation > mit im Paket Ja, eine etwas fragwürdige Entscheidung. Das ist vermutlich so, um es Java-Verweigerern einfacher zu machen, damit sie gar nicht merken dass da eine JRE auf dem Rechner ist. Und für Leute, die allgemein Schwierigkeiten mit Software Installation haben: Roth schrieb: > MingGW/GCC ließ sich nicht installieren bzw. die Serververbindung brach > beim Download immer wieder ab. Das Doployment auf PCs ist bei Java zugegeben nicht so dolle. Aber davon ist nicht die ganze Technologie schlecht. > Wo man z.B. eingibt: >
> und der Inhalt von a dann angezeigt wird. Es gibt ja auch Taschenrechner wo man solches eingeben kann. Passend zur verflossenen Erfahrung des TO ist definitiv der HP16C um ihn nicht gleich mit einem aus der HP-48 Familie zu überfordern... ;-) https://en.wikipedia.org/wiki/HP-16C Rainer schrieb: >>Wozu die Arduino-DE 400 MB braucht, und doch nix kann, wissen wohl nur >>die "Profis", die es programmiert haben. TC-EXE ist gerade mal 1234 KB >>groß. > > Turbo-C unterstützt auch nur einen Prozessortyp und nicht viele wie die > Arduino IDE. > Das Packet ist so groß, weil die ganzen Toolchains für die verschiedenen > Prozessoren und viele Bibliotheken für verschieden Boards mit geliefert > werden. Das Arduino Paket ist nur für Windows so gross und besteht zu 39xMB nur aus ähnlichen Dreingaben wie das gemästete CLS.EXE/BASIC Beispiel. Dies auch nur um dem "Bedürfnis" von Windows-Hirschen zu entsprechen. Das Bedürfnis hat MS selbst geschaffen, durch deren Wahl des Modularisierungskonzeptes für Windows. Bei Debian u. Derivate ist nämlich das Arduino Paket nur knapp über 1MB gross (Nichtskönnender Editor, "IDE", Terminal - aus den Tastaturen der Arduinoprorammierer) + arduino-core Paket 6MB (Arduino-libraries, Targetboard Definitionen, Buildscripts - aus den Tastaturen der Arduinoprogrammierer) Cross-Compilers, Target-libs, AvrDude, Bossa, JRE, ... (NICHT aus den Tastaturen der Arduinoprogrammierer) kommen dank funktionierendem Paketmanagement aus anderen Paketen. Diese stellen den "Rest des angeprangerten Bloats" von 39xMB. Diese können durchaus schon auf dem Entwicklungsrechner vorhanden sein so sie von anderen Programmen bereits benötigt wurden oder werden eben automatisch nachgeholt. [Die Zahlen sind von den nicht mehr taufrischen 1.0.x und 1.5.x Versionen, genügen aber um Licht in das dreckige Halbwissen zu bringen womit in diesem Thread geschmissen wird und um die Grössenverhältnisse zu illustrieren https://packages.debian.org/search?keywords=arduino Um Funktionsumfang Pro Paket-/Programmgrösse kann man jederzeit streiten, genausogut wie man dies vor 25J konnte.] Dr. Sommer schrieb: > Just for fun: Im Anhang ist eine unter x86-Linux ausführbare Datei (ELF) > welche einfach nur "Hello World" ausgibt. Sie ist 384 Bytes groß. Ich habe hier eine 166 Byte großes Programm für x86-64 Linux, das "Hello World\n" ausgibt. Übersetzen kann man es mit NASM:
Inspiriert wurde ich hier, wobei der Autor aber noch viel mehr optimiert: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html Alexander F. schrieb: > Ich habe hier eine 166 Byte großes Programm für x86-64 Linux, das "Hello > World\n" ausgibt Auch schön :) ich wollte zeigen dass es auch mit den Standard-Tools geht, mit welchen man auch komplexe Anwendungen schreiben kann und über deren "Overhead" so gern gelästert wird. Dass das mit Assembler und/oder Hex-Editor noch etwas besser geht ist klar ;-) Bitte 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten