[hercules-390] z/Arch POP error

[[e-mail] [hercules-390]]

In Hercules 3.13 we see this:

general1.c:
DEF_INST(branch_and_set_mode)

#if defined(FEATURE_ESAME)
/* Z/Pops seems to be in error about this */
// regs->GR_LHLCL(r1) &= 0xFE;


Could we add some more comments please?
Specifically that SA22-7832-00 is wrong but
SA22-7832-03 is correct.

Thanks. Paul.

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
DEF_INST(branch_and_set_mode)
#if defined(FEATURE_ESAME)
/* Z/Pops seems to be in error about this */
// regs->GR_LHLCL(r1) &= 0xFE;
Could we add some more comments please?
Specifically that SA22-7832-00 is wrong but
SA22-7832-03 is correct.

Paul,

IIRC...

Early specifications of the z/Architecture introduced a compatibility
error which led to 24 bit and 31 bit addressing mode problem state code
behaving differently in z/Architecture mode than in ESA/390 mode.

In ESA/390 mode, R1 last bit isn't cleared while it is cleared by early
z/Arch specifications when not in 64 bit addressing mode.

This was reported by our very own Jan Jaeger to IBM in the early 2000's
which promptly responded and amended the ensuing specifications to not
clear R1 bit 63 in z/Arch mode when not in 64 bit addressing mode
(although it forces bit 63 to 1 in 64 bit addressing mode - but that's
not incompatible since 64 bit addressing mode is only available in
z/Architecture mode).

That's how I remember it - so I could be wrong.

--Ivan



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

[[e-mail] [hercules-390]]

Hi Ivan. That is all sensible and I agree with all
of it. It's just the comments in the code that I
would like changed. Just saying "The z/Arch
POP is wrong" is not really correct in 2018.

BFN. Paul.

Post by ***@yahoo.com.au [hercules-390]
DEF_INST(branch_and_set_mode)
#if defined(FEATURE_ESAME)
/* Z/Pops seems to be in error about this */
// regs->GR_LHLCL(r1) &= 0xFE;
Could we add some more comments please?
Specifically that SA22-7832-00 is wrong but
SA22-7832-03 is correct.

Paul,

IIRC...

Early specifications of the z/Architecture introduced a compatibility
error which led to 24 bit and 31 bit addressing mode problem state code
behaving differently in z/Architecture mode than in ESA/390 mode.

In ESA/390 mode, R1 last bit isn't cleared while it is cleared by early
z/Arch specifications when not in 64 bit addressing mode.

This was reported by our very own Jan Jaeger to IBM in the early 2000's
which promptly responded and amended the ensuing specifications to not
clear R1 bit 63 in z/Arch mode when not in 64 bit addressing mode
(although it forces bit 63 to 1 in 64 bit addressing mode - but that's
not incompatible since 64 bit addressing mode is only available in
z/Architecture mode).

That's how I remember it - so I could be wrong.

--Ivan



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

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]
Hi Ivan. That is all sensible and I agree with all
of it. It's just the comments in the code that I
would like changed. Just saying "The z/Arch
POP is wrong" is not really correct in 2018.
BFN. Paul.

Paul,

I guess you are free to update the source code (or submit a pull
request) to include a change in the comment to indicate the previous and
current status !

--Ivan



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

[[e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I guess you are free to update the source code (or submit a pull
request) to include a change in the comment to indicate the previous and
current status !

I have already updated my own flavor of the code,
with the second comment below:

/* Z/Pops seems to be in error about this */
/* Specifically SA22-7832-00 says the low bit is cleared, while
SA22-7832-03 says the low bit is unchanged. So Hercules is
correct to leave this line commented out, and it makes sense
as this matches behavior in ESA/390 where the low bit is
not special. */


BFN. Paul.

[Gregg Levine [e-mail] [hercules-390]]

Hello!
Paul do you maintain a repository for your work? if that's the case
work out how the differences track the released code, and your own
work. And then make things available for a patch again following the
usual steps for that patch.

-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
I guess you are free to update the source code (or submit a pull
request) to include a change in the comment to indicate the previous and
current status !

I have already updated my own flavor of the code,
/* Z/Pops seems to be in error about this */
/* Specifically SA22-7832-00 says the low bit is cleared, while
SA22-7832-03 says the low bit is unchanged. So Hercules is
correct to leave this line commented out, and it makes sense
as this matches behavior in ESA/390 where the low bit is
not special. */
BFN. Paul.
------------------------------------
------------------------------------

[[e-mail] [hercules-390]]

Post by Gregg Levine ***@gmail.com [hercules-390]
Paul do you maintain a repository for your work? if that's the case

Hi Gregg. Yes, I have a CVS repository on my
hard disk. I will convert it to GIT when I am
more familiar with GIT. I am already using GIT
for PDOS and MVS/380 because I had no
choice.

It will probably take me a few years to be as
comfortable with GIT as I am with CVS.

Post by Gregg Levine ***@gmail.com [hercules-390]
work out how the differences track the released code, and your own
work. And then make things available for a patch again following the
usual steps for that patch.

I provide a patch in any Hercules/380
distribution I produce, including the betas
that can be found in the file section of the
hercules-os380 group.

So this whitespace change will eventually
appear there, or on sourceforge. I have
changed quite a few things in Hercules/380,
so many that I no longer track the other
branches of Hercules. All that I do is when
I discover an issue I try to report it in terms
of the latest (3.13) stable version, but I fix
it in my own version (3.07-derived).

BFN. Paul.