From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re:    gcc 2.2.2 == toll
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sat, 12 Sep 1992 00:07:01 GMT

In article <1685F145F8.IWS89013@ibm.rz.uni-passau.de> IWS89013@ibm.rz.uni-passau.de writes:
>Ein weiterer Grund mit einem Standard Stack von 4K auszukommen ist aber auch
>die Speicherplatzverschwendung (ich habe zwar 9Megs aber trotzdem soll es

Kleine Information am Rande. Ich hab mal cc1 (das 800k Ding;-)) versuchsweise
mit dem C-Emulator fuer alloca kompiliert. Kurz zur Information: alloca() 
legt Variablen auf dem Stack an, entspricht sonst aber malloc(). Der Vorteil
davon ist, dass man raus kann aus der Funktion und -plopp- sind alle
ge'alloca'ten Variablen freigegeben. Der alloca C-Emulator verwendet malloc,
und gibt bei jedem Aufruf die nicht mehr benoetigten (vom aktuellen
Stack-Wert her berechnet) Bereiche wieder frei. Das Resultat war ziemlich
ernuechternd... erstens war der Compiler traege wie ein Schw@#$, und zweitens
war der Speicherverbrauch ziemlich genau das doppelte von der stack-alloca
Loesung. Dh. im konkreten Fall cc1 koennte man mit C-alloca zwar Stack
sparen, nur wuerde unverhaeltnismaessig mehr sonstiger Speicher dranglauben,
dass man mit Stack-alloca wesentlich besser bedient ist. Kommt noch der
Geschwindigkeitsnachteil des Emulators hinzu.

>ja auch noch Amiga User mit weniger Speicher geben).

Klar.

>Typische Antworten: Wenn ich Compiliere hab' ich sowieso nur unwichtige
>                    Tasks laufen.

Nu mal was klarzustellen: niemand zwingt einen A500 Benutzer mit 1M
RAM, gcc zu laden. Niemand zwingt Dich, neben fbm zu kompilieren noch 
Art Department laufen lassen zu wollen.

>                    Professionelle Software faengt eben erst bei 4Mega
>                    Speicherverbrauch an richtig "professionell" zu werden.
> 
>                    (Antwort: Schon mal was von knappen Ressourcen
>                              (sprich Geld) gehoert? Nicht alle Leute
>                              koennen sich pro Jahr die durch das Update
>                              auf eine neuere Version entstandenen
>Speicherhunger notwendigen RAMS leisten)

Je mehr Speicher (Harddiskplatz, sonstwas) man hat, desto mehr Speicher
(Harddiskplatz, sonstwas) braucht man. Bei gcc sind schonmal die Grund-
voraussetzungen fuer Systeme mit wenig Speicher schlecht. Gcc wurde von
Beginn weg fuer VMem-Systeme konzipiert. In so einem Design geht man davon
aus, dass Speicher da ist! Diese Ueberlegung kann dann zu ganz andern
Implementationen fuehren als wenn man grundsaetzlich konservativ ist mit
Speicher. Zum Beispiel saugt sich der cpp grundsaetzlich alles was er
behandeln muss (source plus alle #include Headers) in den Speicher, und
macht die Behandlung im Speicher. Das ist schlicht die schnellste Art das
zu erledigen, trotzdem wuerde's auf dem Amiga wohl niemand so loesen.

Nun... Mein Ziel war es, mit moeglichst wenig Aenderungen in den Unix
Programmen selbst, diese unter AmigaDOS zum laufen zu kriegen. Wenn Du einen
speziell auf den Amiga angepassten gcc willst, hol Dir die Sourcen, und
knie Dich rein. Wenn Du die Arbeit scheust, akzeptiere bitte dass Unix
Software Stack-intensiv sein kann, ja?

-Markus

PS: die naechste Version der ixemul.library wird mit GigaMem laufen, also
Entwarnung fuer all die Speicher-geplagten Leute mit MMU ;-)
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Newsgroups: de.comp.sys.amiga.misc