On 2018-12-08 05:00, ASSEMBLER-LIST automatic digest system wrote: > Date: Sat, 8 Dec 2018 02:34:20 +0000 > From: Alan Atkinson <[email protected]> > Subject: Re: Getting the Last Condition Code > > So smelly or not we have a lot of stuff that branches conditionally based on > return codes from whatever was just called. CLI *,0 and *,255 along with CR > R11,R11 gives a range of options for indicating if something was good, bad or > indifferent. > You have my sympathy. CLI *,0 looks very similar to some of the code I and my colleagues churned out in the late '60s, when we didn't know what we were doing, nor could foresee the maintenance nightmare we were preparing for ourselves and our unfortunate successors. Indeed, 50 years later, we're *still* fixing it and cussing ourselves and our predecessors daily. So I'm unmoved by arguments like "No it doesn't".
> The ability to insert (say) a logging routine to trace an operation by using > an IPM / <log> / SPM and not having to do the <expensive cc setting routine> > over again or worry that <log> changed the cc outweighs the idea that doing > <expensive cc setting operation> twice is somehow more intellectually pure. > That's a good counter-example, though I hope as a temporary debugging aid only. > YMMV, but it works. It works doesn't necessarily mean it's correct. > In production. > Consistently. > I’ll take that over running IDF at 3am. Yes, IDF is horrid. The "debugging" scenario I was imagining was slightly different: production is failing, and either delivering a dump or sending the wrong output somewhere. The only evidence available is (let's say) the dump, and any tracing I may be able to do is dangerous. Programming is about "sending messages" from one part of a program to another part (which may be a different program altogether). Dump-solving is about "how did this (incorrect?) message get here, and where did it come from?" plus rinse-and-repeat. There are basically three ways messages are sent. In order of increasing fragility: in storage; in registers; and in the condition code. By "fragility" I mean three things. First, being susceptible to breakage by careless maintenance. You might well say "maintenance must not be careless" -- fine, but I've seen this and fixed it more times than I can remember. Second, by leaving, or not, a trail in the dump that can be followed back to the origin of the problem. Unchanged storage is the best evidence, and register contents can give quite good clues. But if the condition code has been changed, accidentally or by design, we have no idea how or where this happened. Third, except by luck, there's probably little chance of correlating the branch mnemonics with the condition being signalled. Of course that could be hidden behind a macro, but that just introduces another layer of unnecessary obscurity. Alternatively, one has to fiddle with stuff like JC 11,WHAT does this mean? That's why I think repeating a test is better than trying to send the CC forward. I don't think that there's a major, important performance hit if you compare, say, CLI with SPM (which I suspect is going to hit the instruction pipeline and branch prediction), and *the code is much clearer at the point of inspection*. On subroutine return codes, IMO, there are far better alternatives to the CC for a subroutine to pass results to its caller. Here are three examples. 1. Pass/Fail (with possible error code in a register) BAS R14,GETSHRUB Obtain shrubbery J SHRUBERR No shrubbery found * Drop through for normal processing In this case GETSHRUB returns with either B 4(,R14) All OK - return or BR R14 Oops, failed 2. Multi-condition branch vector BAS R14,GETSHRUB Obtain shrubbery J SHRUBERR No shrubbery found J NOTGREEN Shrubbery is too dry J NOTAUTH Shrubbery not authorised * Drop through for normal, green shrubbery processing This is an extension of #1 3. Error-code-plus-1 (in, say, R0) BAS R14,GETSHRUB Obtain shrubbery JCT R0,ERROR No shrubbery found * Drop through for normal processing Here we have RC=1 meaning OK, RC<>1 being an error code. I don't pretend to be an authority -- I'm still learning. But in 50 years I've seen many examples of what turned out to be really crappy code (including my own), and these included several cases of people second-guessing the condition code, with hilarious results. TM SOMETHING,X'80' JE THEWRONGPLACE
