We can agree to disagree on this one. I do see some of your points and I guess that if I had ever managed 20+ programmers I might agree more. I totally failed to keep 3 German programmers under control once, but I blame that on cultural differences more that anything. Not that I'm saying anything bad about Germans, just that I'm from a different culture. The company was (is) wildly successful, but the software was (is) pure crap. I do agree that there are times that very tricky code is not desirable when it must be maintained / reused by other programmers who are not as tricky. In the best of all possible worlds, I would like all my programmers to be equally tricky and devoted to good documentation. Let me insert another point in your "level of acceptance of the use of this trick" scale. I would think that a macro in ASM would be somewhere between use in hand coded ASM and compiler use. 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. You seem to be referring to a code "patch" made to the actual binary which I suppose could be a real world occurrence. James Newton mailto:jamesnewton@geocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm -----Original Message----- From: Russell McMahon [mailto:apptech@clear.net.nz] Sent: Saturday, November 13, 1999 2:31 AM To: eplus1@san.rr.com Cc: PICList@MITVMA.MIT.EDU; ADR Subject: Re: C vs. ASM >"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 . 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? > 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