Quote:
Originally Posted by Mrs Beanbag
Tell it to Francois Lionet.
If you load an executable into an AMOS memory bank, you only get the first code hunk. It doesn't process the RELOC table. And even if it did, it throws it away so there is no way to re-RELOC it when you save your program and load it in again.
Also when writing AMOS extensions, the compiler will pull only the extension functions that are actually used out of the executable and concatenate them, with no RELOC data, you use special macros to define branches to one function from another. Actually it is horrible, because it just goes through the file looking for some specific codes, so some of your data might accidentally match! But this is what i've got to work with...
|
Sounds like fun. If faced this, i'd start by trying to encapsulate this horror, like having the code just load something from outside with LoadSeg.
Quote:
Originally Posted by Mrs Beanbag
Yes but my point was JMPM/JSRM d16(An) could be only 4 bytes.
|
You're counting 4 or 6 bytes while having a big 4-byte per entry jump table (the relocs making it even worse). It's like counting cents after having wasted whole dollars.
What about starting by using word size offsets instead ?
Quote:
Originally Posted by Mrs Beanbag
The link does not answer my question. I know how static prediction usually works. What i don't know if whether a forward BEQ is taken more or less often than a forward BVS, for instance.
|
Forward or backward, BVS is rarely taken. BEQ is difficult to predict ; i'd say 50%.
This won't help much though, as BEQ is the most occuring branch type whereas BVS is relatively rare.