Re: OPCODE tables
On Fri, 22 Mar 2024 at 13:46, Dan Greiner wrote: > [...] > One newer facility that might prove to be a significant benefit to older > code – and worthy of upgrade – is the vector packed-decimal facility > (introduced on the z14) and its enhancements 1 and 2 (introduced on the z15 > and z16, respectively). For packed-decimal workloads, avoiding all of the > memory accesses inherent to the Chapter 8 decimal instructions – and having > 32 128-bit registers – is a real attraction. An alternative to branchy > dual-path code might be to have separate load modules – one for the > original-recipe code and one for the extra-crispy code – that are > dynamically invoked based on the presence (or absence) of the particular > facility. > There was talk from IBM some years ago about supporting "fat binaries" i.e. Program Objects that contain two or more alternative modules, along with some environment-based mechanism to choose which one gets invoked by z/OS. IIRC it was Bob Rogers who presented on it, and of course various other OSs and architectures have had this kind of thing for a long time. https://en.wikipedia.org/wiki/Fat_binary I don't think it was ever shipped in z/OS, but it would seem like a good solution to this aspect of the problem. Tony H.
Re: OPCODE tables
A few years back (few being relative), when z/Architecture was first introduced, we wound up doing exactly what Dan suggests. We had one module that did a lot of data manipulation and created another module to do the same processing using 64 bit architecture.I remember dual-pathing one piece of code where a subroutine could be reduced to a handful of instructions, but that was certainly an exceptional case (and IIRC, removed the dual-pathing before putting it into production anyway). *Mark* On Fri, Mar 22, 2024 at 12:46 PM Dan Greiner wrote: > For the past few decades, much of the instruction-set-architecture (ISA) > enhancements to Z-series processors has been driven by Java, where dynamic > code generation can immediately make use of newer instructions. One of the > frustrations in architecting newer ISA facilities is the realization that > they might not get used by non-dynamic-interpretation environments for > years. It was my understanding that this lack of broad utilization is what > killed off transactional execution. > > As Peter Relson notes, it's hard to imagine many newer instructions that > warrant dual-path code, depending on whether they're installed or not. Not > only is there the overhead of branchy code, but the nuisance of testing > both paths and correctly ensuring that the paths are properly taken. > > One newer facility that might prove to be a significant benefit to older > code – and worthy of upgrade – is the vector packed-decimal facility > (introduced on the z14) and its enhancements 1 and 2 (introduced on the z15 > and z16, respectively). For packed-decimal workloads, avoiding all of the > memory accesses inherent to the Chapter 8 decimal instructions – and having > 32 128-bit registers – is a real attraction. An alternative to branchy > dual-path code might be to have separate load modules – one for the > original-recipe code and one for the extra-crispy code – that are > dynamically invoked based on the presence (or absence) of the particular > facility. >
Re: OPCODE tables
For the past few decades, much of the instruction-set-architecture (ISA) enhancements to Z-series processors has been driven by Java, where dynamic code generation can immediately make use of newer instructions. One of the frustrations in architecting newer ISA facilities is the realization that they might not get used by non-dynamic-interpretation environments for years. It was my understanding that this lack of broad utilization is what killed off transactional execution. As Peter Relson notes, it's hard to imagine many newer instructions that warrant dual-path code, depending on whether they're installed or not. Not only is there the overhead of branchy code, but the nuisance of testing both paths and correctly ensuring that the paths are properly taken. One newer facility that might prove to be a significant benefit to older code – and worthy of upgrade – is the vector packed-decimal facility (introduced on the z14) and its enhancements 1 and 2 (introduced on the z15 and z16, respectively). For packed-decimal workloads, avoiding all of the memory accesses inherent to the Chapter 8 decimal instructions – and having 32 128-bit registers – is a real attraction. An alternative to branchy dual-path code might be to have separate load modules – one for the original-recipe code and one for the extra-crispy code – that are dynamically invoked based on the presence (or absence) of the particular facility.
Re: OPCODE tables
Dan Greiner wrote At execution time, the only safe way to ensure that an instruction is present in the configuration (other than taking a punch on the chin if it's not) is to query whether the respective facility is installed by means of the STFLE instruction. If on z/OS you might be able to take advantage of the architecture level set (ALS) for each release. The list of facilities upon which you may rely for each z/OS release are listed. I look here: https://www.ibm.com/docs/en/zos/3.1.0?topic=system-identifying-server-requirements If POp indicates that an instruction will get an operation exception if such and such a facility is not available, and you are allowing your product to run on a z/OS release that does not include that facility in its list, you could/would be putting your customer at risk. As Dan points out, some things are available on a machine but not surfaced to the user, depending on release and on environment (such as whether running as a guest under z/VM). I'd imagine that very few instructions are worth determining at runtime to see if they are available and dual-pathing your code Note of caution: IBM has issued a statement of direction about withdrawal of the transactional execution facility, even though it is part of the z/OS 2.4 ALS. Peter Relson z/OS Core Technology Design
Re: OPCODE tables
This sort of discussion is periodically raised – within IBM as well as without – which caused me to come up with a definitive spreadsheet of what machine implemented each instruction, beginning with the S/360. Unfortunately, it also contained a lot of IBM confidential instructions, and I left it behind when I left the IBM Systems Architecture group. However, even with such a table, it leads to the common misconception of thinking an instruction is installed in a configuration ... just because it's installed on a particular machine. Many of the newer instructions – particularly the more complicated ones – require the assistance of a hypervisor (e.g., zVM or KVM) in order for them to be valid in a guest configuration. Vector instructions are a good example ... there have been hundreds of them available ever since the z13, but if you're running on a z15 with a back-level (pre-z13) hypervisor, the instructions won't be available to a VM guest. This is because the back-level hypervisor is clueless as to the saving and restoring of the vector registers when a guest program is dispatched. There are numerous other examples of such instructions (don't get me started on transactional execution ... grumble, mutter). At execution time, the only safe way to ensure that an instruction is present in the configuration (other than taking a punch on the chin if it's not) is to query whether the respective facility is installed by means of the STFLE instruction. z/OS programmers, don't bother with STFLE, the OS stores this for you somewhere in the prefix or CVT ... I forget which. The PoO description of such newer instructions will indicate the facility to which it's associated in the list of program exceptions for the instruction. The hypervisor will appropriately trim the STFLE results for whichever facilities it knows how to support.
Re: OPCODE tables
I guess the best you can do for your future product updates is to ask your team to make sure they are always checking the latest edition of the PoOps manual when they are coding new changes. Peter From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Thursday, March 21, 2024 5:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables Thanks for the reminder Peter. More curiosity than anything else. The product I support currently uses MACHINE(ARCH-10) in ASMAOPTS so that we can all but guarantee that any customer can run the software. With that said, I try to keep a current copy of PoOps on hand. Since the latest and greatest is -13 (revision 14), I know there are instructions that aren't supported at ARCH-10 (z12). I was really more interested in avoiding the "trial and error" approach to utilizing "new" instructions. We ran into the problem a few years back where one of our developers used some instruction (don't even remember which one now) that assembled clean with the HLASM defaults (OPTABLE(UNI)) but failed at a customer site. That's when we added ARCH-10. The issue hasn't come up since and I am probably the only member of the team crazy enough to even experiment with new instructions. This came to a head the other day when one of our other developers used an instruction that assumed (according to the latest PoOps) a doubleword boundary but his (very) outdated, private copy didn't say anything about it (honestly, it probably did, he just missed it). *Mark Hammack* On Thu, Mar 21, 2024 at 3:46 PM Farley, Peter < 0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote: > Following up on my own reply to ask Mark: What is your goal/need? Just > curiosity, or do you have a project / task that needs this information? If > the latter, can you describe what you need? We may be able to help you > better if we know what you need. > > Peter > > From: IBM Mainframe Assembler List On > Behalf Of Farley, Peter > Sent: Wednesday, March 20, 2024 5:54 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: OPCODE tables > > PoOPS in the “Summary of Changes” sections usually have at least some > listing (in text format, nothing tablularized or easy to pick out) of > instructions added in each manual section, but sometimes those are > “generic” and don’t include all the variations of added instructions. > > The only way I can think of to accurately (more or less) track the > additions would be to extract the Appendix B instruction table that is in > OPCODE order to a text format file and then compare each edition’s table to > the prior edition’s table. > > I can say from personal experience that the “pdftotext” command-line > utility available from the XPDF project ( https://www.xpdfreader.com/ ) > (which is NOT the “pdftotext” version normally included in many linux > systems) for Windows execution works pretty well on most editions of PoOPS > once you use the right command-line parameters. Once extracted to pure > text the tables are at least in a manipulable form that a subsequent text > tool can massage into a format you can use for comparisons and extraction > of “differences”. > > But truthfully the OPTABLE lists are probably the easier solution. Just > run a separate assembly with each OPTABLE value and massage the output to > make the columns of instructions into one-line-per-instruction format and > you will be able to compare each generation to the next. SMOP, and (g)awk > or python would be a reasonable tool to do the text manipulation needed. > > Peter > > From: IBM Mainframe Assembler List On > Behalf Of Mark Hammack > > Sent: Wednesday, March 20, 2024 5:12 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: OPCODE tables > > Is there a list somewhere (other than OPTABLE LIST) that shows which > instructions were added at each hardware level? > > I thought PoP used to have something similar but I don't see anything back > to Revision 7 (oldest copy I have). > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: OPCODE tables
Thanks for the reminder Peter. More curiosity than anything else. The product I support currently uses MACHINE(ARCH-10) in ASMAOPTS so that we can all but guarantee that any customer can run the software. With that said, I try to keep a current copy of PoOps on hand. Since the latest and greatest is -13 (revision 14), I know there are instructions that aren't supported at ARCH-10 (z12). I was really more interested in avoiding the "trial and error" approach to utilizing "new" instructions. We ran into the problem a few years back where one of our developers used some instruction (don't even remember which one now) that assembled clean with the HLASM defaults (OPTABLE(UNI)) but failed at a customer site. That's when we added ARCH-10. The issue hasn't come up since and I am probably the only member of the team crazy enough to even experiment with new instructions. This came to a head the other day when one of our other developers used an instruction that assumed (according to the latest PoOps) a doubleword boundary but his (very) outdated, private copy didn't say anything about it (honestly, it probably did, he just missed it). *Mark Hammack* On Thu, Mar 21, 2024 at 3:46 PM Farley, Peter < 0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote: > Following up on my own reply to ask Mark: What is your goal/need? Just > curiosity, or do you have a project / task that needs this information? If > the latter, can you describe what you need? We may be able to help you > better if we know what you need. > > Peter > > From: IBM Mainframe Assembler List On > Behalf Of Farley, Peter > Sent: Wednesday, March 20, 2024 5:54 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: OPCODE tables > > PoOPS in the “Summary of Changes” sections usually have at least some > listing (in text format, nothing tablularized or easy to pick out) of > instructions added in each manual section, but sometimes those are > “generic” and don’t include all the > > > PoOPS in the “Summary of Changes” sections usually have at least some > listing (in text format, nothing tablularized or easy to pick out) of > instructions added in each manual section, but sometimes those are > “generic” and don’t include all the variations of added instructions. > > > > The only way I can think of to accurately (more or less) track the > additions would be to extract the Appendix B instruction table that is in > OPCODE order to a text format file and then compare each edition’s table to > the prior edition’s table. > > > > I can say from personal experience that the “pdftotext” command-line > utility available from the XPDF project ( https://www.xpdfreader.com/< > https://www.xpdfreader.com/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LTDRS2aaGRXofSVxV_1lkuLsz1cE89LPs6WuA3ZaoAM997uW92xXIwwMdkC10x87ZMhpoO6I-yz86LoK-i82BYuqOoW6YITuY2Wp6edI$> > ) (which is NOT the “pdftotext” version normally included in many linux > systems) for Windows execution works pretty well on most editions of PoOPS > once you use the right command-line parameters. Once extracted to pure > text the tables are at least in a manipulable form that a subsequent text > tool can massage into a format you can use for comparisons and extraction > of “differences”. > > > > But truthfully the OPTABLE lists are probably the easier solution. Just > run a separate assembly with each OPTABLE value and massage the output to > make the columns of instructions into one-line-per-instruction format and > you will be able to compare each generation to the next. SMOP, and (g)awk > or python would be a reasonable tool to do the text manipulation needed. > > > > Peter > > > > From: IBM Mainframe Assembler List On > Behalf Of Mark Hammack > > Sent: Wednesday, March 20, 2024 5:12 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: OPCODE tables > > > > Is there a list somewhere (other than OPTABLE LIST) that shows which > > > > instructions were added at each hardware level? > > > > I thought PoP used to have something similar but I don't see anything back > > to Revision 7 (oldest copy I have). > > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. >
Re: OPCODE tables
Following up on my own reply to ask Mark: What is your goal/need? Just curiosity, or do you have a project / task that needs this information? If the latter, can you describe what you need? We may be able to help you better if we know what you need. Peter From: IBM Mainframe Assembler List On Behalf Of Farley, Peter Sent: Wednesday, March 20, 2024 5:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables PoOPS in the “Summary of Changes” sections usually have at least some listing (in text format, nothing tablularized or easy to pick out) of instructions added in each manual section, but sometimes those are “generic” and don’t include all the PoOPS in the “Summary of Changes” sections usually have at least some listing (in text format, nothing tablularized or easy to pick out) of instructions added in each manual section, but sometimes those are “generic” and don’t include all the variations of added instructions. The only way I can think of to accurately (more or less) track the additions would be to extract the Appendix B instruction table that is in OPCODE order to a text format file and then compare each edition’s table to the prior edition’s table. I can say from personal experience that the “pdftotext” command-line utility available from the XPDF project ( https://www.xpdfreader.com/<https://www.xpdfreader.com/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LTDRS2aaGRXofSVxV_1lkuLsz1cE89LPs6WuA3ZaoAM997uW92xXIwwMdkC10x87ZMhpoO6I-yz86LoK-i82BYuqOoW6YITuY2Wp6edI$> ) (which is NOT the “pdftotext” version normally included in many linux systems) for Windows execution works pretty well on most editions of PoOPS once you use the right command-line parameters. Once extracted to pure text the tables are at least in a manipulable form that a subsequent text tool can massage into a format you can use for comparisons and extraction of “differences”. But truthfully the OPTABLE lists are probably the easier solution. Just run a separate assembly with each OPTABLE value and massage the output to make the columns of instructions into one-line-per-instruction format and you will be able to compare each generation to the next. SMOP, and (g)awk or python would be a reasonable tool to do the text manipulation needed. Peter From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Wednesday, March 20, 2024 5:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: OPCODE tables Is there a list somewhere (other than OPTABLE LIST) that shows which instructions were added at each hardware level? I thought PoP used to have something similar but I don't see anything back to Revision 7 (oldest copy I have). -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: OPCODE tables
Bob, how much is that some $$$ .? I would be willing to help and support the attempt to resurrect Tachyon. Even with Dignus being as good as it is. Would you be able to get in touch with Kay and get somewhere or would it need an other person? Martin Am 21.03.24 um 18:45 schrieb Bob Raicer: What David Cole said is sad and true. After the dissolution of marriage and Kay Bond taking over the business, David and Kay asked me if I would be interested in helping Kay with technical support and maintenance of the Tachyon software suite. I said Yes, and, for a brief time, I did what I could for zero charge (I was a friend and I didn't want any sort of compensation). Unfortunately, Kay lost interest in the products and running a small company, and the rest of the story is the obvious. It really is too bad. The Tachyon software is very good. I started using the assembler when David and I worked together, some time before he and Kay launched the company. I suppose it might be possible to resurrect the products, but Kay would need to be willing to let someone take over the company (probably for some $$$) and that someone would need to help me with the code. I think it's all unlikely. Bob On 2024-03-21 10:41 AM, David Cole wrote: Dave Bond and his wife got divorced. The wife got the business, Dave got his freedom. Tachyon has been orphaned.
Re: OPCODE tables
What David Cole said is sad and true. After the dissolution of marriage and Kay Bond taking over the business, David and Kay asked me if I would be interested in helping Kay with technical support and maintenance of the Tachyon software suite. I said Yes, and, for a brief time, I did what I could for zero charge (I was a friend and I didn't want any sort of compensation). Unfortunately, Kay lost interest in the products and running a small company, and the rest of the story is the obvious. It really is too bad. The Tachyon software is very good. I started using the assembler when David and I worked together, some time before he and Kay launched the company. I suppose it might be possible to resurrect the products, but Kay would need to be willing to let someone take over the company (probably for some $$$) and that someone would need to help me with the code. I think it's all unlikely. Bob On 2024-03-21 10:41 AM, David Cole wrote: Dave Bond and his wife got divorced. The wife got the business, Dave got his freedom. Tachyon has been orphaned.
Re: OPCODE tables
Dave Bond and his wife got divorced. The wife got the business, Dave got his freedom. Tachyon has been orphaned. At 3/20/2024 04:34 PM, Tony Harminc wrote: On Wed, 20 Mar 2024 at 17:12, Mark Hammack wrote: > Is there a list somewhere (other than OPTABLE LIST) that shows which > instructions were added at each hardware level? > > I thought PoP used to have something similar but I don't see anything back > to Revision 7 (oldest copy I have). > Although I don't know the status of the Tachyon assembler, I still find the opcode tables there to be handy. http://www.tachyonsoft.com/inst390o.htm I don't think it's been updated for quite a few years - maybe since the z10 or so - but it's really good for historical stuff. Tony H.
Re: OPCODE tables
The OPCODE table, like the rest of the POO , has change bars to tell you what changed since the previous edition. -- Tom Marchant On Wed, 20 Mar 2024 21:53:35 +, Farley, Peter wrote: >The only way I can think of to accurately (more or less) track the additions >would be to extract the Appendix B instruction table that is in OPCODE order >to a text format file and then compare each edition’s table to the prior >edition’s table.
Re: OPCODE tables
This solution is a bit tedious, but you could first check Appendix J in Principles of Operation to see if the instruction is an extended mnemonic, and if it is then obtain the base mnemonic. Then you could look up the base mnemonic using the OPTABLE(LIST) approach described elsewhere. There are still a few holes in this approach, such as when a mnemonic was introduced on one machine but the instruction received optional operands on later machines. Once you've found the machine an instruction is available on, what are you doing with this information? Are you trying to find the (non-existent) optable that will allow a programmer to use, say, the LFI mnemonic even though the target machine is z9? If so, perhaps writing a few macros to extend the z9 optable would be an easier approach. You could also optionally define the macro only if the mnemonic is not already a defined instruction, to avoid have macro definitions that override valid instructions. Etc. - mb > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Ngan, Robert (DXC Luxoft) > Sent: Wednesday, March 20, 2024 7:26 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: [EXTERNAL] Re: OPCODE tables > > For comparing instructions available by hardware generation, that > doesn't work. OPTABLE(Zn) does not give you the instructions available > for the Zn hardware. It gives you the assembler mnemonics available in > HLASM when support for the Zn series hardware was added to HLASM. > > So LFI is an extended mnemonic for IILF, and IILF was introduced with > the z9. But LFI was added when HLASM was updated to support z16 > instructions so LFI will not assemble with OPTABLE values of Z9 thru > Z15. > The LOC/STOC instructions (z11) have a similar issue, since the OVERFLOW > condition code value were missed on the initial HLASM implementation, > and were subsequently added with z13 support (i.e. LOCE works with > OPTABLE(Z11) or higher, but LOCO required OPTABLE(Z13), and these are > basically the same instruction!). > > So if you want to restrict what instructions are available when your > target is a specific hardware series (which is what I was trying to do), > using OPTABLE for this does not work. > > Robert Ngan > DXC Luxoft > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Farley, Peter > Sent: Wednesday, March 20, 2024 16:54 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: OPCODE tables > > PoOPS in the "Summary of Changes" sections usually have at least some > listing (in text format, nothing tablularized or easy to pick out) of > instructions added in each manual section, but sometimes those are > "generic" and don't include all the variations of added instructions. > > The only way I can think of to accurately (more or less) track the > additions would be to extract the Appendix B instruction table that is > in OPCODE order to a text format file and then compare each edition's > table to the prior edition's table. > > I can say from personal experience that the "pdftotext" command-line > utility available from the XPDF project ( > INVALID URI REMOVED > 3A__www.xpdfreader.com_&d=DwIFAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=1ZPhfSkljoBv > uRHniz6Hffe-ZEO6qSawVTlotmCoew8&m=TTkrrIjrFghWJii- > ZRDvstgCvuQ3K877KrN2AZK8zBt7z2_yfSWkZgcRCawNVVlO&s=_znetlJiObqmSgEl4Qut9 > B1jLsotJaEIbWjCQzSVKO0&e= ) (which is NOT the "pdftotext" version > normally included in many linux systems) for Windows execution works > pretty well on most editions of PoOPS once you use the right command- > line parameters. Once extracted to pure text the tables are at least in > a manipulable form that a subsequent text tool can massage into a format > you can use for comparisons and extraction of "differences". > > But truthfully the OPTABLE lists are probably the easier solution. Just > run a separate assembly with each OPTABLE value and massage the output > to make the columns of instructions into one-line-per-instruction format > and you will be able to compare each generation to the next. SMOP, and > (g)awk or python would be a reasonable tool to do the text manipulation > needed. > > Peter > > From: IBM Mainframe Assembler List On > Behalf Of Mark Hammack > Sent: Wednesday, March 20, 2024 5:12 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: OPCODE tables > > > Is there a list somewhere (other than OPTABLE LIST) that shows which > > instructions were added at each hardware level? > > > > I thought PoP used to have something similar but I don't see anything > back > > to Revision 7 (oldest copy I have). > > -- > > &g
Re: OPCODE tables
Ian, Hercules is IMHO rather lax. So often opcodes which were not enabled at a particular hardware level on physical hardware, but don't clash with any existing opcodes, may be enabled at on Hercules. Dave > -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Ian Worthington > Sent: Wednesday, March 20, 2024 11:37 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: OPCODE tables > > I have a dim and distant memory that the Hercules folks might be on top of > this > as, iirc, isn't is possible to change hardware level with a configuration > parameter? > > Best wishes / Mejores deseos / Best wishes > > Ian ... > > On Wednesday, March 20, 2024 at 10:12:03 PM GMT+1, Mark Hammack > wrote: > > Is there a list somewhere (other than OPTABLE LIST) that shows which > instructions were added at each hardware level? > > I thought PoP used to have something similar but I don't see anything back to > Revision 7 (oldest copy I have). > > > *Mark Hammack* >
Re: OPCODE tables
I have a dim and distant memory that the Hercules folks might be on top of this as, iirc, isn't is possible to change hardware level with a configuration parameter? Best wishes / Mejores deseos / Best wishes Ian ... On Wednesday, March 20, 2024 at 10:12:03 PM GMT+1, Mark Hammack wrote: Is there a list somewhere (other than OPTABLE LIST) that shows which instructions were added at each hardware level? I thought PoP used to have something similar but I don't see anything back to Revision 7 (oldest copy I have). *Mark Hammack*
Re: OPCODE tables
For comparing instructions available by hardware generation, that doesn't work. OPTABLE(Zn) does not give you the instructions available for the Zn hardware. It gives you the assembler mnemonics available in HLASM when support for the Zn series hardware was added to HLASM. So LFI is an extended mnemonic for IILF, and IILF was introduced with the z9. But LFI was added when HLASM was updated to support z16 instructions so LFI will not assemble with OPTABLE values of Z9 thru Z15. The LOC/STOC instructions (z11) have a similar issue, since the OVERFLOW condition code value were missed on the initial HLASM implementation, and were subsequently added with z13 support (i.e. LOCE works with OPTABLE(Z11) or higher, but LOCO required OPTABLE(Z13), and these are basically the same instruction!). So if you want to restrict what instructions are available when your target is a specific hardware series (which is what I was trying to do), using OPTABLE for this does not work. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Farley, Peter Sent: Wednesday, March 20, 2024 16:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables PoOPS in the "Summary of Changes" sections usually have at least some listing (in text format, nothing tablularized or easy to pick out) of instructions added in each manual section, but sometimes those are "generic" and don't include all the variations of added instructions. The only way I can think of to accurately (more or less) track the additions would be to extract the Appendix B instruction table that is in OPCODE order to a text format file and then compare each edition's table to the prior edition's table. I can say from personal experience that the "pdftotext" command-line utility available from the XPDF project ( https://www.xpdfreader.com/ ) (which is NOT the "pdftotext" version normally included in many linux systems) for Windows execution works pretty well on most editions of PoOPS once you use the right command-line parameters. Once extracted to pure text the tables are at least in a manipulable form that a subsequent text tool can massage into a format you can use for comparisons and extraction of "differences". But truthfully the OPTABLE lists are probably the easier solution. Just run a separate assembly with each OPTABLE value and massage the output to make the columns of instructions into one-line-per-instruction format and you will be able to compare each generation to the next. SMOP, and (g)awk or python would be a reasonable tool to do the text manipulation needed. Peter From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Wednesday, March 20, 2024 5:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: OPCODE tables Is there a list somewhere (other than OPTABLE LIST) that shows which instructions were added at each hardware level? I thought PoP used to have something similar but I don't see anything back to Revision 7 (oldest copy I have). -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: OPCODE tables
PoOPS in the “Summary of Changes” sections usually have at least some listing (in text format, nothing tablularized or easy to pick out) of instructions added in each manual section, but sometimes those are “generic” and don’t include all the variations of added instructions. The only way I can think of to accurately (more or less) track the additions would be to extract the Appendix B instruction table that is in OPCODE order to a text format file and then compare each edition’s table to the prior edition’s table. I can say from personal experience that the “pdftotext” command-line utility available from the XPDF project ( https://www.xpdfreader.com/ ) (which is NOT the “pdftotext” version normally included in many linux systems) for Windows execution works pretty well on most editions of PoOPS once you use the right command-line parameters. Once extracted to pure text the tables are at least in a manipulable form that a subsequent text tool can massage into a format you can use for comparisons and extraction of “differences”. But truthfully the OPTABLE lists are probably the easier solution. Just run a separate assembly with each OPTABLE value and massage the output to make the columns of instructions into one-line-per-instruction format and you will be able to compare each generation to the next. SMOP, and (g)awk or python would be a reasonable tool to do the text manipulation needed. Peter From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Wednesday, March 20, 2024 5:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: OPCODE tables Is there a list somewhere (other than OPTABLE LIST) that shows which instructions were added at each hardware level? I thought PoP used to have something similar but I don't see anything back to Revision 7 (oldest copy I have). -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: OPCODE tables
I've used this one https://bixoft.nl/english/opl_bonm.htm Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Mark Hammack Sent: March 20, 2024 17:38 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables Thanks! That's pretty handy :-). *Mark* On Wed, Mar 20, 2024 at 4:35 PM Tony Harminc wrote: > On Wed, 20 Mar 2024 at 17:12, Mark Hammack wrote: > > > Is there a list somewhere (other than OPTABLE LIST) that shows which > > instructions were added at each hardware level? > > > > I thought PoP used to have something similar but I don't see anything > back > > to Revision 7 (oldest copy I have). > > > > Although I don't know the status of the Tachyon assembler, I still find the > opcode tables there to be handy. > > http://www.tachyonsoft.com/inst390o.htm > > I don't think it's been updated for quite a few years - maybe since the z10 > or so - but it's really good for historical stuff. > > Tony H. >
Re: OPCODE tables
Thanks! That's pretty handy :-). *Mark* On Wed, Mar 20, 2024 at 4:35 PM Tony Harminc wrote: > On Wed, 20 Mar 2024 at 17:12, Mark Hammack wrote: > > > Is there a list somewhere (other than OPTABLE LIST) that shows which > > instructions were added at each hardware level? > > > > I thought PoP used to have something similar but I don't see anything > back > > to Revision 7 (oldest copy I have). > > > > Although I don't know the status of the Tachyon assembler, I still find the > opcode tables there to be handy. > > http://www.tachyonsoft.com/inst390o.htm > > I don't think it's been updated for quite a few years - maybe since the z10 > or so - but it's really good for historical stuff. > > Tony H. >
Re: OPCODE tables
On Wed, 20 Mar 2024 at 17:12, Mark Hammack wrote: > Is there a list somewhere (other than OPTABLE LIST) that shows which > instructions were added at each hardware level? > > I thought PoP used to have something similar but I don't see anything back > to Revision 7 (oldest copy I have). > Although I don't know the status of the Tachyon assembler, I still find the opcode tables there to be handy. http://www.tachyonsoft.com/inst390o.htm I don't think it's been updated for quite a few years - maybe since the z10 or so - but it's really good for historical stuff. Tony H.
OPCODE tables
Is there a list somewhere (other than OPTABLE LIST) that shows which instructions were added at each hardware level? I thought PoP used to have something similar but I don't see anything back to Revision 7 (oldest copy I have). *Mark Hammack*
Announcement: Updated opcode tables on hlasm.com
Dear all, It may not have happened as fast as we all would have liked. Still I'm happy to present to you all the updated opcode tables, starting at http://www.hlasm.com/english/opcd00.htm. New features: - all new z196 instructions have been added - quite a few millicode-only instructions have been added with special thanks to Tom Harper, who helped me terrifically. Thanks Tom! - there's a new table of instructions without known opcode - there's now a separate table for the assembler directives As usual, all comments are welcome at a...@hlasm.com. Cheers, Abe Kornelis. =
Re: Opcode tables
On Wed, 27 Oct 2010 14:47:28 -0400, Tom Marchant wrote: >On Wed, 27 Oct 2010 12:33:44 -0400, David Bond wrote: >>The only ways to make the assembler to use a library macro instead of a >>built-in opcode are: >>1) Use an OPTABLE that does not include the opcode. >>2) Delete the built-in opcode entry using OPSYN. >>3) COPY the macro, which will redefine the opcode. >> >Isn't there another? >4) use a :MAC tag on the operation. Yes, I forgot about the :MAC and :ASM tags. If they are not used, the opcode tables effectively work the way I described, which is the way it actually worked before opcode tags were added to HLASM. But now there are effectively two slots for each opcode table entry. If no tag is coded after the opcode, then the macro version is used if it has already been defined, otherwise the built-in version is used if it was in the OPTABLE, and finally the library is searched. Using the :ASM tag references only the built-in version. Using the :MAC tag is the same as omitting the tag except that the built-in version is skipped. OPSYN cannot be used to reference or change only one of the versions because the tag cannot be used on the OPSYN label or operand. If the operand is omitted then both versions will be deleted. And if OPSYN is used to copy an opcode, both versions are effectively copied to the new name. David
Re: Opcode tables
On Wed, 27 Oct 2010 12:33:44 -0400, David Bond wrote: >There is no "search order" for opcodes. There is only one possible entry in >the operation code table for each opcode. Initially the table is populated >from the instructions selected by the OPTABLE option. If an opcode is >encountered in the source that is not in the table, the macro libraries are >searched and if a corresponding macro is found it is used to define the opcode. > Thank you, David. That is very helpful. > >The only ways to make the assembler to use a library macro instead of a >built-in opcode are: >1) Use an OPTABLE that does not include the opcode. >2) Delete the built-in opcode entry using OPSYN. >3) COPY the macro, which will redefine the opcode. > Isn't there another? 4) use a :MAC tag on the operation. -- Tom Marchant
Opcode Tables and Search Order
This is my understanding; I have not tested it nor verified it with the HLASM developers. We will certainly try to clarify this in the next edition of the HLASM Language Reference. HLASM first searches for a mnemonic in its current opcode table. Each of the opcode tables may have both a machine instruction and a macro of the same name. If only one definition exists (the typical case), HLASM uses that definition. A source-file macro takes precedence over a built-in definition (if that definition exists). If both definitions exist, you can select which one you want using a mnemonic "tag": OP:ASM Selects the built-in mnemonic definition, usually a machine instruction OP:MAC Selects the macro definition If no definition exists, HLASM searches SYSLIB for a match; if found, it becomes the only (and OP:MAC) entry in that opcode table. OPSYN simply copies, replaces, or deletes an entire entry for the current opcode table. Regards... John --- 555 Bailey Ave, San Jose CA 95141 +1-408-463-3543 Internet: ehr...@us.ibm.com, ehr...@vnet.ibm.com, EHRMAN at STLVM27 408-463-3543, TIE 543-3543 (fax -3873)
Re: Opcode tables
On Wed, 27 Oct 2010 10:32:53 -0400 Tom Marchant wrote: :>On Tue, 26 Oct 2010 20:16:35 -0500, William H. Blair wrote: :>>the following now-assigned Assembler :>>mnemonics: :>> CHI :>> DSG :>> PGOUT :>>are, in fact, macros still distributed in SYS1.MACLIB :>I thought that a macro definition would override an assembler :>mnemonic, but I have used CHI and it correctly generated the :>compare halfword immediate instruction and not what the macro :>generates. I would expect the opposite, that if the instruction is defined in the table it will not be a macro call. :>I have searched the assembler manuals and I have not found :>where the search order is defined. Does anyone know where :>it is documented? I don't think it has to do with a search order. The assembler knows the OPCODEs. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Opcode tables
On Tue, 26 Oct 2010 20:16:35 -0500, William H. Blair wrote: >the following now-assigned Assembler >mnemonics: > > CHI > DSG > PGOUT > >are, in fact, macros still distributed in SYS1.MACLIB I thought that a macro definition would override an assembler mnemonic, but I have used CHI and it correctly generated the compare halfword immediate instruction and not what the macro generates. I have searched the assembler manuals and I have not found where the search order is defined. Does anyone know where it is documented? -- Tom Marchant
Re: Opcode tables
On Wed, 27 Oct 2010 08:33:14 -0400, Peter Relson wrote: >I don't know what FMID distributes CHI or DSG. They are in "our" >SYS1.MACLIB too, but they are not shipped by z/OS MVS or z/OS DFSMS. EMI2220 MICR/OCR A/B Doc pro -- Tom Marchant
Re: Opcode tables
The PGOUT macro is still supported. Maybe it is not recommended, but it is supported. And unless there is cost associated with keeping it supported, it might well never be removed (as is the case, for compatibility, with lots of things). Regarding the opcode/macro conflict, between IBM development and architecture, we might have fouled up, as there is supposed to be an attempt to check for existing macros that conflict with new mnemonics (we might well not find everything, but this one would have been easy to find). But maybe it was thought that only the operating system (i.e., IBM) should be using this instruction and maybe we did not care if there was such a conflict (as perhaps we never needed to code the assembler instruction -- in some cases of "early support" our code is in place before the assembler support is in place). I don't know what FMID distributes CHI or DSG. They are in "our" SYS1.MACLIB too, but they are not shipped by z/OS MVS or z/OS DFSMS. Maybe they're relics and nothing cleans relics out of SYS1.MACLIB. You could likely find out from SMP/E. Peter Relson z/OS Core Technology Design
Re: Opcode tables
Hi William, The "CHI" & "DSG" are 2 of about 50 macros that were used to code a 3890 SCI ( Stacker Control Instructions ) program. A 3890 SCI program was 'assembled' on the z/OS or z/VSE system using the mainframe assembler and the resulting load module would be downloaded into the IBM 3890 Document Processor by the mainframe-based "item processing" support software ( i.e. IBM CPCS, IBM DOSCHECK, CA SuperMicr ). These macros represent the 'native hardware instructions' of the IBM 3890 machine. HTH Glenn Miller
Re: Opcode tables
Abe F. Kornelis noted: > I have all but completed the updates of the opcode tables on hlasm.com > There's a peculiarity I'd like to discuss here. I have discovered some additional ones. After adding all the new zWhateverR mnemonics to my SPF/SE color tables, SPF/SE complained about duplicate words. I found that there were indeed duplicates, and discovered that the following now-assigned Assembler mnemonics: CHI DSG PGOUT are, in fact, macros still distributed in SYS1.MACLIB (even z/OS 1.11). I know what PGOUT used to be, and I am surprised IBM has left it in SYS1.MACLIB for so long. But I have no clue what the CHI and DSG macros ever did. Does anyone here remember? (They have literally NO comments.) -- WB
Opcode tables
All, (message cross-posted to other assembler-related lists) I have all but completed the updates of the opcode tables on hlasm.com There's a peculiarity I'd like to discuss here. Various instructions have been introduced over the last couple of years that are a kind of umbrella operation. They take an operand (IBM calls it a function code) that specifies the exact operation (or function) to perform. The ones I have found are: KIMD KLMD KM KMAC KMC KMCTR KMF KMO PCC PCKMO PFPO PLO PTFF PXLO SYSOP For PLO and PTFF these functions have been named and supplied with an appropriate mnemonic. For all the other opcodes, the functions are listed in the Principles of Operation, but no mnemonic has been assigned to those functions. I would, of course, dearly love to have all these function mnemonics defined by IBM and published in the PoP. It would at least resolve the inconsistency between PLO and PTFF on the one hand and the other instructions listed above on the other one. Does anybody know whether or not such mnemonics have been assigned or will be assigned? Since they are not in the PoP, I suspect there might be a member (or maybe even members) in sys1.maclib or sys1.modgen holding equates with appropriate symbolic names. Does anybody know if such a member exists, and if it does, what names it specifies for the various functions? For the sake of completeness: you can find the current (outdated) version of the opcode pages starting at: http://www.hlasm.com/english/opcd00.htm Please be aware that individual instruction descriptions are currently far from complete. Many of them are missing. Kind regards, Abe Kornelis. =
