Initializing Base Register(s) in Multi-entry-point CSECT 
Author Message
 Initializing Base Register(s) in Multi-entry-point CSECT

I have a program that contains multiple CSECTs (about 45).  One of the
CSECTs has multiple ENTRYs (as well as a few EXTRNs).  Control is
transferred to the CSECT (lets call it 'FCTRUNER') via GPR 15 (no surprise).
When FCTRUNER gains control, it uses a different base register, GPR 12.

So far, no surprises, n'est-ce pas?

However, at each ENTRY point (other than the first one in the CSECT), there
is the following code to establish addressibility:

LABELX    EQU         *
                    USING     *,R15
                    L               R12,nnnn(,R15)
                    DROP      R15

                    where      nnnn = 1498 for the 2nd ENTRY point
                                                 1468 for the 3rd ENTRY
point
                                                 1438 for the 4th ENTRY
point
                                                 1388 for the 5th ENTRY
point
                                                 1338 for the 6th ENTRY
point

My questions:

1.  What is this number for?  I understand that it is "varying" the base
address (offset from R15), but why?
2.  Why does the number decrease, the further into the CSECT we go?
3.  When I add a single instruction (BCTR R4,0) AFTER the 6th ENTRY point, I
get a S0C4 !!??
Why?  Do I need to modify the nnnn for any or all of the above ENTRY points?
BCTR is a 2-byte instruction.  How much do I need to modify nnnn by?  I
tried to add 2, still got the S0C4 !!??
4.  Well into the 6th ENTRY point, I find the following translate
instruction:

EXTR        TR        LINE+109(1),1275(R12)

Do I need to be concerned that the insertion of my 2-byte instruction may
have effect on the (horrible, IMHO) 1275-byte offset from R12?

TIA



Wed, 06 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT
Ted ha Zaken writes ...

Quote:
>I have a program that contains multiple CSECTs (about 45).  One of the
>CSECTs has multiple ENTRYs (as well as a few EXTRNs).  Control is
>transferred to the CSECT (lets call it 'FCTRUNER') via GPR 15 (no surprise).
>When FCTRUNER gains control, it uses a different base register, GPR 12.

>So far, no surprises, n'est-ce pas?

>However, at each ENTRY point (other than the first one in the CSECT), there
>is the following code to establish addressibility:

>LABELX    EQU         *
>                    USING     *,R15
>                    L               R12,nnnn(,R15)
>                    DROP      R15

so now R12 has what is in the field at (this entry point) +nnnn. Since R12 is
your overall base register, I would assume that this location holds an adcon.
Perhaps at 1498 from the first entry point is an adcon (check your Assembly
listing). Since each subsequent 'nnnn' is decreasing, the code may be allowing
for the fact that each subsuquent entry is closer to the adcon (is the third
entry point 30 bytes from the second, for example?).

Quote:

>                    where      nnnn = 1498 for the 2nd ENTRY point
>                                                 1468 for the 3rd ENTRY
>point
>                                                 1438 for the 4th ENTRY
>point
>                                                 1388 for the 5th ENTRY
>point
>                                                 1338 for the 6th ENTRY
>point

>My questions:

>1.  What is this number for?  I understand that it is "varying" the base
>address (offset from R15), but why?
>2.  Why does the number decrease, the further into the CSECT we go?

See comments above. Do all these offsets end up pointing to the same place in
the program?

Quote:
>3.  When I add a single instruction (BCTR R4,0) AFTER the 6th ENTRY point, I
>get a S0C4 !!??
>Why?  

It looks like this moves every instruction and data field down two bytes, so
now all the earlier offsets are inaccurate

Quote:
>Do I need to modify the nnnn for any or all of the above ENTRY points?
>BCTR is a 2-byte instruction.  How much do I need to modify nnnn by?  I
>tried to add 2, still got the S0C4 !!??

Is the 6th entry point before the 1498 displacement from the second entry
point? If so, then every displacement needs to have 2 added to it; if not, then
only displacements that reference a later displacement need to be adjusted.

