>"Russell McMahon">said
>I have seen the "jump into the middle
>of an instruction" trick done. I don't
>know how common it is.
>I have also seen this done in code made by what appeared to be hand coded
>assembler.
>
>When this is done by a HLL (C or whatever) it is clever, supportable and
may
>be useful.
>
>When done in assembler it is
>- undocumentable
>- dangerous
>- may stop working at any time if you don't remember you did it and
>- you should instantly fire the programmer who does it if he / she ever
does
>it again once you have told them not to :-).
>
>You have no chance of supporting code containing assembler generated code
of
>this sort.

James Newton said -

>I agree on your other points but... I'm glad I don't work for you <GRIN>.


OK. You're fired - obviosuly intractable and won't take instruction :-)

>1. How can anything not be documentable? That has got to be just plain
dogma
>on your part.

Yep. Plain dogma. Some dogma is based on experience or sense though :-)
But see below why it REALLY isn't documentable.

>Just a quick comment at each place where the technique is used
>should warn future code maintainers as to what is going on.

No. Nothing whatsoever will protect you against its universal use.
BECAUSE -
Once you allow or encourage programmers to use parts of existing code as
portions of another instruction you officially tell them that the procedure
is controllable. Even if you say it can be done in xxx situation but not in
yyy situation you open up the possibility of them judging wrong or of the
boundary being unclear or of them just doing it bloody-mindedly (they are
people, after all) or ignorantly. (A friend of mine had a programmer who
insisted on trying to store persistent data in temporary "local" variables
stored on a stack in a subroutine. If a computer science graduate can do
that he/she can surely get confused on multi-function code.)

Here are some examples of where it will fail despite documentation warning
you about it.

- 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 double used code is part of a lookup table. The warning is inserted
either at the top of the table or at the point of actual re-use. Someone
wants to modify the table. They may even see your warning note at the
relevant point. They may make the table longer/shorter (which may or may not
kill your code depending on how it works). They may generate the table using
a new algorithm without looking at the old code because this is how it was
done before, prior to your clever use of code. They may use new table data
and misunderstand your note and leave the data the same at your location
despite its effect on the table's function. In each case Murphy will ensure
that death ensues.

- This one is most unlikely but... : The manufacturer changes the processors
code set. eg Some day,  MChip have told us, the TRIS will vanish - if you
have bodge coded the TRIS instruction then ... .

- The hand bodged instruction is clearly marked. The person-who-comes-after
does not fully understand what you are doing and respectfully leaves it
alone. BUT, the code feeds into somewhere else and because the instruction
was effectively "invisible" at the C or assembler or whatever level then
they ignore its effect when they change the following (or preceding) code.
Death ensues :-).

>2. ALL code will stop working if you don't understand what it does and
>modify it incorrectly.


Yep. This is just a superior way of ensuring that it happens :-)

>3. Any programmer who understands that type of trick is a jewel that should
>not be cast out, but instead allowed to shine on others. The only
>"punishment" I would advocate is a training session for the other
>programmers in the stable as to how to make use of the trick.


He's fired too :-)


>I guess you got burned on this one and are still pissed about it? <WINK>
><WINK> <NUDGE> <NUDGE> I still can't stand to work in a company with more
>than 5 employees for similar reasons; got back stabbed, can't trust
>co-workers to this day.


No. Never have been. But I don't want to ever have more than 6 people
working for me after having had 20+ at one stage long ago.



Someone else asked "why is this acceptable for a compiler to do but not a
person".
I say that it is MORE acceptable (but still dangerous) because the compiler
knows the full rule set it works from and builds the code up "from scratch"
on each occasion. Even this can be made to be untrue but it is reasonable
true. The biggest danger is that someone will attempt to hand optimise or
alter the code, and all bets are off.




regards,


                Russell McMahon