IBM Mainframe Forum

Really it seems like you need a book or two. There are several tutorials on the web but the book I found most useful to start with was by Bill Qualls. It is out of print now but Bill has converted it to an html format reachable from his home page.

These users thanked the author NicC for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

RISCCISCInstSet wrote:Okay so apparently I was falling through. This seems to solve my problem.

I think I forgot a rule: do not post beginner questions where advanced questions are expected.

@BillyBoyo Would this question and its like be more appropriate in "Stupid Questions"?

Now you're in a hole, and still digging. What do you mean "apparently", and "seems"? There's no smoke-'n-mirrors in a program of that size.

This whole site is for beginners and students. You have no "out" there. If you "missed" those errors in any language, then it indicates some problem. That is why I said it was important for you to understand how you missed them. Was it the technique used to get the program together, added to the unfamiliarity with the language? Or you just plain can't program? Or something else? It is important that you know so that you don't make similar mistakes. I'm assuming from your monicker and previous comments that you have written code in other languages. I'm not assuming it is good or bad code, but you are making beginner programming mistakes, let alone with the Assembler.

No, not in the Stupid Questions. The thing is, those were errors that you should have spotted. Since you didn't, you're going about writing the program in a bad way. If you continue with, with all the effort that has been expended on you, then it will make no difference to me where you post.

These users thanked the author BillyBoyo for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

Well when in doubt, I'll use "Stupid Questions."

I'm not currently very literate in assembler, so if I'm trying to have you "debug my programs," there's a pretty good chance I can't read the freaking code.

Maybe you can explain what the code means instead of post solutions/code that works?

I've just looked back through this topic. No one has posted any solutions/code that works for you. I certainly feel that if I just post a solution for you, it is much more difficult for you to learn that way, and I think that is the general consensus of the others who have been helping you.

I've tried to point out to you twice already that your latest problem has not been with Assembler. Any type of "Branch" instruction is a "go to". There is the possibility of the Branch which at the same time establishes a way to return to the following instruction, but the plain Branches will just stay away. With no label to branch back to, code after a plain Branch will not be executed.

Get back to the POP and look at B, BR, BC and compare to BAL and BALR. The BAL and BALR are designed to be able to continue afterwards at the next instruction. They are typically used for internal subroutines and external program calls. The B, BR, BC are designed just to get your program to continue from some other point, a GO TO.

Did the confusion arise from doing the BAL before doing the BC in your examples? Did you believe the BC was acting like some transfer to a function, with the code within the function delimited by the next lable statement?

Maybe that is the explanation for why you coded that way. OK. A Branch that "links" has the mechanism to return to the following instruction but only if you explicitly code for that in the location that you have branched to, there is nothing going to happen automatically. A Branch without a link can only return to the statement following the branch if that statement has a label and if you issue another branch to that label.

Nothing, or almost nothing, is going to happen automatically in an Assembler program. The closest, and why I say almost nothing, is something like the EODAD, but even something like that is nothing like the way a compiled program works.

In Assembler, you have to do everything. If you BAL, you still have to B yourself, although the "AL" bit has given you somewhere to B to. After a BAL - there is nothing that will force you to return if you don't want to, or if you make an error, the program will just march on until it trips up in a storage area or something like that.

In Assembler, one line of source code, one instruction in the object code. Nothing fancy. You have to do everything yourself. In a compiled language, no fixed limit to how many instructions may be generated in the object, and those instructions can accomplish an enormous amount of stuff from just one line of source.

These users thanked the author BillyBoyo for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:56 am)