Re: Relative Branches / IBM macros

[Tom Marchant]

On Fri, 5 Apr 2013 22:29:03 +0200, Bernd Oppolzer wrote:

>There is also a LOOP macro in the SP macro set, which generates in some
>cases
>(in the NORENT case) a decimal loop counter, which is in defined inline,
>near the
>loop instructions.

You might want to look at using LOCTR instructions to group data areas
together. My entry macro includes code similar to this:

J BEGIN
DATA LOCTR
DC C'Program identifiers, etc'
CODE LOCTR
BEGIN DS 0H


Later in the code, if I want to define a data area, I can include:

(instructions)
DATA LOCTR
DC (whatever)
CODE LOCTR
(More instructions)

Then at the end of the program, I code

DATA LOCTR
LTORG

All of the data areas are then grouped by the assembler at the beginning of
the program, covered by a base register that points to the beginning.

--
Tom Marchant

[John Ehrman]

>And only if the target is relatively addressable. I.e. In the same section
>or object.

>sas (phone)
>>On Apr 5, 2013 7:21 PM, "John Ehrman" <ehr...@us.ibm.com> wrote:
>> You can use LARL to replace LA only if the target is at an even address.
>> John Ehrman

This may not be relevant to the original question, but you CAN declare an
external symbol in the operand field of a relative-immediate instruction.

The object module encodes the "relative-adcon" type and the binder resolves
the external reference (again assuming the target is at an even address).

John Ehrman

[Robert Ngan]

Going one step further, define TWO data location counters, one for stuff
that is required to be within 4K of the static base register i.e. are
referenced by SS instructions, and another for stuff that can be referenced
by instructions with displacements larger than 4K (i.e. via LY, STY, LLC,
LARL etc).

Robert Ngan
CSC Financial Services Group

[Bernd Oppolzer]

Hello all,

thank you again for keeping up this discussions.

This reminds me that I have still some things to work on, that is: the
loop counters
in the mainline of our ASSEMBLER programs.

What I've done so far:

We have a macro called ANFEND, which does the definition and
initialization of an
arbitrary number of base registers, which in the past covered the code
area and the
static data area of the mainline of the programs.

I changed this, while maintaining downward compatibility, to support now
"code area
baseless coding", by introducing new keyword parms.

RELB=YES generates SYSSTATE ARCHLVL=2, IEABRCX DEFINE etc.

The code area is in general supposed to be located before the static
data area. So I
introduced two new keyword parms:

BASE2=ADR means, that the second base reg and the following should cover
the
area from ADR, that is: the static data area. The first base reg then
covers the first
4k of the code area, and the 2nd and the following cover the static data
area; the
area following the first 4k of the code area is not covered by base regs.

BASE1=ADR means, that the code area is NOT covered by any base reg; only
the static data area is covered by base regs (from base reg 1 up to base
reg n).

The subroutines start with AVMANF and end with AVMEND. In the past, they
were
restricted to two base regs, that is, 8k. Now, with RELB=YES (specified
on ANFEND), the
second base reg coveres the area after AVMEND (for the local static
data), so
the area between AVMANF and AVMEND (for the code) may grow.

There are also new macros AVPROC / AVPEND, which work almost like AVMANF
/ AVMEND,
but there the base regs don't cover the code area, but only the (up to)
8 k static area
after AVPEND. AVPROC/AVPEND are only allowed with RELB=YES.

The loop counter fields are defined after AVMEND / AVPEND in the data
area (I don't
need LOCTR to do this).

When the global symbol &AVGBTRC is set to 1, every AVMANF / AVMEND is traced
on a file called PUTLIST (at runtime).

What is still missing:

- there is a macro needed to generate the outstanding loop counter
definitions from
the LOOP macros in the mainline (there is no end macro corresponding to the
ANFEND)

- some of our (several hundred ) other macros don't work in a "code area
baseless"
environment, because they generate (for example) inline definitions and
LA. I will
have to change them step by step. For the moment, the solutions are
twofold:
move them into a AVMANF / AVMEND block which is less than 4k, or
etablish a temporary base reg around them.

Anyway: if management allows me to do so, I will change all the macros
to support
this kind of coding, because the remaining developers have much less trouble
dealing with addressibility issues, and existing programs can be
extended with
trace facilities etc. - which already helped me in solving some
difficult problems
that existed for years !!

My conclusion is: this makes ASSEMBLER development much easier and more fun!

Kind regards

Bernd

