> using condition code as return value from subroutines that tested I have never settled on a good scheme for returning what is effectively a bool value from an assembler subroutine that performs a test.
I have tried using the condition code: (all examples using "historical" opcodes) BAL R14,some_test BE success The problem for me was that you have to jump through some convolutions to set the condition code. Sure, it is fairly easy to do, but branching to a CR R0,R0 just to set the CC seems silly. I have tried using a return of BR R14 for true and B 4(,R14) for false: BAL R14,some_test B success B failure I probably like and use that more than anything else, but it is obviously a trap for unwary future maintenance. The necessary coding in the subroutine is fairly straightforward. You can return a truth value in a register but registers are often precious and it sometimes has the convolution problem of the condition code approach. Anyone have a great solution? Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Phil Smith III Sent: Tuesday, June 2, 2020 5:21 AM To: [email protected] Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
