mlaidlaw@Daisy.EE.UND.AC.ZA (Mike Laidlaw) (05/20/91)
Help! 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.When I next load my language,AllocMem gives me memory starting at a different address thus when I load my program,all the absolute calls are incorrect thus my program bombs.My question is this,do I save my sources as ascii text and compile them everytime I load the text back in again,or is there some method of using indirect addressing within secondarys? The problem with ascii text files is if I want to create whole dictionarys which emulate another language which would take pretty long to compile. Does anyone know how JPForth or any other Forth does it? Please Note : I am using assembly code to produce the language. Thanks in Advance. Myron 8->
carolyn@cbmvax.commodore.com (Carolyn Scheppner - CATS) (05/21/91)
In article <1991May20.134453.15378@Daisy.EE.UND.AC.ZA> mlaidlaw@Daisy.EE.UND.AC.ZA (Mike Laidlaw) writes: > >Help! > >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.When I next load my language,AllocMem gives >me memory starting at a different address thus when I load my program,all the >absolute calls are incorrect thus my program bombs.My question is this,do I >save my sources as ascii text and compile them everytime I load the text back >in again,or is there some method of using indirect addressing within >secondarys? The problem with ascii text files is if I want to create whole >dictionarys which emulate another language which would take pretty long to >compile. > >Does anyone know how JPForth or any other Forth does it? > >Please Note : I am using assembly code to produce the language. > >Thanks in Advance. > >Myron 8-> There are probably hundreds of way to do it. The basic concept is that you cannot use absolute memory locations on the Amiga. I gather the table is NOT compiled with your code (that's what you are trying to avoid). So you can not use PC relative addressing like lea.l label(PC),a0 ; gets current address of label move.l label(PC),d0 ; get longword AT current address of label However, you can use base register addressing (which is faster on the 68000 than absolute addressing) Load your table and put its base address in a register like A5. A5 won't get trashed by any system routines (unless you use it to pass an argument but few functions use A5 for arg). Write your program to reference everything in the loaded piece off of the base register. For example: lea.l label(a5),a0 ; gets current address of label move.l label(a5),d0 ; get longword AT current address of label jsr label(a5) ; jump to sub AT current addr of label -- ========================================================================== Carolyn Scheppner -- Tech. Mgr. CATS - Commodore Amiga Technical Support PHONE 215-431-9180 {uunet,rutgers}!cbmvax!carolyn carolyn@commodore.com Oh I'm a numberjack and I'm OK, I code all night and I work all day... ==========================================================================
chrisg@cbmvax.commodore.com (Chris Green) (05/21/91)
In article <1991May20.134453.15378@Daisy.EE.UND.AC.ZA> mlaidlaw@Daisy.EE.UND.AC.ZA (Mike Laidlaw) writes: > >Help! > >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.When I next load my language,AllocMem gives >me memory starting at a different address thus when I load my program,all the >absolute calls are incorrect thus my program bombs. JForth uses a variety of techniques for this. When generating a call to another routine, they use a 16 bit relative branch to get to it, if possible. If not, they generate a JSR xxx(A4) where A4 is a register that points 32k into the image. If even this doesn't reach, then they generate a jsr absolute to the target address, and add this address to an internal list of absolute addresses which must be relocated at load time. -- *-------------------------------------------*---------------------------* |Chris Green - Graphics Software Engineer - chrisg@commodore.COM f | Commodore-Amiga - uunet!cbmvax!chrisg n |My opinions are my own, and do not - killyouridolssonicdeath o |necessarily represent those of my employer.- itstheendoftheworld r *-------------------------------------------*---------------------------d
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/22/91)
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...