>Also, your first example of documentation not working would seem to not be
>an issue if the code was in assembler and was reassembled after the change.


No. 'fraid not.

>You seem to be referring to a code "patch" made to the actual binary which
I
>suppose could be a real world occurrence.

No. Inasmuch as you can do this with an assembler, it will still fail.
It's not possible to make the assembler code an actual instruction as the
whole point of this trick is that you are looking at the code to see whether
it can be used.

Here's how it would work in real life in the example given.
The example was -

>- The double used code is an offset in a relative jump. Some of the code is
>inserted or removed NOT AT THE JUMP LOCATION. The jump offset changes.
Death
>ensues.


the code generated conventionally goes, say

Address            Code
                          ........
1234                45 56
1236                20 B6

where "20 B6" means "jump always with relative branch offset = b6"
Remember 6800 code :-)
$B6 is  "-74" decimal so this branch will go back D74 bytes and execute from
here.

Now our shining star programmer looks at this code and sees that B6 is the
start of "load Accumulator A from extended address", a 3 byte instruction.
eg "B6 56 78" will load the A accumulator with the contents of the memory
Byte at address $5678
so he codes:

1234    45 56
1236    20 B6
Hitme:
1238    56 78
The "56 78" will have to be done with an equate or FCW (form constant word)
or similar.

eg    FCW $5678

By jumping to address "Hitme-1" (ie 1 byte BEFORE the label "Hitme" the B6
at the end of the instruction will become the start of
B6 56 78
= LDAA $5678
and the programmer will have saved one byte.
He will (hopefully) document what he has done and will (hopefully) not just
be so hot a programmer that he writes poetry instead.

All will be well (possibly) until one day somebody adds/removes code
somewhere in the 74 bytes PRIOR to this masterpiece.
At this stage the target of the branch instruction (20 B6) will be a
different distance away than it was and the B6 will change accordingly. Lets
say it get one byte further away. The B6 will change to a B7.
In ye-olde-anciem-regime-Motorola-6800-speak B7 is Store Accumulator A (if
my anciem brain recalls correctly after all these years) and the bodge
instruction will now SAVE the A accumulator to the location $5678 instead of
loading it.

Unless the person doing the change looks ahead up to decimal.74 bytes (more
than a page if there are as many comments in the code as there are in mine
typically) and sees the bodge AND understands it AND realises what affect
the change will have, then death will occur. The assembler will not complain
and not only will the Accumulator have the wrong value in it BUT also the
data intended source will be overwritten.

Looks vanishingly hard to maintain to me :-)

One way around this in this specific case MIGHT be to write conditionally
assembled code that tested for the B6 and if it was no longer present then
substituted a "proper" instruction for the bodge. This would add 1 byte to
the code length when the test failed.

ie something like (pseudo conditional assembler code)

IF   (Hitme-1)=#$B6 then
    FCW    $5678
ELSE
    LDAA    $5678
END

You will also have to do a conditional assembly adjustment to the call to
this code - you call Hitme-1 if the bodge is in place and Hitme if it is
not.
There are (almost) always work-arounds but the code gets very very obscure.

regards,


Russell McMahon