--
Bernd Oppolzer
---------------------------------------------------------------
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
B�renhofstra�e 23
70771 Leinfelden-Echterdingen
---------------------------------------------------------------
Tel.: +49 711 2272522
priv.: +49 711 7949590
eMail: bernd.o...@t-online.de <mailto:bernd.o...@t-online.de>
---------------------------------------------------------------
F�r Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
---------------------------------------------------------------
Jubil�umsjahr 2013:
30 Jahre Oppolzer-Informatik

[Steve Smith]

External relative addressing does work, yet HLASM still warns about this,
e.g. "ASMA215W Relative Immediate external relocation in NOGOFF object text
- ESTAE_RESUME "

Is there any cure for this? My production build process doesn't tolerate
any return code that isn't a multiple of 0.

I haven't tried it, but I'd guess that if you tried to run such a module
through the old linkage-editor that it would produce a suitable error
message. So there shouldn't be any need for the HLASM warning.

sas

--
sas

[John Ehrman]

The reason is that other z platforms (VM, VSE, zLinux) don't support
relative-immediate external references.

An easy way to suppress the diagnostic is to specify SUPRWARN(215) as an
invocation parameter or on a *PROCESS statement at the head of the source
program.

Steve Smith asked:

[Gord Tomlin]

On 2013-11-14 14:18, Steve Smith wrote:
> External relative addressing does work, yet HLASM still warns about this,
> e.g. "ASMA215W Relative Immediate external relocation in NOGOFF object text
> - ESTAE_RESUME "
>
> Is there any cure for this? My production build process doesn't tolerate
> any return code that isn't a multiple of 0.
>
> I haven't tried it, but I'd guess that if you tried to run such a module
> through the old linkage-editor that it would produce a suitable error
> message. So there shouldn't be any need for the HLASM warning.
>
> sas

We dealt with that by adding GOFF,LIST(133) to our HLASM options. The
linkage editor happily processes the resulting object modules.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

[Bauer, Bobby (NIH/CIT) [E]]

I am out of the office until Monday Nov. 18th

[Peter Relson]

>We dealt with that by adding GOFF,LIST(133) to our HLASM options

As do we when we have this case. It's harmless and has no downside.

>But you CAN declare and external symbol in the

>operand field of a relative-immediate instruction.

I'm not sure that is true in general. You can definitely do it for LARL
and BRASL.
I don't know about the long immediates.

For example, I tried
extrn E
llilf 1,A(E)
** ASMA044E Undefined symbol - A
** ASMA173S Delimiter error, expected blank - (E)
And similarly using V(xx) is not accepted either.

Of course for this case, LARL gives the same result if the area is
halfword-aligned (but if you could do A(E+X'80000000') it wouldn't give
the same result. Note that even if the assembler were to support this,
it's not obvious if the binder and/or z/OS loading does. And in practice,
it's not obvious that there's any practical benefit (for example,
halfword-aligning is not often a difficulty)

Peter Relson
z/OS Core Technology Design

[Litwinowich, David]

Out of the office, returning Nov. 18.

[David Stokes]

Well, in fact you wouldn't write that A(...) or V(...) would you, rather

EXTRN TESTSTUA

LARL R15,TESTSTUA
LLILF R15,TESTSTUA

However LARL works, LLILF still gives you a message

** ASMA032E Relocatable value or unresolved symbol found when absolute value required - TESTSTUA



-----Urspr�ngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von Peter Relson
Gesendet: 15 November 2013 14:05
An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: Relative Branches / IBM macros

[Peter Relson]

>Well, in fact you wouldn't write that A(...) or V(...) would you, rather
> EXTRN TESTSTUA
> LARL R15,TESTSTUA
> LLILF R15,TESTSTUA

For LARL yes (and that is exactly how you use this function now) since the
operand is something for which it is expected to take the address (and
would normally have to be resolved by base/displacement).

For LLILF I would have said no since the LLILF operand is an "immediate".

[Lenz Boris]

Thank you for your message. I will take care of your email after November 24th, 2013. For urgent issues, please contact "AXA-BOX IMS Online & DB" (ims.o...@axa-tech.com).
---------
Danke für Ihr E-Mail. Ich werde Ihre Nachricht ab dem 25.11.2013 wieder persönlich bearbeiten können. In dringenden Fällen wenden Sie sich bitte an "AXA-BOX IMS Online & DB" (ims.o...@axa-tech.com).

[Martin Truebner]

Oups- I was about to replace a TR routine (loop for 256 and an extra
for the remainder)

Fortunately I did read POPs first- TRE does not have a mask bit to avoid
stopping on a match with R0

AND-

the results for overlapping operands are unpredictable

I can work around the overlap - but for the "match with r0" case I have
to have extra code.

why is that so?

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[Mark Boonie]

Given a recent enough machine (z9 or later), you could use TROO instead.

- mb

IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> wrote on
11/17/2013 08:23:59 AM:

[John Gilmore]

It is convenient to load r0 with a nul, x'00', when processing a C/C++
nul-delimited string 'of conceptually unlimited length'; and in many
other circumstances doing so is innocuous.

John Gilmore, Ashland, MA 01721 - USA

[David Stokes]

Peter Relson wrote: For LLILF I would have said no since the LLILF operand is an "immediate".



Well, I don't agree. Immediate operands are absolute expressions. Witness the fact that you get the "Symbol A undefined" error just the same writing say

CLI label,A(123)

(or AL1 for that matter), whereas LLILF clearly recognizes the symbol as being external/relocatable, but doesn't like that. It happily accepts say



XX DS 0H

......

LLILF R15,XX-*



(whatever sense that might make).

[Robert A. Rosenberg]

At 09:38 +0000 on 11/18/2013, David Stokes wrote about Re: Relative
Branches / IBM macros:

I think it is choking on the symbol being an external not just a
relocatable. The latter it can compute. It might be interesting to
see what happens if XX is in a different CSECT from the LLILF (ie:
Will it accept it and adjust for the fact that the offset to the
CSECT is unknown until Bind Time - you know the offset in the
assembly but the Binder may move the 2 CSECTs apart).

[Steve Hazzard]

I'm currently out of the office.

I'll reply to your note as soon as I return to the office.

Have a great day,

Steve

[David Stokes]

Well, as I said, the HLASM manual says that immediate operands must be absolute expressions, so end of story it seems. OTOH LARL handles both relative and external, if not functionally exactly the same. (My point was actually that you can't put A(), V(), F' ' etc. into an expression, they are not self-defining terms, like C' ', B' ', X' '.)

-----Urspr�ngliche Nachricht-----
Von: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] Im Auftrag von Robert A. Rosenberg
Gesendet: Dienstag, 19. November 2013 01:37
An: ASSEMBL...@LISTSERV.UGA.EDU
Betreff: Re: Relative Branches / IBM macros

[John Gilmore]

David Stokes writes:

<begin extract>

(My point was actually that you can't put A(), V(), F' ' etc. into an
expression, they are not self-defining terms, like C' ', B' ', X'
'.)

</end extract>

and F' ' seems to me to be an even odder bedfellow for A( ) and V( )
than A( ) and V( ) are for each other here.

The argument that V-type adcons are not self-defining at assembly time
is compelling; for the rest . . .

[Steve Smith]

One could always overlay an address into place:

0000007C 0700 130 CNOP
2,4
0000007E C0FF 0000 0000 00000000 131 LLILF
RG15,0
00000084 00000084 00000080 132 ORG
*-4
00000080 00000000 133 DC
V(CAAINIT)

I agree that between LARL and LAY (which have been supported much longer)
it's not likely you really need to do this.


sas

--
sas

[Bob Raicer]

It seems to me that the real problem is that the assembler is
inconsistent with respect to the evaluation of expressions and using
the result of such an evaluation in various contexts.

The HLASM Language Reference clearly states the requirement of
Immediate Data operands for machine instructions:

Immediate data

In addition to registers, numeric values, relative addresses,
and lengths, some machine instruction operands require
immediate data. Such data is assembled directly into the
object code of the machine instructions. Use immediate data
to specify the bit patterns for masks or other absolute
values you need.

Specify immediate data only where it is required. Do not
confuse it with address references to constants and areas, or
with any literals you specify as the operands of machine
instructions.

Immediate data must be specified as absolute expressions
whose range of values depends on the machine instruction for
which the data is required. The immediate data is assembled
into its binary representation.

The HLASM Language Reference defines an Absolute Expression as shown
below:

Absolute expression: An absolute expression is one whose
value remains the same after program relocation. The value
of an absolute expression is called an absolute value.

An expression is absolute, and is reduced to a single
absolute value if the expression:

1. Comprises a symbol with an absolute value, a
self-defining term, or a symbol length attribute
reference, or any arithmetic combination of absolute
terms. The absolute terms can include Integer and Scale
attributes, but not Type attributes.

2. Contains relocatable terms alone or in combination with
absolute terms, and if all these relocatable terms are
paired.

Paired relocatable terms: An expression can be absolute even
though it contains relocatable terms, if all the relocatable
terms are paired. The pairing of relocatable terms cancels
the effect of relocation.

The assembler reduces paired terms to single absolute terms
in the intermediate stages of evaluation. The assembler
considers relocatable terms as paired under the following
conditions:

. The paired terms must have the same relocatability
attribute.

. The paired terms must have opposite signs after all unary
operators are resolved. In an expression, the paired
terms do not have to be contiguous (that is, other terms
can come between the paired terms).

The assembler permits relocatable expressions in the operands of
Relative Immediate instructions (such as Load Address Relative Long
[LARL], Branch Relative on Condition [BRC], etc.).

For instructions in which one or more operands must be Immediate
Absolute values (such as Compare Logical Immediate [CLI], Load
Halfword Immediate [LHI], etc.), the assembler disallows the use of
"paired relocatable terms" in an Absolute Expression when any of those
terms require creating an entry in the Relocation Dictionary. In my
opinion, this is an unnecessary restriction, but it is what it is.

Bob

[Paul Gilmartin]

On 2013-11-19, at 08:34, Bob Raicer wrote:
>
> For instructions in which one or more operands must be Immediate
> Absolute values (such as Compare Logical Immediate [CLI], Load
> Halfword Immediate [LHI], etc.), the assembler disallows the use of
> "paired relocatable terms" in an Absolute Expression when any of those
> terms require creating an entry in the Relocation Dictionary. In my
> opinion, this is an unnecessary restriction, but it is what it is.
>

When would an RLD entry be required? The assembler ought to be
able to reduce any pair of terms having the same relocatability
attribute and opposite sign to an Absolute value?

Is any of this restriction due to Binder's inability to relocate
bit fields of all lengths and offsets (even discontiguous)
supported nowadays in machine instructions?

-- gil

[John Ehrman]

Paul Gilmartin asked:

>The assembler ought to be
>able to reduce any pair of terms having the same relocatability
>attribute and opposite sign to an Absolute value?

>Is any of this restriction due to Binder's inability to relocate
>bit fields of all lengths and offsets (even discontiguous)
>supported nowadays in machine instructions?

HLASM does appear to handle paired relocatable terms as absolute:

000000 00000 00010 1 rr csect
R:F 00000 2 using *,15
000000 3 a ds f
000004 4 b ds f
000008 A718 0004 00004 5 lhi 1,b-a
00000C 9504 F000 00000 6 cli a,b-a
7 end

Extending similar support to the Binder would require major extensions to
existing object module formats; and to date, there seems to have been no
need for it.

John Ehrman

[Martin Truebner]

Help- I have read POP-8 (ver 9) more than once

I get a SOC6 on a z10 against a KM instruction

KM 6,4

Function code is 18

Password is addressed by by parmblock

R6 is somewhere

R4 is the code to encode

R5 is X'20'

What could be wrong? I am lost and I hope to find someone that
understands what I am saying.

[Lennie J Dymoke-Bradshaw]

If you look in Appendix A of this manual,

http://www.redbooks.ibm.com/abstracts/sg247848.html?Open

You will find an example of the KMC instruction used in module CPACF010.
This should show you how to use both KM and KMC. You should be able to
assemble this module and convince yourself it works.

Lennie Dymoke-Bradshaw MBCS CITP
Accredited Senior I/T Specialist, System z, Security and Cryptography, IBM
Software Group
Mail: Lennie J Dymoke-Bradshaw/UK/IBM@IBMGB or
Lennie_...@uk.ibm.com
There are two types of people in the world; those who have been hacked,
and those who will be hacked.

From: Martin Truebner <Mar...@pi-sysprog.de>
To: ASSEMBL...@listserv.uga.edu,
Date: 19/11/2013 19:33
Subject: Specification exception on a z10
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@listserv.uga.edu>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Bernd Oppolzer]

Hello Martin,

I don't have practical experience with KM.

The only reasons for Specification Exception on KM are:

a) unknown function code in GPR0
b) odd register number in R1 or R2 - which is obviously not the case
c) the length in R2+1 (R5 in your case) is not a multiple of the block size
specific to the desired function (16 in your case, function code 18 =
KM-AES-128).
Which is not the case, because you put X'20' into R5 prior to KM.

