IBM Mainframe Forum

Hi,

I'm trying to write a compiler for some obscure language.

Now I thought that if I do:

S START 0
...
USING S,R2
...
L R5,=F'5'
...
LTORG

...that R5 will be set to 0.
Instead, if I single step it in a debugger (mf), R5 stays zero!
What could it be I'm doing wrong?

regards

Based on the little you posted, we're not likely to be able to help too much. Have you verified that your LTORG is not more than 4095 bytes from your USING? Have you verified that your code is not overwriting the literal pool? Do you have more than one USING in the code? If you are using a debugger, and the load instruction is executed, what address is being used for the literal and how does that compare to the offset to R2 that you specified?

These users thanked the author Robert Sample for the post:

flok (Fri Jun 30, 2017 7:45 pm)

Robert Sample wrote:Based on the little you posted, we're not likely to be able to help too much. Have you verified that your LTORG is not more than 4095 bytes from your USING? Have you verified that your code is not overwriting the literal pool? Do you have more than one USING in the code? If you are using a debugger, and the load instruction is executed, what address is being used for the literal and how does that compare to the offset to R2 that you specified?

Hi Robert,

Regarding the little that I posted: I was not sure if I should post the whole code. The whole code (82 lines) can be found here: https://vps001.vanheusden.com/~folkert/hi-hlasm.asm

I'm very certain that the code itself is less than 4KB Also could happen in theory I guess but not I don't think it can have happened at the first load line (L R5,=F'5').
I verified that the address of the load points to the variable in the LTORG.

Thanks!

regards

This is highly unlikely. The System/360 Load instruction has been around for more than 50 years.

Looking at your incomplete skeleton, I see

Now, when you say

USING S,2

you are telling the Assembler that register 2 has the address of S in it, but I see nothing that puts the address of S in register 2.

When the Assembler gets to your Load instruction it builds these bytes -

58 50 2x xx

The 58 is interpreted by the hardware as a Load instruction. The 5 in 50 is register 5, the 2 in 2x is register 2, and the xxx in 2x xx is the 12 bit difference between the address of S and the address of F'5' in the literal pool established by the LTORG Assembler instruction.

Now, you are telling us you are writing a compiler. Fifty years ago early compilers actually did write Assembler code that was then processed by the Assembler program. But, no more. Roughly 50 years ago compilers started writing real machine code; in other words 58502xxx. In IBM, this can be placed fairly precisely: the Fortran compiler in release 10 of 7090/7094 IBSYS/IBJOB generated real 7090 machine code. This means your compiler must place an address in register 2; this isn't done by magic. It also means your compiler must calculate the xxx bits and store them in the 58502xxx. Other than the BSL, PL/S and PL/X series of internal use IBM "compilers," all IBM compilers for System/360 have generated real machine code.

Now, I'm probably wrong about the release 10, but it was somewhere close to that. I never used 7090/7094 IBSYS/IBJOB. I did use 7040/7044 IBSYS/IBJOB, which was similar in concepts to its big brother, but 7040 stopped at release 9, where 7090 got up to release 13 I think it was before it stopped.

These users thanked the author steve-myers for the post:

flok (Fri Jun 30, 2017 7:45 pm)

steve-myers wrote:This is highly unlikely. The System/360 Load instruction has been around for more than 50 years.

Yes most likely I'm doing something very wrong
Am learning HLASM. My background is x86, arm (and others).

Now, you are telling us you are writing a compiler. Fifty years ago early compilers actually did write Assembler code that was then processed by the Assembler program. But, no more.

That's actually my approach.

If you like(!) please look at my complete code (https://vps001.vanheusden.com/~folkert/hi-hlasm.asm) because I think that I oversimplified my example a bit

No, I am not going to look at your link. You violated forum rules by putting it in your post. You can cross check your generated code with ideas in my post and Mr. Sample's post.

I looked at the code in your link -- which came across as continuous text lines, so I had to reformat it to even make sense of it.

Your first problem is that you have If you are going to load register 12 with the starting address, the USING should also be register 12.

Another issue is where you have Since you have only the one USING statement in your program, and a USING only gives you 4095 bytes of addressability, how do you think the last 27,000-odd bytes of "data_mem" are going to be accessed?

These users thanked the author Robert Sample for the post:

flok (Fri Jun 30, 2017 7:51 pm)

I'm trying to thank you people but the hand points down now?

Robert Sample wrote:... Another issue is where you have

Select all

MSGAREA  EQU   *
         DC    AL2(5)
BUFFER   DC    XL2'00'
         DC    C'!'
data_mem DS    32000C

Since you have only the one USING statement in your program, and a USING only gives you 4095 bytes of addressability, how do you think the last 27,000-odd bytes of "data_mem" are going to be accessed?

In my opinion, there's nothing "wrong" with putting a large data area at the effective end of addressability, but you do need some alternate way to get to the data in the data area.

As an example, back in 2010 I wrote a program to use the read multiple count key and data CCW command to read an entire track image into a large data area defined pretty much the same way as flok defines his data area, though my data area was somewhat larger -

The CCW Assembler instruction is just a convenient way to write

READCCW DC X'5E',AL3(TRKBUF),X'20',X'00',X'FFFF'

Now, as it happened, TRKBUF was addressable, so the code to go through it starts as -

LA reg,TRKBUF

but it could just as easily have been

L reg,READCCW

The register points to a data area that, on the disk, is called a "count" area. Offset 5 is a 1 byte data area that defines the length of the key if it is not 0, and offset 6 defines a 2 byte data area that defines the length of the data area of the record. So to get to the next data record in storage you write something like

SR 14,14
IC 14,5(,reg)
LH 15,6(,reg)
AR 15,14
LA reg,8(15,reg)

It's not really quite that simple. The data area can be greater than 32K, so you have to be ready for that contingency, but that's the basic idea.

Ok, I'll bite.

You say that you expect that R5 will be set to 0 - I hope that you mean set to 5, as that is what L R5,=F'5' should normally do.

I took the program from your link and did an assembly. It ended rc 12 with these errors:

Fix:
1) change 'START 0' to 'CSECT'
2) change 'wloop_0_e NOP' to 'wloop_0_e ds 0a'. You might also use 'wloop_0_e CNOP 0,4', but in this case 'ds 0a' works just as well.

After which it assembles and runs with rc 0.

Comments:
You have two LTORG. While not neccessarily a problem, for a program this small I would just go with the last one.
As other have pointed out, the top of the program is a bit confusing. You have a 'LR R12,R15', which would indicate that you want to use R12 as a base, but then you do 'BALR R2,0' and 'USING *,R2' to set the base to R2. Personally I would do 'LR R12,R15' and 'USING BF,R12'.

And now back your stated problem. I added a ' DC A(0)' right after the 'L R5,=F'5', but the program did not abend. This tells me that the instruction is never executed, so whatever value your debugger shows r5 to have, will be the value it had before your program was started. Or in other words, you have a logic issue with your program.
Hope this helps.