Baseless vs Based
Bodoh John Robert
I am new to this list so excuse me if this has been asked before.
When a macro receives an ordinary symbol as a parameter it may need to
reference the symbol (get the address of the storage location
represented by the symbol). If the symbol is within the current CSECT
and the program is using baseless coding, a relative addressing op code
must be used to get the address of the storage referenced by the symbol.
Otherwise, a base/displacement op code must be used.
My question is how is the macro to determine which op codes to use? The
assembler knows where the symbol is but I can't find any way for the
macro to make the determination. Does anybody know how to do this?
John
Paul Gilmartin
which solve a different problem. I don't believe any such
solution exists.
-- gil
Tony Harminc
> I am new to this list so excuse me if this has been asked before.
Welcome.
> When a macro receives an ordinary symbol as a parameter it may need to
> reference the symbol (get the address of the storage location
> represented by the symbol). If the symbol is within the current CSECT
> and the program is using baseless coding, a relative addressing op code
> must be used to get the address of the storage referenced by the symbol.
> Otherwise, a base/displacement op code must be used.
What are the circumstances that would *require* a base/displacement
instruction to be used? Of course if you have to run on sufficiently
old hardware, then you can't use LAY and such. But then, unless you
are targetting multiple and far apart generations of hardware, you
don't need to ask the question in the first place.
> My question is how is the macro to determine which op codes to use? The
> assembler knows where the symbol is but I can't find any way for the
> macro to make the determination. Does anybody know how to do this?
If your macro really has to know, then I think you'll have to
implement a bit of macro infrastructure that allows you to set the
mode to be used, perhaps in your entry macro, and of course stores it
in a suitable GBLB or the like. There is no formal way in which you
tell the assembler that your program operates in based or baseless
mode, though inferences can be drawn. One could stretch this rather a
long way, but it's getting into the realm of idle speculation... For
instance the assembler could somehow let you know if there is an
active USING that covers any part of CSECT space, and you could base
your decision on that. But that's full of holes, I'm sure.
Tony H.
John Ehrman
> On 17 December 2010 15:22, Bodoh John Robert <John.Rob...@irs.gov>
wrote:
> > When a macro receives an ordinary symbol as a parameter it may need to
> > reference the symbol (get the address of the storage location
> > represented by the symbol). If the symbol is within the current CSECT
> > and the program is using baseless coding, a relative addressing op code
> > must be used to get the address of the storage referenced by the
symbol.
> > Otherwise, a base/displacement op code must be used.
> If your macro really has to know, then I think you'll have to
> implement a bit of macro infrastructure that allows you to set the
> mode to be used, perhaps in your entry macro, and of course stores it
> in a suitable GBLB or the like. There is no formal way in which you
> tell the assembler that your program operates in based or baseless
> mode, though inferences can be drawn. One could stretch this rather a
> long way, but it's getting into the realm of idle speculation... For
> instance the assembler could somehow let you know if there is an
> active USING that covers any part of CSECT space, and you could base
> your decision on that. But that's full of holes, I'm sure.
Unfortunately, there's no general way HLASM can know which base registers
cover which parts of the program until after the end of the first pass --
which is when macro expansion occurs.
If it's really important to you, your best bet is to write your own
"MyUSING" and MyDROP" macros that capture useful information and then issue
the normal USING and DROP instructions.
Martin Trübner
Here is my attempt: there is no point in determining the coverage (or
non-coverage) - use baseless approach all the time and you are safe.
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Edward Jaffe
> While Tony gave a perfect answer-....it might be useless for a newbee.
>
> Here is my attempt: there is no point in determining the coverage (or
> non-coverage) - use baseless approach all the time and you are safe.
I believe the concern is that fields in a control block mapped by a DSECT will
sometimes be referenced with different instructions than fields in the CSECT.
For example, you can't use LARL to get the address of a field in a control block
mapped by a DSECT. That instruction is used only to point to fields in your CSECT.
We have an inner macro that is used by every macro-based service we author. It
processes macro parameters. It allows them to be passed as a name or as a
sublist consisting of a name and a technique. If technique is not present, the
macro makes assumptions about how to handle the parameter (based on syntax,
&SYSALVL,etc.) and is almost always right. If technique is present, it
explicitly specifies the instruction that should be used to access the
parameter. For example KWD=(NAME,LG) says to use LOAD GRANDE when accessing the
field called NAME.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Martin Trübner
While I understand your point (missed you anyway in this thread ;-) ) I
do not see the word DSECT mentioned in the OP-s stmt.
John, was your question as simple as I assume or was it as
sophisticated as Tony and Ed answered (with solutions from John E. and
Paul)?
Don Higgins
compiler which installs in z390\zcobol directory as part of z390 install.
The procedure division code generated uses baseless code for all
branching. For instructions that require base and displacement, a set of
lower level code generation macros keep track of which data access base
reqisters have been set to what work-storage offset, and if a new data
access base register is required the oldest is canceled and a new base is
set via LARL. This example is a special case in that the zcobol compiler
uses macros to define all the working storage data fields including their
relative offset which is then available to base macros. However, it may
still server as a useful example.
All the general COBOL macros are in z390\zcobol and all the z390 HLASM
compatible code generation macros are in z390\zcobol\z390. All the code
is open source. For downloads and more information visit www.z390.org and
www.zcobol.org.
Don Higgins
d...@higgins.net
Binyamin Dissen
wrote:
:>While Tony gave a perfect answer-....it might be useless for a newbee.
:>Here is my attempt: there is no point in determining the coverage (or
:>non-coverage) - use baseless approach all the time and you are safe.
Unless the field has an odd address. Or is not in the CSECT.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
Peter Relson
with the very practical "code-reg-less". You still for most programs are
expected to have a base for your static data.
Typically, parameters passed to macros within the "code space" would be
static data (I know, not always).
Unless specified otherwise, references by the macro will use LA (or LAE).
And it is up to you to set things up and specify things so that that LA(E)
works.
Peter Relson
z/OS Core Technology Design
Bodoh John Robert
What I am doing is creating macros that are used by any other application. I was hoping to avoid having the user of these macros have to specify the technique needed to address symbols. That sounds clutzy and it nowhere else in the assembler do I have to tell the assembler that kind of detail.
At the time the macro is being used, the macro does not know whether baseless coding is being used or not and whether or not a symbol is within the current CSECT or not. If the symbol is within the current CSECT and code invoking the macro is using baseless coding, the macro MUST use baseless instructions. As I understand it, the symbol is within the current CSECT, baseless instructions can be used whether or not the invoking code is using baseless or not. Otherwise, based instructions MUST be used.
I am surprised this not considered a hole in the assembler and is not more pervasive than just for me and my simple case. Do not other macros have the same problem?
John
Steve Comstock
> Ed, Martin, John, Tony, et al,
>
> What I am doing is creating macros that are used by any other
> application. I was hoping to avoid having the user of these
> macros have to specify the technique needed to address symbols.
> That sounds clutzy and it nowhere else in the assembler do I
> have to tell the assembler that kind of detail.
>
> At the time the macro is being used, the macro does not know
> whether baseless coding is being used or not and whether or not
> a symbol is within the current CSECT or not. If the symbol is
> within the current CSECT and code invoking the macro is using
> baseless coding, the macro MUST use baseless instructions.
> AsI understand it, the symbol is within the current CSECT,
> baseless instructions can be used whether or not the invoking
> code is using baseless or not. Otherwise, based instructions
> MUST be used.
I'm at a loss here. First, you reference symbols for one
of two reasons: 1) a target for a branch or execute instruction,
and 2) a location for an operand.
In case 1), you can always use the so-called baseless instructions;
in case 2), it depends on the operation you need to perform.
For example, loading an address of a location can always be done
by LARL - unless the item is at an odd address! If you need to
work with packed decimal data, you must use the xP instructions,
all of which require base / displacement.
What instructions are you thinking of where you would choose
between baseless and based?
>
> I am surprised this not considered a hole in the assembler
> and is not more pervasive than just for me and my simple case.
> Do not other macros have the same problem?
>
> John
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Martin Tr�bner
> Sent: Saturday, December 18, 2010 3:55 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Baseless vs Based
>
> Ed,
>
> While I understand your point (missed you anyway in this thread ;-) ) I
> do not see the word DSECT mentioned in the OP-s stmt.
>
> John, was your question as simple as I assume or was it as
> sophisticated as Tony and Ed answered (with solutions from John E. and
> Paul)?
>
> --
> Martin
>
> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> more at http://www.picapcpu.de
>
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
Steve Comstock
I had done that, but I got an out of office reply
sent to me.]
On 12/20/2010 7:05 AM, Bodoh John Robert wrote:
> Ed, Martin, John, Tony, et al,
>
> What I am doing is creating macros that are used by any other
> application. I was hoping to avoid having the user of these
> macros have to specify the technique needed to address symbols.
> That sounds clutzy and it nowhere else in the assembler do I
> have to tell the assembler that kind of detail.
>
> At the time the macro is being used, the macro does not know
> whether baseless coding is being used or not and whether or not
> a symbol is within the current CSECT or not. If the symbol is
> within the current CSECT and code invoking the macro is using
> baseless coding, the macro MUST use baseless instructions.
> As I understand it, the symbol is within the current CSECT,
> baseless instructions can be used whether or not the invoking
> code is using baseless or not. Otherwise, based instructions
> MUST be used.
I'm at a loss here. First, you reference symbols for one
of two reasons: 1) a target for a branch or execute instruction,
and 2) a location for an operand.
In case 1), you can always use the so-called baseless instructions;
in case 2), it depends on the operation you need to perform.
For example, loading an address of a location can always be done
by LARL - unless the item is at an odd address! If you need to
work with packed decimal data, you must use the xP instructions,
all of which require base / displacement.
What instructions are you thinking of where you would choose
between baseless and based?
>
> I am surprised this not considered a hole in the assembler
> and is not more pervasive than just for me and my simple case.
> Do not other macros have the same problem?
>
> John
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Martin Tr�bner
> Sent: Saturday, December 18, 2010 3:55 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Baseless vs Based
>
> Ed,
>
> While I understand your point (missed you anyway in this thread ;-) ) I
> do not see the word DSECT mentioned in the OP-s stmt.
>
> John, was your question as simple as I assume or was it as
> sophisticated as Tony and Ed answered (with solutions from John E. and
> Paul)?
>
> --
> Martin
>
> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> more at http://www.picapcpu.de
>
Bodoh John Robert
As I understand LARL, the current PSW is used as the base to address the symbol. If the symbol is in a DSECT, the LARL instruction should generate an assembler error.
Martin Trübner
it is Steve not me-
and Steve tries to understand something in Eds posting (he is
making stmts for a synthetical situation to find out what Ed means-
he is certainly aware of the features/restrcitions of the various
instructions)
.... never mind
--
Martin
Steve Comstock
> Martin,
>
> As I understand LARL, the current PSW is used as the
> base to address the symbol. If the symbol is in a
> DSECT, the LARL instruction should generate an assembler
> error.
>
> John
[I am not Martin, but it is my comment you are responding to]
Ah! I see. Then perhaps what you are _really_ after has
nothing really to do with baseless vs. based. What you are
really after is knowing if a data item is located in a DSECT
or in the CSECT being run. Is that right?
If an item is in a DSECT, it is, of necessity, based off
some register. Then, for example, you would need, say,
LA instead of LARL. But you must realize that so-called
baseless programming usually needs a base register for
data items.
I come back to my previous question: what instructions are
you thinking of where you would need to choose between
based and baseless?
From the perspective of most software developers, it is
more critical to be sensitive to the underlying hardware:
which instructions are available on the machine I am
running? For those cases you either run code with lots of
checking for the host machine or you only use instructions
supported by all models for your customer base.
Paul Gilmartin
> Ed, Martin, John, Tony, et al,
>
> What I am doing is creating macros that are used by any other application. I was hoping to avoid having the user of these macros have to specify the technique needed to address symbols. That sounds clutzy and it nowhere else in the assembler do I have to tell the assembler that kind of detail.
> ...
> I am surprised this not considered a hole in the assembler and is not more pervasive than just for me and my simple case. Do not other macros have the same problem?
On Dec 18, 2010, at 15:24, Peter Relson wrote:
>
>
> Unless specified otherwise, references by the macro will use LA (or LAE).
> And it is up to you to set things up and specify things so that that LA(E)
> works.
>
I suppose an IBM employee can easily be unaware that the "you" coding
the macro may not be the same person, or even from the same organization
as the "you" invoking it.
On Dec 17, 2010, at 15:18, John Ehrman wrote:
>
>
> Unfortunately, there's no general way HLASM can know which base registers
> cover which parts of the program until after the end of the first pass --
> which is when macro expansion occurs.
>
I sympathize.
> If it's really important to you, your best bet is to write your own
> "MyUSING" and MyDROP" macros that capture useful information and then issue
> the normal USING and DROP instructions.
>
That may be impractical, even impossible, and may not meet the OP's
need.
Some assemblers have instruction mnemonics that generate different
opcodes as required or permitted by context. This is particularly
difficult when the instruction lengths differ and the decision can
not be made in the first pass. And I recall a wise colleague's
railing decades ago at an Intel assembler which second-guessed him
on an opcode to use in a timing-sensitive area.
Sic transit IHBINNRA. R.I.P. The sophistication of the zSeries
hardware outpaces the ability of the assembler to exploit it.
Is any reader here unconstrained by confidentiality so as to be
able to describe how PL/X deals with such needs? Or perhaps an
erudite reader can advocate a macro approach.
-- gil
Bodoh John Robert
Some of my macros generate a CALL or LINK to a subroutine and pass a parameter list consisting, in part, of the address of storage locations specified through arguments on the macro. In generating the storage address (reentrant code), a LA or LAE(based), or LARL (baseless) would be used.
You're right about calling CSECT or DESCT based. I was referring to the code I needed to generate rather than the location of the symbol.
I guess what irks me is that the macro has no way of knowing what to generate. There is a hole in the assemble architecture. For example, before baseless, when I reference a symbol, the assembler knows how to resolve the storage location. It would lookup the symbol, determine the base register for the storage and the displacement, and generate the machine code.
David Bond
instructions. So if the macro is branching, use the relative instructions.
And macros generally assume that base registers and USINGs will be
established to access any data.
Until recently there were no relative data access instructions. But even if
the program will only run on a machine with those instructions, there is
little reason to use them. If modifiable data fields are separated from
instructions and constants, then a base register will be needed for them
anyway. And the immediate instructions reduce the need for constant data
fields.
If you look at what the compilers generally do, they establish a base
register for the constants and one or more base registers as needed for the
modifiable data areas. This same scheme works well for the assembler
programs that I write and I have not run into the situation that you describe.
If your macros need to be generate different instructions depending on if
certain instructions are available, look at what many of the z/OS macros do
when SYSSTATE ARCHLVL is set. Or macros can check if the OPTABLE contains
specific instructions by testing the O' attribute.
David Bond
Binyamin Dissen
<John.Rob...@irs.gov> wrote:
:>Some of my macros generate a CALL or LINK to a subroutine and pass a parameter list consisting, in part, of the address of storage locations specified through arguments on the macro. In generating the storage address (reentrant code), a LA or LAE(based), or LARL (baseless) would be used.
:>You're right about calling CSECT or DESCT based. I was referring to the code I needed to generate rather than the location of the symbol.
:>I guess what irks me is that the macro has no way of knowing what to generate. There is a hole in the assemble architecture. For example, before baseless, when I reference a symbol, the assembler knows how to resolve the storage location. It would lookup the symbol, determine the base register for the storage and the displacement, and generate the machine code.
On the first pass the assembler does not know that it can address the symbol.
But as the instruction uses the same amount of space anyway, it does not
matter. At a later pass the assembler figures out if it has addressability and
then either reports and error or completes the instruction.
Bodoh John Robert
I cannot assume anything, except that the CPU on which the program is
running supports baseless instructions. So, the phrase "in general"
doesn't apply.
The fact is, a program could specify a symbol on a macro and the symbol
could reference storage anywhere. It could be a based symbol or a
baseless symbol addressable by relative addressing instructions.
Relative addressing is NOT restricted to branching. LARL is not a
branch.
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of David Bond
Sent: Monday, December 20, 2010 10:33 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Bodoh John Robert
What about lookahead? Does that not set attributes based on the
characteristics of symbols not already defined? Why not an attribute
that indicates whether not a symbol is addressable by relative
addressing instructions?
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Binyamin Dissen
Sent: Monday, December 20, 2010 10:39 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
David Bond
Use base registers for data and relative addressing for instructions.
Since most data access instructions require a base register, most data areas
will have a base register and USING established before a macro is invoked.
Yes, it is possible to use LARL to set up a temporary base register before
every data access instruction. e.g.
LARL R14,TARGET
LARL R15,SOURCE
MVC 0(L'TARGET,R14),0(R15)
But it is impractical and pipeline hostile to do so.
A good use for LARL is to set up the base register for the constants - and
maybe the modifiable data area if the program is not reentrant. LARL can
even be used to get the address of other control sections. But I think you
are trying to use LARL for everything.
David Bond
Bodoh John Robert
No, I'm not trying to use LARL for everything. I just want to use it
for the case when a code developer specifies a symbol that references a
storage area that can only be referenced by using LARL. That is, no
base register. Some of my macro usage would be for a particular symbol
to "usually" be a constant, but would not have to be a constant. For
example, I have a macro that generated the parameter list to IEANTCR.
The LEVEL that is passed is usually a constant, but it wouldn't have to
be. If it's a constant within the CSECT and the CSECT does not have a
base register, LARL would be the only way to obtain the address of the
LEVEL. In all other cases, a LA would work.
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of David Bond
Sent: Monday, December 20, 2010 11:03 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
David Bond
fields (including constants) need to be addressed via base register.
Setting it up via LARL does not change that fact.
The convention for macros usually is: If a symbol is supplied then it can be
addressed via a pre-established base register and USING. Otherwise the
address can be passed in a register, using the (reg) notation. If the
module has not set up a base register and USING for a symbol prior to
calling the macro then the module is in error.
David Bond
On Mon, 20 Dec 2010 11:16:59 -0500, Bodoh John Robert wrote:
>David,
>
>No, I'm not trying to use LARL for everything. I just want to use it
>for the case when a code developer specifies a symbol that references a
>storage area that can only be referenced by using LARL. That is, no
>base register. Some of my macro usage would be for a particular symbol
>to "usually" be a constant, but would not have to be a constant. For
>example, I have a macro that generated the parameter list to IEANTCR.
>The LEVEL that is passed is usually a constant, but it wouldn't have to
>be. If it's a constant within the CSECT and the CSECT does not have a
>base register, LARL would be the only way to obtain the address of the
>LEVEL. In all other cases, a LA would work.
>
>John
>
>-----Original Message-----
>
Paul Gilmartin
>
> What about lookahead? Does that not set attributes based on the
> characteristics of symbols not already defined? Why not an attribute
> that indicates whether not a symbol is addressable by relative
> addressing instructions?
>
symbol is defined textually prior to its application, yet HLASM
by its rules can not resolve the definitions. This doesn't
even involve base-displacement resolution.
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Binyamin Dissen
> Sent: Monday, December 20, 2010 10:39 AM
>
> On the first pass the assembler does not know that it can address the
> symbol.
> But as the instruction uses the same amount of space anyway, it does not
> matter. At a later pass the assembler figures out if it has
> addressability and
> then either reports and error or completes the instruction.
>
"[S]ame amount of space" is crucial. LA is 4 bytes and LALR is 6.
I could imagine a pseudoinstruction mnemonic which on Pass 1 reserves
6 bytes and on Pass 2 generates either LALR or a 2-byte NOP followed
by LA; whichever works. As John E. states, this determination can
not be made by a macro (but will John G. agree?). Would macro
authors welcome such a facility or shun it?
On Dec 20, 2010, at 08:32, David Bond wrote:
>
> Until recently there were no relative data access instructions. But even if
> the program will only run on a machine with those instructions, there is
> little reason to use them. If modifiable data fields are separated from
> instructions and constants, then a base register will be needed for them
> anyway. And the immediate instructions reduce the need for constant data
> fields.
>
Are modifiable data fields separated for pipeline performance? How?
In separate CSECTs, or by "DS 4096C"? If in the same CSECT, the reach
of relative addressing is sufficient for a wide range of programs.
-- gil
Bodoh John Robert
I have never heard of that "convention". I don't understand your
statement that data fields need to be addressed via a base register.
Since I can use LARL to address data fields within my CSECT, I don't
require a base register. It maybe poor coding technique to do a LARL
every time I reference my storage, but it is not an error and it would
work. For macros I use, the usual usage would be for some symbols to
specify constants and would the constant would usually only be
referenced by the macro. If there are only a few constants in a program
and they are seldom needed, why not use baseless coding and free up
another register?
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of David Bond
Sent: Monday, December 20, 2010 11:30 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Tom Marchant
>No, I'm not trying to use LARL for everything. I just want to use it
>for the case when a code developer specifies a symbol that references a
>storage area that can only be referenced by using LARL. That is, no
>base register. Some of my macro usage would be for a particular symbol
>to "usually" be a constant, but would not have to be a constant. For
>example, I have a macro that generated the parameter list to IEANTCR.
>The LEVEL that is passed is usually a constant, but it wouldn't have to
>be. If it's a constant within the CSECT and the CSECT does not have a
>base register, LARL would be the only way to obtain the address of the
>LEVEL. In all other cases, a LA would work.
I share John Gilmore's dislike for referring to code as "baseless"
primarily because it is not accurate. As many others have pointed
out, base registers are required for many instructions. To attempt
to write code without the use of any base registers is folly.
If you have constants in your program, you will have to have a base
register in order to use them. Your insistence that LARL is the only
way to obtain the address of a constant in your CSECT is just not
accurate. Furthermore, LARL can not always be used to obtain the
address of a constant within your CSECT. Specifically, if the
address is not on a halfword boundary, you can not use LARL.
The value of relative addressing is primarily to avoid using base
registers for code. That is, for branches. As a result of
eliminating the base register for code, more registers are available
for other purposes, including base registers for data.
It sounds to me as if you are overly concerned with the erroneous
term, "baseless". It is often used to describe code that does not
require a base register in order to branch. The use of that word
to describe the programming technique has led to considerable
misunderstanding.
--
Tom Marchant
David Bond
>Are modifiable data fields separated for pipeline performance? How?
>In separate CSECTs, or by "DS 4096C"? If in the same CSECT, the reach
>of relative addressing is sufficient for a wide range of programs.
A cache line (256 bytes) is sufficient padding. Or generate alignment using:
ORG *,256
Or if the section alignment is 256 or greater:
ORG (*+255-section)/256*256+section
My preference is to write reentrant modules. The separation is automatic.
David Bond
Paul Gilmartin
> Except for some of the most recent additions to the architecture, data
> fields (including constants) need to be addressed via base register.
> Setting it up via LARL does not change that fact.
>
> The convention for macros usually is: If a symbol is supplied then it can be
> addressed via a pre-established base register and USING. Otherwise the
> address can be passed in a register, using the (reg) notation. If the
> module has not set up a base register and USING for a symbol prior to
> calling the macro then the module is in error.
>
You're merely restating a restriction arising from outmoded
hardware design from which the OP is trying to liberate himself.
In days of yore, there was only one way to access data referenced
by a symbol. Now there are two (three, at least, if you add
immediate.) The macro processor is limited in its ability to
exploit this new facility.
I suppose that if the OP has a register available, perhaps R15
to be subsequently to return status, he could:
PUSH USING
BALR R15,0
USING *,R15
... stuff ...
POP USING
This supports only a restricted relative displacement range, and
invites overlapping USING warnings.
> On Mon, 20 Dec 2010 11:16:59 -0500, Bodoh John Robert wrote:
>>
>> No, I'm not trying to use LARL for everything. I just want to use it
>> for the case when a code developer specifies a symbol that references a
>> storage area that can only be referenced by using LARL. That is, no
>> base register. Some of my macro usage would be for a particular symbol
>> to "usually" be a constant, but would not have to be a constant. For
>> example, I have a macro that generated the parameter list to IEANTCR.
>> The LEVEL that is passed is usually a constant, but it wouldn't have to
>> be. If it's a constant within the CSECT and the CSECT does not have a
>> base register, LARL would be the only way to obtain the address of the
>> LEVEL. In all other cases, a LA would work.
>>
Even more generally, there are numerous ways to place a value in
a storage location or a register, such as "LH; ST", "LHI; ST";
"XC; MVI", ... Compilers regularly make optimized choices among
such techniques. But IBM's support for customers' using available
compilers for systems programming is meager and IBM's favorite
compiler is unavailable to customers. (NDA? Anyone who knows
wouldn't be allowed to tell.)
-- gil
Edward Jaffe
> I am surprised this not considered a hole in the assembler and is not more pervasive than just for me and my simple case. Do not other macros have the same problem?
ROT: Unless you're talking about a branch location, you should not be using
relative instructions. All literals and other data should be covered by a base
register, no matter where they appear.
Bodoh John Robert
It sounds like you're agreeing with me: There is a limitation in
macros.
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, December 20, 2010 11:54 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
John P. Baker
I have to disagree.
What is the problem with using LARL to reference static data significantly
offset within a large CSECT/RSECT?
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Edward Jaffe
Sent: Monday, December 20, 2010 11:54 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
David Bond
>I have never heard of that "convention".
Almost all of the z/OS macros use this convention.
>I don't understand your
>statement that data fields need to be addressed via a base register.
>Since I can use LARL to address data fields within my CSECT, I don't
>require a base register. It maybe poor coding technique to do a LARL
>every time I reference my storage, but it is not an error and it would
>work.
Consider:
LARL R14,TARGET
L R0,0(,R14)
R14 is the base register. Just because it was not defined in a USING
statement does not change that fact.
And I do consider it poor coding to use LARL before every instruction to set
up a local base register. It kills pipeline performance. The referencing
instruction will be stalled for several cycles waiting for the result of the
LARL to be converted into a usable address. This is called Address
Generation Interlock.
>For macros I use, the usual usage would be for some symbols to
>specify constants and would the constant would usually only be
>referenced by the macro. If there are only a few constants in a program
>and they are seldom needed, why not use baseless coding and free up
>another register?
Because if you don't, you will run into these problems. But if you really
want to use LARL then use it right before the macro call, passing the
register instead of the symbol.
David Bond
Bodoh John Robert
Where does it state that? I have been reading the POP and I can find
nowhere where it states that relative addressing instructions are to be
used for branching only.
John
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Edward Jaffe
Sent: Monday, December 20, 2010 11:54 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Paul Gilmartin
>
> It sounds like you're agreeing with me: There is a limitation in
> macros.
>
positive weight in this list.
-- gil
Tom Marchant
>Are modifiable data fields separated for pipeline performance? How?
>In separate CSECTs, or by "DS 4096C"? If in the same CSECT, the reach
>of relative addressing is sufficient for a wide range of programs.
I think you are confusing pipeline performance with cache performance.
We want to avoid Address Generation Interlock to avoid pipeline stalls.
We also want to avoid having data (especially modifiable data) sharing
a cache line with the code that will reference it to avoid cache
performance penalties.
--
Tom Marchant
Chris Craddock
If I was writing enormous great gobs of code that needed more than one base register, the first thing I would do is slap myself silly. Then I would rearrange that code into manageable chunks so that problem went away. My personal rule has always been 4KB or less per function. Sure I could do more (and in exceptionally rare cases, I will) but why would I want to? It is a lot easier to maintain intellectual control over small well structured hunks of code than those gigantic single CSECT monsters with half a dozen on the fly subroutine linkage conventions smeared haphazardly across five thousand lines of code. Yeah you know the ones I'm talking about. Literally nobody has ever complained about having to maintain my code - just ask the folks that still do.
Now if I was a compiler writer, I might get a lot more excited about long displacement and relative instructions. To begin with there are no "legacy" assembly macros to deal with in generated code and pretty much all compiler writers tend to burn a base register for addressing constants anyway. After the first blush of curiosity wears off, nobody ever looks at the generated code anyway and they certainly don't have to maintain it, so all in all it is a pretty decent deal for compiler writers and (btw) that's who it was done for.
My bottom line is: don't get carried away with this stuff. If you're an assembly language programmer you don't need it and it is only going to end up biting you in the ass if you pursue unnatural acts just to avoid having a base register for code.
CC
David Bond
base-displacement. Examples are L, MVC, AP, MVCLE. There are a few very
new instructions that can access data via a relative address. An example is
LLHRL. Using LARL just before MVC to set up a temporary base does not turn
the MVC into a relative addressing instruction.
So almost every modern program sets up a base register for the constants and
maybe one or more for the modifiable data areas and uses relative
instructions for branches. LARL is a good instruction to use to set up the
base register for the constants or modifiable fields within the same
section. LARL can also be use to get the address of other sections that are
linked into the same module. LARL cannot be used for arbitrary data access
because it does not work for odd addresses. Instructions are always at even
addresses so I think you can conclude that LARL is designed to be more
useful for addressing instructions rather than data.
David
On Mon, 20 Dec 2010 12:02:22 -0500, Bodoh John Robert wrote:
>Edward,
>
>Where does it state that? I have been reading the POP and I can find
>nowhere where it states that relative addressing instructions are to be
>used for branching only.
>
>John
>
>-----Original Message-----
>
John P. Baker
I have a software package consisting of roughly 250,000 lines of assembler
code. It would be 2-3 times that size if I had not gone to considerable
effort to use relative addressing and immediate operands.
You apparently feel that baseless code is unnecessary. My real world
experience tells me a wholly different story.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Chris Craddock
Sent: Monday, December 20, 2010 12:38 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Savor, Tom
>I have a software package consisting of roughly 250,000 lines of assembler code. It would be 2-3 times that >size if I had not gone to considerable effort to use relative addressing and immediate operands.
>You apparently feel that baseless code is unnecessary. My real world experience tells me a wholly different >story.
>John P. Baker
John,
I have to side with Chris on this. I have been coding Assembler programs for many years (Application) and don't see a "need" for Baseless code in my World. Maybe it's because I would have to learn many different instructions that I don't understand today, but I haven't seen the need so far.
So let me ask the dumb question, Why "Baseless" ?? What's wrong with establishing a Base register and coding appropriately ?? Is Baseless faster/better ?? If so, in what way. Is Baseless better as System code ??
Why does Base code add 2-3 times more code ??
Thanks,
Tom Savor
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________
Chris Craddock
> code. It would be 2-3 times that size if I had not gone to considerable
> effort to use relative addressing and immediate operands.
>
> You apparently feel that baseless code is unnecessary. My real world
> experience tells me a wholly different story.
I have written a few hundred thousand lines of commercial assembly language code myself. Based on my real world experience I can say for sure that the gymnastics people are going through to eliminate code addressability would be a waste of time me personally. But if it works for you, have at it. I don't think any more or less of anyone else who disagrees with me.
CC
Edward Jaffe
> Where does it state that? I have been reading the POP and I can find
> nowhere where it states that relative addressing instructions are to be
> used for branching only.
LOL! That's why it's called a ROT (Rule of Thumb).
The original intended use of relative instructions was for instructions only,
which is why the relative operand must always be on a halfword boundary.
Until fairly recently, the only relative instruction that could conceivably be
used to address anything other than an instruction was LARL. It's normally used
to set up the pointer to a program's literals/constants, which normally begin on
at least a double- or quadword boundary. (Non-reentrant work areas should be
forced onto a new cache line.)
Recent hardware generations have implemented a few other options such as
compare, load and store relative but this is still very restricted functionality
when compared to the full range of instructions available to data addressed in
the traditional manner.
John P. Baker
In my code I have a need to be able to simultaneously access a number of
different control blocks, so I have a lot of registers tied up. No space
for more than one instruction base register, but I cannot limit the code in
a procedure to 4K. So I write baseless code.
I tried breaking the procedures down. The code size grew dramatically. At
the same time, performance went to hell in a handbasket. MVCL and PLO
instructions tend to do that to you.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Savor, Tom
Sent: Monday, December 20, 2010 12:57 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Binyamin Dissen
wrote:
:>In my code I have a need to be able to simultaneously access a number of
:>different control blocks, so I have a lot of registers tied up. No space
:>for more than one instruction base register, but I cannot limit the code in
:>a procedure to 4K. So I write baseless code.
:>I tried breaking the procedures down. The code size grew dramatically. At
:>the same time, performance went to hell in a handbasket. MVCL and PLO
:>instructions tend to do that to you.
One wonders the connection between breaking down a procedure and the use of
MVCL and PLO.
John P. Baker
MVCL requires 4 registers. PLO can require even more.
With R0, R1, R13, R14, and R15 already unavailable, and several more tied up
with critical control blocks, the number of available registers is already
limited. Instruction base registers exacerbate the problem.
Breaking down a procedure so that it uses fewer base registers in order to
free up sufficient registers for such instructions, and adding the necessary
procedure calls and associated returns therefrom, particularly where the
procedure is repeatedly invoked, can add an unacceptable level of overhead
to a time-sensitive critical path system application.
A general purpose application may not have these sensitivities.
A system application has to be concerned with them.
Actually, both need to be concerned. Since many vendors now charge by MSU,
a poorly constructed application, whether general purpose or system, can
have its inefficiencies show up on the bill at the end of the month. To my
mind, that would not make for a good bullet point on a sales presentation.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Binyamin Dissen
Sent: Monday, December 20, 2010 2:04 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Edward Jaffe
> ... performance went to hell in a handbasket. MVCL and PLO
> instructions tend to do that to you.
PLO made our programs run *much* faster because we replaced the sequence "ENQ,
traverse or manipulate queue pointers with ordinary instructions, DEQ" with PLO
to traverse and update the queue.
John P. Baker
No doubt about it. PLO is a great instruction!
Difficult to understand at first, and the operand mapping could drive a
troll to fits, but it is very fast.
My point was that some of the PLO variants use "lots" of registers.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
Duffy Nightingale
couple for code and a couple for storage. Try to keep prog size small. Use
small routines which store work regs at begin of routine, then restore at
routine exit. Same way with using if an area is used almost everywhere
using goes at top. Other than that I put my using at begin of routine, then
drop at end. So have never needed baseless. But the idea below sounds very
good.
Gerhard Adam
up
>with critical control blocks, the number of available registers is already
>limited. Instruction base registers exacerbate the problem.
There is no reason to use base registers for branching, so the only concern
would be for static work areas for which R13 can be used (since it is
committed already). As a result, you can have a combination of baseless and
base-register within a program without the register usage penalty.
Steve Comstock
> I like this idea. But regs are rarely a problem for me. I always use a
> couple for code and a couple for storage. Try to keep prog size small. Use
> small routines which store work regs at begin of routine, then restore at
> routine exit. Same way with using if an area is used almost everywhere
> using goes at top. Other than that I put my using at begin of routine, then
> drop at end. So have never needed baseless. But the idea below sounds very
> good.
[Note: you left your own email address in as the reply-to; I
do that all the time, since it's the default in Thunderbird;
I changed it back to the Assembler list.]
You might find some insights on this page:
http://www.trainersfriend.com/General_content/Book_site.htm
in the paper titled "Applications Assembler Programming for z";
it doesn't refer to the instructions added with the z10 or z196
machines, since it was written before they came out, but you
can get some general ideas about 'baseless' coding.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
John P. Baker
R13 is being used for dynamic storage (register save areas).
My whole point in this discussion is that I am using baseless code (for
instructions) so that I have additional registers available for various
control blocks, complex instructions (such as MVCL and PLO), etc.
Chris made the argument that writing baseless code is a waste of time, a
position that may be fine for his applications, but is anything but for my
development efforts.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Gerhard Adam
Sent: Monday, December 20, 2010 4:08 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Gerhard Adam
>My whole point in this discussion is that I am using baseless code (for
>instructions) so that I have additional registers available for various
>control blocks, complex instructions (such as MVCL and PLO), etc.
>Chris made the argument that writing baseless code is a waste of time, a
>position that may be fine for his applications, but is anything but for my
>development efforts.
I understand, but my point is that if the save area is the first part of any
storage area, then R13 can serve as the save area pointer as well as the
base register to address the remaining storage areas. Consequently a
register that couldn't be used for anything else anyway can now serve the
role of base register to storage areas.
As for the rest of it, baseless code is trivial since once the storage areas
are dealt with, using relative branch instructions is a "no-brainer", so it
isn't a waste of time. In fact, it's so trivial that IBM even has a "macro"
IEABRC which allows you to replace all existing base/displacement branch
instructions with branch relative, so there is no basis for arguing that
baseless code is difficult or requires any effort for processing
instructions.
It is trivially easy to do.
Robert A. Rosenberg
>A good use for LARL is to set up the base register for the constants - and
>maybe the modifiable data area if the program is not reentrant. LARL can
>even be used to get the address of other control sections. But I think you
>are trying to use LARL for everything.
A LARL reference to another control section is playing with fire
since the displacement of the CSECT being referenced can change at
Bind Time. Only a ACON can track the real location/displacement:
DC A(CSECT1) located in CSECT2
David Bond
references, even those from relative addresses such as those in LARL and BRASL.
Edward Jaffe
Since z/OS 1.7 (and even better in 1.8) the binder manages relative references
to external symbols as needed.
John Ehrman
> I guess what irks me is that the macro has no way of knowing what to
generate. There is a hole in the assemble architecture. For example,
before baseless, when I reference a symbol, the assembler knows how to
resolve the storage location. It would lookup the symbol, determine the
base register for the storage and the displacement, and generate the
machine code.
If you're willing to do a little extra work, you might be able to assign a
Program Attribute to the symbols your macros must reference (either with
the DC or EQU instructions) that indicates where the symbol is defined,
what program-relevant properties it has, and therefore what kind(s) of
instruction(s) might be needed to address it.
Program Attributes are a very powerful tool for enhancing the power and
flexibility of macro-generated code; an example is given in Case Study 9 of
my presentation at SHARE 115 in Boston titled "Assembler Language as a
Higher Level Langage: Conditional Assembly and Macro Techniques".
John Ehrman
Savor, Tom
>In my code I have a need to be able to simultaneously access a number of
>different control blocks, so I have a lot of registers tied up. No space
>for more than one instruction base register, but I cannot limit the code in
>a procedure to 4K. So I write baseless code.
>I tried breaking the procedures down. The code size grew dramatically. At
>the same time, performance went to hell in a handbasket. MVCL and PLO
>instructions tend to do that to you.
>John P. Baker
Ok, but it sounds more like a choice than an actual need.
I have run into the same problem many times where you need access to many areas and those addresses kept for later use. To solve it, save address to save area, or if re-entrant, acquire some storage, save address in storage, then dsect storage...1 register. Sounds like many different ways to skin a cat to me.
So I'm still trying to figure out how or why Baseless is "required" for the above need.
How does Baseless eliminate the need or use of the MVCL instruction ??
Savor, Tom
>MVCL requires 4 registers. PLO can require even more.
>With R0, R1, R13, R14, and R15 already unavailable, and several more tied up
>with critical control blocks, the number of available registers is already
>limited. Instruction base registers exacerbate the problem.
John,
Everyone of my MVCL routines uses R0, R1, R14 and R15. Since they are unavailable to save something under those registers....they get used as work registers all the time.
John P. Baker
Running baseless just frees up additional registers, so that I can avoid the
overhead of repeated stores and loads.
It does NOT eliminate any need for a CLCL, MVCL, or PLO machine instruction.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Savor, Tom
Sent: Monday, December 20, 2010 2:15 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
John P. Baker
In some cases, I can and do use R0, R1, R14, and R15.
At other times, this is not an option available to me.
Run baseless just makes the job easier.
What would really make things easier would be baseless macros.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Savor, Tom
Sent: Monday, December 20, 2010 3:02 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Baseless vs Based
Paul Gilmartin
> On 12/20/2010 1:13 PM, Robert A. Rosenberg wrote:
>> At 11:03 -0500 on 12/20/2010, David Bond wrote about Re: Baseless vs
>> Based:
>>
>>> A good use for LARL is to set up the base register for the constants
>>> - and
>>> maybe the modifiable data area if the program is not reentrant.
>>> LARL can
>>> even be used to get the address of other control sections. But I
>>> think you
>>> are trying to use LARL for everything.
>>
>> A LARL reference to another control section is playing with fire
>> since the displacement of the CSECT being referenced can change at
>> Bind Time. Only a ACON can track the real location/displacement:
>
> Since z/OS 1.7 (and even better in 1.8) the binder manages relative
> references
> to external symbols as needed.
>
exceed the relative displacement reach. Or remembering
that SMP/E may rearrange CSECTs at its whim.
I'm pleasantly surprised: this implies considerable collusion
between HLASM and Binder to generate and resolve complex
relocatable constants, divided by 2, and with the bits
discontiguous. I'd not have dared to suggest such a
facility as a Requirement. That two(?) development groups
expended such effort effort shows that IBM, at least
perceives considerable value in relative addressing.
Perhaps it's in support of that compiler that I hear
rumors about.
On 2010-12-20 15:26, John Ehrman wrote:
> John Bodoh observed:
>
>> I guess what irks me is that the macro has no way of knowing what to
>> generate. ...
>
> If you're willing to do a little extra work, you might be able to
assign a
> Program Attribute to the symbols your macros must reference (either with
> the DC or EQU instructions) that indicates where the symbol is defined,
> what program-relevant properties it has, and therefore what kind(s) of
> instruction(s) might be needed to address it.
>
I suspect the OP is willing to expend that extra work, but
loath to require it of his clients.
-- gil
Edward Jaffe
> On 2010-12-20 15:24, Edward Jaffe wrote:
>> On 12/20/2010 1:13 PM, Robert A. Rosenberg wrote:
>>>
>>> A LARL reference to another control section is playing with fire
>>> since the displacement of the CSECT being referenced can change at
>>> Bind Time. Only a ACON can track the real location/displacement:
>>
>> Since z/OS 1.7 (and even better in 1.8) the binder manages relative
>> references to external symbols as needed.
>>
> Always presuming that the size of your load module does not
> exceed the relative displacement reach. Or remembering
> that SMP/E may rearrange CSECTs at its whim.
True. But, a +/- 2GiB relative displacement allows for a pretty darn big module! ;-)
Edward Jaffe
>
> True. But, a +/- 2GiB relative displacement allows for a pretty darn big
> module! ;-)
Oops. Of course, I should have said a +/- 4GiB relative displacement. :-[
Robert A. Rosenberg
I had not realized that there were now RLD records that showed the
displacements for these type of cross CSECT offsets. That is what
would be needed (An offset into the CSECT with the LARL) so the
command could be located and parsed to compute the new offset when
the displacement from the LARL's CSECT to the Target CSECT is altered
by the Binder.
Martin Trübner
>> Oops. Of course, I should have said a +/- 4GiB relative
>> displacement. :-[
Considering the options for running/residency of the program- where
would that make a difference? ;-)
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
john gilmore
This being the case, and with little prospect that the maximal size of a program object will be increased any time soon (and none that the maximal size of load modules will ever be increased), the relative displacements being discussed are already desirably larger than life, clearly adequate, for the proximate future.
There are in fact no good arguments for writing new code that uses base registers.
Those who put them forth should understand that in doing so they risk being lumped together with reflexively risk-averse Luddites who resist all innovation until it is obsolescent.
John Gilmore Ashland, MA 01721-1817 USA
Martin Trübner
>> What would really make things easier would be baseless macros.
Which is apparently a stmt made from the VSE side of op-sys.
z/OS has for that very purpose (althru it does also handle your code)
IEABRC and IEABRCX
In z/VSE you can use MAKEREL from me
http://pi-sysprog.de/free/makerel.html
and it is better than the IBM piece - does handle this case:
B *+4*(NUMACONS)
David Bond
>I had not realized that there were now RLD records that showed the
>displacements for these type of cross CSECT offsets. That is what
>would be needed (An offset into the CSECT with the LARL) so the
>command could be located and parsed to compute the new offset when
>the displacement from the LARL's CSECT to the Target CSECT is altered
>by the Binder.
The last 6 z/OS binder releases and the last two HLASM releases have
supported relocatable relative-immediate RLD items. (GOFF type 6).
The z/Linux assembler and linker have supported RI relocation since the
original 64-bit port. And z/TPF uses the same ELF formats as z/Linux.
z/Linux even supports relocatable RI references to shared objects (DLLs) and
I don't think there are any limitations on the size of an executable or
shared object so the ± 4GiB maximum displacement can be a problem.
David Bond
David Bond
>Or remembering that SMP/E may rearrange CSECTs at its whim.
Just as for all external references, RI relocation will be recalculated when
a module is relinked. This is a binder function and has nothing to do with
SMP/E.
David
Paul Gilmartin
>
>>> Oops. Of course, I should have said a +/- 4GiB relative
>>> displacement. :-[
>
> Considering the options for running/residency of the program- where
> would that make a difference? ;-)
>
the bar? Might Content Supervision report an error in some cases?
On Dec 20, 2010, at 23:09, Robert A. Rosenberg wrote:
>
>
> I had not realized that there were now RLD records that showed the
> displacements for these type of cross CSECT offsets. That is what
> would be needed (An offset into the CSECT with the LARL) so the
> command could be located and parsed to compute the new offset when
> the displacement from the LARL's CSECT to the Target CSECT is altered
> by the Binder.
>
I suspect this could most simply be done as complex relocation;
negative for the code CSECT, positive for the data. I hope
intermediate results are kept as 64 bits for present and future
OSes in which the bar is erased.
I hope the Program Management APIs for this are documented for
the benefit of ISV compiler writers. I wish, with less optimism,
that the SYSLIN format is documented for the benefit of
cross-compiler authors. I was dismayed at SHARE Denver to hear
an IBM representative boast of the design liberty IBM has
gained by making the program object format non-GUPI.
-- gil
Mike Shaw
> <snip>... I was dismayed at SHARE Denver to hear
> an IBM representative boast of the design liberty IBM has
> gained by making the program object format non-GUPI.
>
> -- gil
>
No doubt, someone @ IBM thinks a GUPI-format program object would slow down
compiler development...
--
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
Paul Gilmartin
Certainly. But I have a lingering concern that my developer coworkers
may gain a false sense of security by allowing order of INCLUDEs to
determine order of CSECTs during unit testing, only to have an
unpleasant surprise at SMP/E installation.
Will Content Supervision relocate 12-bit displacements across the
boundaries of (necessarily small) CSECTs? (ISTR from long ago that
there is an RLD format for 12-bit data.) This might be considered
a bad idea because of the likelihood that the target CSECT will be
loaded below the base. But it differs only quantitatively from
the hazard that a CSECT will be loaded out of range of RI
relocation.
-- gil
Paul Gilmartin
>
> No doubt, someone @ IBM thinks a GUPI-format program object would slow down
> compiler development...
>
customers had exploited documented features of load module format
that IBM itself had never used. IBM's subsequent desire to change
the specification or withdraw the features was then hindered by
extant art.
-- gil
David Bond
>Will Content Supervision relocate 12-bit displacements across the
>boundaries of (necessarily small) CSECTs? (ISTR from long ago that
>there is an RLD format for 12-bit data.) This might be considered
>a bad idea because of the likelihood that the target CSECT will be
>loaded below the base.
There is no (documented) format for 12-bit displacement relocation. GOFF
RLD type 9 is for 20-bit displacement relocation. 20-bit displacements can
be negative so the target section can be loaded before the base.
>But it differs only quantitatively from
>the hazard that a CSECT will be loaded out of range of RI
>relocation.
This is not a problem in current z/OS. As Ed Jaffe noted, the current
maximum module size is 1GiB and the 4GiB range of a 4-byte RI reference is
more than sufficient to cover RMODE 31 modules. RMODE SPLIT is currently
only for 24/31 modules.
The 4GiB range can cause a problem for z/Linux and possibly z/TPF. Mark
Boonie can enlighten us as to any z/TPF limitations on the size of ELF
modules or references to shared objects outside of the 4GiB range.
David
Edward Jaffe
>
> Could this happen with RMODE(SPLIT); code below and data above
> the bar? Might Content Supervision report an error in some cases?
RMODE(SPLIT) does not support RMODE(64) modules, nor it is likely to. It was a
neat idea, but introduces unnecessary complexity and is almost never used.
john gilmore
<begin snippet>
RMODE(SPLIT) does not support RMODE(64) modules, nor it is likely to. It was a
neat idea, but introduces unnecessary complexity and is almost never used.
I have two comments.
1) I entirely agree with EJ's judgment that SPLIT support for RMODE(64) modules is unlikely, although it would be useful to be able to place tables and the like that were conceptually a part of a program object above the bar and its executables below the bar.
2) RMODE(SPLIT) support was not, initially, nearly so clean as it is now; and this was discouraging; but it has important uses, not certainly for an ISV, but in situations in which AMODE(24) COBOL behemoths must be maintained and enhanced. Its use permits replacement routines to be written as AMODE(31) ones without requiring complete conversion to AMODE(31) from AMODE(24).
'Almost never' may well be an accurate description of the current use of RMODE(SPLIT): I have conducted no survey, and I know what is going on in only a very small sample of the mainframe COBOL shops that could use it to advantage, but I have recommended and overseen its successful use in three of them.
To summarize now, the niche for RMODE(SPLIT) may well be small; but it is economically important in the situations I have described; and no one who must work with these COBOL behemoths should hesitate to use it.
Edward Jaffe
> 'Almost never' may well be an accurate description of the current use of RMODE(SPLIT): I have conducted no survey, and I know what is going on in only a very small sample of the mainframe COBOL shops that could use it to advantage, but I have recommended and overseen its successful use in three of them.
>
> To summarize now, the niche for RMODE(SPLIT) may well be small; but it is economically important in the situations I have described; and no one who must work with these COBOL behemoths should hesitate to use it.
These are good points, John. I should not have so authoritatively stated that
RMODE(SPLIT) is 'almost never' used. I've heard that its use is minimal and that
is part of IBM's rationale for thinking it need not be carried forward into the
64-bit realm. I did not mean to imply that its use should be avoided.
Robert A. Rosenberg
>True. But, a +/- 2GiB relative displacement allows for a pretty darn
>big module!
So long as you are using the newer 20-bit offset as opposed to the
original 12-bit offset versions of the instructions.
David Bond
>>True. But, a +/- 2GiB relative displacement allows for a pretty darn
>>big module!
>
>So long as you are using the newer 20-bit offset as opposed to the
>original 12-bit offset versions of the instructions.
You are confusing the relative instructions with the long displacement
instructions. The original base-displacement form had a 12-bit displacement
allowing for a range of 0-4095. The 20-bit long displacement instructions
allow for at range of +/-512KiB. There are two forms of relative addresses.
The 16-bit form allows for +/-64Kib but no odd addresses. The 32-bit form
allows for +/-4GiB also without odd addresses.
David
John Ehrman
> I hope the Program Management APIs for this are documented for
> the benefit of ISV compiler writers. I wish, with less optimism,
> that the SYSLIN format is documented for the benefit of
> cross-compiler authors. I was dismayed at SHARE Denver to hear
> an IBM representative boast of the design liberty IBM has
> gained by making the program object format non-GUPI.
The APIs and SYSLIN formats are, and have been, documented in the Binder
Advanced
Facilities manual. (You may now resume your optimism.)
The internal format of a program object should be of no interest to anyone
except
the Binder and Program Loader developers, since the APIs provide access to
all
information you might need. If anything is missing, the APIs can be
extended.
John Ehrman
> Will Content Supervision relocate 12-bit displacements across the
> boundaries of (necessarily small) CSECTs? (ISTR from long ago that
> there is an RLD format for 12-bit data.) This might be considered
> a bad idea because of the likelihood that the target CSECT will be
> loaded below the base. But it differs only quantitatively from
> the hazard that a CSECT will be loaded out of range of RI
> relocation.
The Binder provides information in the program object for the Program
Loader to
relocate relative-immediate offsets across Csects, even if they are in
different segments
that may be loaded below and above the 16M line.
I know of no RLD for 12-bit data.
Robert A. Rosenberg
>Certainly. But I have a lingering concern that my developer coworkers
>may gain a false sense of security by allowing order of INCLUDEs to
>determine order of CSECTs during unit testing, only to have an
>unpleasant surprise at SMP/E installation.
It has been a while but I seem to remember a Linkedit/Binder command
called ORDER that insured the order of the named CSECTs. If the
mapping of the CSECTs in the Load Module were designated via this
command as well as the INCLUDEs, SMP/E would not mess with the
developer's designated/intended order. Every Load Module has its
Binder commands supplied to SMP/E so this ordering can be insured (as
INCLUDE will not since SMP/E will just do INCLUDEs of the new
versions of the CSECTs and then INCLUDE the Load Module itself to
pick up the non-replaced CSECTs) via supplying the ORDER statements.
Paul Gilmartin
> At 08:15 -0700 on 12/21/2010, Paul Gilmartin wrote about Re: Baseless
> vs Based:
>
>> Certainly. But I have a lingering concern that my developer coworkers
>> may gain a false sense of security by allowing order of INCLUDEs to
>> determine order of CSECTs during unit testing, only to have an
>> unpleasant surprise at SMP/E installation.
>
> It has been a while but I seem to remember a Linkedit/Binder command
> called ORDER that insured the order of the named CSECTs. If the
may inadvertently introduce a dependency on ordering of CSECTs
and not discover it during unit testing, nor even until one of
the CSECTs is updated by a later PTF. I've been tempted to
scramble the INCLUDEs during unit testing to try to uncover
such flaws.
Do you know what a pain it is to force a CSECT to appear last
in a complex load module, particularly when an INCLUDEd member
may contain multiple CSECTs?
-- gil
John Ehrman
> Do you know what a pain it is to force a CSECT to appear last
> in a complex load module, particularly when an INCLUDEd member
> may contain multiple CSECTs?
Might you consider submitting a Market or SHARE Requirement asking for a
binder control statement like "ORDER LAST"?
Edward Jaffe
> Might you consider submitting a Market or SHARE Requirement asking for a
> binder control statement like "ORDER LAST"?
I had a similar requirement (or wish list item) for LOCTR. It's impossible to
make a given LOCTR appear last in an assembly unless you have absolute control
over every LOCTR in the module.
John McKown
CSECTs within a module matter? I even have trouble understanding PAGE
alignment for anything other than perhaps performance or page fixing.
--
John McKown
Maranatha! <><
Paul Gilmartin
> I don't really do development at this level. Why would the order of
> CSECTs within a module matter? I even have trouble understanding PAGE
> alignment for anything other than perhaps performance or page fixing.
>
The most I know is that some of the developers I work for insist
on supplying ORDER statements for every CSECT. It could be as
simple as wanting the eyecatcher to appear first. Or having
several data CSECTs and wanting to move them en masse with MVCL.
This requires that they be contiguous and in a known order. and
have an end marker. Is HLASM happy with 0-length CSECTs
nowadays? I know Binder is unhappy with empty load modules.
Your rhetoric could equally apply to Ed's wish for control of
LOCTR. But I remember a discussion here a few years ago.
It had something to do with macros, and not wanting the caller
to supply dummy LOCTRs to get things in a desired order.
-- gil
Tony Harminc
> I don't really do development at this level. Why would the order of
> CSECTs within a module matter? I even have trouble understanding PAGE
> alignment for anything other than perhaps performance or page fixing.
It may be the worst possible reason, but I have discovered code in
more than one ISV product (lamentably including a case in an obscure
corner of one of our own) that assumes that the load point and entry
point of a module are the same.
Just as Paul Gilmartin describes, all was well while unit testing (and
indeed packaging and production use) were done without SMP/E, but as
we converted to SMP/E maintenance we quickly discovered and corrected
the error.
In most cases this kind of error affects no one but the authors and
packagers of the code in question, but where the assumption is in a
routine that loads and calls an exit that the customer is expected to
provide, things can turn ugly.
Tony H.
Edward Jaffe
> It may be the worst possible reason, but I have discovered code in
> more than one ISV product (lamentably including a case in an obscure
> corner of one of our own) that assumes that the load point and entry
> point of a module are the same.
Not a bad reason at all. The system returns the EPA on a LOAD macro, but the
module load point is much harder to find. CSVQUERY will give it to you in 2010
but in the old days programs had to "crawl" through CSV control blocks to get
this information.
Jim Mulder
the
> module load point is much harder to find. CSVQUERY will give it to you
in 2010
> but in the old days programs had to "crawl" through CSV control blocks
to get
> this information.
The LOADPT keyword has been available on the LOAD macro since
the first release of MVS/XA.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Edward Jaffe
> The LOADPT keyword has been available on the LOAD macro since
> the first release of MVS/XA.
I forgot about that keyword. Of course, I was thinking about the old, old days.
I don't envy those guys that are still writing for MVS 3.8.
Robert A. Rosenberg
> > Not a bad reason at all. The system returns the EPA on a LOAD macro, but
>the
>> module load point is much harder to find. CSVQUERY will give it to you
>in 2010
>> but in the old days programs had to "crawl" through CSV control blocks
>to get
>> this information.
>
> The LOADPT keyword has been available on the LOAD macro since
>the first release of MVS/XA.
That Keyword, if I remember correctly, allows an authorized program
to control where the module is loaded into memory. What is being
asked for is for the LOAD request to not only return the EPA but the
Load Location. Thus if a normal program issues the LOAD (or an
authorized one does but does not use the LOADPT parm) the user is not
informed of where the module ended up - only where to branch to enter
the module.
Edward Jaffe
> At 22:55 -0500 on 12/21/2010, Jim Mulder wrote about Re: Baseless vs Based:
>
>> The LOADPT keyword has been available on the LOAD macro since
>> the first release of MVS/XA.
>
> That Keyword, if I remember correctly, allows an authorized program
> to control where the module is loaded into memory.
|LOADPT=addr
| Specifies that the starting address at which the module was loaded is
| to be returned to the caller at the indicated address.
You're thinking of ADDR= and ADRNAPF=.
Binyamin Dissen
wrote:
:>On 12/21/2010 3:44 PM, John Ehrman wrote:
:>> Might you consider submitting a Market or SHARE Requirement asking for a
:>> binder control statement like "ORDER LAST"?
:>I had a similar requirement (or wish list item) for LOCTR. It's impossible to
:>make a given LOCTR appear last in an assembly unless you have absolute control
:>over every LOCTR in the module.
That is why in the front of every module that I use LOCTR in has the list of
LOCTR's in the order that I want them, i.e.,
@CODE LOCTR ,
@SUBR LOCTR ,
@DATA LOCTR ,
etc.
@CODE LOCTR ,
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
ANDREAS F. GEISSBUEHLER
> I forgot about that keyword. Of course, I was thinking about the old, old
> days.
> I don't envy those guys that are still writing for MVS 3.8.
>
blocks have seen massive changes, as recent as zos17 I got them
(had to) from:
XTLMSBAD
XTLMSBLN
This is almost certainly no longer "official" or documented !
Andreas F. Geissbuehler
AFG Consultants Inc.
http://www.afgc-inc.com/
Edward Jaffe
>
> ... IBM's rationale for thinking it need not be carried forward into the
> 64-bit realm.
I remembered a SHARE speaker implying that binder/loader "split" support to
include possible future RMODE(64) segments might be overly complex. I've been
reminded that comment was probably in reference to a three-way split: 24/31/64.
I guess that leaves the door open for various two-way splits: 24/31, 24/64 or 31/64.
Paul Gilmartin
> On 12/21/2010 10:24 AM, Edward Jaffe wrote:
>>
>> ... IBM's rationale for thinking it need not be carried forward into the
>> 64-bit realm.
>
> I remembered a SHARE speaker implying that binder/loader "split" support to
> include possible future RMODE(64) segments might be overly complex. I've been
> reminded that comment was probably in reference to a three-way split: 24/31/64.
>
In most endeavors the complexity barrier is between 1 and 2, not between
2 and 3 or more. Barring shortsighted design such as allocating only a
single bit to select the RMODE.
> I guess that leaves the door open for various two-way splits: 24/31, 24/64 or 31/64.
>
Reminiscent of the 2-out-of-3 tape density switches from days of yore.
Some drives (not necessarily IBM's) had a 3-position switch: 200/556,
556/800, or 200/800.
The CCW contained only a single bit to select the density.
-- gil