So I don't see an obvious reason for the specification exception.

I would suggest that you double check the contents of
GPR0 and GPR5, just to check for the cases a) and c) from above.

Good luck, kind regards

Bernd

[Tony Thigpen]

I have come across this before.

Not all z-boxes have all the KM features enabled. Because of
import/export rules, the boxes are shipped without the features enabled.
Upon installation, they are turned on by IBM as a no-charge micro-code
update, as long as the box is in a country that can have the feature.

In the case where I saw this, nobody had installed the feature for the
first user of the box. It had been resold, so was no longer eligible.

Have you tested the code on another physical box?

Have you done a KM Query (function code is 0) to see what encryption is
available?


Tony Thigpen

[Martin Truebner]

Thanks to all that gave a hint - It is now in the hands of a
HW-technician

I have (meanwhile) written a KM Query and
it shows on my CPU everything is enabled and on the other nothing
(first 4 bytes are =80000000) comes back.

[Bernd Oppolzer]

That is:

KM is known to the machine - if not, this should be S0C1, not S0C6.

But all function codes are disabled, so function code 18 is not known
to the machine, so the S0C6. Is this correct?

This is not very nice: there should be mentioned in the PoOp that the
different functions of KM have to be enabled individually, and that
that may be another reason for S0C6.

Kind regards

Bernd

[Rob van der Heij]

On 20 November 2013 09:50, Bernd Oppolzer <bernd.o...@t-online.de>wrote:


> KM is known to the machine - if not, this should be S0C1, not S0C6.
>
> But all function codes are disabled, so function code 18 is not known
> to the machine, so the S0C6. Is this correct?
>
> This is not very nice: there should be mentioned in the PoOp that the
> different functions of KM have to be enabled individually, and that
> that may be another reason for S0C6.
>

"Yes we know what KM is, and no you have not enabled the priceless feature
that makes me do it for you!"

Isn't this exactly as expected? Once enabled, the query will show you which
particular cryptic operations are provided for that model. With Linux we
learned that even when your hardware can, it depends on the particular
libica version whether it will use it.

Rob (who considers it unwise that we did not get instrumentation at least
to count them)

[Bob Raicer]

Here is an example of what I was trying to describe:

ABLE CSECT ,
EXTRN IEFBR14

USING ABLE,R7
LARL R15,IEFBR14
BRC 0,IEFBR14
LHI R15,(IEFBR14-ABLE)
LHI R15,(SECOND-FIRST)


OFFSET DC A(IEFBR14-ABLE)
FIRST DC F'1'
SECOND DC F'3'


And here are some snippets from the assembly listing:

00000000 C0F0 0000 0000 00000000 22 LARL R15,IEFBR14
00000006 A704 0000 00000000 23 BRC 0,IEFBR14
0000000A 0000 0000 00000000 24 LHI R15,(IEFBR14-ABLE)

** ASMA032E Relocatable value or unresolved symbol found when absolute value required -

(IEFBR14-ABLE)
** ASMA435I Record 24 in RAICER.TEMP.SOURCE(SIMPLE) on volume: DV2D19
0000000E A7F8 0004 00000004 25 LHI R15,(SECOND-FIRST)

00000024 00000000 30 OFFSET DC A(IEFBR14-ABLE)
00000028 00000001 31 FIRST DC F'1'
0000002C 00000003 32 SECOND DC F'3'


Relocation Dictionary
Pos.Id Rel.Id Address Type Action
00000004 00000006 00000002 RI 4 +
00000004 00000006 00000008 RI 2 +
00000004 00000004 00000024 A 4 -
00000004 00000006 00000024 A 4 +


Statements 22 and 23 cause entries to be placed in the Relocation
Dictionary which indicate the Relocation Type is Relative Immediate
and the size (in bytes) of the corresponding item to be adjusted by
the relocation processing is four and two, respectively.

For statement 24, entries in the Relocation Dictionary would be
required in order to compute the Absolute Value of the expression
during relocation processing, much like the RLD entries necessary to
resolve the same expression for statement 30.

And, yes, binder support is required for this, much like the binder
support needed to handle the RLD items for statements 22 and 23.

Bob

[Jon Perryman]

The binder can handle the relocation without a problem. If you have any doubt about it, then change OFFSET to use AL2 instead of A.

Having the LHI fail with the external reference is a good thing. I personally think that BRC with an external label should also be flagged as an error (at the very minimum a warning). Halfwords have a range from -32767 to 32767. Everything works fine until one day a re-link causes these limits to be exceeded causing you to add ORDER statements or modify the programs to remove these. 

LARL allows 16M relative addressability so it is fine.

You really need to ask yourself when we've gone to far in making it easy for newbies to easily shoot themselves in the foot.

Jon Perryman.

>________________________________
> From: Bob Raicer <r...@raicer.com>