:43 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
In a huge number of cases, programs using relative branch are not
base-less. They have no "code base register" but that does not mean they
are base-less.
For the most part, z/OS has simply decided that we will not w
In a huge number of cases, programs using relative branch are not
base-less. They have no "code base register" but that does not mean they
are base-less.
For the most part, z/OS has simply decided that we will not worry about
"no base register at all" cases when customers use our macros. We
Martin Ward wrote:
> > No space is wasted except, possibly, at the origin of the pool, and
> > in aligning to the start of the statement following the literal
> > pool.
>
> So this isn't entirely correct: the last segment may have padding bytes.
A documentation update was included in APAR PH34824
On 09/11/2021 08:53, Jonathan Scott wrote:
It is still stored within the last section of the literal pool
(because at the time of definition, it is not necessarily known
whether it will be referenced by relative address)
Given that it has an odd length, it cannot be stored in the forth
APAR PH34824 in March 2021 fixed the LARL loophole; if a literal
with odd byte length is referenced by relative address, it is
now automatically aligned to a halfword by inserting a padding
byte before it if necessary.
It is still stored within the last section of the literal pool
(because at the
So Jonathan doesn't have to respond:
> And LA R1,-CL128'x' on a 128 byte boundary?
>From the Language Reference:
Each literal pool has five segments into which the literals are stored (a)
in the order that the literals are
specified, and (b) according to their assembled lengths, which, for
We leave that as an exercise for the student.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, November 8, 2021 4:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On Nov 8, 2021, at 16:42:40, Charles Mills wrote:
>
> Are the rules special for literals?
>
> Yes. Literals have always aligned on a "multiple-of-length-power2" boundary.
> =CL8... will be on a doubleword.
>
And LA R1,-CL128'x' on a 128 byte boundary?
>> What if you want a speciic length?:
>>
ver' is a 5-byte literal.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, November 8, 2021 1:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On Nov 8, 2021, at 13:57:10, Me
Better than a brach-around IMHO. CharlesSent from a mobile; please excuse the
brevity.
Original message From: Melvyn Maltz
<072265160664-dmarc-requ...@listserv.uga.edu> Date: 11/8/21 12:57 PM
(GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less
Hi there,
I am sure Jonathan will confirm...but yes, even byte literals will be on
an even boundary, they are sorted
If you code it and use LARL, you'll get an error if not on an even boundary
=CL5 may not align, a frequent source of 'it worked then but not now'
syndrome
Melvyn Maltz.
On
On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote:
> ...
> LARL R3,=C'ABCDE-'
>
> Yes, it's a 5-byte literal extended to 6 to keep the LARL happy
>
Does giving a character constant even length guarantee even
alignment? I'm thinking of such as:
DC. 0H'0'
EVEN DC C'?'
ODD DC
Hi there,
I hate the term base-less it means 'without foundation' !
I'm not sure what the fuss is about, I've been using base-free code with
literals for years.
eg.
LARL R3,=C'ABCDE-'
MVC THERE(5),0(R3)
Yes, it's a 5-byte literal extended to 6 to keep the LARL happy
LARL has a range of +/-
Everyone,
Thanks for your suggestions.
More info:
My macro supports parms in the formats:
XXX=address
XXX=(reg)
XXX=(S,address)
XXX=*address
XXX='constant'
The only time I need a local defined area is when the user uses
XXX='constant'. Based on the info posted today, I think I will document
I've been using (for a shockingly large number of years!) the
approach that Keith Moe and Charles Mills described. It has worked
very well and caused no trouble for my product development and
support teams. All of the products on which I've been a designer
and developer have been nearly 100
Am 08.11.2021 um 17:08 schrieb Charles Mills:
Only if you write into the data areas;
the OP wrote of constants in macros, so the areas should be read-only.
Can someone who knows the hardware architecture definitively confirm or deny
that assertion? I always thought there were separate D- and
On 11/8/2021 1:45 AM, Tony Thigpen wrote:
I decided to put the constant in-line and use BRAS to acquire it's
address:
AIF (''(1,1) NE ).N0004
BRAS ,N2
SETC ''(2,K')
N1 DC CL''
N2 DS 0H
AGO .N0099
.N0004 ANOP
Back in the day, it was quite common
vember 8, 2021 10:45 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On Nov 8, 2021, at 08:13:09, Seymour J Metz wrote:
>
> What's wrong with using LOCTR in a customer-facing macro?
>
It requires an unlikely degree of coordination between
vendor and customer leest a
On 11/8/2021 8:05 AM, Charles Mills wrote:
Ship an additional required macro, TTLTORG, that pushes the current LOCTR,
switches to "your" data LOCTR, issues a LTORG, and then pops the LOCTR.
He already has a trivially-easy solution (JAS around an in-line
constant) that is guaranteed to be 100%
R-LIST@LISTSERV.UGA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Monday, November 8, 2021 1:01 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Am 08.11.2021 um 05:40 schrieb Charles Mills:
> +1
>
> I have my LOCTR's named CODE and DATA but I agree with the concept: base
&g
igpen
Sent: Monday, November 8, 2021 6:09 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
My regular code has used location counters for about 20 years. But, that
is not applicable to the question at hand, which is a service calling
macro provided to customers.
Tony Thigpen
ssage-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Monday, November 8, 2021 4:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
It is not unreasonable to require your clients to provide a literal pool.
It is no
On Nov 8, 2021, at 08:13:09, Seymour J Metz wrote:
>
> What's wrong with using LOCTR in a customer-facing macro?
>
It requires an unlikely degree of coordination between
vendor and customer leest a construct like the following
unwittingly occur:
BAR LOCTR
USING *,2
* ... (More stuff)
FOO
What's wrong with using LOCTR in a customer-facing macro?
From: IBM Mainframe Assembler List on behalf
of Tony Thigpen
Sent: Monday, November 8, 2021 9:08 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
My regular code has used
@LISTSERV.UGA.EDU] on behalf
of Tony Thigpen [t...@vse2pdf.com]
Sent: Sunday, November 7, 2021 7:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Base-less macros
I finally am to the point where I no longer need to worry about specific
customers having hardware that does not support relative
On Nov 8, 2021, at 06:35:20, Martin Truebner wrote:
>
>
>>> I'm curious how you EQU to generate an S-constant properly.
>
> Like this:
>
> * below are for USE by EX against instructions in Literal pool
>SETC 'X''512''(13)'
>SETC 'X''512''(5)'
>
ITYM:
SETC
Paul,
>> I'm curious how you EQU to generate an S-constant properly.
Like this:
* below are for USE by EX against instructions in Literal pool
SETC 'X''512''(13)'
SETC 'X''512''(5)'
Yes- I know the difference between an EQU and a SETC (it is just the
old memory
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tony Thigpen [t...@vse2pdf.com]
Sent: Sunday, November 7, 2021 7:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Base-less macros
I finally am to the point where I no longer need to worry about
In general, z/OS macros that accommodate relative branching assume that
the user has addressability to a static data area and that they will have
a suitable LTORG.
And that means that we feel free to use literals in such cases.
Of course there are now a lot of "immediate" instructions that can
Steve,
In my specific case, I cant add a LTORG requirement.
Although the macro I am working on is specific to our product, I have to
provide a compatibility macro that converts another vendors macro to our
macro. While I can require the customer to re-assemble, I don't want
them to have to
It is not unreasonable to require your clients to provide a literal pool.
It is not your problem, it's the user's. Even IBM accepted this, about 30
years ago, when relative-addressing was invented. Their macros require
SYSSTATE ARCHLVL=2 or higher to generate with literals instead of inline
Ref: Your note of Mon, 8 Nov 2021 03:32:34 -0700
An attempt to execute a literal gives warning ASMA016W which
can be suppressed by the NOEXLITW option.
gil writes:
> I've seen some surprising behavior such as:
>LA R1,=E'3.14' works
>DC S(=E'3.14') fails to resolve the same
On Nov 8, 2021, at 01:26:34, Martin Truebner wrote:
>...
> I never had readability concerns/complains about this
>
> EX R4,=S(,TARGET,SOURCE)
>
> with appropriate EQUs at the beginning of the code.
>
I'm curious how you EQU to generate an S-constant properly.
> Well; almost never.
I decided to put the constant in-line and use BRAS to acquire it's address:
AIF (''(1,1) NE ).N0004
BRAS ,N2
SETC ''(2,K')
N1 DC CL''
N2 DS 0H
AGO .N0099
.N0004 ANOP
Tony Thigpen
Bernd Oppolzer wrote on 11/8/21 4:01 AM:
Am 08.11.2021 um 05:40
Am 08.11.2021 um 05:40 schrieb Charles Mills:
+1
I have my LOCTR's named CODE and DATA but I agree with the concept: base
register points to the CSECT; CSECT has data and LTORG's first. Hard to get
totally away from base registers, especially if your ARCH does not support EXR.
You don't want
>> You don't want inline data values that you branch around. They are
>> cache-killers.
For certain types it does not realy matter (i.e. OPEN or CLOSE), but if
that is a concern I would go to MF=L and MF=E - That is a convention in
use since ages.
>> ... especially if your ARCH does not support
IMHO, if you are a macro provider and have no control on the environment
provided by the open code (which comes from the customer's programmer),
the literal approach is more dangerous, because it assumes that the
programmer
will provide space and addressibility for the literals.
Doing LTORG
. They are
cache-killers.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Keith Moe
Sent: Sunday, November 7, 2021 7:40 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
A trick I use is to have a single
> option.
>
> HTH,
> Mike
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Tony Thigpen
> Sent: Sunday, November 7, 2021 7:25 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Base-less mac
Good points both, I overlooked the context.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Thigpen
Sent: Sunday, November 7, 2021 8:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Caution
macros? If not, maybe that's another option.
HTH,
Mike
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Thigpen
Sent: Sunday, November 7, 2021 7:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Base-less macros
Caution
Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Thigpen
Sent: Sunday, November 7, 2021 7:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Base-less macros
Caution! This message was sent from outside your organization.
I finally am to the point where I no longer need
I finally am to the point where I no longer need to worry about specific
customers having hardware that does not support relative instructions,
so I am updating some macros I provide to be baseless.
What is the 'preferred' approach to macro generated constants? In the
past, I have used both
101 - 143 of 143 matches
Mail list logo
