Re: Self-documenting Bit Settings
> I am not familiar with AL0 and I am too lazy to look it up. By analogy to > AL4 it *should* do pretty much nothing at all. > It does something. But not what gil said. > > Charles > >
Re: Constants in MVI/CLI instructions
MVHI and MVHHI operate on signed operands, and do sign extension. The point was that 255 (x'ff') isn't a negative number, and so won't produce the 2 or 4 bytes of all ones that he wants. Jonathan Scott has explained the workings of HLASM absolute values more than once... it is what it is. But fundamentally, you really can't use signed numbers in a logical context and not expect there's going to be some issues. There is some limited support for 8-bit signed numbers. LB I know about, and I have vague memories of vector support. Oh yeah, there's CIB/J, which also has a signed 1-byte operand. As for the assembler "understanding". It does what you want, you just don't like the warning, which you prefer not to suppress. Anyway, I think HLASM does the best it can to accommodate all desires. sas On Fri, Aug 11, 2023 at 7:17 PM Jon Perryman wrote: > > Mark Hammack > > YES EQU X'FF' > > NO EQU X'00' > > TRUEEQU -1 > > FALSE EQU 0 > > Using TRUE EQU YES makes your intent clear. Coding X'FF' would be > consistent. -1 should not be used. > > > I realize that bytes are unsigned whereas anything bigger is signed. > > Numbers in HLAsm are signed or unsigned and have a length of 2, 4 or 8 > bytes (ignoring float & packed). 1 byte is not considered a number. > > > it would be nice if the assembler "understood" that x'FF' and -1 are > "equivalent" > > In C, they are equivalent but HLAsm is warning us that it's making an > assumption about our intent. > > > MVHI (and MVHHI for a halfword bool) doesn't sign extend > > I'm not familiar with these instructions but I assume they are for the C > compiler. If there aren't signed equivalents, then I'm guessing the C > compiler did not need them. >
Re: Self-documenting Bit Settings
DS 0x (where by x I mean any constant type (A, F, H, D etc.), not a literal X) I think always means (1) align for type x and then reserve no storage. DS 0F or DC 0A(123) both align to a fullword and then reserve no storage. I am not familiar with AL0 and I am too lazy to look it up. By analogy to AL4 it *should* do pretty much nothing at all. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, August 11, 2023 4:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings ITYM 0A From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 11, 2023 7:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings On 8/11/23 16:42:06, Charles Mills wrote: > Sorry. Did not mean to be cryptic or obscure. By the question mark I meant > "why not?" > > Why not AL4? > > Yes, I never found it intuitive that A should be word-aligned and AL4 not, > but that is what it is. *But* AL0 *is* word-aligned. Go figger.
Re: Self-documenting Bit Settings
ITYM 0A From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 11, 2023 7:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings On 8/11/23 16:42:06, Charles Mills wrote: > Sorry. Did not mean to be cryptic or obscure. By the question mark I meant > "why not?" > > Why not AL4? > > Yes, I never found it intuitive that A should be word-aligned and AL4 not, > but that is what it is. *But* AL0 *is* word-aligned. Go figger. -- gil
Re: Self-documenting Bit Settings
On 8/11/23 16:42:06, Charles Mills wrote: Sorry. Did not mean to be cryptic or obscure. By the question mark I meant "why not?" Why not AL4? Yes, I never found it intuitive that A should be word-aligned and AL4 not, but that is what it is. *But* AL0 *is* word-aligned. Go figger. -- gil
Re: Constants in MVI/CLI instructions
> Mark Hammack > YES EQU X'FF' > NO EQU X'00' > TRUEEQU -1 > FALSE EQU 0 Using TRUE EQU YES makes your intent clear. Coding X'FF' would be consistent. -1 should not be used. > I realize that bytes are unsigned whereas anything bigger is signed. Numbers in HLAsm are signed or unsigned and have a length of 2, 4 or 8 bytes (ignoring float & packed). 1 byte is not considered a number. > it would be nice if the assembler "understood" that x'FF' and -1 are > "equivalent" In C, they are equivalent but HLAsm is warning us that it's making an assumption about our intent. > MVHI (and MVHHI for a halfword bool) doesn't sign extend I'm not familiar with these instructions but I assume they are for the C compiler. If there aren't signed equivalents, then I'm guessing the C compiler did not need them.
Re: Self-documenting Bit Settings
I believe the presence of an explicit length in AL4 (for example) removes the alignment constraints - irrespective of the length) iCBW as often happens after 50+ years on various bits of hardware/software On Fri, Aug 11, 2023, 6:42 PM Charles Mills wrote: > Sorry. Did not mean to be cryptic or obscure. By the question mark I meant > "why not?" > > Why not AL4? > > Yes, I never found it intuitive that A should be word-aligned and AL4 not, > but that is what it is. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU > ] > On Behalf Of Dave Clark > Sent: Friday, August 11, 2023 11:19 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Self-documenting Bit Settings > > "IBM Mainframe Assembler List" wrote on > 08/11/2023 01:43:18 PM: > > AL4 ? > > > I guess the question mark either means you weren't sure that would > result in no alignment or you weren't sure that is what I was asking for. > Well, I'd never thought of assigning a specific length to an address > constant. But, I tried it and it works as desired. Thanks. > > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > > > * >
Re: Self-documenting Bit Settings
Sorry. Did not mean to be cryptic or obscure. By the question mark I meant "why not?" Why not AL4? Yes, I never found it intuitive that A should be word-aligned and AL4 not, but that is what it is. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, August 11, 2023 11:19 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings "IBM Mainframe Assembler List" wrote on 08/11/2023 01:43:18 PM: > AL4 ? I guess the question mark either means you weren't sure that would result in no alignment or you weren't sure that is what I was asking for. Well, I'd never thought of assigning a specific length to an address constant. But, I tried it and it works as desired. Thanks. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Self-documenting Bit Settings
> Dave Clark wrote: > FLAGS DC A(LDAP_AUTH_ENABLED+TRACE) > But that yields aligned storage, correct? You'll need to test it but I believe AL4( ) ignores alignment.
Re: Modifying the CC in the PSW
> David Eisenberg wrote: > I want to generate baseless code using as few instructions as possible, > Can my macro modify the resulting condition code? I'm horrified this was your solution especially considering all the other options available. 1. Regardless of programming language or whatever you are doing, you should always ask yourself if you are making a choice for the right reason. Far too often we overthink a decision or problem only to find we are solving problems that will never exist. 2. In the next 5 years, how many programs will need that extra register and you are willing to give up addressability to constants? For most people, it will only be at couple. Don't disable a useful HLAsm feature because someone convinced you that baseless is important. Your only job at this time is to make that extra register a simple choice if if's more important than constants. Needlessly removing the base reg is a terrible idea but preparation is important. The truth is that constant addressability is more important than as an 11th register. Truly baseless is often not the answer. For me, baseless was not a solution when I added entries to a large TSO parser table that caused addressability problems. Each addressability problem is unique and, in this situation, moving the table after all constants (including LTORG) was the only acceptable solution. It's understandable you want to solve a problem but consider the cost/risk/benefit of going beyond preparation. 3. Forget about converting B to J by hand because you can't modify IBM macros. The correct and very simple solution is to internally translate B to J. OPSYN B instructions to a macro. The macro only coverts B to J when it doesn't involve a register (no parenthesis). There are a couple of extremely unlikely exceptions but it's doubtful anyone will experience these exceptions. 4. Inform everyone of how to use their new choices. If they need a second base reg, simply change the using to the start of the constants because executable code does not need addressability since you B is now J (with a couple of IBM macro exceptions). If they absolutely need the extra register, then they need to decide how to best handle constants. 5. If you insist on conversion instead of prepping for baseless code, then instead of CLHHSI, use LARL R1,=X'' before the CLC. No sense in making this complicated. 6. Depending on CC outside the macro should be avoided if possible. 7. I suggest you look at using the structured macros available in the IBM HLASM Took Kit. Your CLHHSI problem is about esthetics. You may find coding IF (CLHHSI,AA,LE,X'') more palatable.
Constants in MVI/CLI instructions
I came across something working on a new (to me) assembler program. The program was written many years ago and the programmer used C'Y' and C'N' as flags. Sometime later, another programmer added: YES EQU X'FF' NO EQU X'00' For some "new" flags that were added (there are external flags that still require Y/N characters). What I was trying to do was to add: TRUEEQU -1 FALSE EQU 0 To add some consistency with the C code I also support. However: MVI FLAG,TRUE Causes an ASMA320W message (which I understood after thinking about it). I know I can turn off magnitude checking (I've run into this before trying to play loose with "halfwords"), but would rather keep it on. I guess I could define TRUE as X'FF' (or 1 for that matter) which would take care of the 99% (the reason not to use x'01' would be to make it easier to read in a dump). However, in another nod to C, there may be a case somewhere that a fullword is being used a bool. MVHI (and MVHHI for a halfword bool) doesn't sign extend x'FF' to x'' (or x'"). Yes, it's a very minor thing which I've already resolved but it would be nice if the assembler "understood" that x'FF' and -1 are "equivalent" in a 1 byte immediate instruction (like -1 and x'" are equivalent in a halfword immediate instruction). And yes, I realize that bytes are unsigned whereas anything bigger is signed. Thanks! *Mark*
Re: Modifying the CC in the PSW
Jonathan, Thank you for that information! It's very helpful. David
Re: Self-documenting Bit Settings
AL1(foo+bar...) is very common for flag bytes, and AL4 is conceptually the same paradigm. From: IBM Mainframe Assembler List on behalf of Dave Clark Sent: Friday, August 11, 2023 2:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Self-documenting Bit Settings "IBM Mainframe Assembler List" wrote on 08/11/2023 01:43:18 PM: > AL4 ? I guess the question mark either means you weren't sure that would result in no alignment or you weren't sure that is what I was asking for. Well, I'd never thought of assigning a specific length to an address constant. But, I tried it and it works as desired. Thanks. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Self-documenting Bit Settings
"IBM Mainframe Assembler List" wrote on 08/11/2023 01:43:18 PM: > AL4 ? I guess the question mark either means you weren't sure that would result in no alignment or you weren't sure that is what I was asking for. Well, I'd never thought of assigning a specific length to an address constant. But, I tried it and it works as desired. Thanks. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Self-documenting Bit Settings
AL4 ? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, August 11, 2023 10:25 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Self-documenting Bit Settings Given this: FLAGS DC XL4'8001' LDAP_AUTH_ENABLED EQUX'0001'LDAP AUTH IS ENABLED USE_SSLEQUX'0002'SSL IS ENABLED STRICT_MODEEQUX'0004'STRICT USER MAPPING TRACE EQUX'8000'ENABLE TRACING It makes more sense to me (and is self-documenting) to code it this way. FLAGS DC A(LDAP_AUTH_ENABLED+TRACE) But that yields aligned storage, correct? Is there a way to achieve the same result but without aligned storage? Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Self-documenting Bit Settings
Given this: FLAGS DC XL4'8001' LDAP_AUTH_ENABLED EQUX'0001'LDAP AUTH IS ENABLED USE_SSLEQUX'0002'SSL IS ENABLED STRICT_MODEEQUX'0004'STRICT USER MAPPING TRACE EQUX'8000'ENABLE TRACING It makes more sense to me (and is self-documenting) to code it this way. FLAGS DC A(LDAP_AUTH_ENABLED+TRACE) But that yields aligned storage, correct? Is there a way to achieve the same result but without aligned storage? Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Modifying the CC in the PSW
Any sequence of multiple instructions is almost certain to be slower than the original CLC which I assume would be comparing with a literal, especially if the macro expansion required a branch. For baseless code, I normally still have a base register for a static area containing literals and constants, and I would expect that keeping the original CLC with a literal would be the simplest and fastest solution in any case where the operands would otherwise be the wrong way round. Jonathan Scott, HLASM IBM Hursley, UK
Re: Modifying the CC in the PSW
>Are the Set/Insert Program Mask instructions useful for this?< Yes, that's in the code snippet I posted at the start of this thread... I'm wondering if there's an even more efficient way to do it. Perhaps not!
Re: Modifying the CC in the PSW
On 8/11/23 06:08:44, David Eisenberg wrote: ... I know that I can always code the comparands in the correct order by loading them into the high-halves of R0 and R1, then use CLHHR. Or, of course, I can generate a CLC with a literal. But I figured I’d ask: if I use CLHHSI, then (if the macro determines that it’s necessary) can I modify the resulting condition code to appear as though the original comparands were swapped? (I.e.: CC=00 stays the same, CC=01 becomes 10, CC=10 becomes 01.) Are the Set/Insert Program Mask instructions useful for this? -- gil
Re: Modifying the CC in the PSW
So, your macro doesn't know the condition. I was thinking of something like an IF macro. OK, some more unsolicited free advice (as usual maybe worth what you pay for it). I doubt that loading the operands into registers and comparing them there is going to be any faster than a CLC. It will definitely take up more space, which may cause USING range problems. I'll take it for granted you know all operands fit into 4 bytes. sas On Fri, Aug 11, 2023 at 9:09 AM David Eisenberg wrote: > >I think it would much more straightforward to adjust the condition< > > Steve, > > I understand what you mean. My issue is that the macro is intended to > replace pre-existing CLC instructions within legacy applications (the macro > will examine and potentially modify the comparands prior to the compare). > My hope is to code the macro in such a way that the original two CLC > operands can be passed as positional parameters to the macro without > swapping their order, and without the need for the developer to change any > of the conditions in the subsequent jump instructions. I.e., my desire is > to make the macro as functionally transparent as possible to the invoking > applications. > > If it’s too nonsensical for me to modify the CC after a CLHHSI, then I’ll > probably take the approach of putting the operands in the high-halves of R0 > and R1 and doing a CLHHR. > > Thanks, > > David >
Re: Modifying the CC in the PSW
>I think it would much more straightforward to adjust the condition< Steve, I understand what you mean. My issue is that the macro is intended to replace pre-existing CLC instructions within legacy applications (the macro will examine and potentially modify the comparands prior to the compare). My hope is to code the macro in such a way that the original two CLC operands can be passed as positional parameters to the macro without swapping their order, and without the need for the developer to change any of the conditions in the subsequent jump instructions. I.e., my desire is to make the macro as functionally transparent as possible to the invoking applications. If it’s too nonsensical for me to modify the CC after a CLHHSI, then I’ll probably take the approach of putting the operands in the high-halves of R0 and R1 and doing a CLHHR. Thanks, David
Re: Modifying the CC in the PSW
I think it would much more straightforward to adjust the condition, i.e. when you need to reverse the specified operand order, you change JL to JNL, H to NH, NL to L, NH to H. Might be messy in the macro, but the executable part would be clean. For the record, I wouldn't go down this road at all. Every assembler programmer has to deal with coding compare instructions, so let them handle it. sas On Fri, Aug 11, 2023 at 8:09 AM David Eisenberg wrote: > I’m trying to puzzle something out… I hope this question isn’t too goofy. > > I’m coding a macro to logically compare a halfword in storage to a 2-byte > unsigned constant that is calculated by the macro assembler. I want to > generate baseless code using as few instructions as possible, and I’d like > to use the fewest number of registers possible (although I have no problem > using the high-halves of any registers). My preference is to use CLHHSI to > do the compare, because no literal is required for the constant. > > However: CLHHSI requires that the constant be the second (immediate) > operand. There will be times when the macro parameters will indicate that > that comparands must be reversed (i.e., where the immediate operand must be > the first comparand), in which case I can’t use CLHHSI. > > I know that I can always code the comparands in the correct order by > loading them into the high-halves of R0 and R1, then use CLHHR. Or, of > course, I can generate a CLC with a literal. But I figured I’d ask: if I > use CLHHSI, then (if the macro determines that it’s necessary) can I modify > the resulting condition code to appear as though the original comparands > were swapped? (I.e.: CC=00 stays the same, CC=01 becomes 10, CC=10 becomes > 01.) > > So far, this is what I’ve come up with (just as an example of the macro’s > generated code): > > CLHHSI HALF,X'A24B' I like CLHHSI… no literal needed > JEDONE if the comparands are equal, don’t modify > the CC > IPM R1 > XILF R1,X'3000'flip the bits in the CC > SPM R1set the new CC, program mask remains > unmodified > DONE DS0H > > Is that the best I can do? Or might there be some clever way to modify the > CC using fewer (or shorter) instructions? (Or is my entire concept > ridiculous?) > > Thanks so much, > > David >
Modifying the CC in the PSW
I’m trying to puzzle something out… I hope this question isn’t too goofy. I’m coding a macro to logically compare a halfword in storage to a 2-byte unsigned constant that is calculated by the macro assembler. I want to generate baseless code using as few instructions as possible, and I’d like to use the fewest number of registers possible (although I have no problem using the high-halves of any registers). My preference is to use CLHHSI to do the compare, because no literal is required for the constant. However: CLHHSI requires that the constant be the second (immediate) operand. There will be times when the macro parameters will indicate that that comparands must be reversed (i.e., where the immediate operand must be the first comparand), in which case I can’t use CLHHSI. I know that I can always code the comparands in the correct order by loading them into the high-halves of R0 and R1, then use CLHHR. Or, of course, I can generate a CLC with a literal. But I figured I’d ask: if I use CLHHSI, then (if the macro determines that it’s necessary) can I modify the resulting condition code to appear as though the original comparands were swapped? (I.e.: CC=00 stays the same, CC=01 becomes 10, CC=10 becomes 01.) So far, this is what I’ve come up with (just as an example of the macro’s generated code): CLHHSI HALF,X'A24B' I like CLHHSI… no literal needed JEDONE if the comparands are equal, don’t modify the CC IPM R1 XILF R1,X'3000'flip the bits in the CC SPM R1set the new CC, program mask remains unmodified DONE DS0H Is that the best I can do? Or might there be some clever way to modify the CC using fewer (or shorter) instructions? (Or is my entire concept ridiculous?) Thanks so much, David
