[hercules-390] STD

Discussion:

[hercules-390] STD

kerravon86@yahoo.com.au [hercules-390]

2018-10-15 23:58:24 UTC

I have taken a program from z/OS compiled
with IBM's C compiler and attempted to run
it on Hercules/380 which is based on
Hercules 3.07 but which enables lots of
z/Arch facilities.

The program is falling over on an STD
from R8:

10:11:47 PSW=078D1000 800BE39C 0000000000000000 INST=6080D0F0 STD 8,240(0,13) store_float_long
10:11:47 V:00000000000CF424:K:8E=00000000 00000000 00000000 00000000 ................
10:11:47 R0=00000000000CF434 R1=00000000000CF324 R2=00000000000B59D0 R3=00000000000BE38A
10:11:47 R4=0000000000000000 R5=00000000000B59D0 R6=0000000000000000 R7=00000000000B59D4
10:11:47 R8=00000000000C40F8 R9=0000000002011308 RA=00000000000CF094 RB=0000000000000001
10:11:47 RC=00000000000CECD8 RD=00000000000CF334 RE=00000000000CF334 RF=0000000000000000
10:11:47 CR00=C080EC40 CR01=0F855C00 CR02=FFFFFFFF CR03=00000000
10:11:47 CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000
10:11:47 CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000
10:11:47 CR12=00000000 CR13=00000000 CR14=EFC00000 CR15=00FE51B8
10:11:47 FPR0=00000000 00000000 FPR2=00000000 00000000
10:11:47 FPR4=00000000 00000000 FPR6=00000000 00000000
10:11:47 HHCCP014I CPU0000: Data exception CODE=0007 ILC=4 DXC=01

I looked up STD in the z/Arch POP but didn't
find anything useful.

I looked at the Hercules 3.07 and Hyperion
code and found this check:

https://github.com/hercules-390/hyperion/blob/master/opcode.h

/* Program check if r1 is not 0, 2, 4, or 6 */
#define HFPREG_CHECK(_r, _regs) \
if( (_r) & 9 ) \
(_regs)->program_interrupt( (_regs), PGM_SPECIFICATION_EXCEPTION)

So R8 is not valid, ie an R8/R9 pair.

Note that from looking at the Hercules code
it appears that z/Arch has increased the
number of floating point registers:

/*160*/ /* FWORD storefpr[8]; */ /* FP register save area */
/*xxx*/ FWORD storefpr[32]; /* FP register save area */

I can do that too, but R8 is still going to
fall under the (_r) & 9 check which
ensures the 4-bit value is either 0, 2,
4 or 6. I don't see a z/Arch version of
the check that relaxes that
restriction.

Any idea what is going on?

Thanks. Paul.

Ivan Warren ivan@vmfacility.fr [hercules-390]

2018-10-16 00:25:37 UTC

Permalink

Post by ***@yahoo.com.au [hercules-390]
10:11:47 HHCCP014I CPU0000: Data exception CODE=0007 ILC=4 DXC=01

Post by ***@yahoo.com.au [hercules-390]
(_regs)->program_interrupt( (_regs), PGM_SPECIFICATION_EXCEPTION)

Obviously looking at the wrong spot ! (A Data Exception is NOT an
Specification Exception)

So comparing a VERY old version of hercules to your VERY own private
modified version to any principle of operations ? You must be kidding
right ?

--Ivan

[Non-text portions of this message have been removed]

Gregg Levine gregg.drwho8@gmail.com [hercules-390]

2018-10-16 01:15:57 UTC

Permalink

Hello!
Actually Ivan its worse than that. He is seeing the problem happen
because he arranged it to happen that way. Paul try it again on an
unmodified release of Hercules, not your specially customized
versions.

Besides there's always a good reason for everything.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
10:11:47 HHCCP014I CPU0000: Data exception CODE=0007 ILC=4 DXC=01

Post by ***@yahoo.com.au [hercules-390]
(_regs)->program_interrupt( (_regs), PGM_SPECIFICATION_EXCEPTION)

Obviously looking at the wrong spot ! (A Data Exception is NOT an
Specification Exception)
So comparing a VERY old version of hercules to your VERY own private
modified version to any principle of operations ? You must be kidding
right ?
--Ivan
[Non-text portions of this message have been removed]
------------------------------------
------------------------------------