Quote:
>4.  Well into the 6th ENTRY point, I find the following translate
>instruction:

>EXTR        TR        LINE+109(1),1275(R12)

>Do I need to be concerned that the insertion of my 2-byte instruction may
>have effect on the (horrible, IMHO) 1275-byte offset from R12?

>TIA

Yes, be concerned. And, yes, it is terrible code. It looks like one of those
programs that was clever at the time because it got around limitations (perhaps
memory size, perhaps limited number of registers, for example). It's probably
worth looking at a rewrite.

With a little more information we may be able to help you better.

Regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Wed, 06 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT

Quote:

> However, at each ENTRY point (other than the first one in the CSECT), there
> is the following code to establish addressibility:

> LABELX    EQU         *
>                     USING     *,R15
>                     L               R12,nnnn(,R15)
>                     DROP      R15

>                     where      nnnn = 1498 for the 2nd ENTRY point
>                                                  1468 for the 3rd ENTRY
> point
>                                                  1438 for the 4th ENTRY
> point
>                                                  1388 for the 5th ENTRY
> point
>                                                  1338 for the 6th ENTRY
> point

> My questions:

> 1.  What is this number for?  I understand that it is "varying" the base
> address (offset from R15), but why?
> 2.  Why does the number decrease, the further into the CSECT we go?

R15 has a different value for every entry point, so apparently
the program is loading the same value into R12 in every case
by adding a different adjustment to R15. The different numbers
would correspond to the positions of the entry points.

Now what is R12 supposed to point to? Is there a USING for it?

Quote:
> 4.  Well into the 6th ENTRY point, I find the following translate
> instruction:

> EXTR        TR        LINE+109(1),1275(R12)

> Do I need to be concerned that the insertion of my 2-byte instruction may
> have effect on the (horrible, IMHO) 1275-byte offset from R12?

The whole mess is horrible!

They should have used symbolic expressions and dsects rather
than hard-coded numbers. For example:

        L     R12,=A(CONSTANTS)
        USING CONSTANTS,R12
                ...
        TR    LINE+109(1),TRANTABLE
                ...
        CONSTANTS DSECT
        TRANTABLE DC 256C'...

--
Allan Beatty
allan [dot] beatty [at] donnelleymarketing [dot] com, where
I've had to clean up code like that but never written any!



Wed, 06 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT
The code looks like output from a disassembler.  Best of luck.

I agree with earlier postings.


[snip]

Quote:
>However, at each ENTRY point (other than the first one in the CSECT), there
>is the following code to establish addressibility:

>LABELX    EQU         *
>                    USING     *,R15
>                    L               R12,nnnn(,R15)
>                    DROP      R15

>                    where      nnnn = 1498 for the 2nd ENTRY point
>                                                 1468 for the 3rd ENTRY
>point
>                                                 1438 for the 4th ENTRY
>point
>                                                 1388 for the 5th ENTRY
>point
>                                                 1338 for the 6th ENTRY
>point

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Wed, 06 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT
Several answers already, but none seem to address the probable way
your program was originally written. Was your listing the output from a
dis-assembler?

Forget every assembler statement where the reference is of the form
nnnn(R15) or nnnn(R12)! The proper code should look like this:

FCTRUNER CSECT
    USING *,R12
. . . . .
    ENTRY LABELX
LABELX EQU *
    USING LABELX,R15
    L    R12,=A(FCTRUNER)
    DROP R15
. . . . .

and the assembler will calculate all the various needed nnnn values, they
depend a lot upon your code and will change on almost any code change.
I believe this should answer all your questions?

By the way, your entry code is violating a very important standard in
360/370
linkage: The code modifies R12 without first saving it, so when you return
to the calling program this register will not have the correct contents.
There
should at least have been a  STM R14,R12,12(R13) statement between
 LABELX EQU *  and  L R12,=A(FCTRUNER) - and of course a
 corresponding construction where you return from this CSECT to the
calling program.

hth regards Sven



