I am about to write some code using compare and trap/branch as well as
store/load on condition.
Is there a convention/macro/copy_structure that I can use?
What I like to write is this (assuming COND_E is the condition equal):
CIT R15,(L'STRUC/4),COND_E
Or am I in the wrong book and there
Yes, there are extended suffixes for COMPARE AND BRANCH and COMPARE AND
TRAP. The defined suffixes are -H, -L, -E, -NH, -NL, and -NE.
- mb
Mark Boonie
z/TPF Development
Martin Trübner wrote on 12/20/2010 05:57:18 AM:
...
Or am I in the wrong book and there are extended mnemonics for CIT
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
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
Mark,
Thank you - works
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
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
-Original Message-
From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On
John,
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
On Dec 20, 2010, at 07:05, 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
On Mon, 20 Dec 2010 10:28:21 -0500 Bodoh John Robert
john.robert.bo...@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
How about un-registered computing? Kind of like off-the-grid, but not
exactly...
-Original Message-
From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On
Behalf Of john gilmore
Sent: Saturday, December 18, 2010 12:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
My advice is to do what most assembler programmers and most compilers do.
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.
On Dec 20, 2010, at 08:49, Bodoh John Robert wrote:
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?
Lookahead has its
John,
the BRUX-case can easy be coded like this:
L R15,=A(RTN01,RTN02,RTN03,RTN04)(R2)
BRR15
It is just a little change in habits - but that is all.
No need for a new instruction
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
On Mon, 20 Dec 2010 17:39:54 +0100 Martin Trübner mar...@pi-sysprog.de
wrote:
:the BRUX-case can easy be coded like this:
: L R15,=A(RTN01,RTN02,RTN03,RTN04)(R2)
: BRR15
1. If there are literals under a base register.
2. IIRC the assembler does not allow indexed literals.
3. Would
David,
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
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
On Mon, 20 Dec 2010 09:28:27 -0700, Paul Gilmartin wrote:
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
On Dec 20, 2010, at 09:30, David Bond wrote:
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
On 12/20/2010 6:05 AM, Bodoh John Robert wrote:
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
Binyamin,
I am currently using a BASR/B approach for the BRUX case.
I just question whether it is the best approach. Since BRUX would not
change any registers, I would think that it would be more efficient in the
pipeline.
John P. Baker
-Original Message-
From: IBM Mainframe Assembler
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-
From: IBM Mainframe Assembler List
[mailto:assembler-l...@listserv.uga.edu] On Behalf Of
On Dec 20, 2010, at 09:59, Bodoh John Robert wrote:
It sounds like you're agreeing with me: There is a limitation in
macros.
Thanks. But don't cite me as an authority. My opinions carry little
positive weight in this list.
-- gil
On Mon, 20 Dec 2010 09:28:27 -0700, Paul Gilmartin wrote:
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
wow what a busy topic! At the risk of throwing gasoline on a burning building,
I have to say it sounds like a lot of people are struggling to write baseless
code (or whatever is eventually decreed as the politically correct term) just
for the sake of being baseless. It is obviously very trendy
Ed is saying that most of the data manipulation instructions are base or
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
Chris,
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
Chris,
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
On 12/20/2010 9:02 AM, Bodoh John Robert wrote:
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
For an example of using relative addressing of data using z/OS macros, consider:
PUT DCB,RECORD
which can also be coded as:
LARL R1,DCB
LARL R0,RECORD
PUT (1),(0)
The macro does not need to somehow determine DCB and RECORD need to be
addressed via LARL instead of LA because the
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
On Mon, 20 Dec 2010 13:36:26 -0500 John P. Baker jbaker...@comporium.net
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
Benyamin,
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
Edward,
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
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
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.
There is no reason to use base registers for branching, so the only concern
would be
Gerhard,
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
At 18:47 +0200 on 12/20/2010, Binyamin Dissen wrote about Re: Still Needed:
:the BRUX-case can easy be coded like this:
: L R15,=A(RTN01,RTN02,RTN03,RTN04)(R2)
: BRR15
1. If there are literals under a base register.
2. IIRC the assembler does not allow indexed literals.
So go
At 11:43 -0500 on 12/20/2010, John P. Baker wrote about Re: Still Needed:
Martin,
Except that the L instruction requires a base register.
John P. Baker
Even with BaseLess Programming you usually have one base register for
your constants (the baseless if for your code) so the literal would
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
Why is it playing with fire? The z/OS linker happily resolves external
references, even those from relative addresses such as those in LARL and BRASL.
On Mon, 20 Dec 2010 16:13:44 -0500, Robert A. Rosenberg wrote:
A LARL reference to another control section is playing with fire
since the
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
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
Tom,
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
43 matches
Mail list logo
