Is the AFP control bit (big #13 in CR0) testable in an application?

[Thomas David Rivers]

I was hoping to determine if a program is allowed
to use the Additional Floating Point (AFP) registers.

There are two qualifications for this; first the "basic floating point
extensions"
has to be installed (which can be assumed after OS/390 2.6) and
second, the AFP CONTROL BIT of Control Register 0 has to be enabled
(bit #13.)

So - while the hardware allows it, it's possible - for some reason or
other -
the control register disallows it.

I'm looking around in the various locations (CVT, PSA, etc...) and hunting
for a mechanism where an application program can ask "Am I allowed to
use all 16 floating-pt registers, or am I restricted to the traditional 4?"

Is there an assembler service somewhere that provides the value of control
registers? You can just use STORE CONTROL (STCTL) instruction as it is
privileged.

- Many thanks -
- Dave Rivers -

[Steve Smith]

LDR R1,R1 - If you get an "AFP-register data exception (DXC 1)." then
no. I don't know, and can't experiment to see how this presents
itself if no recovery is provided.

sas

Post by Thomas David Rivers
I was hoping to determine if a program is allowed
to use the Additional Floating Point (AFP) registers.
There are two qualifications for this; first the "basic floating point
extensions"
has to be installed (which can be assumed after OS/390 2.6) and
second, the AFP CONTROL BIT of Control Register 0 has to be enabled
(bit #13.)
So - while the hardware allows it, it's possible - for some reason or other
-
the control register disallows it.
I'm looking around in the various locations (CVT, PSA, etc...) and hunting
for a mechanism where an application program can ask "Am I allowed to
use all 16 floating-pt registers, or am I restricted to the traditional 4?"
Is there an assembler service somewhere that provides the value of control
registers? You can just use STORE CONTROL (STCTL) instruction as it is
privileged.
- Many thanks -
- Dave Rivers -
--
Get your mainframe programming tools at http://www.dignus.com

[Greg Dyck]

Post by Thomas David Rivers
So - while the hardware allows it, it's possible - for some reason or
other -
the control register disallows it.

To limit overhead when saving and restoring status for a unit of work
z/OS *always* performs the initial dispatch with CR0.45 set to 0.

Upon execution of the first instruction requiring the additional
floating point registers a save area for them will be allocated and they
will be saved and restored from that point on until IEAFP is used to
stop it.

So if CR0,45 is off, do *not* assume you can not use the registers. I
believe they are always be safe to use in task mode. I don't remember
if SRB mode is the same as task mode. But don't even think about using
these registers while executing within an interrupt handler.

Regards,
Greg

[Greg Dyck]

Post by Greg Dyck
Upon execution of the first instruction requiring the additional
floating point registers a save area for them will be allocated...

I realized after I sent this that I mixed up changes made in support of
vector (and now SIMD) and additional floating point registers. There is
no need to allocate a save area for the additional floating point
registers but everything else is correct.

For tasks there is space in STCBAFPR to hold them and STCBBFP will be
set on execution of the first instruction to start saving and restoring
them. For SRBs there is space in SSRXAFPR to hold them and SSRXBFP will
be set on execution of the first instruction to start saving and
restoring them.

Regards,
Greg

[Jim Mulder]

In the old days, you would check

CVTBFP EQU X'10' Binary Floating Point support @MGA
* (simulated unless CVTBFPH is on) @MGA


That bit is always on with OS/390 2.6 or higher.

You definitely should not look at the CR0 bit.


Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

Date: 09/26/2017 03:29 PM
Subject: Is the AFP control bit (big #13 in CR0) testable in an

application?

I was hoping to determine if a program is allowed
to use the Additional Floating Point (AFP) registers.
There are two qualifications for this; first the "basic floating point
extensions"
has to be installed (which can be assumed after OS/390 2.6) and
second, the AFP CONTROL BIT of Control Register 0 has to be enabled
(bit #13.)
So - while the hardware allows it, it's possible - for some reason or
other -
the control register disallows it.
I'm looking around in the various locations (CVT, PSA, etc...) and hunting
for a mechanism where an application program can ask "Am I allowed to
use all 16 floating-pt registers, or am I restricted to the traditional 4?"
Is there an assembler service somewhere that provides the value of control
registers? You can just use STORE CONTROL (STCTL) instruction as it is
privileged.
- Many thanks -
- Dave Rivers -

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[David Cole]

Dave Rivers: You may find the following commentary to be relevant. -Dave Cole

*************************************************************
* * Z21-1505F
* Save floating point and vector registers (when the * Z21-1505F
* hardware support is present AND!!! their use has been * Z21-1505F
* activated in the target thread). * Z21-1505F
* * Z21-1505F
*************************************************************
* * 04/09 Z1A
* * 04/09 Z1A
* "Whereas the old FP regs (0/2/4/6) are saved in the * 04/09 Z1A
* TCB (always), the advanced FP stuff (the other 12 FP * 04/09 Z1A
* regs and the FPC reg) are saved in the STCB. But, * 04/09 Z1A
* ONLY IF necessary. There is a bit (STCBFPFL/STCBBFP * 04/09 Z1A
* X'80') that if set on, will cause MVS to save/restore * 05/14 Z21
* all state. * 04/09 Z1A
* * 04/09 Z1A
* "MVS leaves the relevant CR0 bit off, and any attempt * 04/09 Z1A
* to execute an FP instruction that references one of * 04/09 Z1A
* the 12 extra regs, or BFP, or DFP, will cause a pgm * 04/09 Z1A
* check (data exception). MVS sees that, sets on the * 04/09 Z1A
* STCB flag, sets on the CR0 flag, and resumes * 04/09 Z1A
* execution. From that point on, any TCB context * 04/09 Z1A
* save/restore will save/restore all FP state. * 04/09 Z1A
* * 04/09 Z1A
* So if AFP hardware has not yet been used in the current * Z21-1505F
* thread, then I must not attempt to save any AFP registers * Z21-1505F
* because the mere act of doing so will cause z/OS to turn * Z21-1505F
* AFP support on, and that could be an unplesant surprise * Z21-1505F
* to the target program. * Z21-1505F
* * 04/09 Z1A
************************************************************* 04/09 Z1A
* * Z21-1505F
* Ditto for the SIMD vector registers... If their use has * Z21-1505F
* not yet been activated in the target thread, then I must * Z21-1505F
* not attempt to save them. * Z21-1505F
* * Z21-1505F
************************************************************* Z21-1505F

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:***@colesoft.com>***@colesoft.com

Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

In the old days, you would check
That bit is always on with OS/390 2.6 or higher. You definitely
should not look at the CR0 bit.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

Post by Jim Mulder

Date: 09/26/2017 03:29 PM
Subject: Is the AFP control bit (big #13 in CR0) testable in an

application?

I was hoping to determine if a program is allowed
to use the Additional Floating Point (AFP) registers.
There are two qualifications for this; first the "basic floating point
extensions"
has to be installed (which can be assumed after OS/390 2.6) and
second, the AFP CONTROL BIT of Control Register 0 has to be enabled
(bit #13.)
So - while the hardware allows it, it's possible - for some reason or
other -
the control register disallows it.
I'm looking around in the various locations (CVT, PSA, etc...) and

hunting

for a mechanism where an application program can ask "Am I allowed to
use all 16 floating-pt registers, or am I restricted to the traditional

4?"

Is there an assembler service somewhere that provides the value of

control

registers? You can just use STORE CONTROL (STCTL) instruction as it is
privileged.
- Many thanks -
- Dave Rivers -

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Peter Relson]

No there is no way for an unauthorized application to test it but, more
important, as Jim M alluded, there is no reason to do so.

The actual bit to check would have been CVTBFPH which looks for the
hardware being available (rather than CVTBFP which looks for the software
being available).

Use of all 16 floating point regs is supported unconditionally on all
supported releases.

That was not true prior to z/OS 2.1 (although if running on a "real
machine" it was true since AFPRs are part of base z Architecture).

It remains a fact that if you don't need more than 4 FPRs (and you don't
need FPCR or anything other than the "old" hex floating point
instructions) that you should limit yourself to FPRs 0/2/4/6 to save a few
cycles with respect to status saving and restoring.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Steve Smith]

Well, what do you know, I follow that rule without knowing why until
today. And the IEAFP macro makes sense now. Thanks Dave Cole and
Peter Morrison for the enlightenment.

Also, obviously my suggestion about referring to FPR 1 to test the
facility is superfluous unless your program needs to run on old
long-out-of-support hardware and systems.

sas

On Wed, Sep 27, 2017 at 7:48 AM, Peter Relson <***@us.ibm.com> wrote:
...

Post by Peter Relson
It remains a fact that if you don't need more than 4 FPRs (and you don't
need FPCR or anything other than the "old" hex floating point
instructions) that you should limit yourself to FPRs 0/2/4/6 to save a few
cycles with respect to status saving and restoring.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Thomas David Rivers]

Post by Peter Relson
No there is no way for an unauthorized application to test it but, more
important, as Jim M alluded, there is no reason to do so.
The actual bit to check would have been CVTBFPH which looks for the
hardware being available (rather than CVTBFP which looks for the software
being available).
Use of all 16 floating point regs is supported unconditionally on all
supported releases.
That was not true prior to z/OS 2.1 (although if running on a "real
machine" it was true since AFPRs are part of base z Architecture).
It remains a fact that if you don't need more than 4 FPRs (and you don't
need FPCR or anything other than the "old" hex floating point
instructions) that you should limit yourself to FPRs 0/2/4/6 to save a few
cycles with respect to status saving and restoring.
Peter Relson
z/OS Core Technology Design

The problem is that a BPX SIR needs to save/restore the floating-pt
registers before invoking the signal handler.

Checking the CVT bits is all well-and-good, but then unconditionally
saving all 16 registers then will cause MVS to set the bit in CR0.

If the program has no need to save/restore all of the FP registers (because
it's not using them) it would be nice if the BPX signal handler didn't
accidently
kick the AFP bit of CR0 "on" by using the AFP registers.

That is - I'm in this state of "If the AFP regs haven't been used, I don't
want to be the one to use them, but if they have I need to save/restore
them."

But - on reflection - perhaps that is incorrect thinking... the invoked
signal
handler may use the AFP registers. In fact, it might be the first such use
in the execution of the program. In that case, the SIR should have
saved/restored
all the AFP registers, even though CR0's AFP bit might have been "off"
at the start
of the SIR. Since the SIR can't know what the handler is going to do;
I guess it's stuck at always saving/restoring the AFP regs if the
CVTBFPH flag
is on...

- Thanks everyone! -
- Dave Rivers -

[Greg Dyck]

Post by Thomas David Rivers
The problem is that a BPX SIR needs to save/restore the floating-pt
registers before invoking the signal handler.

STCBFPFL, and thus STCBBFP, is defined to part of the intended program
interface. If STCBBFP is off, you do not need to save the extended
floating point registers. If it was off when you saved the registers
and is set on when you are ready to restore the registers you could
issue an IEAFP STOP to reset it.

Regards,
Greg

[Thomas David Rivers]

Post by Greg Dyck

Post by Thomas David Rivers
The problem is that a BPX SIR needs to save/restore the floating-pt
registers before invoking the signal handler.

STCBFPFL, and thus STCBBFP, is defined to part of the intended program
interface. If STCBBFP is off, you do not need to save the extended
floating point registers. If it was off when you saved the registers
and is set on when you are ready to restore the registers you could
issue an IEAFP STOP to reset it.
Regards,
Greg

Thanks Greg! That seems to be what I need to look into...

I checked the doc on IEAFP (gotta say -that's one I've never seen) - it
doesn't
seem to have any particular requirements - so it looks good.

And - I'll rummage around for STCBFPFL too!

Thanks!

- Dave R. -

[David Cole]

Hmmm. It seems to me that you can check the STCBBFP flag both at save
time and at restore time:
* If off at save time, then don't save them, but remember that it was off.
* At restore time, if STCBBFP had been off at save time, but now
is on, then you know that the signal handler did, indeed, use the AFP
regs, in which case, you can "restore" them simply by zeroing them.
Wouldn't that work?

Dave Cole

Post by Thomas David Rivers
The problem is that a BPX SIR needs to save/restore the floating-pt
registers before invoking the signal handler.
Checking the CVT bits is all well-and-good, but then unconditionally
saving all 16 registers then will cause MVS to set the bit in CR0.
If the program has no need to save/restore all of the FP registers (because
it's not using them) it would be nice if the BPX signal handler
didn't accidently
kick the AFP bit of CR0 "on" by using the AFP registers.
That is - I'm in this state of "If the AFP regs haven't been used, I don't
want to be the one to use them, but if they have I need to
save/restore them."
But - on reflection - perhaps that is incorrect thinking... the
invoked signal
handler may use the AFP registers. In fact, it might be the first such use
in the execution of the program. In that case, the SIR should have
saved/restored
all the AFP registers, even though CR0's AFP bit might have been
"off" at the start
of the SIR. Since the SIR can't know what the handler is going to do;
I guess it's stuck at always saving/restoring the AFP regs if the
CVTBFPH flag
is on...
- Thanks everyone! -
- Dave Rivers -
--
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:***@colesoft.com>***@colesoft.com

Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Greg Dyck]

   * At restore time, if STCBBFP had been off at save time, but now is
on, then you know that the signal handler did, indeed, use the AFP regs,
in which case, you can "restore" them simply by zeroing them.
Wouldn't that work?

If you wish. It depends on which will be more overhead in the long run,
and Murphy says that whichever choice you make will be wrong for at
least one important customer. ;-)

Regards,
Greg

[Greg Dyck]

    * At restore time, if STCBBFP had been off at save time, but now
is on, then you know that the signal handler did, indeed, use the AFP
regs, in which case, you can "restore" them simply by zeroing them.
Wouldn't that work?

If you wish.  It depends on which will be more overhead in the long run,
and Murphy says that whichever choice you make will be wrong for at
least one important customer.  ;-)

Grrr... I realized I had my prior post on the brain, and that after I
sent this your's was not in response to mine. The choice I mention
above is to zero the registers or to use IEAFP STOP to reset the flag.

Regards,
Greg

[Peter Relson]

Post by Thomas David Rivers
I guess it's stuck at always saving/restoring the AFP regs if the
CVTBFPH flag

not true.

You do not have to save/restore if the registers are not currently being
saved/restored (because upon their first use, their value will be 0).
.
IHASTCB byte STCBFPFL bit STCBBFP is on if and only if the AFPRs are being
used.
IHAPSA byte PSAFPFL bit PSABFP is similarly on (I need to, and will do so
going forward, update IHAPSA to indicate that PSAFPFL is an interface,
which, as the commentary indicates, is the case for PSABFP and PSAVSS).

And, FWIW, there is no reason to check CVTBFPH if running on any support
z/OS release.

If you happened to have control over the usage "beneath you", then you
could take advantage of that knowledge: the requirement is to preserve
which could either by by not using or by save/restore.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN