
			C - PROGRAM P AMIGA


Som vi tidigare konstaterade r C ett mycket flyttbart sprk. Det gller 
ocks Amiga. S lnge man hller sig till standardfunktionerna i sprket och 
inte ger sig in p Intuition eller execniv, utan njer sig med program som
kr under AmigaDOS frn CLI, s kan man flytta program till och frn UNIX och
MS-DOS och annat med sm eller inga ndringar. Mnga av de PD-program som 
finns till Amiga r tagna direkt frn PD-biblioteken i andra system och bara
kompilerade med en Amigakompilator. 

Det gr frsts aldrig att ta kompilerad kod frn andra system och tro att 
det ska g att kra p Amiga. P den nivn r ju skillnaderna stora. 

Kompilatorn skrmar av dig frn 68000-processorns instruktioner, och du be-
hver inte heller veta s mycket om hur Amigasystemet hanterar din kod. Men
det kan i alla fall vara intressant att se p en del grundlggande begrepp.

Latticekompilatorn gr sitt jobb i tv steg, lc1 och lc2. Det frsta steget,
lc1, skapar en filtyp som kallas quadfil, med tillnamnet .q. Sedan matas lc2
med quadfilen och producerar en objektfil, med tillnamnet .o. Dessutom finns
det frsts en hel massa options till bda kompilatorstegen. Det normala st-
tet att kra kompilatorn r genom kommandot lc, som skter hela kompilerin-
gen och hller reda p i vilket steg den ska anvnda de options som du anger.

Nr du har ftt din objektfil, eller flera, s r det dags att lta lnkaren
gra sitt, och stta ihop dem med en startkod och de olika biblioteken till
ett krbart program. Till skillnad frn enklare system, s bestr ett lnkat
Amigaprogram av tskilliga delar, som kallas fr hunks. Amiga hanterar ju 
minnet s att det ska kunna utnyttjas s fullstndigt som mjligt, och efter
en stunds krning av ngra program har olika programdelar spritt sig s att
det kvarvarande minnesutrymmet bestr av mnga sm stycken hr och var. Om d
ett nytt program ska kunna laddas, s fr det inte best av kod som mste 
ligga i ett kontinuerligt utrymme. 

Det finns tre typer av hunks med olika uppgifter:

CODE	Dessa innehller de maskininstruktioner som r sjlva programmet. All
 	kod som genereras av Lattice C kan placeras i ROM, eftersom den inte
 	innehller ngot som ska frndras under progrankrningen.

DATA	Dessa innehller alla data som har initialvrden, som initierade 
 	variabler och konstanter. En sn hunk kan inte placeras i ROM efter-
 	som den innehller variabler som kommer att frndras under krning.

BSS	Dessa innehller allt datautrymme som inte har ngot initialvrde. De
 	kan frsts heller inte placeras i ROM. En BSS-hunk tar faktiskt inte
 	upp ngot utrymme i objektkoden eller i det lnkade programmet, den
 	r att betrakta som en instruktion till systemet att allokera minne
 	och nollstlla det.

Det finns ytterligare tv viktiga delar av programmet som inte utgr ngon 
del av objektkoden utan bara finns under krningen.

STACK	Stacken anvnds fr att skicka parametrar, spara registervrden vid 
 	funktionsanrop och fr alla automatiska variabler. Om inget annat
 	anges s blir stacken p 4000 bytes. Huruvida det rcker r omjligt
 	att avgra i frvg. Det beror i huvudsak p antalet automatiska
 	variabler som ska finnas samtidigt, och p hur mnga funktionsanrop
 	som ligger ute samtidigt, allts funktioner som anropar funktioner
 	som anropar funktioner osv. Brja alltid med en liten stack och ka
 	p den om det behvs. Tnk p att stacken ligger i chip memory, som 
 	r en viktig resurs fr andra program och fr systemet. Ju strre 
 	stack du reserverar, desto mindre minne blir det kvar till annat.

HEAP	Detta r namnet p det minne som fr tillfllet r ledigt och kan 
 	allokeras av systemet. Dess storlek beror p det totala tillgngliga 
 	minnet och p hur mycket minne som systemet, ditt program och andra
 	program som r igng, krver. Mnga funktioner i C-biblioteket allo-
 	kerar minne frn HEAPen under krning.

Alla dessa hunks och minnesdelar ligger utspridda ver hela maskinens minne,
beroende mest p var det fanns lediga platser nr programmet laddades in. Hur
stora hunks man ska ha r alltid en kompromiss. Mnga sm ger ondigt lnga 
laddningstider, medan fr stora hunkar kan resultera i att systemet inte kan
hitta ett tillrckligt stort kontinuerligt utrymme och laddningen misslyckas.
Att sl samman hunkar till strre r en uppgift fr lnkaren och styrs av ett
direktiv till den som medfr att kodsegment med samma namn sammanfrs. Namnen
ges t segmenten i kompilatorns fas 2.



			CHIP MEMORY OCH FAST MEMORY  


Vid det hr laget knner vl alla till att Amiga har tv sorters minne, CHIP
memory och FAST memory. CHIP memory r det adressomrde som bde 68000 och
hjlpprocessorerna kan komma t. Fast memory kan bara 68000 adressera. Tanken
bakom denna organisation r att det inte ska kunna uppst ngra konflikter om 
bussen nr det gller data som inte ska hanteras av hjlpprocessorerna. Detta
innebr att data som ska kunna ns av hjlpprocessorerna mste ligga i CHIP
memory. Men det innebr ocks att programkod inte behver, och inte ens br
ligga i CHIP memory. Systemet kommer normalt att ladda allt frn disken till 
FAST memory om det finns sdant. Fr att data som mste hamna i CHIP memory 
verkligen ska gra det s finns det direktiv till kompilatorns andra steg som
anger var de olika hunkarna ska placeras. Grundregeln r att lgga s mycket 
som gr i FAST memory och spara CHIP memory fr DATA och BSS hunkar om de 
innehller data som mste hanteras av hjlpprocessorerna. Typfallet r fr-
sts alla former av grafik och ljuddata.
