Open jphartmann opened 7 years ago
Where does it state in any Principles of Operation it shouldn't be implemented ?
If it doesn't state it, it's OK
--Ivan
On 1/9/2017 1:55 PM, John P. Hartmann wrote:
ARCHLVL ESAME is supposed to be the initial z, which does not include long displacements (aka dyslexic instructions). That does not seem to be the case.
The ALC instruction is one of a handful that was added to z as an RXE instruction. It was backported to ESA as an RXE instruction. For z it was (along with the rest) quietly promoted to RXY by the long displacement facility, or perhaps the fast long displacement facility.
HLASM correctly refuses to generate a long displacement for ALC with machine(z), if that is any indication of what should happen.
Either we roll back the ESAME differences from Z or we implement FEATURE_LONG_DISPLACEMENT as a dynamic test of the CPU's feature list in the affected instructions.
So what will it be?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/184, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMWwtn0jFd-BrQyQsn25rbRq829ZgQks5rQi5agaJpZM4LeOto.
Good, Ivan, you took the bait.
If you dig out the relevant PoO you will find that RXE ignores the unused byte. It does not require it to be zero. You can add dancing girls, but you cannot make the original Z have long displacement.
Actually you will find a handful of RXE operations in the current PoO where the penultimate byte is still ignored.
Reference (manual, page number, chapter) please
--Ivan
On 1/9/2017 2:26 PM, John P. Hartmann wrote:
Good, Ivan, you took the bait.
If you dig out the relevant PoO you will find that RXE ignores the unused byte. It does not require it to be zero. You can add dancing girls, but you cannot make the original Z have long displacement.
Actually you will find a handful of RXE operations in the current PoO where the penultimate byte is still ignored.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/184#issuecomment-271283470, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMW9_yq46E23_xLvyNY4Fq6GmRfzhjks5rQjVvgaJpZM4LeOto.
No, Ivan, that is being supercilious. Go dig out the manual itself or refer the the description of RXE in the current PoO.
John,
When you make a claim, you ARE to reference it - not the other way around.
--Ivan
On 1/9/2017 2:55 PM, John P. Hartmann wrote:
No, Ivan, that is being supercilious. Go dig out the manual itself or refer the the description of RXE in the current PoO.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/184#issuecomment-271289840, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMW-WssLpu81uMd2ASARmGwTUIyuNiks5rQjxtgaJpZM4LeOto.
John,
I am not to search through all the manuals for a possibly unsubstantiated claim.
It is up to you to prove your statement.
Whenever I make a statement, I always DO indicate what article proves what I say is correct.
Please provide the manual number, the version of the manual, the page, chapter and paragraph that proves what you say is correct.
...
Then we can discuss it.
--Ivan
On 1/9/2017 2:55 PM, John P. Hartmann wrote:
No, Ivan, that is being supercilious. Go dig out the manual itself or refer the the description of RXE in the current PoO.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hercules-390/hyperion/issues/184#issuecomment-271289840, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjMW-WssLpu81uMd2ASARmGwTUIyuNiks5rQjxtgaJpZM4LeOto.
It wasn't a silent change. SA22-7832-10's Summary of Changes in Third Edition says:-
In Chapter 7, “General Instructions”: – Thirty-nine instructions provided by the long- displacement facility are added. With the exception of the new LOAD BYTE instruc- tion, the instructions added by the long-dis- placement facility have names and functions that are the same as existing instructions (but the mnemonics and opcodes are new). The new instructions are of formats RSY, RXY, and SIY and have a 20-bit signed dis- placement instead of a 12-bit unsigned dis- placement. – All previously existing format-RSE and for- mat-RXE instructions are changed to be of formats RSY and RXY, respectively, by use of a previously unused byte in the instruc- tions. These changes are not marked by a bar in the margin. – Five instructions provided by the message- security assist are added. – The instruction format of SUPERVISOR CALL is changed to I.
It also shows the RXY Format in Figure 5-1 on page 5-5.
SA22-7201-08 page 5-6 says:-
Instruction fields shown in Figure 5-1 on page 5-4 as containing slashes (/) are currently unassigned. These fields in an instruction should contain zeros; otherwise, the program may not operate compatibly in the future.
It also shows the RXE Format in Figure 5-1 on page 5-4.
Because ARCHLVL supports a specification of ESAME or zArch, two different level sets, ALC and friends should be fixed.
mcisho thanks for the PoO reference and details.
ARCHLVL ESAME is supposed to be the initial z, which does not include long displacements (aka dyslexic instructions). That does not seem to be the case.
The ALC instruction is one of a handful that was added to z as an RXE instruction. It was backported to ESA as an RXE instruction. For z it was (along with the rest) quietly promoted to RXY by the long displacement facility, or perhaps the fast long displacement facility.
HLASM correctly refuses to generate a long displacement for ALC with machine(z), if that is any indication of what should happen.
Either we roll back the ESAME differences from Z or we implement FEATURE_LONG_DISPLACEMENT as a dynamic test of the CPU's feature list in the affected instructions.
So what will it be?