MISSING Facilities support

[Fish-Git]

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.

• BEAR-Enhancement Facility
• Configuration-z/Architecture-Architectural-Mode (CZAM) Facility
• Constrained-Transactional-Execution Facility
• CPU-Measurement Counter Facility
• CPU-Measurement Sampling Facility
• Decimal-Floating-Point Packed-Conversion Facility
• Decimal Floating Point Zoned-Conversion Facility
• DEFLATE-Conversion Facility
• Enhanced-DAT Facility 2
• Enhanced-Sort Facility
• Enhanced-Suppression-on-Protection Facility 2
• Entropy Encoding Compression Facility
• ESA/390-Compatibility-Mode Facility
• Execution-Hint Facility
• Extended-I/O-Measurement-Block Facility
• Extended-I/O-Measurement-Word Facility
• FCX-Bidirectional-Data-Transfer Facility
• Fibre-Channel Extensions (FCX) Facility
• Guarded-Storage Facility
• Insert-Reference-Bits-Multiple Facility
• Instruction-Execution-Protection Facility
• Load-and-Trap Facility
• Load-and-Zero-Rightmost-Byte Facility
• Load-Program-Parameter Facility
• Load/Store-on-Condition Facility 2
• Local-TLB-Clearing Facility
• Message-Security-Assist Extension 5
• Message-Security-Assist Extension 6
• Message-Security-Assist Extension 7
• Message-Security-Assist Extension 8
• Message-Security-Assist Extension 9
• Miscellaneous-Instruction-Extensions Facility 1
• Miscellaneous-Instruction-Extensions Facility 2
• Miscellaneous-Instruction-Extensions Facility 3
• Move-Page-and-Set-Key Facility
• Multiple-Epoch Facility
• Multithreading Facility
• Neural-Network-Processing-Assist Facility
• Nonquiescing Key-Setting Facility
• Order Preserving Compression Facility
• PER Storage-Key-Alteration Facility
• PER Zero-Address-Detection Facility
• PFPO (Perform Floating Point Operation) Facility
• PPA-in-order Facility
• Processor-Activity-Instrumentation Facility
• Processor-Activity-Instrumentation Extension 1 Facility
• Processor-Assist Facility
• Reset-DAT-Protection Facility
• Restore-Subchannel Facility
• Secure-Execution-Unpack Facility
• Server-Time-Protocol Facility
• Side-Effect-Access Facility
• Storage-Key-Removal Facility
• Test-Pending-External-Interruption Facility
• Transactional-Execution Facility
• Ultravisor-Call Facility
• Vector-Enhancements Facility 1
• Vector-Enhancements Facility 2
• Vector Packed-Decimal Facility
• Vector-Packed-Decimal-Enhancement Facility 1
• Vector-Packed-Decimal-Enhancement Facility 2
• Warning-Track Interruption Facility
• z/Architecture Vector Facility

[Fish-Git]

• At opcode.c
  static INSTR_FUNC gen_opcode_e7xx[256][NUM_INSTR_TAB_PTRS];
