Gibt es einen Formelparser für C (Arduino)

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:

1

### c() { echo "main(){int a;$1;printf(\"$1  -> a=%d\n\",a);}" | gcc -xc -w - && ./a.out; }

2

### c "a=128; a |= (1<<2)"

3

a=128; a |= (1<<2)   -> a=132

4

### c "a=255; a &= ~(1<<2)"

5

a=255; a &= ~(1<<2)   -> a=251

>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

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?

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.

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!

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:
> 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.

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.

>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.

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:
>

1

a |= (1 << 2)

> 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.]

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 ;-)