Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!knuth!mjbtn!raider!elgamy!elg
From: elg@elgamy.RAIDERNET.COM (Eric Lee Green)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Help with language writing
Message-ID: <00674878100@elgamy.RAIDERNET.COM>
Date: 22 May 91 02:08:20 GMT
References: <1991May20.134453.15378@Daisy.EE.UND.AC.ZA>
Organization: Eric's Amiga 2000 @ Home
Lines: 34

From article <1991May20.134453.15378@Daisy.EE.UND.AC.ZA>, by mlaidlaw@Daisy.EE.UND.AC.ZA (Mike Laidlaw):
> I'm writing a Forth-like language and am stuck.My problem is this,when
> creating secondarys using the outer interpreter (editor) I am using absolute
> memory jumps to primitives or other secondarys.

> I then save the dictionary to  disk as a straight memory dump.

Big mistake. You need to save it to disk as an Amiga relocatable load
module, and use LoadSeg to get it back into memory again. This is somewhat,
uhm, involved... basically, for every absolute address, you need to store
a relocation pointer. Given that a FORTH program consists of a list of
addresses, your relocation info would get be as big as the program!

One thing you might try is keeping addresses PC-relative or start-of-hunk
relative, i.e., always indexing off of an address register. The only
problem here is that it limits you to 64K of dictionary space... which may
not be enough for some applications. Also presents allocation problems, in
that you'd need to AllocMem 64K of memory to make sure that you got
contiguous RAM. For larger programs, you might try something more
ambitious, having multiple "hunks" (64K in size) and an explicit direct
call to routines in other hunks (allows you to put that info into a symbol
table when you generate a load module, without having  absolute relocation
info hanging around for every word). Some amount of kludgery seems
advisable, in any event, on the 68000. (The '020 and up allow 32-bit
relative addressing in addition to the 68K's 16-bit relative addressing, so
you don't have to worry so much about relocation there... just about memory
allocation).

Anybody have any better way of doing it? I'm as curious as anybody else!

--
Eric Lee Green   (318) 984-1820  P.O. Box 92191  Lafayette, LA 70509
elg@elgamy.RAIDERNET.COM               uunet!mjbtn!raider!elgamy!elg
 Looking for a job... tips, leads appreciated... inquire within...