tinypy - Was kann es?
Höher im Sinne von "man kann damit halbwegs anständig prozedural und / oder (wenn möglich) objektorientiert / funktional / xyz programmieren". Momentan nutze ich auf diesem Gerät, das 188kb freien Ram bei Betrieb besitzt, C. Funktioniert auch relativ gut, wenngleich meine C Kenntnisse nicht die besten sind [1]. Aber das hört sich schonmal ganz nett an. Nur wäre die Frage, inwiefern grade Sprachen wie Python oder Ruby oder auch Scheme und Io speicherhungriger sind, zb auch in Kombination mit einer StdLib.Was sind für Dich "höhere" Sprachen? Es gibt zum Beispiel BASIC, Comal, Pascal und auch Forth für den C64, also für maximal 64 KiB RAM. Smile
[1] Ich habe leider immernoch keine gute Ressource für das Programmieren mit C gefunden, die mehr als nur die Syntax und ein paar Basisfunktionen erklärt gefunden. Grade bei C hat es ja oft Umwälzungen gegeben (gets?), kennt da jemand was?
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
``python setup.py linux`` und das Binary findet man dann in Build. Geht übrigens sehr schnell, der Buoldvorgang dauert bei mir 4 Sekunden. Das ist etwa so lange wie sich Javac (OpenJDK Java Compiler) für eine recht kleine Java-Datei rausnimmt.burli hat geschrieben:Weiß jemand wie man das compilieren kann?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@str1442: C von A bis Z soll sehr gut sein. <anspielung>Achte bei der Qualität nicht auf den Verlag, sondern auf den Autor. 
</anspielung>
</anspielung>-
lunar
Der ist ja nun auch nicht der schnellste ^^Leonidas hat geschrieben:``python setup.py linux`` und das Binary findet man dann in Build. Geht übrigens sehr schnell, der Buoldvorgang dauert bei mir 4 Sekunden. Das ist etwa so lange wie sich Javac (OpenJDK Java Compiler) für eine recht kleine Java-Datei rausnimmt.burli hat geschrieben:Weiß jemand wie man das compilieren kann?
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Tatsache. Ich habe mich immer gewundert warum der Scala-Compiler so lange braucht, nachdem ich javac etwas eingesetzt habe liegt die Antwort auf der Handlunar hat geschrieben:Der ist ja nun auch nicht der schnellste ^^
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
BlackJack
@str1442: Ich finde die "man pages" vom GCC zu den C-Standardfunktionen ganz nützlich, wo zum Beispiel vor `gets()` eindringlich gewarnt wird.
-
lunar
Ich nutze ecj. Und der ist – abgesehen davon, dass er besser mit emacs-jde zusammenarbeitet – selbst bei kleinen Dateien spürbar schneller.Leonidas hat geschrieben:Tatsache. Ich habe mich immer gewundert warum der Scala-Compiler so lange braucht, nachdem ich javac etwas eingesetzt habe liegt die Antwort auf der Handlunar hat geschrieben:Der ist ja nun auch nicht der schnellste ^^
Zur Ehrenrettung von Java sei gesagt, dass bei mir Clojure mit 107 Dateien und 40722 Zeilen Java-Code in 2.5 Sekunden mit javac kompiliert. Clojure selbst braucht dann länger (etwa 3.5 Sekunden), seine eigenen 6333 Zeilen Code zu übersetzen. Insgesamt entstehen ~1100 class files die in einer Sekunde zu einem jar gemacht werden.
Der Scala-Compiler ist in Scala geschrieben, welches sehr viele class-Dateien erzeugt, die die JVM alle jedes Mal mühsam laden muss. Das verlängert leider die Startzeit. Für mehrere Dateien sollte man daher unbedingt ant oder eine IDE einsetzen, weil dort der Compiler jeweils nur 1x geladen werden muss. Scalas Compiler ist zudem wahrscheinlich nicht auf Geschwindigkeit optimiert und er führt IIRC mehrere Läufe über den AST des eingelesenen Programms aus, in dem jeweils verschiedene Programmtransformationen durchgeführt werden, bis dann das ganze endlich so primitiv ist, dass Bytecode und damit class files erzeugt werden können.
Ein Forth-System, das in 4 KB passte, brauchte vielleicht nochmal 2 KB RAM - je nachdem natürlich, wie groß man seine eigenen Programme machen wollte. In 2 KB passen etwa 1000 Befehle. Das mag für die Steuerung eines Radioteleskops ausgereicht haben. Man bedenke, dass man ja auch jederzeit von Diskette weitere Befehle nachladen und auf diese Weise "pagen" konnte. Forth hat die Diskette in Sektoren a 1024 Bytes eingeteilt, die dann jeweils als Seiten von 64x16 Zeichen gelesen wurden und in die man den Quelltext eintragen konnte. Natürlich müssen diese 1024 Bytes ins System passen, aber das wäre dann ja der Bildschirmspeicher, der nochmals extra zählen könnte.
Ich würde tippen, dass tinypy mit relativ wenig Hauptspeicher auskommt, da es im wesentlichen ja nur eine VM ist der Python-Code für Parser und Compiler in relativ kompaktem Bytecode hinzugefügt wird.
Aber was ist heutzutage schon wenig? Mein Rechner hat 4 GB Hauptspeicher, die ich bei Apple recht teuer bezahlen durfte, die aber auf dem freien Markt für PCs inzwischen unter 50€ kosten. Ist also 1 GB relativ wenig? Oder 1 MB?
Und was erwartet man? Reicht eine Kommandozeile und ein dünner Wrapper um Funktionen, die das Betriebssystem zur Verfügung stellt oder soll es eine grafisch opulente farbige Fensteroberfläche sein und Bibliotheken für jedes denkbare Problem verfügbar sein?
Das C64-Basic würde ich aus heutiger Sicht nicht als höhere Sprache bezeichnen :) goto, gosub und ausschließlich globale Variablen sind nicht gerade etwas, mit dem man Programmabstraktionen bauen kann. Und bei UCSD-Pascal für den C64 musste man laufend Disketten wechseln, weil es nicht komplett in den Hauptspeicher passte.
Stefan
Der Scala-Compiler ist in Scala geschrieben, welches sehr viele class-Dateien erzeugt, die die JVM alle jedes Mal mühsam laden muss. Das verlängert leider die Startzeit. Für mehrere Dateien sollte man daher unbedingt ant oder eine IDE einsetzen, weil dort der Compiler jeweils nur 1x geladen werden muss. Scalas Compiler ist zudem wahrscheinlich nicht auf Geschwindigkeit optimiert und er führt IIRC mehrere Läufe über den AST des eingelesenen Programms aus, in dem jeweils verschiedene Programmtransformationen durchgeführt werden, bis dann das ganze endlich so primitiv ist, dass Bytecode und damit class files erzeugt werden können.
Ein Forth-System, das in 4 KB passte, brauchte vielleicht nochmal 2 KB RAM - je nachdem natürlich, wie groß man seine eigenen Programme machen wollte. In 2 KB passen etwa 1000 Befehle. Das mag für die Steuerung eines Radioteleskops ausgereicht haben. Man bedenke, dass man ja auch jederzeit von Diskette weitere Befehle nachladen und auf diese Weise "pagen" konnte. Forth hat die Diskette in Sektoren a 1024 Bytes eingeteilt, die dann jeweils als Seiten von 64x16 Zeichen gelesen wurden und in die man den Quelltext eintragen konnte. Natürlich müssen diese 1024 Bytes ins System passen, aber das wäre dann ja der Bildschirmspeicher, der nochmals extra zählen könnte.
Ich würde tippen, dass tinypy mit relativ wenig Hauptspeicher auskommt, da es im wesentlichen ja nur eine VM ist der Python-Code für Parser und Compiler in relativ kompaktem Bytecode hinzugefügt wird.
Aber was ist heutzutage schon wenig? Mein Rechner hat 4 GB Hauptspeicher, die ich bei Apple recht teuer bezahlen durfte, die aber auf dem freien Markt für PCs inzwischen unter 50€ kosten. Ist also 1 GB relativ wenig? Oder 1 MB?
Und was erwartet man? Reicht eine Kommandozeile und ein dünner Wrapper um Funktionen, die das Betriebssystem zur Verfügung stellt oder soll es eine grafisch opulente farbige Fensteroberfläche sein und Bibliotheken für jedes denkbare Problem verfügbar sein?
Das C64-Basic würde ich aus heutiger Sicht nicht als höhere Sprache bezeichnen :) goto, gosub und ausschließlich globale Variablen sind nicht gerade etwas, mit dem man Programmabstraktionen bauen kann. Und bei UCSD-Pascal für den C64 musste man laufend Disketten wechseln, weil es nicht komplett in den Hauptspeicher passte.
Stefan
-
BlackJack
@sma: CBM BASIC V2 ist tatsächlich reichlich eingeschränkt, aber Comal ist als Mischung zwischen BASIC und Pascal ganz nett. Ausserdem gibt's für den C64 einen ganzen Haufen "aufgebohrte" BASIC-Varianten, teilweise auch mit Prozeduren mit Namen und lokalen Variablen.
Hm, schau ich mir mal an. Ich hatte von dem Buch schon gehört, und hatte dann auf ProLinux einen Artikel dazu gefunden, und da wurde auf das hier verwiesen:@str1442: C von A bis Z soll sehr gut sein. <anspielung>Achte bei der Qualität nicht auf den Verlag, sondern auf den Autor. Wink </anspielung>
http://groups.google.com/group/de.comp. ... ode=source
http://groups.google.com/group/de.comp. ... ode=source
Was auch immer man sich unter Vorwärtsdeklaration von Funktionen vorstellen soll, es hört sich unschön an. Aber ich schau es mir mal an, Danke!
Welche? Also für gcc selbst finde ich nur doc Pakete die manpages zu GCC selbst enthalten und einem Tool namens gcov, und bei ersterem wird nur in aller Länge der Compiler erklärt. Meinst du dieses Manual hier: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/ ? Das sieht ganz interessant aus.@str1442: Ich finde die "man pages" vom GCC zu den C-Standardfunktionen ganz nützlich, wo zum Beispiel vor `gets()` eindringlich gewarnt wird.
-
BlackJack
Ups, sorry, ich meinte die zur `libc`. Bei Ubuntu AFAIK das `manpages-dev`-Paket.
-
abgdf
Hi,Also für gcc selbst finde ich nur doc Pakete die manpages zu GCC selbst enthalten und einem Tool namens gcov, und bei ersterem wird nur in aller Länge der Compiler erklärt.
hatte mal angefangen, selbst was über gcc zu schreiben:
http://www.angelfire.com/linux/tux25/c/gcc.html
Die Profis nörgeln mich aber immer zu ...
Schau Dir auch unbedingt mal diesen Geheimtip zu C-Strings an:
http://www.howstuffworks.com/c36.htm
Könnte noch mehr von solchen Tips vertragen. Sollte man vielleicht im Offtopic-Forum diskutieren ...
HTH
Gruß
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Du könntest erwähnen dass GCC normalerweise gnu89 als C-Dialekt verwendet und gnu99 zusätzlich dazu verfügbar hat. Die GNU-Dialekte haben nette bis freakige Erweiterungenabgdf hat geschrieben:hatte mal angefangen, selbst was über gcc zu schreiben:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
