Shmuel wrote:
Assuming that the caller has initialized the save area and subsequently
used it in accordance with IBM linkage conventions, offset 4-7 will
contain 4 EBCDIC characters ending iin SA only if it is 144 bytes long;
Not true. An example is the longest-existing. That's where the
> In that scenario, offset 4 of Xs save area will no longer contain
> FnSA, and can thus be identified as the forward pointer of a 72-bytesave
area.
The point that several recent posts have been trying to make is that the
contents of word 1 indicate how the registers were saved in the
@LISTSERV.UGA.EDU] on behalf
of Mark Boonie [boo...@us.ibm.com]
Sent: Wednesday, December 1, 2021 2:09 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
> The one case where there could be an issue is if the
> routine calls both code expecting a 72-byte save area an
> The one case where there could be an issue is if the
> routine calls both code expecting a 72-byte save area and code
> calling a 144-byte area.
>
> If the linkage conventions are followed, under what circumstances
> would you be unable to follow the forward chain with a little bit of
work?
du/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Charles Mills [charl...@mcn.org]
Sent: Wednesday, December 1, 2021 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Nope! Read what Peter wrote
Nope! Read what Peter wrote.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Wednesday, December 1, 2021 10:27 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Assuming
://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Peter Relson [rel...@us.ibm.com]
Sent: Wednesday, December 1, 2021 10:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Charles
:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Charles wrote:
Ah! I have not been clear on the convention. As I read it now, the called
program puts one of the FnSA strings in its *new* save area to indicate
how
*it* previously stored the registers in its entry save area.
This
Charles wrote:
Ah! I have not been clear on the convention. As I read it now, the called
program puts one of the FnSA strings in its *new* save area to indicate
how
*it* previously stored the registers in its entry save area.
This point has been made multiple times in this forum and in
you notify us by reply mail or telephone and delete the original
> message from your mail system.
>
>
> -Original Message-
> > From: IBM Mainframe Assembler List [mailto:
> ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> > On Behalf Of Peter Relson
> > Sent: Tuesday, N
: Re: Base-less macros
Steve Smith wrote:
And there are other bizarre ways to return without
restoring R14, which is not actually required by documented conventions.
Only restoring of AR14 and the high half of R14 are required (for
non-AMODE 64 cases), in general.
(Although I would g
On Nov 30, 2021, at 11:51:40, Laddie Hanus wrote:
>
> How about all of that code written before 64 bit z. I had stuff as old as
> 1985 still running in 2017.
>
The interface specifications should require 31-bit linkage conventions.
That should have been explicit ni 1985 to preclude 24-bit.
From the conversation, I think this is an internal convention at their
shop. They require the callers to put the eyecatcher in to indicate
they created/reserved a 144-byte savearea. Callers that don't do that
are probably some kind of legacy and can't be assumed to have a 144 byte
save area. I
gt;
>>
>> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
>> behalf of Mark Hammack [mark.hamm...@gmail.com]
>> Sent: Tuesday, November 30, 2021 12:43 PM
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Subjec
On Nov 30, 2021, at 11:21:51, Mark Hammack wrote:
>
> If the caller only passes a 72 byte save area (rather than part of a larger
> save area stack) then I've got bigger problems than how to test and/or set
> c'F4SA' in the save area. :-)
>
The code of the subroutine should cut the Gordian
dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, November 30, 2021 12:50 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
And IIRC in ancient days the PL1 runtime used to use word 1 of the RSA for its
own purposes. Don’t know if LE and Enterprise PL1 (or Enterprise COBOL for
t
__
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Mark Hammack [mark.hamm...@gmail.com]
> Sent: Tuesday, November 30, 2021 12:43 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base-less macros
>
> Couldn't do
Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Mark Hammack [mark.hamm...@gmail.com]
Sent: Tuesday, November 30, 2021 12:36 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
I think it is one of those "better safe than sorry" things. If a prior
1 10:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On Nov 30, 2021, at 11:02:48, Charles Mills wrote:
>
> Yes, LE uses word 1 (or word 0 if you will).
>
Might that be for a static frame pointer, which must be provided
For any language supporting nested pro
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Mark Hammack [mark.hamm...@gmail.com]
Sent: Tuesday, November 30, 2021 12:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Couldn't do a "normal" STM R14
Subject: Re: Base-less macros
You don't have to always save ALL the registers. No matter what the
caller provides, you can always do a
STMG 14,4,8(13)
STG 13,64(13)
because it fits in the standard 72 byte minimal save area.
After the STMG, you can then decide if the caller passed a larger area
me Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU
]
On Behalf Of Peter Relson
Sent: Tuesday, November 30, 2021 5:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Steve Smith wrote:
And there are other bizarre ways to return without
restoring R14, which is not actually re
Hammack
Sent: Tuesday, November 30, 2021 12:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
I think it is one of those "better safe than sorry" things. If a prior
subroutine call used this RSA in 31 bit mode, then 4(13) should be an address
so the low order bit
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area
to be checked. STGM 14,12,8(13) would probably work in most cases. Either
the first 72 bytes will be rewritten with the STM or the data is already
stored.
sage-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Mark Hammack
> Sent: Tuesday, November 30, 2021 7:54 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base-less macros
>
> In our case, the caller doesn't "know" whet
> Sent: Tuesday, November 30, 2021 10:53 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base-less macros
>
> In our case, the caller doesn't "know" whether the called subroutine is
> base 31 or base 64. So it is up to the called subroutine to "figure out"
&g
On Nov 30, 2021, at 10:07:51, Gary Weinhold wrote:
>
> Actually the 24-bit architecture wasn't the legacy problem as much as
> not restricting the leading byte of a fullword (whether in memory or
> registers) that the hardware would interpret as an address. That led to
> the use of the
[charl...@mcn.org]
Sent: Tuesday, November 30, 2021 9:36 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Ah! I have not been clear on the convention. As I read it now, the called
program puts one of the FnSA strings in its *new* save area to indicate how
*it* previously stored
2 AM
To:ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On 30/11/2021 16:36, Paul Gilmartin wrote:
Didn't IBM do that?
Doesn't mean that it was a good idea :-)
"The 64-bit IBM zSeries (2001) still supports 24-bit mode,
40-plus years later. Why did 24-bit happen? I’m told that i
-less macros
On 30/11/2021 16:36, Paul Gilmartin wrote:
> Didn't IBM do that?
Doesn't mean that it was a good idea :-)
"The 64-bit IBM zSeries (2001) still supports 24-bit mode,
40-plus years later. Why did 24-bit happen? I’m told that it was
all for the sake of one low-cost early model,
]
Sent: Tuesday, November 30, 2021 10:53 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
In our case, the caller doesn't "know" whether the called subroutine is
base 31 or base 64. So it is up to the called subroutine to "figure out"
whether the caller used
On 30/11/2021 16:36, Paul Gilmartin wrote:
Didn't IBM do that?
Doesn't mean that it was a good idea :-)
"The 64-bit IBM zSeries (2001) still supports 24-bit mode,
40-plus years later. Why did 24-bit happen? I’m told that it was
all for the sake of one low-cost early model, the 360/30,
where
On Nov 30, 2021, at 09:10:03, Martin Ward wrote:
>
> On 30/11/2021 15:53, Mark Hammack wrote:
>> using the high half of R14 may be an option. ...
>
> Does anyone still remember the problems caused by clever
> programmers using the top 8 bits of a 24 bit address to store data
>
Didn't IBM do
That's exactly what I was thinking about using "may" :-). Just because it
is below the bar today doesn't mean it won't be in a few years (after I
retire). I'm not a fan of someone looking at the code in the future and
saying "why the did they do that!".
*Mark*
On Tue, Nov 30, 2021 at
say in the save area
format.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Mark Hammack
Sent: Tuesday, November 30, 2021 7:54 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
In our case, the caller does
On 30/11/2021 15:53, Mark Hammack wrote:
using the high half of R14 may be an option. ...
Does anyone still remember the problems caused by clever
programmers using the top 8 bits of a 24 bit address to store data
when the code had to be ported to 31 bit mode?
"Those that fail to learn from
SEMBLER-LIST@LISTSERV.UGA.EDU
> ]
> On Behalf Of Peter Relson
> Sent: Tuesday, November 30, 2021 5:39 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base-less macros
>
> Steve Smith wrote:
> >And there are other bizarre ways to return without
> >restorin
]
On Behalf Of Peter Relson
Sent: Tuesday, November 30, 2021 5:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Steve Smith wrote:
>And there are other bizarre ways to return without
>restoring R14, which is not actually required by documented conventions.
Only restoring o
Steve Smith wrote:
>And there are other bizarre ways to return without
>restoring R14, which is not actually required by documented conventions.
Only restoring of AR14 and the high half of R14 are required (for
non-AMODE 64 cases), in general.
(Although I would guess that there are many
As per the FPR usage thread, you could also save GR(s) to FP registers 0 thru 7.
Robert
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Charles Mills
Sent: Monday, November 29, 2021 18:03
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
I did
f Charles Mills
Sent: Monday, November 29, 2021 3:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
LLILF and C?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Mark Hammack
Sent: Monday, Novem
Well, I messed up CLRL... it is not an SS-like instruction.
If you really can't afford to trash half of any general register, AR0 is a
convenient hidey-hole. It's the appendix of z/Arch, as it appears to have
no functional purpose. If AR0 can't be trashed, then surely you can borrow
a FPR. If
CLRL 04(r13),=C'F4SA' ...you have USING issues, but as long as LTORG is
within +/- 2G, no problem.
I'd go with
LLIHF 0,C'F4SA'
CLHF 0,4(R13)
or
LFH 0,4(R13)
CLIH 0,C'F4SA'
So many ways to skin the cat.
As usual, not tested, subject to typos, memory checks, etc.
sas
On Mon, Nov 29, 2021 at
LLILF and C?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Mark Hammack
Sent: Monday, November 29, 2021 2:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
So an interesting dilemma:
I have
notify us by reply mail or telephone and delete the original message from your
mail system.
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com]
Sent: Monday, November 29, 2021 3:57 PM
To:ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subje
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com]
> Sent: Monday, November 29, 2021 3:57 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Base-less macros
>
&g
DU
Subject: Re: Base-less macros
Using R14 as a temporary code base after a call isn't going to work in
those cases. I'd never heard about using BIC to return (nor can I see much
reason for it). And there are other bizarre ways to return without
restoring R14, which is not actually required by
du/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com]
Sent: Monday, November 29, 2021 3:57 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
The assembler services guide doesn
Using R14 as a temporary code base after a call isn't going to work in
those cases. I'd never heard about using BIC to return (nor can I see much
reason for it). And there are other bizarre ways to return without
restoring R14, which is not actually required by documented conventions.
For BASSM,
, November 29, 2021 14:01
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote:
>
> DON'T DO THAT!
> I had to find/redo all our code that did this when our subroutine return
> logic was changed to use a BIC
On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote:
>
> DON'T DO THAT!
> I had to find/redo all our code that did this when our subroutine return
> logic was changed to use a BIC instruction.
>
Which of you violated standard linkage conventions?
My understanding is that R14 is
@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
My suggestion of using R14 for the base was because it's already set by the
call to the subroutine.
sas
On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold wrote:
> The performance consideration I think would be the loading of R14
> immediately before i
On Nov 25, 2021, at 12:49:20, Steve Smith wrote:
>
> My suggestion of using R14 for the base was because it's already set by the
> call to the subroutine.
>
RR15? (BALR 14,15)
-- gil
-LIST@LISTSERV.UGA.EDU] on behalf
of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu]
Sent: Thursday, November 25, 2021 2:11 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Nice job and thanks for correction on branch to table. One thing to point out
especially
My suggestion of using R14 for the base was because it's already set by the
call to the subroutine.
sas
On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold wrote:
> The performance consideration I think would be the loading of R14
> immediately before its use in the branch instruction. Moving it
BLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
CAUTION: This message was sent from outside the company. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
It could be shorter, and B BRTAB(R15) is not baseless. How about
Mainframe Assembler List on behalf
of Seymour J Metz
Sent: Thursday, November 25, 2021 8:31 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
CAUTION: This message was sent from outside the company. Do not click links or
open attachments unless you recognize the sender
lto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Thursday, November 25, 2021 6:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
It could be shorter, and B BRTAB(R15) is not baseless. How about
CIJL R15,0,RC_MINUS
CIJH R15,MA
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Here's another form of branch table combining compare and branches. Just
thought it was interesting and one reason why I love assembler. So many
possibilities.
XR R0,R0 INCREMENT
ubject: Re: Base-less macros
CAUTION: This message was sent from outside the company. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
In light of subsequent messages, yes.
From: IBM Mainframe Assemble
: Tuesday, November 23, 2021 10:21
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
...some BASR R14, or JAS R14, etc.
USING *,R14
B *+4(R15)
DROP R14
JRC0ROUTINE
JRC4ROUTINE
JRC8ROUTINE
sas
In light of subsequent messages, yes.
From: IBM Mainframe Assembler List on behalf
of Tony Thigpen
Sent: Tuesday, November 23, 2021 1:33 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
I think Martin is really commenting
, Robert (DXC Luxoft)
Sent: Tuesday, November 23, 2021 2:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Or even simpler:
CLIJE R15,0,RC0ROUTINE
CLIJE R15,4,RC4ROUTINE
CLIJE R15,8,RC8ROUTINE
CLIJE R15,12,RC12ROUTINE
J UnexpectedRC
Robert Ngan
DXC Luxoft
-Original
RE: Base-less macros
Seymour J Metz
Tue 11/23/2021 12:48 PM
> Maybe I missed something?
Actually, I did; the LARL is necessary. Sorry.
> I had started to use:
It would have been correct with an ALR or LA rather than an L.
> they're cleaner than trying to use the select structured m
I vote for this one!
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ngan, Robert (DXC Luxoft)
Sent: Tuesday, November 23, 2021 11:44 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Or even
checking?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Martin Ward [mar...@gk
* To make Seymour happy,...
I certainly do like that comment,
Just for the record- there are lots of comments like this in all kind of
programs for all kind of purposes:
* since Martin insisted: here is
whatever.
Best
Martin
Oops, I didn't notice Pieter's response.
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Ngan, Robert (DXC Luxoft)
Sent: Tuesday, November 23, 2021 13:44
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Or even simpler:
CLIJE
-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Or
CIJE R15,0,RC0ROUTINE
...etc
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Watkins, Doug
Sent: Tuesday, 23 November 2021 20:00
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject
@LISTSERV.UGA.EDU] on behalf
of Martin Ward [mar...@gkc.org.uk]
Sent: Tuesday, November 23, 2021 12:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On 23/11/2021 17:12, Seymour J Metz wrote:
LTR R15,R15
JMBADIX
CHI R15,LIMIT
Or
CIJE R15,0,RC0ROUTINE
...etc
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Watkins, Doug
Sent: Tuesday, 23 November 2021 20:00
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Mark,
Another vote
Alternatively, consider the BRANCH INDIRECT ON CONDITION (BIC) instruction
(available on the z14). The second operand of BIC is an 8-byte location in
memory from which the branch address is fetched.
BIC was designed to assist Java in returning from a garbage collection
operation, where the
, November 23, 2021 10:42 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Re: Base-less macros
So as a related question, I started working on a 'baseless' version of a branch
table macro I wrote years ago. I have it working but was curious what other
people have done.
In 'based' code
t;
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Charles Mills [charl...@mcn.org]
> Sent: Tuesday, November 23, 2021 11:24 AM
> To: ASSEMBL
, 2021 12:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On 23/11/2021 17:12, Seymour J Metz wrote:
> LTR R15,R15
> JMBADIX
> CHI R15,LIMIT
> JHBADIX
> TML R15,3
> JNZ BADIX
>
, 2021 12:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
How about fixing the problem you had with branch tables and introducing
a new instruction JIC (branch relative indexed conditional)?
JIC *+4(15),nn
J RC0ROUTINE
J RC4ROUTINE
J RC8ROUTINE
J RCERR_RTN
Where
On 23/11/2021 17:12, Seymour J Metz wrote:
LTR R15,R15
JMBADIX
CHI R15,LIMIT
JHBADIX
TML R15,3
JNZ BADIX
J *+4(R15)
BRTABEQU *
J RC0ROUTINE
J RC4ROUTINE
J
ember 23, 2021 7:42 AM
To:ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
So as a related question, I started working on a 'baseless' version of a
branch table macro I wrote years ago. I have it working but was curious
what other people have done.
In 'based' code, it typically gener
, November 23, 2021 11:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
Should that second instruction be an LA?
I quit using branch tables. I know, they are useful, but IMHO wild branches are
the worst of bugs, and so I have eschewed branch tables.
The architecture could
: Re: Base-less macros
So as a related question, I started working on a 'baseless' version of a
branch table macro I wrote years ago. I have it working but was curious
what other people have done.
In 'based' code, it typically generates something like:
B *+4(15)
BRC0ROUTINE
BRC
Mark,
(I do not really get the replacement-code. Maybe I did not look long
enough)
My solution to your problem:
B *+4(15)
BRC0ROUTINE
BRC4ROUTINE
BRC8ROUTINE
is this:
LR15,=A(RC0ROUTINE,RC4ROUTINE,RC8ROUTINE)(15)
BR R15
Preserves R14 (but eats up space in literal-pool)
...some BASR R14, or JAS R14, etc.
USING *,R14
B *+4(R15)
DROP R14
JRC0ROUTINE
JRC4ROUTINE
JRC8ROUTINE
sas
So as a related question, I started working on a 'baseless' version of a
branch table macro I wrote years ago. I have it working but was curious
what other people have done.
In 'based' code, it typically generates something like:
B *+4(15)
BRC0ROUTINE
BRC4ROUTINE
BRC8ROUTINE
etc.
This draft document, entitled Register Constraint Relief 2021,
coincidentally addresses the subject of Base-less/Base-free Macros. See
references to Base Address Register (BAR) 15 and relative addressing for
all base/displacement operands..
Wendell wrote:
> From Tony's explanation concerning moving the TR command to the data area
via LOCTR, can I surmise that it might be counter-productive to do so--that
leaving the TR and EX commands in consecutive memory is more efficient?
My $0.02 is that I'm not so sure about the "do it once
] on behalf
of Keith Moe [ke...@sbcglobal.net]
Sent: Thursday, November 11, 2021 4:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
Actually the inline TR/EX will do the TR the first time for ONE byte, not 256,
followed by the EX of the specified length
, November 10, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I'm reluctant to admit this, but I'm still unclear about SIIS is
] on behalf
of Tony Harminc [t...@harminc.com]
Sent: Wednesday, November 10, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I
Lovewell [09624390d784-dmarc-requ...@listserv.uga.edu]
Sent: Thursday, November 11, 2021 12:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Avoiding SIIS - (Was Base-less macros)
Adam & Tony--thanks for the good explanations.
>From Tony's explanation concerning moving the TR
Adam & Tony--thanks for the good explanations.
From Tony's explanation concerning moving the TR command to the data area via
LOCTR, can I surmise that it might be counter-productive to do so--that leaving
the TR and EX commands in consecutive memory is more efficient?
> Example 2:
>
If size isn't a problem:
"skel64" is csect name:
* Round start of data to next 256-byte boundary to separate from ipipe
zArchorg skel64+(((*+256)-skel64)/256)*256
LTORG
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell
<09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
>
> I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could
> someone please explain what happens to the D- and I-cache in these situations?
I can tell you my
For current processors, 256 bytes.
Some IBMers talking with us on these topics suggested a macro called
NEXTCLB,
which inserts some space depending on some address arithmetic.
IMO, if you use this, you could adjust it later if a future processor
requires more.
(256 is a constant used inside
How do you ensure that your storage areas are far enough away from the code to
not be in the instruction cache line, when your data isn't in GETMAIN storage?
You can mitigate by putting constants in between, but how do you know if that's
enough?
For the first 2 examples, those are not SIIS violations because no
modification of storage takes place. The modification of the instruction
happens in the core itself (I once heard it called the "instruction
register" where this happens... I can't verify the validity of that
statement).
In
I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could
someone please explain what happens to the D- and I-cache in these situations?
Example 1:
TxtTRNull TR0(*-*,R14),NoNulls
EX R5,*-6
Example 2:
PgmConst LOCTR ,
TxtTRNull TR
The documentation update for APAR PH34824, for the alignment of
literals referenced by relative address, has now been completed.
https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=instruction-literal-pool
It seems it was overlooked after being transferred from our old
request tool to the new - a
If you provide the option of specifying labels or literals, it is up to the
end user to provide addressability to the literals.
I would not be against a keyword such as PERFORMANCE=CRAP to force the data
items inline so that no end-user data area is needed.
On Mon, 8 Nov 2021 09:09:42 +0100
...@phoenixsoftware.com]
Sent: Tuesday, November 9, 2021 1:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less macros
On 11/9/2021 9:55 AM, Seymour J Metz wrote:
> LOCTR may not help with literals, but it can help with macros that generate a
> DC. Instead of branching around the constan
On 11/9/2021 9:55 AM, Seymour J Metz wrote:
LOCTR may not help with literals, but it can help with macros that generate a
DC. Instead of branching around the constant, put a LOCTR before and after it.
There is no guarantee a existing USING is in place for a literal or DC
in a given LOCTR.
1 - 100 of 143 matches
Mail list logo
