atari-home.de - Foren
Software => Coding => Thema gestartet von: mfro am Mi 26.06.2013, 09:14:59
-
Hallo allerseits,
wir hatten die Diskussion hier ja schon mal: die GNU cross compiler und die Programmgröße.
Die mintlib unterstützt (weitgehend) POSIX und andere Standards. Leider führt das dazu, daß Programme, die mit ihr gelinkt werden, riesige Binaries ergeben. Das hat zu dem (falschen) Gerücht geführt, die gcc-Compiler würden unnötig große Programme erzeugen. Der gcc-Compiler kann aber gar nichts dafür (tatsächlich kann er sogar sehr kompakten Code erzeugen), es ist die mintlib, die diese Programmgrößen bedingt. Ich will sie nicht schlecht machen, schließlich erlaubt sie durch ihre Standards-Konformität einfaches Portieren von UNIX/Linux Quellen auf den Atari und hat deshalb sehr wohl in dieser Form eine Berechtigung.
Viele, direkt für den Atari geschriebene Programme brauchen diese Standards-Konformität aber nicht. Solche Programme sollten eher klein und leichtgewichtig sein, damit man sie auch auf den "kleinen" Ataris sinnvoll nutzen kann.
Dafür habe ich dieses Projekt auf AtariForge ins Leben gerufen: libcmini, die kleine und simple C-Library für gcc Compiler für TOS und MiNT (http://www.atariforge.org/gf/project/libcmini)
Das Ding ist bei weitem nicht komplett, viele Sachen sind gar nicht, andere (zu) simpel oder vielleicht sogar falsch implementiert, aber manches kann man schon benutzen und die Ergebnisse zeigen, daß der Ansatz funktioniert:
Ein einfaches "Hello World"-Programm:
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("hello world\n");
}
Compiliert mit -Os, für 68000, gestrippt:
mintlib: 118225 bytes
libcmini: 2281 bytes
Beide Programme tun genau dasselbe. Ziel ist, daß die Library mal ungefähr den Funktionsumfang bekommt, den man von Pure C kennt.
Libcmini kann für alle vom gcc-Compiler unterstützten Targets (m68000, m68020-60, m5475 und die dazugehörigen -mshort-Varianten) compiliert werden und unterstützt das "multilib"-Konzept von gcc (Programme werden abhängig von den Compiler-Optionen "automatisch" zur richtigen Library gelinkt. Die beiliegenden Makefiles zeigen, wie das geht.
Mit dabei ist ein (relativ simples, aber lauffähiges) Beispiel-Programm, das zeigt, daß das Konzept auch für komplexere Programme taugt. Eine GEM-Applikation mit Fenstern und Dialogboxen in weniger als 15k (das mit der mintlib gelinkte Gegenstück hat 180k), per make automatisch in einem Durchgang compiliert für alle Atari-Plattformen (auch m5475 und m5475/mshort - hoffentlich trägt das zur Verfügbarkeit von mehr nativen Firebee-Programmen bei).
Weil die Library noch nicht mal ansatzweise "fertig" und noch viel zu tun ist, werden Mitstreiter gesucht. Bitte meldet Euch auf AtariForge an, falls Ihr helfen wollt.
(Konstruktives) Feedback ist ebenso gern gesehen.
Gruß,
Markus
-
Klasse Idee, das werde ich sicherlich verfolgen und irgendwann mal ausprobieren!
-
Könnte man dann Mint auch mit der kleinen Lib übersetzen so das es auf den STs besser läuft? Eine andere Frage wär noch ob es beim Kompilieren keine Option gibt die verhndert das wegen dem Posixkram die Kompilate so groß werden mit der Mintlib.... Kann nur ein wenig Basic... aber interessieren würds mich schon.
-
Könnte man dann Mint auch mit der kleinen Lib übersetzen so das es auf den STs besser läuft? Eine andere Frage wär noch ob es beim Kompilieren keine Option gibt die verhndert das wegen dem Posixkram die Kompilate so groß werden mit der Mintlib.... Kann nur ein wenig Basic... aber interessieren würds mich schon.
MiNT benutzt die mintlib selbst nicht und ist weitgehend "so klein wie möglich". Es ist eben ein komplettes 32-Bit Multitasking-Betriebssystem mit vielen Features, das ist nicht viel kleiner zu bekommen, ohne Funktionalität wegzulassen ("kein Fett - nur Muskeln" ;) ). Man kann höchstens eine der frühen Versionen (MultiTOS, so wie es mit dem Falcon ausgeliefert wurde, z.B.) einsetzen - die waren deutlich kleiner, konnten aber auch deutlich weniger.
Die mintlib ist natürlich nicht nur wegen des "Posix-Krams" so groß. Sie implementiert (fast) alles, was zu einer modernen, standard-konformen C-Library gehört. Das wird die libcmini nie können.
Braucht sie aber auch nicht. Die meisten einfacheren GEM-Programme kommen mit weniger als zwanzig Standard-Library-Funktionen aus, viele brauchen noch nicht mal eine Hand voll.
-
Könnte man dann Mint auch mit der kleinen Lib übersetzen so das es auf den STs besser läuft?
Der MiNT Kernel ist ja nur etwas über 300kB groß ...
Die Funktionalität macht es halt Speicherhungrig ...
Ich hatte früher oft Knarfmint auf einem Atari Mega ST mit Riebl Netzwerkkarte laufen und ich kann sagen das man damit
kaum arbeiten kann weil viel, viel zu langsam ...
https://www.knarf.de/MiNT.html
Außerdem sind viele Programme und auch Teile vom MiNT nur als 020er Binaries vorhanden ...
-
Gibt es denn da kein Compiler Steuerwort wie das CUTLIB in Omikron.Basic, damit nicht alle nichtverwendeten Kommandos mit im Programmcode landen? Daß Sparsamkeit heute kein Thema mehr ist, kann ich mir denken. Zu Atari Zeiten war das noch eins. o.O
-
Gibt es denn da kein Compiler Steuerwort wie das CUTLIB in Omikron.Basic, damit nicht alle nichtverwendeten Kommandos mit im Programmcode landen? Daß Sparsamkeit heute kein Thema mehr ist, kann ich mir denken. Zu Atari Zeiten war das noch eins. o.O
Das braucht's hier nicht. Ein anständiger Linker linkt nur das ins Programm, was auch tatsächlich benutzt wird bzw. benutzt werden könnte. Der Linker kann nicht erkennen, ob Code abhängig von einem Variablenwert im fertigen Programm durchlaufen wird oder nicht - wenn ein "if" vor einem Codeteil steht, das im Programm nie wahr wird, wird der Inhalt trotzdem eingebunden.
Die mintlib initialisiert für das laufende Programm eine fast vollständige Unix-Umgebung. Nur ein paar wenige Beispiele (die Liste ist tatsächlich viel länger): sie holt sich beim Start eine Liste aller Unix-User und -Gruppen (die auf einem "normalen" ST ziemlich kurz ist), holt sich die Uhrzeit und die Zeitzone und wandelt sie ins Unix-Format, holt sich das komplette Environment (bei einem "normalen" ST auch ziemlich wenig) und bereitet es Unix-konform auf, ... .
Ein Posix-konformes printf() beispielsweise muß die Environment-Variable LC_NUMERIC auswerten, um entsprechend der Ländereinstellung einen Dezimalpunkt oder ein Dezimal-Komma auszugeben. Wenn die nicht gesetzt ist (beim ST der Normalfall), muß das Environment Posix-konform nach anderen Indikatoren für die Ländereinstellung durchsucht werden ($LANG, ...). Auch da wird die mintlib (auf einem "normalen ST" nicht fündig werden), machen muß sie es trotzdem - sonst ist sie nicht standardkonform.
Kleinere Programme erreicht man hier nur durch Weglassen und Aufgeben des Standards.
-
Für ST und nichtbeschleunigten Falcon braucht es IMHO auf 100% POSIX kompatibele Implementierung nicht anzukommen. Die Plattform ist so speziell, da kann man sich auch an andere Standards halten, die viel wichtiger sind.
Man kann dann halt nicht blind irgendwas aus der GNU Welt durchwursten, aber das braucht man am Atari nicht immer. Ich bevorzuge eine dem Atari gemäße angepasste Implementierung einer Funktionalität gegenüber einem blinden Port.
-
Hi Markus,
ich hab da noch einen Bug gefunden. Ein malloc(8165) bis malloc(8180) bzw. alle malloc's zwischen (x*8192-27) bis (x*8192-12) führen, wenn dabei ein neuer Chunk vom System geholt werden muss zu einem zu kleinen Chunk.
Der folgende kleine Patch behebt den Fehler:
Index: libcmini/sources/malloc.c
===================================================================
--- libcmini/sources/malloc.c (Revision 41)
+++ libcmini/sources/malloc.c (Arbeitskopie)
@@ -39,7 +39,7 @@
/* if not enough memory, get more from the system */
if (q == NULL)
{
- sz = n;
+ sz = n + BORDER_EXTRA;
static int page_size = 0;
PS: hat das einen Grund warum nicht bcopy.S und bzero.S sondern bcopy.c und bzero.c verwendet werden?
Gruß
Armin
-
Der folgende kleine Patch behebt den Fehler:..
Angeschaut, für gut befunden, eingebaut, getestet, eingecheckt ;).
Herzlichen Dank!
Falls Du Lust hast, selbst ein bißchen dran mitzuhelfen (ich komm' grad viel zu wenig dazu): ich würde dir gerne Schreibrechte einrichten, wenn Du willst.
PS: hat das einen Grund warum nicht bcopy.S und bzero.S sondern bcopy.c und bzero.c verwendet werden?
Die Geschwindigkeit war (für mich) völlig ausreichend und der Code ist kleiner als die optimierten Assemblerroutinen (glaub' ich wenigstens).
-
Falls Du Lust hast, selbst ein bißchen dran mitzuhelfen (ich komm' grad viel zu wenig dazu): ich würde dir gerne Schreibrechte einrichten, wenn Du willst.
Gerne. Ich würde auch erst einmal nur einen branch machen.
Ich möchte gern den extra include-Ordner weg haben. Denn Ich möchte die mintlib-includes mit benutzen dann kann ich alle sourcen so belassen und muß nicht alles nach #include <libcmini/...> umschreiben oder mit -nostdinclude und -I's arbeiten. Dann braucht man nur an statt -lc nur -cmini zu linken und fertig. Für mein gcc kann ich mir einen commandline switch -stdlibcmini vorstellen.
Wenn du damit einverstanden bist.
ardi
-
Falls Du Lust hast, selbst ein bißchen dran mitzuhelfen (ich komm' grad viel zu wenig dazu): ich würde dir gerne Schreibrechte einrichten, wenn Du willst.
Gerne. Ich würde auch erst einmal nur einen branch machen.
Kannst Du mal auf "Project join request" drücken? Anscheinend hast Du ja schon einen Account auf Atariforge.
Ich möchte gern den extra include-Ordner weg haben. Denn Ich möchte die mintlib-includes mit benutzen dann kann ich alle sourcen so belassen und muß nicht alles nach #include <libcmini/...> umschreiben oder mit -nostdinclude und -I's arbeiten. Dann braucht man nur an statt -lc nur -cmini zu linken und fertig.
Wenn man den Luxus eines eigenen Compilers hat, geht das natürlich. Hast Du dir mal das Beispielprogramm "bench" angeschaut? Auf das Makefile bin ich einigermaßen stolz ;).
Wenn du damit einverstanden bist.
Klar, bin ich. Ich bin ganz froh, wenn's ein wenig vorwärts geht, solange ich selbst nicht dazu komme. Ich hätte nur eine Bitte: wenn Du allgemeingültige Library-Erweiterungen gleich im main-branch anlegen würdest (oder entsprechend "selektiv mergen"). Dann kommt die Erweiterung auch denjenigen zugute, die nicht deinen Compiler benutzen.
Gruß,
Markus
-
Probier' mal - SVN müsste jetzt gehen.
-
Falls Du Lust hast, selbst ein bißchen dran mitzuhelfen (ich komm' grad viel zu wenig dazu): ich würde dir gerne Schreibrechte einrichten, wenn Du willst.
Gerne. Ich würde auch erst einmal nur einen branch machen.
Kannst Du mal auf "Project join request" drücken? Anscheinend hast Du ja schon einen Account auf Atariforge.
gerade geschehen
Ich möchte gern den extra include-Ordner weg haben. Denn Ich möchte die mintlib-includes mit benutzen dann kann ich alle sourcen so belassen und muß nicht alles nach #include <libcmini/...> umschreiben oder mit -nostdinclude und -I's arbeiten. Dann braucht man nur an statt -lc nur -cmini zu linken und fertig.
Wenn man den Luxus eines eigenen Compilers hat, geht das natürlich.
Dazu braucht es keinen "eigenen" Compiler einfach mit -nodefaultlibs -lgcc -lcmini -lgcc linken fertig.
Dazu muß nur noch die libcmini so angepasst werden, daß sie mit der crt0 der mintlib arbeitet (sonst braucht es -nostdlib startupmini.o -lgcc -lcmini -lgcc).
Hast Du dir mal das Beispielprogramm "bench" angeschaut? Auf das Makefile bin ich einigermaßen stolz ;).
Noch nicht
Probier' mal - SVN müsste jetzt gehen.
also ich kann angemeldet (nicht anonymous) auschecken. Ich denke es funzt. Danke
ardi
-
Moderatorhinweis:
Auf Wunsch von mfro habe ich die neue Diskussion vom Sticky abgetrennt und hier angefügt.
Der Sticky soll als kompakte Kurzanleitung bestehen bleiben
-
Wie geht die libcmini denn mit dem ___main() Symbol um? Wird das mitangeboten?
-
Wie geht die libcmini denn mit dem ___main() Symbol um? Wird das mitangeboten?
Das existiert, tut aber (momentan) nichts. Wozu brauchst Du das?
-
Ich brauche es eben nicht, aber alles was fertig zum linken leer angeboten wird, muss nicht weiter bedacht werden. Scheinbar brauchst es ja der gcc ;)
-
Ich brauche es eben nicht, aber alles was fertig zum linken leer angeboten wird, muss nicht weiter bedacht werden. Scheinbar brauchst es ja der gcc ;)
Gcc realisiert darüber die Funktionsattribute constructor und destructor
void hallo(void) __attribute__((constructor));
void goodbye(void) __attribute__((destructor));
Wenn man die nicht nutzt, braucht man auch nicht mehr als einen leeren Funktionsrumpf.
-
Eben, und den kann die lib mitbringen. Dann braucht sich der Benutzer nicht mehr darum kümmern.
Wer C++ verwenden will, dem unterstelle ich, daß die libcmini eher sowieso nicht verwendet wird (optimiert für C).
-
Eben, und den kann die lib mitbringen. Dann braucht sich der Benutzer nicht mehr darum kümmern.
Wer C++ verwenden will, dem unterstelle ich, daß die libcmini eher sowieso nicht verwendet wird (optimiert für C).
__attribute__((constructor)) und __attribute__(destructor) hat nichts (zumindest nicht unmittelbar) mit C++ zu tun. Das kann man durchaus auch prima in C verwenden.
-
Das entfernt sich dann aber von jeglichem ISO Standard....
-
Das entfernt sich dann aber von jeglichem ISO Standard....
Nö, nicht unbedingt. Die Implementierung von irgendwelchen Initialisierungsroutinen oder das Aufrufen von mit atexit() angemeldeten Funktionen läßt sich darüber lösen, ohne daß man den Startup-Code als Quelle ausliefern müsste (was trotzdem meist passiert). Der ISO-Standard sagt nicht, wie das passieren, nur daß es möglich sein muß.
-
Wo ich schon mal dran bin:
libcmini gibt es jetzt in einer releasten, vorcompilierten Form hier (http://www.atariforge.org/gf/project/libcmini/frs/?action=FrsReleaseBrowse&frs_package_id=24) zum Runterladen. Die Beispielprogramme (bench, insbesondere) wurden ein wenig erweitert und stehen als Quellen zur Verfügung. M.E. gut als "Skellett" geeignet für Leute, die in die GEM-Programmierung einsteigen möchten. Die Makefiles erzeugen Code für m68000, m68020-60 und Coldfire (jeweils in der "mshort" und "normalen" Version.
-
Ich setze hier mal auf. :D
Lebt das Projekt noch? Die letzten Sourcen, die ich heruntergeladen habe, sind mehr als ein Jahr alt. Ich habe eine Reihe Bugs behoben und neue Funktionen hinzugefügt. Ich habe zwar auf der Version 0.5 aufgesetzt, das ganze aber heute mit der 0.6 abgeglichen. So viel hat sich da ja nicht getan.
Bugs habe ich zum Beispiel bei ...printf gefunden (Nachkommastellen bei %f funktionierten u.a. nicht), aber auch woanders. vsnprintf() kann jetzt auch mit NULL-Pointer umgehen. Das ist wichtig, weil man so den benötigten Speicherplatz für eine Formatierung ermitteln kann. Dadurch konnte ich asprintf() und vasprintf() implementieren (s.u.).
Ich habe ein paar Funktionen hinzugefügt. Zum Beispiel qsort(), asprintf(), vasprintf(), ...scanf(), strtod(), strtof(), feof(), ferror(), ungetc(), getchar(), fgets(), getc(), fflush(), remove(), rename(), bsearch(), strnlen(), strtok(), localtime(), strftime().
Die FILE-Struktur habe ich erweitert, um feof(), ferror() und ungetc() implementieren zu können, und die Feldnamen denen der MINT-Library angepasst.
mktime() habe ich korrigiert, hier wurden Schaltjahre nicht richtig berücksichtigt (einfaches Teilen durch 4 reicht nicht).
ctype.h hat ein paar neue Makros bekommen (isalnum, iscntrl, isgraph, isprint, ispunct, isxdigit) und isspace berücksichtigt jetzt auch "\f").
Die ...scanf()-Funktionen müssen noch ordentlich getestet werden, das habe ich nur rudimentär gemacht. Aber ich fände es gut, wenn das Projekt nicht einschläft, denn die Speicherersparnis ist schon enorm. Allein mein kleines Testprogramm für sscanf() ist nur 16,5 KB groß, mit der MINT-Library sage und schreibe das Zehnfache!
Meine aktuellen Sourcen von heute könnt ihr gerne herunterladen:
http://www.graf-bussmeier.de/download/libcmini_20170729.rar
Änderungen werden ja mit diff sichtbar. ;)
Oliver
-
Lebt das Projekt noch?
Hallo Oliver,
klar doch, lebt noch.
Auch wenn ich nicht gar so viel dran mache, für mich reicht der bislang implementierte Umfang für die meisten Sachen aus.
Wenn Du magst, melde dich als User bei AtariForge an. Ich kann dich dann freischalten und wenn Du Lust und Zeit hast, kannst Du deine Änderungen und Erweiterungen selbst einarbeiten.
Gruß,
Markus
-
Nachdem AtariForge schon seit Längerem nicht verfügbar ist (und es auch keine Anzeichen gibt, dass sich daran noch mal etwas ändert), habe ich libcmini umgezogen.
Es ist jetzt hier zu finden: https://github.com/mfro0/libcmini
-
Nachdem AtariForge schon seit Längerem nicht verfügbar ist (und es auch keine Anzeichen gibt, dass sich daran noch mal etwas ändert), habe ich libcmini umgezogen.
Es ist jetzt hier zu finden: https://github.com/mfro0/libcmini
Bestens, danke. Mit git ist’s gleich bequemer einen Klon zu ziehen, und mit den Sternchen spannende Projekte im Blick zu halten.
-
Nachdem AtariForge schon seit Längerem nicht verfügbar ist (und es auch keine Anzeichen gibt, dass sich daran noch mal etwas ändert), habe ich libcmini umgezogen.
Es ist jetzt hier zu finden: https://github.com/mfro0/libcmini
Bestens, danke. Mit git ist’s gleich bequemer einen Klon zu ziehen, und mit den Sternchen spannende Projekte im Blick zu halten.
Schade nur, dass ich anscheinend *zu* lange damit gewartet habe. Ohne das Orginal-Repository ist leider die Historie weg. Damit ist jetzt halt wieder "Stunde null".
-
Nachdem libcmini in den letzten Monaten einiges dazuge- (und viel Falsches ver-) lernt hat (unter tätiger Mithilfe von @Count, vielen Dank dafür!), wurde es Zeit für ein neues Release:
hier:
https://github.com/mfro0/libcmini/releases
gibt's die Quellen und Binaries als .tar-Dateien und hier:
https://github.com/mfro0/libcmini
ist das github-Repository
-
Ich versuche gerade, ein Programm, an dem ich z.Zt. entwickle mit libcmini (und gcc 4.6.4) zu compilieren und erhalte...
$ m68k-atari-mint-gcc -omyprog.tos -s -mshort -fomit-frame-pointer -O1 -nostdlib ../libcmini/build/mshort/startup.o myprog.c -L../libcmini/build/mshort -lcmini -lgcc
/tmp/ccIEniML.o:/tmp/ccIEniML.o:(.text+0x768): undefined reference to `___flshfp'
collect2: ld returned 1 exit status
Hast Du eine Idee, woran das liegen könnte? Welche Funktion ruft ___flshfp auf?
-
Aargh, kaum hat man die Frage gestellt, findet man plötzlich die Lösung. Ich sollte offensichtlich die libcmini-Includes verwenden. (Der Auslöser war übrigens putchar().) So funkioniert's:
$ m68k-atari-mint-gcc -omyprog.tos -s -mshort -fomit-frame-pointer -O1 -nostdlib ../libcmini/build/mshort/startup.o myprog.c -I../libcmini/include -L../libcmini/build/mshort -lcmini -lgcc
-
Aargh, kaum hat man die Frage gestellt, findet man plötzlich die Lösung. Ich sollte offensichtlich die libcmini-Includes verwenden. (Der Auslöser war übrigens putchar().)
Ja, das ist generell eine gute Idee. ;)
putchar() kann ja (wie putc(), getc() und getchar()) als Makro definiert sein. Scheinbar ist das bei deiner Mintlib-Version (oder welche Header-Dateien da auch immer gezogen wurden) der Fall.
-
Falls Ihr libcmini vermisst - das ist jetzt hier zu finden:
https://github.com/freemint/libcmini
und damit Teil der freemint-Organisation.
-
Es ist schön, dass hier nach den Diskussionen eine Lösung gefunden wurde. Just saying...
-
Es ist schön, dass hier nach den Diskussionen eine Lösung gefunden wurde. Just saying...
Ja, finde ich auch erfreulich.