static INSTR_FUNC gen_opcode_e7xx[256][NUM_INSTR_TAB_PTRS] =
{
/*E700*/ GENx___x___x___ ,
/*E701*/ GENx___x___x___ ,
/*E702*/ GENx___x___x___ ,
/*E703*/ GENx___x___x___ ,
/*E704*/ GENx___x___x___ ,
/*E705*/ GENx___x___x___ ,
/*E706*/ GENx___x___x900("VL" , VRX , ASMFMT_none , vector_load),...

 

Compile ok, build a minimum test and starts Hercules with facility 129 enabled. But I'm receiving a 0C1 because the opcode (E7xxxxxxxx06) is undefined.

What am i missing? Can you point me to a good place in cpu.c to place a breakpoint to debug?

Thanks in advance, salva.

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 e7xx table with an entry for the E7........06 Vector Load and E7........0E Vector Store instructions, but the e7xx table is not being used anywhere! (Oops!)

In the gen_opcode_table table in opcode.c, you need to update the entry for the E7 opcode in the same way we're currently doing it for the E3, E4, E5 and E6 opcodes:

 /*E7*/   GENx___x___x900 ( ""          , e7xx , ASMFMT_e7xx     , execute_opcode_e7xx                                 ),

Additionally, you're going to need to add a new IPRINT_ROUT2 entry for e7xx:

IPRINT_ROUT2( e7xx, [5] )

and a corresponding IPRINT_FUNC function for format ASMFMT_VRX (and fix your gen_opcode_e7xx table entry to specify that format instead of ASMFMT_none which you're using now, which is wrong).

And finally, and most importantly, you're going to need to add a new statement to the init_runtime_opcode_tables function to properly initialize the e7xx table entries so that the facility.c code can properly update them to actually enable the instructions (and so our instruction routing logic can find them too!):

      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 E3, E4, E5 and E6 series of opcodes. So you can use one of them as a template, as guidance, for what you need to do for the new E7 opcodes you're adding.

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!

[salva-rczero]

Thanks @Fish-Git, I made some progress:

At opcode.c "e7xx" looks similar to "e6xx":

	Line 1841: static INSTR_FUNC gen_opcode_e7xx[256][NUM_INSTR_TAB_PTRS];
	Line 1897: #define execute_opcode_e7xx     operation_exception
	Line 2818:  /*E7*/   GENx370x390x900 ( ""          , e7xx , ASMFMT_e7xx     , execute_opcode_e7xx          ),
	Line 4593: static INSTR_FUNC gen_opcode_e7xx[256][NUM_INSTR_TAB_PTRS] =
	Line 7316:       replace_opcode_xxxx(arch, gen_opcode_e7xx[i][arch], 0xe7, i);

	Line 1840: static INSTR_FUNC gen_opcode_e6xx[256][NUM_INSTR_TAB_PTRS];
	Line 1896: #define execute_opcode_e6xx     operation_exception
	Line 2817:  /*E6*/   GENx370x390x900 ( ""          , e6xx , ASMFMT_e6xx     , execute_opcode_e6xx           ),
	Line 4333: static INSTR_FUNC gen_opcode_e6xx[256][NUM_INSTR_TAB_PTRS] =
	Line 7315:       replace_opcode_xxxx(arch, gen_opcode_e6xx[i][arch], 0xe6, i);

ASMFMT_VRX is working fine:

19:38:31 HHC00801I Processor CP00: Operation exception interruption code 0001 ilc 6
19:38:31 HHC02324I PSW=0000000000000000 000000000000000E INST=E710C0380006 VL    1,56(0,12),0           vector_load
19:38:31 HHC02326I R:0000000000000038:K:06=00000000 00000000 00000000 00000000  ................
19:38:31 HHC02326I R:0000000000000006:K:06=41D0 C80041D0 D800E710 C0380006 47F0 .}H..}Q.X.{....0
19:38:31 HHC02269I R0=0000000000000000 R1=0000000000000000 R2=0000000000000000 R3=0000000000000000
19:38:31 HHC02269I R4=0000000000000000 R5=0000000000000000 R6=0000000000000000 R7=0000000000000000
19:38:31 HHC02269I R8=0000000000000000 R9=0000000000000000 RA=0000000000000000 RB=0000000000000000
19:38:31 HHC02269I RC=0000000040000000 RD=0000000000001000 RE=0000000000000000 RF=0000000000000000

but still abending with 01C. I'll keep going, but there is too much new things for me.

Regards, salva.

[Fish-Git]

but still abending with 01C.

Can you show us your code? Do you have a repository we could clone? I'm sure it's something simple.

I'll keep going, but there is too much new things for me.

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?

[Fish-Git]

but still abending with 01C.

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:

Vector Enablement Control

The vector instructions should only be used if both
the vector enablement control (bit 46) and the AFP-
register-control (bit 45) in control register zero are set
to one. If the vector facility for z/Architecture is
installed and a vector instruction is executed without
the vector enablement control set, a data exception
with DXC FE hex is recognized. If bit 45 of control
register zero is not also set to one, it is unpredictable
if a data exception is recognized. If the vector facility
for z/Architecture is not installed, an operation excep-
tion is recognized.

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:

Programming Note: When a control program initially
enables the vector facility for z/Architecture for a task,
which may occur in response to a data exception with
DXC FE, it should ensure that newly enabled full vec-
tor registers as well as the rightmost portions of vec-
tor registers that overlap with any enabled floating-
point registers are zeroed.

Try setting a breakpoint on your test instruction ('b' command), and when it's hit, display the control registers ('cr' command) and verify whether bits 45 and 46 of Control Register 0 are set or not. If they're not set, then it might z/OS that's causing your problem? (I don't know z/OS!)