Quote:
>I have a program that contains multiple CSECTs (about 45).  One of the
>CSECTs has multiple ENTRYs (as well as a few EXTRNs).  Control is
>transferred to the CSECT (lets call it 'FCTRUNER') via GPR 15 (no
surprise).
>When FCTRUNER gains control, it uses a different base register, GPR 12.

>So far, no surprises, n'est-ce pas?

>However, at each ENTRY point (other than the first one in the CSECT), there
>is the following code to establish addressibility:

>LABELX    EQU         *
>                    USING     *,R15
>                    L               R12,nnnn(,R15)
>                    DROP      R15

>                    where      nnnn = 1498 for the 2nd ENTRY point
>                                                 1468 for the 3rd ENTRY
>point
>                                                 1438 for the 4th ENTRY
>point
>                                                 1388 for the 5th ENTRY
>point
>                                                 1338 for the 6th ENTRY
>point

>My questions:

>1.  What is this number for?  I understand that it is "varying" the base
>address (offset from R15), but why?
>2.  Why does the number decrease, the further into the CSECT we go?
>3.  When I add a single instruction (BCTR R4,0) AFTER the 6th ENTRY point,
I
>get a S0C4 !!??
>Why?  Do I need to modify the nnnn for any or all of the above ENTRY
points?
>BCTR is a 2-byte instruction.  How much do I need to modify nnnn by?  I
>tried to add 2, still got the S0C4 !!??
>4.  Well into the 6th ENTRY point, I find the following translate
>instruction:

>EXTR        TR        LINE+109(1),1275(R12)

>Do I need to be concerned that the insertion of my 2-byte instruction may
>have effect on the (horrible, IMHO) 1275-byte offset from R12?

>TIA



Fri, 08 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT

Quote:

> I have a program that contains multiple CSECTs (about 45).  One of the
> CSECTs has multiple ENTRYs (as well as a few EXTRNs).  Control is
> transferred to the CSECT (lets call it 'FCTRUNER') via GPR 15 (no surprise).
> When FCTRUNER gains control, it uses a different base register, GPR 12.

> So far, no surprises, n'est-ce pas?

> However, at each ENTRY point (other than the first one in the CSECT), there
> is the following code to establish addressibility:

> LABELX    EQU         *
>                     USING     *,R15
>                     L               R12,nnnn(,R15)
>                     DROP      R15

>                     where      nnnn = 1498 for the 2nd ENTRY point
>                                                  1468 for the 3rd ENTRY
> point
>                                                  1438 for the 4th ENTRY
> point
>                                                  1388 for the 5th ENTRY
> point
>                                                  1338 for the 6th ENTRY
> point

> My questions:

> 1.  What is this number for?  I understand that it is "varying" the base
> address (offset from R15), but why?

It's the offset to an address constant from the entry point, and very
bad style, since adding code will blow you out of the water. IMHO you
should change those to symbolic expressions before making any other
changes.

Quote:
> 2.  Why does the number decrease, the further into the CSECT we go?

Because it's ADCON-EP, ADCON is constant and EP is going up.

Quote:
> 3.  When I add a single instruction (BCTR R4,0) AFTER the 6th ENTRY point, I
> get a S0C4 !!??
> Why?  Do I need to modify the nnnn for any or all of the above ENTRY points?

See above.

Quote:
> BCTR is a 2-byte instruction.  How much do I need to modify nnnn by?  I
> tried to add 2, still got the S0C4 !!??
> 4.  Well into the 6th ENTRY point, I find the following translate
> instruction:

> EXTR        TR        LINE+109(1),1275(R12)

Bletch! Was this code by a real human being, or was it the output of a
disassembler?

Quote:
> Do I need to be concerned that the insertion of my 2-byte instruction may
> have effect on the (horrible, IMHO) 1275-byte offset from R12?

Yes. Save yourself some tza'aroth and clean up that mess before you make
any other changes to it. Anywhere that you see a decimal value greater
than one digit, figure out what the code is doing and replace the field
with a symbol or symbolic expression. You'll probably need to add labels
to some DCs.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Sat, 09 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT
Hi Sven,



Quote:
> Several answers already, but none seem to address the probable way
> your program was originally written. Was your listing the output from a
> dis-assembler?

> Forget every assembler statement where the reference is of the form
> nnnn(R15) or nnnn(R12)! The proper code should look like this:

> FCTRUNER CSECT
>     USING *,R12
> . . . . .
>     ENTRY LABELX
> LABELX EQU *
>     USING LABELX,R15
>     L    R12,=A(FCTRUNER)
>     DROP R15
> . . . . .

The ADCON A(FCTRUNER) is likely (in this example) to be addressed by R12
(from the USING on the CSECT). If you enter via LABELX won't the load of R12
with the adcon grab a "randomish" bit of storage to load into the register,
i.e. it'll be nnnn bytes offset (i.e. the adcon's base/displ) from whatever
R12 was on entry, which was perhaps the base address for the caller?

If I recall correctly I've done this in the past by

FCTRUNER CSECT
    USING *,R12
. . . . .
    ENTRY LABELX
LABELX EQU *
    USING LABELX,R15
    LR  R12,R15
    SH   R12,OFFSET
    B     CONTINUE
OFFSET DC AL2(LABELX-FCTRUNER)
    DROP R15
CONTINUE EQU *

<remainder snipped>

CB

Sent via Deja.com http://www.deja.com/
Before you buy.



Tue, 26 Mar 2002 03:00:00 GMT  
 Initializing Base Register(s) in Multi-entry-point CSECT



:>> Several answers already, but none seem to address the probable way
:>> your program was originally written. Was your listing the output from a
:>> dis-assembler?

:>> Forget every assembler statement where the reference is of the form
:>> nnnn(R15) or nnnn(R12)! The proper code should look like this:

:>> FCTRUNER CSECT
:>>     USING *,R12
:>> . . . . .
:>>     ENTRY LABELX
:>> LABELX EQU *
:>>     USING LABELX,R15
:>>     L    R12,=A(FCTRUNER)
:>>     DROP R15
:>> . . . . .

:>The ADCON A(FCTRUNER) is likely (in this example) to be addressed by R12
:>(from the USING on the CSECT).

Actually not.

All assemblers will use the base register with the smaller displacement.

:>                               If you enter via LABELX won't the load of R12
:>with the adcon grab a "randomish" bit of storage to load into the register,
:>i.e. it'll be nnnn bytes offset (i.e. the adcon's base/displ) from whatever
:>R12 was on entry, which was perhaps the base address for the caller?

No, it will not.

:>If I recall correctly I've done this in the past by

:>FCTRUNER CSECT
:>    USING *,R12
:>. . . . .
:>    ENTRY LABELX
:>LABELX EQU *
:>    USING LABELX,R15
:>    LR  R12,R15
:>    SH   R12,OFFSET
:>    B     CONTINUE
:>OFFSET DC AL2(LABELX-FCTRUNER)
:>    DROP R15
:>CONTINUE EQU *

Your code has the same dependency on the base register with the smaller
displacement being used.

The only "advantage" your code may have is no need for relocation processing.

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Wed, 27 Mar 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. COBOL II, Linkage Editor Options for Multi-Entry Point Module

2. Embed points for double entry or templates for double entry bookkeeping

3. Break out of a While Loop then jump back in (to re-initialize a shift register)

4. Initializing segment registers

5. Initializing Multi-dimensional array in Fortran 90 Module

6. Initialized data segment when using entries (CA-REALIA 5.x)

7. Need help initializing entry widgets within namespaces

8. Error: Clock skew plus hold time of destination register exceeds register-to-register delay

9. Error: Clock skew plus hold time of destination register exceeds register-to-register delay

10. How to model multi-dimension registers?

11. ibm logowrite: what does .REGISTER point to ?

12. Floating Point Register on Sparc

 

 
Powered by phpBB® Forum Software