L not working as expected

[flok]

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

[Robert Sample]

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?

[flok]

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

[steve-myers]

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

Looking at your incomplete skeleton, I see

Code: Select all

S        START
         ...
         USING S,2
         ...
         L     5,=F'5'
         ...
         LTORG
         ...

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.

[flok]

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

[steve-myers]

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.

[Robert Sample]

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

Code: Select all

        LR    R12,R15
        USING BF,R2

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

Code: 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?

[flok]

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

[steve-myers]

... Another issue is where you have

Code: 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 -

Code: Select all

READCCWS CCW   X'31',IOBSEEK+3,X'40',5  SEARCH ID EQUAL      
         CCW   X'08',*-8,0,0            TIC                  
READCCW  CCW   X'5E',TRKBUF,X'20',X'FFFF' READ MULTIPLE C-K-D
         ...
TRKBUF   DS    (X'FFFF')X

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.

[willy jensen]

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:

Code: Select all

000000                00000 07E1D    36 BF       START 0        
ASMA153S START statement illegal - CSECT already begun          
ASMA435I Record 3 in xx.ASMTEST.JOB02782.D0000101.? on volume:  
000074 0000 0000            00000    78 wloop_0_e NOP          
ASMA040S Missing operand    
 

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.