MISSING Facilities support #77
Comments
Fish-Git
added
the
Missing
Hi salva! First, I'm very pleased to see someone try to take on this challenge! Providing z/Architecture Vector Facility support is going to take a lot of effort! That said, I think I might see what you're missing. Maybe. Because the Vector instructions are extended opcode instructions, you're going to need to also add the required instruction decoding and routing logic for them, which currently doesn't exist. You've coded the In the Additionally, you're going to need to add a new and a corresponding And finally, and most importantly, you're going to need to add a new statement to the replace_opcode_xxxx(arch, gen_opcode_e5xx[i][arch], 0xe5, i);
replace_opcode_xxxx(arch, gen_opcode_e6xx[i][arch], 0xe6, i);
replace_opcode_xxxx(arch, gen_opcode_e7xx[i][arch], 0xe7, i); <-----ADD THIS LINE!----<<<
replace_opcode_xx________xx(arch, gen_opcode_ebxx[i][arch], 0xeb, i);
replace_opcode_xx________xx(arch, gen_opcode_ecxx[i][arch], 0xec, i);
replace_opcode_xx________xx(arch, gen_opcode_edxx[i][arch], 0xed, i);
Do all that and I think things might work better. Basically, you need to use the same technique as is currently being used for the But to be honest, I'm not 100% sure. I've never tried adding a brand new series of extended opcode instructions before, so take all of this with a grain of salt. Hope that helps! |
|
Thanks @Fish-Git, I made some progress: At opcode.c "e7xx" looks similar to "e6xx": ASMFMT_VRX is working fine: but still abending with 01C. I'll keep going, but there is too much new things for me. Regards, salva. |
Can you show us your code? Do you have a repository we could clone? I'm sure it's something simple.
Please don't give up now! You're almost there! If you could allow us to see all of your existing code, we could help you better. Do you have a repository we could clone? |
Are you doing your testing under z/OS? Or are you using a stand-alone test program? I'm not familiar with z/OS. What does "01C" mean? You should be using a stand-alone test program to initially test with, not z/OS. Only once your test program works correctly, should you then try to use the instruction(s) under z/OS. Then if they still don't work, then you know it is something about z/OS, not Hercules. I noticed that according to page 21-2 of the SA22-7832-13 "Principles of Operation" manual, in order to be able to use Vector Facility instructions under z/OS (i.e. the "control program"), you need to have certain Control Register bits set:
Additionally, it appears z/OS (i.e. the "control program") may also need to perform some special handling too before Vector instructions can be used:
Try setting a breakpoint on your test instruction ( p.s. I'd still like to see your code. |
|
Thanks you, @Fish-Git
I really appreciate your offer to look at my code. But I am learning a lot about Hercules in the debugging process . If I don't make progress today, I will upload my code to a repository to share it with you and the community. Regards, salva. |
|
Finally, I get the zVector facility enabled. Please check my updates at https://github.com/salva-rczero/hyperion-zvector. Thanks for your guidance and encouragement. Now I'll try to reach some vector instruction working as POP dictates. p.s. Please be patient, I'm an old mainframer and Visual Studio, x64, Git... are all new things for me. |
Fantastic! I'm very proud of you!
I'll definitely do that the moment I get the opportunity. (I'm still busy --AS USUAL! -- with many other things right now)
Understood. Both Visual Studio and Git (either one of them, let alone both!) can each be quite intimidating and confusing when you're not familiar with them. But try not to let either one distract you, and concentrate instead on the Hercules (instruction) code and your ASMA test code. Both of those should hopefully be more familiar to you, and are the most important part of your effort. You're doing GREAT, salva! Please keep up the good work! I'm confident that much of your effort will eventually make it into Hercules itself. You should be proud of yourself! I know I am. |
|
Thank you @Fish-Git. Now I have four zvector instructions "working": And of course I have a zillion questions. First, can I still ask you my questions, or should I spend more time reading the code and documentation? If yes:
|
Fantastic! I'm cloning and looking at your repository now.
Of course you can still ask questions! It doesn't have to be to me either. I'm sure any of the other Hercules developers or Hercules users/enthusiasts would be happy to help you too! Reading the Hercules source code is always a good idea. The more you understand how Hercules works, the more it will help you with your effort. Is this thread the right place? It is not the best place, no. We should probably move it somewhere else, but I'm unsure where the best place should be. The main Hercules groups.io/Hercules group might be a good place, yes. But for now, here is fine.
Probably, yes. Precisely what you are doing wrong I don't know. Be aware however, that Release (optimized) builds do normally take much longer than Debug (unoptimized) builds. This is expected and completely normal since Visual Studio is trying very hard to create the best, most efficient optimized code possible, and Hercules is quite large and complicated. So Visual Studio may take several minutes to complete a fully optimized Release build.
Probably not, no. Hercules is not designed like most other fairly simple (but large) Windows programs. Hercules is written very differently from the way most other programs are written. Many of its source code members are designed to be compiled multiple times, each time with a different set of #defines active (different set of constants and different set of macros). As a result, yes, Visual Studio does frequently "get confused".
I don't understand this question.
I have not tried yet. But error 0xC0150002 usually means you're missing the require Visual Studio runtime DLLs. I'm guessing you probably did not install Visual Studio correctly.
Another question I don't quite understand. Generally speaking however, yes, Hercules definitely needs to take host alignment requirements into consideration. Each host platform is different though. Some host platforms require certain operands to be aligned. Other host platforms simply run less efficiently if operands are not aligned. Such alignment requirements are handled by various fetch.store macros defined in our
This is a question which I do fully understand, but unfortunately do not have an answer for. This is precisely one of the items that makes providing support for the z/Architecture Vector Facility so challenging. It's not just the overwhelming number of vector instructions introduced by the facility, but the complete redesign of our floating point register handling that will be required as a result that presents the greatest challenge. I don't have an answer for this one. |
|
The file "CZAM_390-CM" has been uploaded to the groups.io hercules-390 file section. This document discussion in detail what is involved in both CZAM and 390-CM facilities. |
SWAP128 Test ProgramI would appreciate feeback on the attached. Refer to the README file for details: It's a little test program I recently wote that tests a possible(?) Hercules implementation of z/Vector support. It does not test any vector instructions. It only tests the proposed possible implementation of Hercules internal support for vector registers, i.e. how the registers in REGS should be defined, and how a new 128-bit variable type might be handled (i.e. how all the swapping/storing/fetching might be handled). It builds and runs on both Windows AND Linux too, and comes with sample test run output. Please read the README. It explains everything. Any/all feedback greatly appreciated. Thanks. |
SWAP128 version 2Here's the updated .zip file: Changes: BIG-ENDIAN support. Built and tested on LinuxONE Ubuntu 22.04. Works fine. I'm still quite concerned about my overall proposed internal support however. My program does prove we can indeed provide support for it with a minimal number of changes, but it only does so for Intel "x86" CPUs right now (and now, s390x systems too, obviously). Providing the same support for the many other host CPU architectures out there that we currently support that don't support Intel SIMD instructions however, is the hard part. THAT I have not figured out how to do yet, and is what I very much need help with. I'm somewhat anxious to integrate my changes into Hercules as soon as possible if others feel it's okay to do so at this time (i.e. that doing so won't break existing Hercules), so that people like @salva-rczero and others can have a version of Hercules they can work with (i.e. one that provides the needed internal framework). That way others can get started on coding the actual vector instructions themselves without worrying about "how it's all going to hang together". That is to say, once we have the framework in place, then the actual coding of the actual vector instructions themselves can proceed normally. But that can't really be done until we have the internal support framework in place first. THAT's what I'm trying to do here with my test program. So I'd really appreciate any type of feedback from my fellow developers out there regarding whether I'm on the right track or not. I don't want to screw things up! So I need your help to prevent that from happening. Thanks. |
|
Thanks @Fish-Git. I have not been able to dedicate time to zVector, because I have a terrible toothache. I hope to be back soon. From what I have been able to understand of your work, it would remain to adapt any reference to FPR to the new macros. On my side, I already had about 40 vector instructions written. My approach was to keep VR always in BIGENDIAN, but I guess it won't be too difficult to change it. Regards, salva. |
|
Hi @salva-rczero , Regards, Loet |
|
Please try to add:
zvector.c \
in Makefile.am at line 523.
Regards, salva.
|
|
thanks for the quick response Regards, |
|
Hi Loet,
I am developing in Visual Studio, so I only tested the MSVC build
version. I don't know much about building in Linux, but the only new file I
added to Hyperion if zvector.c. Please, try to clean your build branch
(make -clean or make -a) and repeat the make.
Post the result if not ok.
salva.
|
|
Hi @salva, I've read that the makefile.in is the real input to the installation process:
Thanks again |
|
Hi just for information, I try to Ipl Z/OS 3.1 and receive wait state 000000000023007B I presume those 2 facilities are not enabled : The vector binary-coded decimal facility Vincent |
|
Hi Vincent
Thanks for this update.
I still run on z/OS 2.5, but I'm warned
Thanks,
Loet
Op do 4 apr 2024 om 14:36 schreef Vf58 ***@***.***>:
… Hi
just for information, I try to Ipl Z/OS 3.1 and receive wait state
000000000023007B
https://www.ibm.com/docs/en/zos/3.1.0?topic=wsc-07b
I presume those 2 facilities are not enabled :
The vector binary-coded decimal facility
The vector enhancements facility 1
Vincent
—
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGI7IYNUJUBF3IJ7FQ334ZLY3VCMRAVCNFSM4EIWLNL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBTG4YDONZSGA2Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hi Vincent, As you wrote :
Have you already tried to bypass the The first one of these is already needed for z/OS 2.5 to bypass the WAIT state, but is only partially used, like for (the default) z/OSMF. That default can be circumvented, although not with the |
Wrong. If a facility is not supported, you can't enable it. You'll get an error if you try to: HHC00896E Facility( 054_EE_CMPSC ) not supported for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4554) HHC01441E Config file[67] C:/Users/Fish/HercGUI/Configuration Files/CCKD64 zOS-3.1-ADCD-WARM-QETH.txt: error processing statement: FACILITY ENABLE 054_EE_CMPSC HHC00007I Previous message from function 'process_config' at script.c(431) HHC00896E Facility( 129_ZVECTOR ) not supported for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4554) HHC01441E Config file[68] C:/Users/Fish/HercGUI/Configuration Files/CCKD64 zOS-3.1-ADCD-WARM-QETH.txt: error processing statement: FACILITY ENABLE 129_ZVECTOR HHC00007I Previous message from function 'process_config' at script.c(431) HHC00896E Facility( 130_INSTR_EXEC_PROT ) not supported for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4554) HHC01441E Config file[69] C:/Users/Fish/HercGUI/Configuration Files/CCKD64 zOS-3.1-ADCD-WARM-QETH.txt: error processing statement: FACILITY ENABLE 130_INSTR_EXEC_PROT HHC00007I Previous message from function 'process_config' at script.c(431) HHC00896E Facility( 134_ZVECTOR_PACK_DEC ) not supported for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4554) HHC01441E Config file[70] C:/Users/Fish/HercGUI/Configuration Files/CCKD64 zOS-3.1-ADCD-WARM-QETH.txt: error processing statement: FACILITY ENABLE 134_ZVECTOR_PACK_DEC HHC00007I Previous message from function 'process_config' at script.c(431) HHC00896E Facility( 135_ZVECTOR_ENH_1 ) not supported for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4554) HHC01441E Config file[71] C:/Users/Fish/HercGUI/Configuration Files/CCKD64 zOS-3.1-ADCD-WARM-QETH.txt: error processing statement: FACILITY ENABLE 135_ZVECTOR_ENH_1 HHC00007I Previous message from function 'process_config' at script.c(431) HHC00898W Facility( 054_EE_CMPSC ) *Enabled for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4611) HHC00898W Facility( 129_ZVECTOR ) *Enabled for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4611) HHC00898W Facility( 130_INSTR_EXEC_PROT ) *Enabled for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4611) HHC00898W Facility( 134_ZVECTOR_PACK_DEC ) *Enabled for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4611) HHC00898W Facility( 135_ZVECTOR_ENH_1 ) *Enabled for z/Arch HHC00007I Previous message from function 'facility_enable_disable' at facility.c(4611) When you do that, you can get past the disabled wait, but then Which is more than likely caused by missing support for one or more of the above facilities. I'm currently working on trying to get the Instruction-Execution-Protection Facility coded, and after that, the Entropy Encoding and Order Preserving Compression Facilities as well (which will take a while!), but it's really the z/Architecture Vector Facility that's killing us. Support for the Vector Facility is likely going to take years to code, as it requires redesigning/rewriting our entire floating point support. I'm sorry, but it looks like z/OS 3.1 might very well be the end-of-the-line for Hercules. |
|
Hi Fish, Thanks for the feedback. I didn't know there was a difference for the So you answered my question, in that in this case such facility bypasses do not allow IPL-ing z/OS 3.1. Cheers, Peter |
|
Hi @salva-rczero, I am about to start work on changes to use a shared area for zVector and Floating Point registers, so that updates to one register type updates the other register type. There is a lot of FP usage to be changed, so this is is going to be a slow process on my part, but my changes will impact the work you are doing on zVector instructions. Can we chat offline? Cheers, Ian |
|
Hi @mcisho My first approach was to use another area for VR and REFRESH/UPDATE from/to AFPR at every use. Then @Fish-Git proposed the shared area in POC SWAP128 (in this thread). My development of instructions for zVector, involving bigendian storage, and the REFRESH/UPDATE mechanism. So I will absolutely have to change it. I have not had much time to dedicate to it in these months and I don't have access to a real mainframe to test some complex instructions. But I think Fish's approach is the right one and I encourage you to start the AFPR changes while I adapt the VR ones. Regards, salva. |
|
Hi Salva, From my limited knowledge of Vector, and reading your code, it appears to me that when the 128-bits are loaded from storage into a vector register, the vector register might contain one 128-bit vector, or two 64-bit vectors, or four 32-bit vectors, or eight 16-bit vectors, or sixteen 8-bit vectors, or maybe even a combination of different sized vectors. It's only when a zVector instruction subsequently manipulates the contents of the register that the size of a vector becomes apparent. Hence your vector code has to keep the register contents in the regs structure as a sequence of bytes (i.e. effectively big endian), and CSWAP the vector(s) to/from host endianness to suit the vector size required by the vector instruction. Is this your understanding too? Or am I missing something? The FP registers contents in the regs structure are currently kept in the endianness of the host. If vector registers must be kept as big endian, then fp registers will also have to be kept as big endian. Which will have an impact on the design and usage of the shared area for vector/fp registers. Cheers, Ian p.s. Is you name Salva, am I addressing you correctly? |
* * * PLEASE NOTE: * * *A new issue has been created for discussing development of the z/Architecture Vector Facility: Issue #650: "Vector Facility for z/Architecture" GitHub Issue #77 (i.e. this issue) is a generic GitHub Issue regarding all yet-to-be-developed z/Architecture facilities, and not just the Vector Facility. Please refrain from discussing z/Architecture Vector Facility development anywhere else, and discuss instead in the newly created GitHub Issue #650. Thank you. |
Hercules is currently missing support for the following z/Architecture facilities:
Note: Those that are checked have been recently implemented and thus are now supported. The ones that are unchecked are those which are currently unsupported and still need to be implemented.
For a complete list of supported/unsupported facilities, please see Question 5.01 of our "Frequently Asked Questions" document.
The text was updated successfully, but these errors were encountered: