CSECT and DSECT semantics? 
Author Message
 CSECT and DSECT semantics?

By now I have the "High Level Assembler Language Reference", which
certainly answers many questions.  Reading it, I came across DSECT
and CSECT.

It looks like I can have one unnamed section of each type, and many
named sections.  The section contents would not have to be defined
sequentially, but I could do the following:

CONE  CSECT
      ...
DONE  DSECT
      ...
CTWO  CSECT
      ...
DTWO  DSECT
      ...
CONE  CSECT
      ...
DONE  DSECT
      ...
      END

The manual says: "The assembler language statements that appear in a
dummy section are not assembled into object code." So I can not put DC
statements in dummy sections to initialize variables? If so, a dummy
sections sounds like the BSS segment in UNIX, the segment containing
uninitialized data, which is not part of the executable.

Why would I want to have more than one section of each type, though?
I could think of two control sections, one for shared code, one for data,
but more than one segment for uninitialised data? How can I determine
the sequence of sections? In the above example, I could think of two ways:
CONE, CTWO, DONE, DTWO or CONE, DONE, CTWO, DTWO.

Any explainations are appreciated.  Just writing my thesis and learning
for the upcoming final exams, digging into IBM assembler is simply
mentally refreshing! :)

Michael
--
d? H- s(+)/(-) g! au a- w+ v(---) C++(+++) UL++++S++++?++++ L++ 3 E-



Mon, 05 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

Quote:

> By now I have the "High Level Assembler Language Reference", which
> certainly answers many questions.  Reading it, I came across DSECT
> and CSECT.

consider CSECT to be the Code SECTion which is assembled into actual
binary blocks for instructions and initialized data.

consider DSECT to be just mapping of Data SECTions, that is you tell
how the elements in a data area are organized, but you cannot
initialise them in any way through the DSECT assembly.

Quote:

> It looks like I can have one unnamed section of each type, and many
> named sections.

Correct, but make it a habit to always name both your CSECTs and your
DSECTs. There is little if anything to gain from unnamed sections.
Besides, unnamed DSECTS are very awkward to use.

Quote:
>  The section contents would not have to be defined
> sequentially, but I could do the following:

> CONE  CSECT
>       ...
> DONE  DSECT
>       ...
> CTWO  CSECT
>       ...
> DTWO  DSECT
>       ...
> CONE  CSECT
>       ...
> DONE  DSECT
>       ...
>       END

Correct. The assembler maintains the location counter individually for
each section and will resume a named section from where it left
previously. You can also use the ORG instruction to reset the location
counter.

Quote:
> The manual says: "The assembler language statements that appear in a
> dummy section are not assembled into object code." So I can not put DC
> statements in dummy sections to initialize variables?

Correct. Within a DSECT a DC statement is assembled exactly as would be
the corresponding DS statement.

Quote:
> If so, a dummy
> sections sounds like the BSS segment in UNIX, the segment containing
> uninitialized data, which is not part of the executable.

But be aware that no address space is set aside just because of a DSECT.
For instance a dynamic workarea requires BOTH a DSECT to describe it
AND a GETMAIN to actually obtain the required address space!

Quote:

> Why would I want to have more than one section of each type, though?
> I could think of two control sections, one for shared code, one for data,

Would hardly be of any advantage, you could as well put them into the
same
CSECT.

Quote:
> but more than one segment for uninitialised data?

That is not the effect of a DSECT as such, see my note above on dynamic
workarea

Quote:
> How can I determine
> the sequence of sections? In the above example, I could think of two ways:
> CONE, CTWO, DONE, DTWO or CONE, DONE, CTWO, DTWO.

The sequence of sections is usually immaterial.

Within a single assembly you very seldom gain anything from having more
than one CSECT. A complete program typically consists of several CSECTs
that have been assembled as separate modules and brought together during
the linkage process.

DSECT on the other hand are useful for many purposes, if you are
familiar
with the Pascal language you will recognise a corresponding feature in
the RECORD definition block.

You frequently use DSECT to describe input and output record structures,
internal table structures and so on. A typical process is to access a
certain structure and make a particular general purpose register
pointing
to this structure. Now by telling the assembler with: USING DONE,R11
that
register R11 (in this case) points to the structure described in
DSECT DONE you can address all elements within this structure by their
logical names without bothering where in your address space the current
instance is located. Without this technique you would frequently have
to move your instance into a predefined local area rather than work
on it directly in a system buffer area (which has some benefits when it
comes to performance).

Quote:
> Any explainations are appreciated.  Just writing my thesis and learning
> for the upcoming final exams, digging into IBM assembler is simply
> mentally refreshing! :)

> Michael
> --
> d? H- s(+)/(-) g! au a- w+ v(---) C++(+++) UL++++S++++?++++ L++ 3 E-


Hope this is of some help

merry Xmas
regards Sven



Sat, 10 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

: By now I have the "High Level Assembler Language Reference", which
: certainly answers many questions.  Reading it, I came across DSECT
: and CSECT.

: It looks like I can have one unnamed section of each type, and many
: named sections.  The section contents would not have to be defined
: sequentially, but I could do the following:

: CONE  CSECT
:       ...
: DONE  DSECT
:       ...
: CTWO  CSECT
:       ...
: DTWO  DSECT
:       ...
: CONE  CSECT
:       ...
: DONE  DSECT
:       ...
:       END

: The manual says: "The assembler language statements that appear in a
: dummy section are not assembled into object code." So I can not put DC
: statements in dummy sections to initialize variables? If so, a dummy
: sections sounds like the BSS segment in UNIX, the segment containing
: uninitialized data, which is not part of the executable.

A DSECT is nothing more than a structure definition.  It does not occupy
storage in the executable.  At run time, the application points a register
to an area of storage and that becomes the "base" for the DSECT in the
program.  A "USING" instruction communicates this information to the
assembler at compile time.

: Why would I want to have more than one section of each type, though?
: I could think of two control sections, one for shared code, one for data,
: but more than one segment for uninitialised data? How can I determine
: the sequence of sections? In the above example, I could think of two ways:
: CONE, CTWO, DONE, DTWO or CONE, DONE, CTWO, DTWO.

I use literally hundreds of DSECTs in a single program.  Each and every
structure you want to define in dynamic storage should have a DSECT.  You
can have multiple CSECTs for a variety of purposes (somewhat beyond the
scope of my limited time to respond).  The order of CSECTs is unimportant.
You use an A-CON or V-CON to get the virtual address of any CSECT in the
executable at run time.

--
| Edward E. Jaffe                | Voice:       (310) 338-0400 x318    |
| Mgr, Research & Development    | Facsimile:   (310) 338-0801         |

| 9841 Airport Blvd, Suite 700   | IBM Mail:    USS24J24 at IBMMAIL    |        
| Los Angeles, CA 90045          | Web page:    www.phnxsoftware.com   |



Sat, 10 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?


Quote:
>By now I have the "High Level Assembler Language Reference", which
>certainly answers many questions.  Reading it, I came across DSECT
>and CSECT.
>It looks like I can have one unnamed section of each type, and many
>named sections.  The section contents would not have to be defined
>sequentially, but I could do the following:
>CONE  CSECT
>      ...
>DONE  DSECT
>      ...
>CTWO  CSECT
>      ...
>DTWO  DSECT
>      ...
>CONE  CSECT
>      ...
>DONE  DSECT
>      ...
>      END
>The manual says: "The assembler language statements that appear in a
>dummy section are not assembled into object code." So I can not put DC
>statements in dummy sections to initialize variables? If so, a dummy
>sections sounds like the BSS segment in UNIX, the segment containing
>uninitialized data, which is not part of the executable.

Actually, you can put DC statements in a DSECT.  It is just that the
defined constant value is ignored.  Whether you would do so is a
matter of what would better document the program.

A DSECT is more like a 'struct' declaration in C.  The assembler not
only fails to initialize it, but the assembler does not assign any
address.  You have to dynamically assign memory to it yourself.  You
can have as many of them as there are different data structures you
want to model.

You never mentioned 'COM', but a COM is about equivalent to the BSS
segment in Unix.  Technically, a COM is a named (or unnamed) common
area, for compatibility with the fortran COMMON.  A memory area is
assigned to it, but the data in that COM section is not initialized.

Quote:
>Why would I want to have more than one section of each type, though?
>I could think of two control sections, one for shared code, one for data,
>but more than one segment for uninitialised data?

Think of a CSECT containing only code and constants as like the unix
text segment.  Think of a CSECT containing changeable data as like
the unix data segment, and think of a COM as like the unix BSS.  You
might want multiple CSECTS for the same reason that you want multiple
folders in a file cabinet.  That is, it is a way of organizing what
is stored there.

Quote:
>                                                  How can I determine
>the sequence of sections? In the above example, I could think of two ways:
>CONE, CTWO, DONE, DTWO or CONE, DONE, CTWO, DTWO.

I think the default order is the order in which the CSECTs are
started.  But you can instruct the link editor to put the CSECTS in
whatever order you like.


Sat, 10 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

CSECTs are to lowest level unit you can pass through the link editor.
A CSECT may be shared between (included into) more than one program.
They may have different attributes such as reentrant or non-reentrant.
They may be placed in particular relative order.  A CSECT may be
aligned on a page boundary if desired.  All this is done with the link
editor.

The assembler also provides supports reentrancy checking on a CSECT
basis.  Code RSECT instead of CSECT and all references to  to it are
reentrant or they are flagged.

There are other special types of sections, such as COM for FORTRAN
common, external dummy sections, pseudo vectors, and {*filter*}a to
support compiler generated code.

Also check out the LOCTR assembler operation; it gives something
similar to sections by allowing sections of code in the listing to be
placed in non sequential address order.  This is most useful for
multi-part tables generated from macros.  The macro expansion can
switch between parts, knowing that each part will be contiguous and in
the same CSECT.



Sat, 10 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

l
On Date: Thu, 18 Dec 97 18:50:40 MET

From: Michael Haardt,

 ..., a dummy sections sounds like the BSS segment in UNIX, the segment
containing uninitialized data, which is not part of the executable.

Why would I want to have more than one section of each type, though? I could
think of two control sections, one for shared code, one for data, but more than
one segment for uninitialised data?
<<

In addition to the excellent points made in other responses, permit me to point
out that the fundamental architecture of the 360/370/390 instruction set
involves a displacement factor encoded in merely twelve bits.  

Using this field of any given instruction permits a RANGE of only 4096 bytes
(displacement 0 through 4095). The reality that the architecture targeted had
smaller chunks than we luxuriate in today.

If the location that you had interest in is further than 4k from the  current
address value in the base register which you intended to use, then you have to
either adjust that value or use a different base address value (from a
different register, or swapped into the particular base register you want to
use, (from memory or from another register)).

The 360 architecture compells the coder or compiler to establish, preserve and
traffic-manage many base addresses. The syntax of the assembler and the
subfields of the instructions manage the displacements, as a nearly transparent
set of programming items.

The exact meaning of a dummy section is that you could code displacements
SYMBOLICALLY, that is with names, and the assembler would do the displacement
math, and the instruction encoding.

Alternative architectures compell the coder or compiler to establish and manage
displacements as more readily apparent data items. That is, there will be
(assembler) source code references to the displacement factors. The 360
instruction set does have some instructions that allow a base register and an
index register (as well as the displacement factor) in some instructions but
not all.

This 4k displacement consideration applies to data references and to code
references to nearby instruction locations. The USING directive, mentioned in
another response, simply informs the assembler that a specific register is to
be assumed (very much like MASM ASSUME directive) relevant for certain
references to code or data, and that the displacement to be automatically
calculated and encoded within instructions are to be figured from that symbolic
start point. Separately, the base value has got to be placed in that register
for the displacements calculated to work. But the coder does not have to
calculate the displacements, nor load them into any register.

The maximum distance from the assumed starting point specified by the USING
directive is, naturally, 4k. (This is called the DOMAIN of the USING
directive). This domain can be shortened by a DROP directive or a contervening
USING directive per the same register. Good programmers put DROPs into the
code.
Regrettably USING directives transgress CSECT boundaries.
This can create serious bugs, but admittedly it proves very useful in
environments like CICS where certain assumptions are intended to apply to many
CSECTs within in a source file.

An interesting effect that the twelve bit displacement has had on legacy
assembly code is that it coerced modularization to a large extent - a
completely unintended result I would think.  The real objective was to allow
displacement imbedding within the instructions (as opposed to discrete
displacement item management in registers), and automated calculation of
displacement by symbolic assemblers.

-------------------

As a brief further point that may interest you, the vast operating environments
of these machines involve genuinely large collections of data groupings that
might be all over the place.  You could not hope to establish a single base
register and know ahead of time what the displacement would be to the area you
needed to work on.  In other words, its not just that the displacement would be
beyond a measily 4k or any other limit.  It is just that the relationship
between any universal base and the actual offsets is non-intrinsic, and
definitely not known to the compilation technology.

The DSECT and CSECT tokens support a syntax that harnesses the base register
plus instruction encoded displacement technology built into the architecture.
Somewhere in there is a compromise that addresses a fundamental trade-off that
you thesis writers could place into more exact terms. In English you might say
that if you do not encode the displacements within the instructions then you
will encode distinct instructions that move the displacements to registers as
separate resource consuming steps.

-----------

If I may, I would like to comment on the suggested use of RSECTs, which was
posted here.

Generally, it would be better to stick with CSECTs and use the assembler option
to check all code for reentrancy.  IMHO, the only application of RSECT would be
if you had uddles of CSECTs that you did not want reentrant and could not use
the assembler option to check them, and thus need to get the same support but
only limitted to the sections so marked (with RSECT).

------

And just for fun, let me ask for help on something.

Do EX instructions tick the RENT option?

Do EX instructions trick the RSECT token?

Generally, is it easier to trick RSECT or the RENT option?

I hope that these questions do not offend the original poster, as this subject
has been known to trigger considerable interaction, and that may be a bit of a
distraction.  But it seems relevant, because one of the tricks I have seen
frequently implemented with EXs is manipulation of displacements and lengths,
which are the exact attibutes parsed from the symbolic expressions in DSECTs
originally under consideration here.

Robert Rayhawk



Thu, 15 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

Quote:

(big snip)
> ------

> And just for fun, let me ask for help on something.

> Do EX instructions tick the RENT option?

> Do EX instructions trick the RSECT token?

> Generally, is it easier to trick RSECT or the RENT option?

> I hope that these questions do not offend the original poster, as this subject
> has been known to trigger considerable interaction, and that may be a bit of a
> distraction.  But it seems relevant, because one of the tricks I have seen
> frequently implemented with EXs is manipulation of displacements and lengths,
> which are the exact attibutes parsed from the symbolic expressions in DSECTs
> originally under consideration here.

> Robert Rayhawk


no,
no,
don't know.

Bill {*filter*}

PS: The following is excerpted from IBM's ESA "Principles of Operations"
(note the 2nd paragraph):

7.5.37 EXECUTE

   EX     R1,D2(X2,B2)     [RX]

    ________ ____ ____ ____ ____________  
   |  '44'  | R1 | X2 | B2 |     D2     |
   |________|____|____|____|____________|
   0         8   12   16   20          31

The single instruction at the second-operand address is modified by the
contents of general register R1, and the resulting instruction, called
the target instruction, is executed.

When the R1 field is not zero, bits 8-15 of the instruction designated
by the second-operand address are ORed with bits 24-31 of general
register R1. The ORing does not change either the contents of general
register R1 or the instruction in storage, and it is effective only for
the interpretation of the instruction to be executed. When the R1 field
is zero, no ORing takes place.

The target instruction may be two, four, or six bytes in length. The
execution and exception handling of the target instruction are exactly
as if the target instruction were obtained in normal sequential
operation, except for the instruction address and the instruction-length
code.

The instruction address of the current PSW is increased by the length of
EXECUTE. This updated address and the instruction-length code of EXECUTE
are used, for example, as part of the link information when the target
instruction is BRANCH AND LINK. When the target instruction is a
successful branching instruction, the instruction address of the current
PSW is replaced by the branch address specified by the target
instruction.

When the target instruction is in turn EXECUTE, an execute exception is
recognized.

The effective address of EXECUTE must be even; otherwise, a
specification exception is recognized. When the target instruction is
two or three halfwords in length but can be executed without fetching
its second or third halfword, it is unpredictable whether access
exceptions are recognized for the unused halfwords. Access exceptions
are not recognized for the second-operand address when the address is
odd.

The second-operand address of EXECUTE is an instruction address rather
than a logical address; thus, the target instruction is fetched from the
primary address space when in the primary-space, secondary-space, or
access-register mode.

Condition Code: The code may be set by the target instruction.

Program Exceptions:

     Access (fetch, target instruction)
     Execute
     Specification

Programming Notes:

     1. An example of the use of the EXECUTE instruction is given in
Appendix A, "Number Representation and Instruction-Use Examples."

     2. The ORing of eight bits from the general register with the
designated instruction permits the indirect specification of the length,
index, mask, immediate-data, register, or extended-op-code field.

     3. The fetching of the target instruction is considered to be an
instruction fetch for purposes of program-event recording and for
purposes of reporting access exceptions.

     4. An access or specification exception may be caused by EXECUTE or
by the target instruction.

     5. When an interruptible instruction is made the target of EXECUTE,
the program normally should not designate any register updated by the
interruptible instruction as the R1, X2, or B2 register for EXECUTE.
Otherwise, on resumption of execution after an interruption, or if the
instruction is refetched without an interruption, the updated values of
these registers will be used in the execution of EXECUTE. Similarly, the
program should normally not let the destination field in storage of an
interruptible instruction include the location of EXECUTE, since the new
contents of the location may be interpreted when resuming execution.

       ? Copyright IBM Corp. 1990, 1991, 1993, 1994, 1996



Thu, 15 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

Quote:

> By now I have the "High Level Assembler Language Reference", which
> certainly answers many questions.  Reading it, I came across DSECT
> and CSECT.

Unmentioned so far is that the length of a DSECT can be captured at
assembly time as a Q-type constant.

        TTT     DSECT  
        FIELD1  DS      A
        FIELD2  DS      CL8
        ...
        DSPTTT  DC      Q(TTT)

In an initialization module you can capture the total length of all
Q-type contants

INIT    CSECT  
        ...
LENALL  COM

At link time, LENALL will be assigned the total length of a Q-type
constants. In this initialization module you can get and initialize
storage of all such dsects. The address of the common storage needs to
be passed to all modules with the DSECTs. The Q-type constant is set by
the linker to a displacement needed to address the particular dsect.
Take the passed address, add the displacement, use result to address the
data described by the DSECT.

I used that once in a multiple csect program (400+ CSECTs).  I could add
and change the DSECT definitions with storage allocation and
initialization to zero happening automatically. The result was a
reentrant way to have CSECT unique storage.

john alvord



Fri, 16 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

I think where you have LENALL COM you really
meant LENALL CXD right?

and yes, Q-Cons (pseudo registers) are quite handy.
I wish there was a way to group them better though.
I would really have liked multiple pools.. oh well.


Quote:


> > By now I have the "High Level Assembler Language Reference", which
> > certainly answers many questions.  Reading it, I came across DSECT
> > and CSECT.

> Unmentioned so far is that the length of a DSECT can be captured at
> assembly time as a Q-type constant.

>         TTT     DSECT  
>         FIELD1  DS      A
>         FIELD2  DS      CL8
>         ...
>         DSPTTT  DC      Q(TTT)

> In an initialization module you can capture the total length of all
> Q-type contants

> INIT    CSECT  
>         ...
> LENALL  COM

> At link time, LENALL will be assigned the total length of a Q-type
> constants. In this initialization module you can get and initialize
> storage of all such dsects. The address of the common storage needs to
> be passed to all modules with the DSECTs. The Q-type constant is set by
> the linker to a displacement needed to address the particular dsect.
> Take the passed address, add the displacement, use result to address the
> data described by the DSECT.

> I used that once in a multiple csect program (400+ CSECTs).  I could add
> and change the DSECT definitions with storage allocation and
> initialization to zero happening automatically. The result was a
> reentrant way to have CSECT unique storage.

> john alvord



Fri, 16 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

In a message dated 12-29-97, John G. Alvord said to All about Re: Csect And
Dsect Seman

Quote:

> By now I have the "High Level Assembler Language Reference", which
> certainly answers many questions.  Reading it, I came across DSECT
> and CSECT.

JA>Unmentioned so far is that the length of a DSECT can be captured at
JA>assembly time as a Q-type constant.

JA> TTT DSECT
JA> FIELD1 DS A
JA> FIELD2 DS CL8
JA> ...
JA> DSPTTT DC Q(TTT)

JA>In an initialization module you can capture the total length of all
JA>Q-type contants

JA>INIT CSECT
JA> ...
JA>LENALL COM

Surely you mean:

 LENALL  CXD

JA>At link time, LENALL will be assigned the total length of a Q-type
JA>constants. In this initialization module you can get and initialize
JA>storage of all such dsects. The address of the common storage needs to
JA>be passed to all modules with the DSECTs. The Q-type constant is set by
JA>the linker to a displacement needed to address the particular dsect.
JA>Take the passed address, add the displacement, use result to address the
JA>data described by the DSECT.

JA>I used that once in a multiple csect program (400+ CSECTs).  I could add
JA>and change the DSECT definitions with storage allocation and
JA>initialization to zero happening automatically. The result was a
JA>reentrant way to have CSECT unique storage.

Indeed, we PL/I bigots have been using external dummy sections in our
assembler routines for years. The PL/I run-time even does the GETMAIN. You
just have to know what value it places there to indicate uninitialized
storage. [Hint: not zero.]

Regards

Dave
<Team PL/I>
___
 * MR/2 2.25 #353 * Be a {*filter*}; wear boxer shorts.
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Fri, 16 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

In a message dated 12-28-97, Rkrayhawk said to All about Re: Csect And Dsect
Seman

[mega snip]
R>And just for fun, let me ask for help on something.

R>Do EX instructions tick the RENT option?

EX does not modify the instruction it targets, so reentrability is not
compromised.

R>Do EX instructions trick the RSECT token?

Same again.

R>Generally, is it easier to trick RSECT or the RENT option?

No difference. RENT in the assembler options simply says use the
reentrability checking logic on all CSECTs, regardless of them being marked
RSECT or CSECT.

You can trick either by using a specific base-displacement address in your
instruction to modify the code bytes. The S0C4 abend at run-time, if the
code gets into SP 252, will be just as fatal either way.

Regards

Dave
<Team PL/I>
___
 * MR/2 2.25 #353 * If ignorance is bliss, I'm in hog heaven!!
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Fri, 16 Jun 2000 03:00:00 GMT  
 CSECT and DSECT semantics?

Quote:

> Unmentioned so far is that the length of a DSECT can be captured at
> assembly time as a Q-type constant.

Note that the term "external dummy" used in the assembler documentation
is the same as the term "pseudoregister" used elsewhere.

Quote:
> In an initialization module you can capture the total length of all
> Q-type contants

> INIT    CSECT
>         ...
> LENALL  COM

I believe that you mean:

  LENALL  CXD

--

        Shmuel (Seymour J.) Metz
        Senior Software SE
        EDS

The values in From are for the benefit of spammers:
reply to domain exse01.exch.eds.com, user seymour.metz.



Fri, 16 Jun 2000 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Initializing Base Register(s) in Multi-entry-point CSECT

2. pl/I CSECT

3. TSO Rexx & load module CSECT info

4. IMS QLOGMSGP DSECT

5. Converting DSECTs to COBOL data definitons

6. Linkage stack DSECTs

7. DSECT->C?

8. DSECT for MVS PDS vol def block?

9. getting DSECT entry address

10. Two questions regarding J's syntax and semantics

11. Tgen semantics?

12. sed: s flag combination semantics?

 

 
Powered by phpBB® Forum Software