IBM Mainframe Forum

I, for one, don't understand why you would expect 01000080. The "difference", considering the wrap, between before and after for reg 2, is 00000100, as it should be. To get reg 2 to your value, original reg 3 should have been 01000100. Unless my brain is totally out of gear this morning.

Start up your Windows calculator, switch it to hex mode (you may have to change it to the "scientific" mode first), type in the initial reg 2 value, add 100, and, guess what, you get 01000080.

See what you mean, but I was assuming the wrap would set the address/reg 2 to zero along the way, as the wrap happens, and then continue the addition from reg 3.

BillyBoyo wrote:See what you mean, but I was assuming the wrap would set the address/reg 2 to zero along the way, as the wrap happens, and then continue the addition from reg 3.

That seems to be what Principles of Operation says, too. Actually, it is not an add in the usual sense. In concept, though it doesn't really work that way, you move a byte, add 1 to the even register and subtract 1 from the odd register.

Sorry to be unclear in my description.

It has to set to zero, otherwise you're outside of the address space. Alternatively, an MVCL with an invalid high adress would crap all over low storage, rather than producing some exception. Wouldn't that be fun. And you'd have to have a special case where on completion the reg 2 is not pointing to the byte position after the last byte moved. If I'm not explaining that well, I'm sure you can still understand what I mean.

I wasn't being knowledgeable about this, I'd picked it up from the POP after you'd mentioned how long the text on MVCL was when I was looking for the destructive overlap.

I was wondering what the point of the wrap was. After all, the lesser instructions wouldn't be able to cross the boundary from high memory to low, would they? For instance, on an MVC it doesn't say, "by the way, you can wrap around memory when using MVC if you fancy it". However, on a little, light, further reading, it seems that the memory wrapping technique is important for virtual memory (and other things). So maybe in virtual memory, wrapped around physical memory, an MVC could actually operate like that - but without "knowing" it. I must be nuts to keep trying to follow this, and probably hopelessly wrong.

BillyBoyo wrote:... I was wondering what the point of the wrap was...

I agree, I don't understand what the point of storage "wrapping" is, too.

At one point setting bits in the high order byte of the even register is meaningless, since they would not be used for addressing in the 24-bit addressing mode. On the other hand, if a programmer is going to turn around and use the register one would be better off if the register is correct. I will often use regs 14 and 15 to build a message from message segments, finishing up with code like this to build an RDW -

LA 14,MSG+4
... Code to build the message, bumping reg 14 as it goes
LA 1,MSG
SR 14,1
STH 14,0(,1)
XC 2(2,1),2(1)

Now this scheme won't work if reg 14 wrapped, but you'll never encounter this in the real world, so who cares.

Yeah, imagine having to test each time you increase (or decrease) the value in a register?

If you really sat a trainee down with a POP to "learn" assembler, they might be unlucky enough to be able to understand the MVCL description, then think that they do need to do code to protect register values for "wrap" situations. Alternatively, if only learning from a "mentor", then it relies on what the mentor knows, and is able to explain in an understandable manner.

Perhaps someone should write a "pop" solely for business-application programmers. Then there is not even potential confusion with all the stuff they will never actually come across but might accidently read. I'm sure it would be a wildfire best-seller

There are a couple of pretty decent texts for using Assembler for business applications, but ( don't see a need for a "Principle of Operations for Business Applications."

Sorry, it is my tendency not to be too serious, again. I'm sure "my new idea" has been thought of long ago and been appropriately addressed in the sort of texts you mention. I used to have, in fact still have somewhere, one called "Assembler Language for Application Programming" (or programmers, can't quite be sure). Big, red, hardback, reassuring. Almost certainly not a "wildfire best-seller"