On Apr 21, 2:48 pm, "Maki" <veselic...@[EMAIL PROTECTED]
> wrote:
> I have recently cross-compiled my first forth system (subroutine
threads),
> and now I want to separate headers from code. Current header arrangement
> looks like this:
> [link][flags][count][name] code
> I guess I need one more pointer in the header like this:
> [link][flags][count][name][code_ptr] which will connect header to
> definition.
[link][flags][code_ptr][count][name]
because name is variable length
>
> Questions:
>
> 1. What is the best way to handle allocation in name dictionary? My
current
> thought is to revector dp with words like:
> PROGRAM HERE ( returns dp from program code dictionary)
> NAMES HERE ( returns dp from name dictionary)
An alternative is
: N-HERE N-DP @[EMAIL PROTECTED]
;;
: N-ALLOT N-DP +! ;
etc.
I do not know which one is best (a global switch or wordset
duplication).
>
> 2. Implementation of word >name is trickier. It appears that >name now
> should use FIND to go back to name field.
It's not really find... I promise, you will enjoy coding.
And even a better one is the word that determines in which
definition the address is. (Say, you want to print the return stack in
case of errors).
You will need an array of pointers to the last word in each chain of
each word list.
>
> Are there any other pitfalls that I should pay attention to when doing
this?
> Any advices an comments appreciated.
> Best regards,
> M.
Relative links in name fields are probably worth doing it.
Probably so are relative links in branches.
But in general, relocation is not a problem.
If you have a system with segments for, say, code, data, and names,
you load the system two times at different offsets,
for example, c1, d1, n1 for the first time, and c2, d2, n2 the 2nd
time,
and the offsets for segments will be all different:
c2-c1=10h; d2-d1=40h; n2=n1=80h.
Now you can compare two images and find references that must be
relocated.
The difference will tell you what kind of reference is that:
10h -- code
40h -- data
80h -- names
30h: relative code->data
and so on.
|