And this message is being sponsored by HARLIE and his fellow Lethetic
Intelligence Engines.

kerravon86@yahoo.com.au [hercules-390]

2018-10-16 02:08:54 UTC

Permalink

Post by Gregg Levine ***@gmail.com [hercules-390]
Actually Ivan its worse than that. He is seeing the problem happen
because he arranged it to happen that way. Paul try it again on an
unmodified release of Hercules, not your specially customized
versions.

It's a 31-bit program using z/Arch instructions.
I can't legally run it on anything other than
MVS/380 under Hercules/380.

Since it was compiled with IBM C but linked
with the public domain C library PDPCLIB I can
legally take the load module to MVS/380.

The program works on z/OS.

Thanks guys for the correction. I'm now
guessing that I need the extra floating
point registers initialized to valid values
at machine initialization time.

BFN. Paul.

Joe Monk joemonk64@gmail.com [hercules-390]

2018-10-16 01:57:01 UTC

Permalink

Ummm ... You've got a S0C7 there ... a data exception.

10:11:47 HHCCP014I CPU0000: Data exception CODE=0007 ILC=4 DXC=01

That's not a Hercules problem.

Joe

Post by ***@yahoo.com.au [hercules-390]
I have taken a program from z/OS compiled
with IBM's C compiler and attempted to run
it on Hercules/380 which is based on
Hercules 3.07 but which enables lots of
z/Arch facilities.
The program is falling over on an STD
10:11:47 PSW=078D1000 800BE39C 0000000000000000 INST=6080D0F0 STD
8,240(0,13) store_float_long
10:11:47 V:00000000000CF424:K:8E=00000000 00000000 00000000 00000000
................
10:11:47 R0=00000000000CF434 R1=00000000000CF324 R2=00000000000B59D0 R3=00000000000BE38A
10:11:47 R4=0000000000000000 R5=00000000000B59D0 R6=0000000000000000 R7=00000000000B59D4
10:11:47 R8=00000000000C40F8 R9=0000000002011308 RA=00000000000CF094 RB=0000000000000001
10:11:47 RC=00000000000CECD8 RD=00000000000CF334 RE=00000000000CF334 RF=0000000000000000
10:11:47 CR00=C080EC40 CR01=0F855C00 CR02=FFFFFFFF CR03=00000000
10:11:47 CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000
10:11:47 CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000
10:11:47 CR12=00000000 CR13=00000000 CR14=EFC00000 CR15=00FE51B8
10:11:47 FPR0=00000000 00000000 FPR2=00000000 00000000
10:11:47 FPR4=00000000 00000000 FPR6=00000000 00000000
10:11:47 HHCCP014I CPU0000: Data exception CODE=0007 ILC=4 DXC=01
I looked up STD in the z/Arch POP but didn't
find anything useful.
I looked at the Hercules 3.07 and Hyperion
https://github.com/hercules-390/hyperion/blob/master/opcode.h
/* Program check if r1 is not 0, 2, 4, or 6 */
#define HFPREG_CHECK(_r, _regs) \
if( (_r) & 9 ) \
(_regs)->program_interrupt( (_regs), PGM_SPECIFICATION_EXCEPTION)
So R8 is not valid, ie an R8/R9 pair.
Note that from looking at the Hercules code
it appears that z/Arch has increased the
/*160*/ /* FWORD storefpr[8]; */ /* FP register save area */
/*xxx*/ FWORD storefpr[32]; /* FP register save area */
I can do that too, but R8 is still going to
fall under the (_r) & 9 check which
ensures the 4-bit value is either 0, 2,
4 or 6. I don't see a z/Arch version of
the check that relaxes that
restriction.
Any idea what is going on?
Thanks. Paul.

Joe Monk joemonk64@gmail.com [hercules-390]

2018-10-16 02:02:22 UTC

Permalink

Now, lets talk about the real problem. Register 8 is NOT an AFP register.
You've got a DXC of 01, which says invalid additional floating point
register.

Joe

Joe Monk joemonk64@gmail.com [hercules-390]

2018-10-16 02:06:15 UTC

Permalink

