
Filerna i det h{r direktoryt {r t{nkta att ge ideer om hur man kan 
l|sa vissa implementations problem. 

I filen term.h definieras termer och operationer p} prolog object. Vi har
f|reslagit en representation d{r man l{gger taggen i dom tv} sista bitarna
i adressen, man kan t{nka sig andra representationer. 

Filerna atom_table.h och atom_table.c definierar en atomdatabas. F|r
att l{tt kunna se om tv} atomer {r lika lagrar man atomer unikt och
ger varje atom en identifierare.

Kod l{ses in med hj{lp av en YACC - LEX grammatik som ocks} fungerar
som top-loop. Kod representeras i minnet med ett helord (4 bytes) per
argument. Man kan mycket v{l t{nka sig kompaktare representationer.


Makefile
	F|rslag till makefil.

atom_table.h
atom_table.c
	Definierar atomdatabasen. Alla filer som anv{nder sig av den ska
	inkludera atom_table.h eller include.h. Atomer lagras unikt i
	en hashtabell med hinkar. Varje hink avs|ks linj{rt.

	Tabellen m}ste f|rst initializeras och detta g|rs med functionen
	init_atomtable().

	Functionen store_atom() anv{nds f|r att lagra en str{ng som atom
	i atomdatabasen. Den returnerar en TAGGAD pekare som representerar
	atomen. Macrot GetString (definierat i term.h) returnerar en 
	pekare till teckenstr{ngen givet en TAGGAD atom pekare.

config.h
	Den h{r filen {r t{nkt att inneh}lla systemspecifika saker. 
	F|r n{rvarande inneh}ller den definitionen av PROTO som 
	g|r att prototyper anv{nds n{r kompilatorn klarar av det (och
	man har definierat PROTOTYPES i makefilen).

constants.h
	H{r ligger olika konstanter som anv{nds i emulatorn, t.ex. 
	heapstorlek och databasstorlek.

database.h
database.c
	H{r ligger en fullst{ndig definition av predikatdatabasen.
	Databasstrukturen liknar atomdatabasens, som nyckel i databasen
	anv{nds predikatets funktor. 
	
	Man lagrar emulerade predikat med hj{lp av funktionen 
	store_emulated_predicate() som tar en funktor och en kodpekare som 
	argument. 

	Predikat skrivna i C lagras med hj{lp av store_c_predicate() som 
	tar en funktor och en pekare till en c function (f}s genom att
	ange funktionsnamnet).

	F|r att hitta ett predikat i databasen anv{nds funktionen
	get_definition() som tar en funktor som argument. Den returnerar
	en pekare till en 'definition'-struktur. Den inneh}ller information
	om vilken typ av predikat det {r (ENTER_EMULATED, ENTER_C och
	ENTER_UNDEFINED), dess namn och kodpekare respektive funktions-
	pekare.

include.h
	Den h{r filen include:erar alla include-filer. Detta f|r att
	slippa g|ra det i varje fil.

init.h
init.c
	Dom h{r filerna {r t{nkta att inneh}lla det som beh|vs f|r att
	initialisera maskinen, d.v.s. initialisera atom och predikat
	tabellen, minnet, register m.m.

instrdef.h
	H{r ligger definitionen av opkoderna f|r instruktionerna.
	Det {r viktigt att alla eventuella switch:ar anv{nder sig
	av samma ordning som h{r, annars blir det inte en tabell
	av switch:en utan en massa if:ar. Det g{ller generellt att
	en switch med case v{rden 0,1,2,3...n blir en tabell.

parser.l
parser.y
	Dom h{r {r ofullst{ndiga f|rslag till YACC-LEX grammatik. 
	YACC grammatiken fungerar b}de som inl{sare av kod och
	top loop. H{r ligger {ven definitionen av main(). Tanken
	{r att man l{ser in koden genom att g|ra 'load' p} en fil
	och sedan k|r predikatet start/0 med hj{lp av 'go'. 


storage.h
storage.c
	Funktioner f|r att allokera minne f|r kod, databasen, heapen, 
	stacken, och trailen ligger h{r. [ven en funktion f|r att 
	allokera minne fr}n databasen (static area) finns. Tanken 
	{r att dom andra minnesareorna ska manipuleras genom att
	flytta top pekaren (*_current) fram och tillbaka. F|r att
	effektivisera kan man t{nka sig att cacha l{mpliga pekare
	i register i t.ex. huvud emulator loopen.

term.h
	H{r har vi n}gra f|rslag p} hur prolog termer kan representeras.
	Vi har valt en representation d{r taggen ligger i dom tv}
	nedersta bitarna. Det har vi gjort f|r att l{tt kunna ta bort och
	l{gga till en tag. I filen finns ett antal macron som vi starkt
	rekommenderar att ni anv{nder er av (eller liknande macros).

	Support f|r tal finns inte i filen. Man kan t{nka sig flera 
	s{tt att g|ra det p}. 


En k|rbar implementation beh|ver f|ljande ut|ver ovan n{mnda.

	En emulator loop. Detta g|rs t.ex. med hj{lp av en eller fler
	switch:ar. I emulator loopen b|r kod f|r fail och eventuellt
	unify finnas. Det {r ocks} l{mpligt att l{gga in n}gon form
	av debugging s} man kan f|lja exekveringen p} instruktionsniv}.
	
	En generell unifierare som unifierar tv} termer.
	
	Support f|r choicepoints och trailning.
	
	N}gra inbyggda predikat t.ex. 'time'/1, '$display' m.m. 
	
	Initialiseringsrutinerna m}ste utvidgas, parsern m}ste 
	utvidgas m.m.

	Eventuellt support f|r tal.

	Eventuellt utnyttjande av den oanv{nda tag:en till n}got 
	l{mpligt.

