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

[Peter Relson]

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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






At 9/27/2017 01:25 PM, Thomas David Rivers wrote:

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 -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Thomas David Rivers]

Peter Relson wrote:

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 -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

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

[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  wrote:
...
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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
* This from Peter Morrison <peter.morri...@ca.com>: * 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:dbc...@colesoft.com>dbc...@colesoft.com

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






At 9/26/2017 03:37 PM, Jim Mulder wrote:

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
IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
09/26/2017 12:47:40 PM:


> From: Thomas David Rivers <riv...@dignus.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/26/2017 03:29 PM
> Subject: Is the AFP control bit (big #13 in CR0) testable in an
application?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
> 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 -


--

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

[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

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
09/26/2017 12:47:40 PM:

> From: Thomas David Rivers <riv...@dignus.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/26/2017 03:29 PM
> Subject: Is the AFP control bit (big #13 in CR0) testable in an 
application?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[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

On Tue, Sep 26, 2017 at 12:47 PM, Thomas David Rivers  wrote:
> 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 -
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com




-- 
sas

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

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 -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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