Sorry.... hit enter to quickly. What I meant to say was that bit 45 of CR0
has to be on in order to use register 8 as an AFP register. Since it is not
on here, then register 8 is not an AFP register... which is why you got a
data exception DXC 01. It is not on because your CR's are only 32 bits.

Joe

Post by Joe Monk ***@gmail.com [hercules-390]
Now, lets talk about the real problem. Register 8 is NOT an AFP register.
You've got a DXC of 01, which says invalid additional floating point
register.
Joe

kerravon86@yahoo.com.au [hercules-390]

2018-10-16 02:24:06 UTC

Permalink

Post by Joe Monk ***@gmail.com [hercules-390]
Sorry.... hit enter to quickly. What I meant to say
was that bit 45 of CR0 has to be on in order to
use register 8 as an AFP register. Since it is not
on here, then register 8 is not an AFP register...
which is why you got a data exception DXC 01.
It is not on because your CR's are only 32 bits.

Thanks for that analysis.

I couldn't find anywhere in Hercules that was
setting that bit, so I assume it only gets set
with a LCTL.

Bit 45 means that it is in the lower 32 bits, so
I should only need 32-bit CRs. However, my
CRs are 64 bits as far as I am aware, ie same
as the GPRs.

I am thinking of setting CR0_AFP whenever
CR0 is loaded, so that I don't need to change
all CR0 loads in MVS/380 (which I don't have
source to). Do you envisage any problem if
AFP is always on?

Thanks. Paul.

Joe Monk joemonk64@gmail.com [hercules-390]

2018-10-16 02:40:16 UTC

Permalink

"Bit 45 means that it is in the lower 32 bits, so
I should only need 32-bit CRs. However, my
CRs are 64 bits as far as I am aware, ie same
as the GPRs."

According to your display, your CRs are 32bit... and Bit 13 is off, since
that second byte is x'80'.

10:11:47 CR00=C080EC40

Joe

Post by ***@yahoo.com.au [hercules-390]

Thanks for that analysis.
I couldn't find anywhere in Hercules that was
setting that bit, so I assume it only gets set
with a LCTL.
Bit 45 means that it is in the lower 32 bits, so
I should only need 32-bit CRs. However, my
CRs are 64 bits as far as I am aware, ie same
as the GPRs.
I am thinking of setting CR0_AFP whenever
CR0 is loaded, so that I don't need to change
all CR0 loads in MVS/380 (which I don't have
source to). Do you envisage any problem if
AFP is always on?
Thanks. Paul.

kerravon86@yahoo.com.au [hercules-390]

2018-10-16 03:10:38 UTC

Permalink

Post by Joe Monk ***@gmail.com [hercules-390]

Post by ***@yahoo.com.au [hercules-390]
Bit 45 means that it is in the lower 32 bits, so
I should only need 32-bit CRs. However, my
CRs are 64 bits as far as I am aware, ie same
as the GPRs.

According to your display, your CRs are 32bit... and
Bit 13 is off, since that second byte is x'80'.
10:11:47 CR00=C080EC40

Ok, thanks. When I press "ESC" at the
Hercules integrated console it shows the
registers as 64-bit, so it's probably a
display issue.

Regardless, with this change:

C:\devel\hercules>cvs diff -l
cvs diff: Diffing .
Index: control.c
===================================================================
RCS file: c:\cvsroot/hercules/control.c,v
retrieving revision 1.5
diff -r1.5 control.c
1887a1888,1892

Post by Joe Monk ***@gmail.com [hercules-390]
#ifdef FEATURE_S380
/* unconditionally switch on additional floating point */
regs->CR_L(0) |= CR0_AFP;
#endif

Index: esa390.h
===================================================================
RCS file: c:\cvsroot/hercules/esa390.h,v
retrieving revision 1.13
diff -r1.13 esa390.h
731a732,734

Post by Joe Monk ***@gmail.com [hercules-390]
#ifdef FEATURE_S380
/*xxx*/ FWORD storefpr[32]; /* FP register save area */
#else

732a736

Post by Joe Monk ***@gmail.com [hercules-390]
#endif

My test program is working! So people on
z/OS can use their IBM C compiler to
produce load modules that also execute
on MVS/380.

I will upload the load module and a new
Hercules/380 to the os380 group.

Thanks for isolating the problem Joe.

BFN. Paul.