p.s. I'd still like to see your code.

[salva-rczero]

Thanks you, @Fish-Git

• 0C1 = operation exception (PIC 001). I'm sorry, I still think in JCL & Assembler.
• I'm trying a STAK standalone core sample, following your instructions.

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.

[salva-rczero]

@Fish-Git

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.

[Fish-Git]

Finally, I get the zVector facility enabled.

Fantastic! I'm very proud of you!  :)

Please check my updates at https://github.com/salva-rczero/hyperion-zvector.

I'll definitely do that the moment I get the opportunity.  (I'm still busy --AS USUAL! -- with many other things right now)

p.s. Please be patient, I'm an old mainframer and Visual Studio, x64, Git... are all new things for me.

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!     :-D

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.  :)

[salva-rczero]

Thank you @Fish-Git.

Now I have four zvector instructions "working": VL, VLM, VST and VSTM:

• https://github.com/salva-rczero/hyperion-zvector

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:

1. Is this thread the right place? Or should I do it somewhere else (e.g. groups.io/Hercules, email...)?

2. The compilation seems slow to me. Even modifying a small line, it recompiles almost the whole project. Is there something I'm doing wrong?

3. On the other hand, there are times when it is necessary to clean and do a complete re-completion (with so much macro, VS sometimes seems to become disoriented). Again, am I doing something wrong?

4. How do I get compiler output mapping of structs? (layout including type, size & offset), as Mainframe do for Assembler, Cobol, PL/1...

• I can build the Debug config, but can't run it. I receive a 0xC0150002 windows error. Point to a DLL error. Does it works for you?
  Solved: download & rebuild extpkgs following "Building "External Packages""

6. Some vector opcodes admit an "alignment hint" to speed up load/store. Does Hercules need to consider it or it is only for real iron?

7. As you know VR0-16 overlaps (partially) with FPR. In addition, Hercules considers FPRs as 32x32b instead 16x64b.
   Pointing all these data to same contiguous storage location sounds impossible. What is the best approach?

[Fish-Git]

Now I have four zvector instructions "working": VL, VLM, VST, VSTM. Check at https://github.com/salva-rczero/hyperion-zvector.

Fantastic! I'm cloning and looking at your repository now.

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:

1. Is this thread the right place? Or should I do it somewhere else (e.g. groups.io/Hercules, email...)?

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.

 

2. The compilation seems slow to me. Even modifying a small line, it recompiles almost the whole project. Is there something I'm doing wrong?

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.

 

3. On the other hand, there are times when it is necessary to clean and do a complete re-completion (with so much macro, VS sometimes seems to become disoriented). Again, am I doing something wrong?

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".

 

4. How do I get compiler output mapping of structs? (layout including type, size & offset), as Mainframe do for Assembler, Cobol, PL/1...

I don't understand this question.  :(

 

5. I can build the Debug config, but can't run it. I receive a 0xC0150002 windows error. Point to a DLL error. Does it works for you?

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.

 

6. Some vector opcodes emit an "alignment hint" to speed up load/store. Does Hercules need to consider it or it is only for real iron?

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 machdep.h header.

 

