L not working as expected



High Level Assembler(HLASM) for MVS & VM & VSE

L not working as expected

Postby flok » Fri Jun 30, 2017 5:37 pm

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
flok
 
Posts: 8
Joined: Mon May 09, 2016 2:25 pm
Location: Gouda, the Netherlands
Has thanked: 4 times
Been thanked: 0 time

Re: L not working as expected

Postby Robert Sample » Fri Jun 30, 2017 6:40 pm

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
Global moderator
 
Posts: 3657
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 270 times

Re: L not working as expected

Postby flok » Fri Jun 30, 2017 6:59 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
flok
 
Posts: 8
Joined: Mon May 09, 2016 2:25 pm
Location: Gouda, the Netherlands
Has thanked: 4 times
Been thanked: 0 time

Re: L not working as expected

Postby steve-myers » Fri Jun 30, 2017 7:01 pm

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

Looking at your incomplete skeleton, I see
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.

These users thanked the author steve-myers for the post:
flok (Fri Jun 30, 2017 7:45 pm)
steve-myers
Global moderator
 
Posts: 2086
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Re: L not working as expected

Postby flok » Fri Jun 30, 2017 7:10 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 :D
flok
 
Posts: 8
Joined: Mon May 09, 2016 2:25 pm
Location: Gouda, the Netherlands
Has thanked: 4 times
Been thanked: 0 time

Re: L not working as expected

Postby steve-myers » Fri Jun 30, 2017 7:16 pm

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.
steve-myers
Global moderator
 
Posts: 2086
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Re: L not working as expected

Postby Robert Sample » Fri Jun 30, 2017 7:37 pm

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

These users thanked the author Robert Sample for the post:
flok (Fri Jun 30, 2017 7:51 pm)
Robert Sample
Global moderator
 
Posts: 3657
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 270 times

Re: L not working as expected

Postby flok » Fri Jun 30, 2017 7:52 pm

I'm trying to thank you people but the hand points down now?
flok
 
Posts: 8
Joined: Mon May 09, 2016 2:25 pm
Location: Gouda, the Netherlands
Has thanked: 4 times
Been thanked: 0 time

Re: L not working as expected

Postby steve-myers » Sat Jul 01, 2017 8:57 pm

Robert Sample wrote:... Another issue is where you have
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 -
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.
steve-myers
Global moderator
 
Posts: 2086
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Re: L not working as expected

Postby willy jensen » Sun Jul 02, 2017 4:27 pm

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:

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.
willy jensen
 
Posts: 316
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 42 times

Next

Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post