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
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?:
>>
Are the rules special for literals?
Yes. Literals have always aligned on a "multiple-of-length-power2" boundary.
=CL8... will be on a doubleword.
> What if you want a speciic length?:
>LARL R3,=CL5'ABCDE-'
You can't always get what you want. -- Mick Jagger
CL5'whatever' is a 5-byte
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 macros
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
I wasn't proposing using LOCTR for the literal pool, but for named constants
that you would otherwise branch around.
From: IBM Mainframe Assembler List on behalf
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Monday, November
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%
> 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 I-cache lines, and
so the branch-around
Ship an additional required macro, TTLTORG, that pushes the current LOCTR,
switches to "your" data LOCTR, issues a LTORG, and then pops the LOCTR.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tony Thigpen
Sent:
I would agree. How hard is it for the customer to provide an addressable LTORG?
It's just like some other requirement that your macro might have, such as "R0
and R1 are available as work registers" or "R13 points to a sufficient save
area."
Charles
-Original Message-
From: IBM
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
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
Seymour J Metz wrote on 11/8/21 8:08 AM:
Well, my preferred approach is to use a location counter. I would
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
Well, my preferred approach is to use a location counter. I would say don't
branch around anything, but I like to have extra text in my save area
trace-back, so I put up with the otherwise extraneous branch..
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
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
Sigh.
Well, thanks for looking. I appreciate it.
Dave
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)
At 11/8/2021 06:21 AM, Jonathan Scott wrote:
David Cole writes:
>Is there a way to increase the assembly listing header lines limit
>past 8? I looked
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
David Cole writes:
>Is there a way to increase the assembly listing header lines limit
>past 8? I looked recently but didn't find anything.
Sorry, but I've just had a look at the heading routine, and the
limit of 4 lines of USING headers cannot easily be changed. It
isn't even a simple constant;
Hi, I've got a question.
Is there a way to increase the assembly listing header lines limit
past 8? I looked recently but didn't find anything.
You might ask why 8 lines isn't enough. Well... I use named USINGs a
LOT! So much so, that I frequently blow through the 8 line limit.
And of
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
35 matches
Mail list logo
