Re: A85: Re: Re: What am I doing wrong?

[Prev][Next][Index][Thread]

Re: A85: Re: Re: What am I doing wrong?


I have thought of a very simple and effective solution that works
guarenteed, every time :) I even brought it to Andreas Ess and he agreed
with me that it was a neat idea.
You see, in the Usgard relocation table, which is added to the end of the
program (trust me, I have done much research on this) Each relocation
pointer points to what it thinks of as a word that needs to be relocated in
your program.  So, the SRcWiz program replaces all lines with & in them with
a special label, before it is run through the tasm program.  At the end, a
special label table file is created by a special invocation of tasm, and the
string85 program uses these label values as what needs to be in the reloc
table.  But, since these labels point to a beginning of an instruction, like
this:

R_5:
   call MyLabel

if used directly, the loader engine on the calc would adjust the first word
at that address, meaning the actual call opcode and the first byte of the
word.  So, what the string85 program does is put an entry into the reloc
table for the value of the label +1 byte for the call opcode.  for certain
other instructions, it is +2, but the default is +1.  So, we can use this in
our programs for .dw tables.
if we have:
.dw &Address1
.dw &Address2
.dw &Address3
in our program, srcwiz replaces it with:
R_1:
.dw Address1
R_2:
.dw Address2
R_3:
.dw Address3
then, when string85 sees those labels, it adds one to there value and stores
them in the reloc table.  BUT, in this case, since there is no leading
opcode, the reloc table is wrong, these three relocs point to one byte too
far from where they shouyld.
So, to correct this, i simply use this, adding no more bytes whatsoever to
the code:
.org $-1
.dw &Address1
.dw &Address2
.dw &Address3
.org $+1

This simple change makes all those R_N labels srcwiz creates to be wrong, by
one byte backwords.  So, when string85 adds the one extra byte, the reloc
table becomes correct again.

very simple, very efficient, and doesnt hurt source readability very much
either.

-Jonathan Kaus

----- Original Message -----
From: Sam Heald <evil_sam@hotmail.com>
To: <assembly-85@lists.ticalc.org>
Sent: Thursday, June 17, 1999 9:41 AM
Subject: Re: A85: Re: Re: What am I doing wrong?


>
>>Maybe the problem is in  ".dw &xxxx+nn" part of your code. Try to >arrange
>>your labels so that you only need to write ".dw &yyyy". >Please tell if
>>that works...
>
>   No, that's not the problem. The problem has to do with the presence of &
>signs in the "door_table". To fix the bug temporarily, I used old the
>programming technique "when in doubt, bloat the program". Basically, I
>copied all of maps to addresses in GRAPH_MEM, so that the & signs in the
>table were no longer neccessary. Obviously, once more maps are made, this
>solution becomes void.
>
>   Can anyone think of a better solution? Or perhaps, explain why & signs
>would cause the data in the table to be incorrect?
>    Sam
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>