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
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
>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!
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
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
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
>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
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
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
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
> 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
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
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
"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
Jonathan,
Thank you for that information! It's very helpful.
David
> 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.
> 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
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
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
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
> 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
>
>
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
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
23 matches
Mail list logo