7. As you know VR0-16 overlaps (partially) with FPR. In addition, Hercules considers FPRs as 32x32b instead 16x64b.
Pointing all these data to same contiguous storage location sounds impossible. What is the best approach?

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. :(

[s390guy]

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.

[Fish-Git]

SWAP128 Test Program

I would appreciate feeback on the attached. Refer to the README file for details:

• swap128.zip

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.

[Fish-Git]

SWAP128 version 2

Here's the updated .zip file:

• swap128.zip

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.

[salva-rczero]

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.

[Dorpstraat]

Hi @salva-rczero ,
I tried to build your version of Hyperion on Linux, but I get the following messages.
Does that tell you something. It's the result of the make:

/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_logical_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_galois_field_multiply_sum_and_accumulate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_subtract_compute_borrow_indication'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_subtract_with_borrow_indication'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_left'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_select'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_test_data_class_immediate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_logical_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_compare_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_fp_integer'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_add'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_unpack_low'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_gr_from_vr_element'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_positive'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_permute_doubleword_immediate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_unpack_logical_low'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_compare_scalar'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_find_element_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_subtract'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_minimum'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_find_element_not_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_scatter_element_32'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_element_16'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_maximum_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_64'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_right_arithmetic_vector'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_exclusive_or'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_left_by_byte'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_load_lengthened'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_pack_saturate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_load_count_to_block_boundary'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_compare_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_add_with_carry'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_gather_element_64'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_convert_to_fixed_64_bit'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_load_rounded'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_and_with_complement'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_isolate_string'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_string_range_compare'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_compare_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_16'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_average'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_minimum_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_and'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_gather_element_32'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_maximum'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_right_arithmetic'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_element_64'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_pack'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_add_compute_carry'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_vector'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_pack_logical_saturate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_multiply_and_add'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_galois_field_multiply_sum'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_even'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_with_length'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_8'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_right_arithmetic_by_byte'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_immediate_64'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_convert_from_fixed_64_bit'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_logical_element_and_zero'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_subtract_with_borrow_compute_borrow_indication'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_compare_high_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_sum_across_word'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_even'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_checksum'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_odd'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_right_arithmetic'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_vr_from_grs_disjoint'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_replicate_immediate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_complement'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_sign_extend_to_doubleword'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_convert_from_logical_64_bit'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_logical_odd'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_low'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_sum_across_doubleword'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_right_logical_by_byte'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_unpack_logical_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_add_with_carry_compute_carry'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_multiple'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_odd'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_logical_even'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_compare_and_signal_scalar'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_with_length'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_subtract'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_immediate_16'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_low'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_vr_element_from_gr'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_count_trailing_zeros'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_divide'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_perform_sign_operation'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_rotate_left_logical_vector'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_and_replicate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_logical_odd'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_merge_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_population_count'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_generate_mask'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_left'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_element_8'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_count_leading_zeros'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_and_add_logical_even'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_rotate_and_insert_under_mask'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_convert_to_logical_64_bit'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_scatter_element_64'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_immediate_8'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_right_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_average_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_compare'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_left_double_by_byte'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_unpack_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_sum_across_quadword'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_immediate_32'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_square_root'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_nor'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_element_32'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_compare_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_or'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_test_under_mask'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_left_vector'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_permute'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_add'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_compare_high_or_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_generate_byte_mask'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_shift_right_logical_vector'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_shift_right_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_element_32'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_find_any_element_equal'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_multiply_and_subtract'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_store_multiple'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_element_rotate_left_logical'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_merge_low'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_load_to_block_boundary'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_fp_multiply'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_replicate'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_compare_high'
/usr/bin/ld: ./.libs/libherc.so: undefined reference to `z900_vector_multiply_high'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:2352: hercules] Error 1
make[2]: Leaving directory '/home/hercules/hyperion-zvector-develop'
make[1]: *** [Makefile:2661: all-recursive] Error 1
make[1]: Leaving directory '/home/hercules/hyperion-zvector-develop'
make: *** [Makefile:1987: all] Error 2

Regards, Loet

[salva-rczero]

Please try to add: zvector.c \ in Makefile.am at line 523. Regards, salva.

[Dorpstraat]

Hi @salva-rczero

thanks for the quick response
However...I get exactly the same errors from the make.
Must confess I don't know much about developing on Linux.
For example, how do I see whether zvector.c is actually included in the compilation

Regards,
Loet

[salva-rczero]

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.

[Dorpstraat]

Hi @salva,

I've read that the makefile.in is the real input to the installation process:

1. ./configure
2. make
3. make install
   I have therefore modified makefile.in and added a similar line with 'zvector' where 'vector' is mentioned. I may have broken some development protocols with this.
   The make process no longer gave any error messages. Now continue testing what the result is

Thanks again
Loet

[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

[Dorpstraat]

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: ***@***.***>

[Peter-J-Jansen]

Hi Vincent,

As you wrote :

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

Have you already tried to bypass the WAIT 07B RAESON 23 by using the Hercules' facility command, e.g. :

facility enable 129_ZVECTOR
facility enable 134_ZVECTOR_PACK_DEC
facility enable 135_ZVECTOR_ENH_1

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 MACHMIG VEF statement in the appropriate 'SYS1.IPLPARM(LOADxx)' member.

[Fish-Git]

facility enable 129_ZVECTOR
facility enable 134_ZVECTOR_PACK_DEC
facility enable 135_ZVECTOR_ENH_1

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)

 
Instead, you need to forcibly set (forcibly enable) the corresponding facility bit number:

FACILITY  ENABLE  054       # 054_EE_CMPSC
FACILITY  ENABLE  129       # 129_ZVECTOR
FACILITY  ENABLE  130       # 130_INSTR_EXEC_PROT
FACILITY  ENABLE  134       # 134_ZVECTOR_PACK_DEC
FACILITY  ENABLE  135       # 135_ZVECTOR_ENH_1

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 *MASTER* crashes during startup with:

 19.48.43   IEF773I TIOT SIZE = 0032K, MAXIMUM SINGLE UNIT DD ENTRIES = 00001635
 19.48.44   IEFJ200I MASTER SCHEDULER JCL FOR THIS IPL TAKEN FROM MEMBER MSTJCLSA OF PARMLIB
 19.48.44   IEF403I MSTJCLSA - STARTED - TIME=19.48.44
 19.48.44   IEA045I AN SVC DUMP HAS STARTED AT TIME=19.48.44 DATE=03/27/2024 FOR ASIDS(0001,0012) ERROR ID = SEQ00001 CPU00 ASID0001 TIME 19.48.44.7 QUIESCE = YES
*19.48.47  *IEE479W MASTER SCHEDULER ABEND 0A0, DUMPED, REIPL - CODE 1Z
 19.48.47   IEA794I SVC DUMP HAS CAPTURED: DUMPID=001 REQUESTED BY JOB (*MASTER*) DUMP TITLE=ERROR IN INITIATOR,ABEND=0A0,COMPON=INIT,COMPID=SC1B6,ISSUER=IEFIB620 INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING
*19.48.47  *01 IEA793A NO DUMP DATA SETS AVAILABLE FOR DUMPID=001 BY JOB (*MASTER*). USE THE DUMPDS COMMAND OR REPLY D TO DELETE THE DUMP

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.  :(

[Peter-J-Jansen]

Hi Fish,

Thanks for the feedback. I didn't know there was a difference for the facility command between using bit numbers and the longer format also specifying the facility in text format. And yes, indeed, to IPL z/OS 2.5 I did use just the bit number, 129 in this case, which works.

So you answered my question, in that in this case such facility bypasses do not allow IPL-ing z/OS 3.1.

Cheers,

Peter

[mcisho]

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

[salva-rczero]

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.

[mcisho]

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?

[Fish-Git]

* * *  PLEASE NOTE:  * * *

A new issue has been created for discussing development of the z/Architecture Vector Facility:

        Issue #650:   "Vector Facility for z/Architecture"

 
All discussion regarding development of the z/Architecture Vector Facility should take place in GitHub Issue #650, and NOT HERE,

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.