Neues Projekt auf AtariForge: libcmini

[mfro]

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

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:

Code: [Auswählen]

#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

[simonsunnyboy]

Klasse Idee, das werde ich sicherlich verfolgen und irgendwann mal ausprobieren!

[Arthur]

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.

[mfro]

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.

[Lukas Frank]

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

[Omikronman]

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

[mfro]

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.

[simonsunnyboy]

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.

[ardi]

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:

Code: [Auswählen]

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

[mfro]

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

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

[mfro]

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

[mfro]

Probier' mal - SVN müsste jetzt gehen.

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

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

[simonsunnyboy]

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

[simonsunnyboy]

Wie geht die libcmini denn mit dem ___main() Symbol um? Wird das mitangeboten?

[mfro]

Wie geht die libcmini denn mit dem ___main() Symbol um? Wird das mitangeboten?

Das existiert, tut aber (momentan) nichts. Wozu brauchst Du das?

[simonsunnyboy]

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

[mfro]

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

Code: [Auswählen]

void hallo(void) __attribute__((constructor));
void goodbye(void) __attribute__((destructor));
Wenn man die nicht nutzt, braucht man auch nicht mehr als einen leeren Funktionsrumpf.

[simonsunnyboy]

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