kerravon86@yahoo.com.au [hercules-390]

2018-10-16 03:20:11 UTC

Permalink

And for good measure, below is the new
trace showing the new CR setting and
also additional floating point registers
are being displayed.

BFN. Paul.

13:57:27 PSW=078D1000 800BE39A 0000000000000000 INST=18DE LR 13,14 load_register
13:57:27 R0=00000000000CF434 R1=00000000000CF324 R2=00000000000B59D0 R3=00000000000BE38A
13:57:27 R4=0000000000000000 R5=00000000000B59D0 R6=0000000000000000 R7=00000000000B59D4
13:57:27 R8=00000000000C40F8 R9=0000000002011308 RA=00000000000CF094 RB=0000000000000001
13:57:27 RC=00000000000CECD8 RD=00000000000CF28C RE=00000000000CF334 RF=0000000000000000
13:57:27 CR00=C084EC40 CR01=0F855C00 CR02=FFFFFFFF CR03=00000000
13:57:27 CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000
13:57:27 CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000
13:57:27 CR12=00000000 CR13=00000000 CR14=EFC00000 CR15=00FE51B8
13:57:27 PSW=078D1000 800BE39C 0000000000000000 INST=6080D0F0 STD 8,240(0,13) store_float_long
13:57:27 V:00000000000CF424:K:8E=00000000 00000000 00000000 00000000 ................
13:57:27 R0=00000000000CF434 R1=00000000000CF324 R2=00000000000B59D0 R3=00000000000BE38A
13:57:27 R4=0000000000000000 R5=00000000000B59D0 R6=0000000000000000 R7=00000000000B59D4
13:57:27 R8=00000000000C40F8 R9=0000000002011308 RA=00000000000CF094 RB=0000000000000001
13:57:27 RC=00000000000CECD8 RD=00000000000CF334 RE=00000000000CF334 RF=0000000000000000
13:57:27 CR00=C084EC40 CR01=0F855C00 CR02=FFFFFFFF CR03=00000000
13:57:27 CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000
13:57:27 CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000
13:57:27 CR12=00000000 CR13=00000000 CR14=EFC00000 CR15=00FE51B8
13:57:27 FPR0=00000000 00000000 FPR2=00000000 00000000
13:57:27 FPR1=00000000 00000000 FPR3=00000000 00000000
13:57:27 FPR4=00000000 00000000 FPR6=00000000 00000000
13:57:27 FPR5=00000000 00000000 FPR7=00000000 00000000
13:57:27 FPR8=00000000 00000000 FP10=00000000 00000000
13:57:27 FPR9=00000000 00000000 FP11=00000000 00000000
13:57:27 FP12=00000000 00000000 FP14=00000000 00000000
13:57:27 FP13=00000000 00000000 FP15=00000000 00000000
13:57:27 PSW=078D1000 800BE3A0 0000000000000000 INST=1821 LR 2,1 load_register

Tony Harminc tharminc@gmail.com [hercules-390]

2018-10-16 19:27:35 UTC

Permalink

[...]

Post by ***@yahoo.com.au [hercules-390]
My test program is working! So people on
z/OS can use their IBM C compiler to
produce load modules that also execute
on MVS/380.

The reason the AFP bit is not on by default after a system reset is so
that the operating system has the opportunity to indicate to the
hardware that it has the necessary infrastructure to handle more FP
registers. In particular, who is going to save and restore those new
FP regs on interrupts and task switches and such? Certainly not MVS
3.8...

Try running two of your nifty C programs at the same time on a
uniprocessor using the same register (F8, say) but with different
values. I'll bet you find they interfere.

Tony H.

kerravon86@yahoo.com.au [hercules-390]

2018-10-17 02:33:44 UTC

Permalink

Post by Tony Harminc ***@gmail.com [hercules-390]
The reason the AFP bit is not on by default after a system reset is so
that the operating system has the opportunity to indicate to the
hardware that it has the necessary infrastructure to handle more FP
registers. In particular, who is going to save and restore those new
FP regs on interrupts and task switches and such? Certainly not MVS
3.8...

Ok, I'll document this restriction along with
the high halves of 64-bit registers mandating
one enhanced task at a time until such time
as Hercules/380 is updated to save these
things itself on task switch.

BFN. Paul.