Re: HLASM "Anomaly"

plus not wanting to annoy all those old-timer's who love their coding tricks. Craig Brookes IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 24/03/2017 23:55:31: > From: Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: ASSEMBLER-

Re: HLASM "Anomaly"

uot; <rn...@csc.com> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 25/03/2017 07:34 > Subject: Re: HLASM "Anomaly" > Sent by: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > > My "favorite" is the warning you get when

Re: HLASM "Anomaly"

To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" My "favorite" is the warning you get when the target of your JAS/BRAS shifts to an offset more that 64K from the instruction. You only get a ASMA320W warning (when would this not be an error?), and at execution time the

Re: HLASM "Anomaly"

Melvyn Maltz. - Original Message - From: "Peter Relson" <rel...@us.ibm.com> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Saturday, March 25, 2017 8:30 PM Subject: Re: HLASM "Anomaly" Regarding the lengthy discussion of immediate operands and whether th

Re: HLASM "Anomaly"

On 2017-03-25, at 13:30, Peter Relson wrote: > > We often choose to live with the poor decisions that we might have made on > initial implementation because compatibility is a huge strength of our > platform. > But beware lest that platform collapse under the accumulated weight of those

Re: HLASM "Anomaly"

Regarding the lengthy discussion of immediate operands and whether there should be warnings or errors, I will point out that there is next to zero chance that the assembler will unconditionally change its rules in this regard, as that could cause currently working JCL to fail (I'm with Charles

Re: HLASM "Anomaly"

Different PTFs CharlesSent from a mobile; please excuse the brevity. Original message From: Peter Relson <rel...@us.ibm.com> Date: 3/25/17 11:16 AM (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" My "favorite" i

Re: HLASM "Anomaly"

My "favorite" is the warning you get when the target of your JAS/BRAS shifts to an offset more that 64K from the instruction. You only get a ASMA320W warning (when would this not be an error?), and at execution time the truncated immediate offset branches you to some arbitrary address! Am I

Re: HLASM "Anomaly"

Well, good news! That was a nasty little issue. On Sat, Mar 25, 2017 at 5:48 AM, Jonathan Scott wrote: > Ref: Your note of Fri, 24 Mar 2017 23:34:21 + > > This was fixed over a year ago. Since APAR PI34981 in early > 2016, a relative immediate operand which

Re: HLASM "Anomaly"

Ref: Your note of Fri, 24 Mar 2017 23:34:21 + This was fixed over a year ago. Since APAR PI34981 in early 2016, a relative immediate operand which is out of range gives error message ASMA223E. Robert Ngan wrote: > My "favorite" is the warning you get when the target of your > JAS/BRAS

Re: HLASM "Anomaly"

On 2017-03-24, at 17:34, Ngan, Robert wrote: > My "favorite" is the warning you get when the target of your JAS/BRAS shifts > to an offset more that 64K from the instruction. You only get a ASMA320W > warning (when would this not be an error?), and at execution time the > truncated immediate

Re: HLASM "Anomaly"

ess! Thank you for BEAR! -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Boonie Sent: Friday, March 24, 2017 13:39 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" One reason to implement the messages

Re: HLASM "Anomaly"

harles Mills <charl...@mcn.org> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 03/24/2017 11:18 AM > Subject: Re: HLASM "Anomaly" > Sent by: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > > Apologies for the late reply. Outlook thought this was SPAM.

Re: HLASM "Anomaly"

On 2017-03-24, at 09:17, Charles Mills wrote: > > Warnings are not much better or different than errors. It sounds great to > say "issue a warning" but the fact is that then the programmer has to either > (a.) live with and ignore RC=4 for the life of the project; of (b.) change > the code. If

Re: HLASM "Anomaly"

it is half wrong (4 rather than 8) is just bailing on the decision. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Abe Kornelis Sent: Sunday, March 19, 2017 12:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLAS

Re: HLASM "Anomaly"

On 2017-03-21, at 11:03, MELVYN MALTZ wrote: > Hi Steves, and Paul, > > Ok, I don't want this argument to get circular > Yet, here I am. Why not just specify -1 > As in: > CLI HERE,-1 > No. You took a a well-reasoned statement of Steve's: On 2017-03-20, at 20:18, Steve Smith wrote:

Re: HLASM "Anomaly"

On 2017-03-20, at 20:18, Steve Smith wrote: > On 3/20/2017 20:58, Paul Gilmartin wrote: >> Please don't reply with "Subject:...Digest..." > Sorry... I wish I remembered to do that, but I usually don't. >> >> On 2017-03-20, at 17:45, Steve Smith wrote: >> >>> Two's-complement is an amazingly

Re: HLASM "Anomaly"

Maltz. - Original Message - From: "Steve Smith" <sasd...@gmail.com> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Tuesday, March 21, 2017 2:18 AM Subject: Re: HLASM "Anomaly" On 3/20/2017 20:58, Paul Gilmartin wrote: Please don't reply with "Sub

Re: HLASM "Anomaly"

On 3/20/2017 20:58, Paul Gilmartin wrote: Please don't reply with "Subject:...Digest..." Sorry... I wish I remembered to do that, but I usually don't. On 2017-03-20, at 17:45, Steve Smith wrote: Two's-complement is an amazingly great way for binary computers to store negative numbers. It

Re: HLASM "Anomaly"

Please don't reply with "Subject:...Digest..." On 2017-03-20, at 17:45, Steve Smith wrote: > Two's-complement is an amazingly great way for binary computers to store > negative numbers. It is not so great for humans to read or write. First > of all, you have to know where the sign bit is, and

Re: HLASM "Anomaly"

r's intent, did they mean to code LGFI ? Melvyn. - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Saturday, March 18, 2017 10:21 PM Subject: Re: HLASM "Anomaly" O

Re: HLASM "Anomaly"

Paul, To my mind, X'' is also -1, which is in the halfword range. Thus it merits a warning as the assembler cannot know whether the X'' value of H5 is intended to be signed or unsigned. Neither should it make any assumptions. So I'm entirely fine with HLASM accepting the value and using

Re: HLASM "Anomaly"

-- From: "Paul Gilmartin" > Sent: Saturday, March 18, 2017 2:10 PM > Subject: Re: HLASM "Anomaly" > > For which of these intructions do you agree/disagree with > HLASM's behavior: > ... > H2 EQU X'' >LHI 1,H2 >

Re: HLASM "Anomaly"

correctly, except the last LHI which has the invalid 2AL1...doh Melvyn Maltz. - Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Saturday, March 18, 2017 2:10 PM Subject: Re:

Re: HLASM "Anomaly"

On 2017-03-17, at 17:40, MELVYN MALTZ wrote: > > A pity our Emails crossed, with regards to the 2X'FF issue please read my > latest post > As for the Scon...I agree with you, you must submit a bug report for that one > For which of these intructions do you agree/disagree with HLASM's behavior:

Re: HLASM "Anomaly"

9b-dmarc-requ...@listserv.uga.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Friday, March 17, 2017 11:15 PM Subject: Re: HLASM "Anomaly" On 2017-03-17, at 04:44, Martin Ward wrote: Given that 2X'FF' generates the same two bytes as X'', there is no reason why we should not

Re: HLASM Anomaly

that the HLASM output listing is very inconsistent about immediate operands, when I've done further research I'll include it in my RFE Melvyn Maltz. - Original Message - From: "Tom Marchant" <000000a69b48f3bb-dmarc-requ...@listserv.uga.edu> To: <ASSEMBLER-LIST@LISTS

Re: HLASM "Anomaly"

On 2017-03-17, at 04:44, Martin Ward wrote: > > Given that 2X'FF' generates the same two bytes as X'', > there is no reason why we should not be allowed to replace > the latter by the former. > I tend more to be value-oriented. The operand of MVHHI is an expression, and it is prudently

Re: HLASM "Anomaly"

Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Friday, March 17, 2017 2:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" On Fri, 17 Mar 2017 10:44:41 +, Martin Ward wrote: >Given that 2X'FF' generates the s

Re: HLASM "Anomaly"

On Fri, 17 Mar 2017 10:44:41 +, Martin Ward wrote: >Given that 2X'FF' generates the same two bytes as X'', >there is no reason why we should not be allowed to replace >the latter by the former [in an immediate expression]. Maybe so, but I don't see it as a significant limitation.

Re: HLASM "Anomaly"

Martin Ward > Sent: Friday, March 17, 2017 3:45 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: HLASM "Anomaly" > > Melvyn Maltz has proposed that repeat counts should be allowed in > immediate operands. Given that the modern instructions allow larger > i

Re: HLASM "Anomaly"

@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" Melvyn Maltz has proposed that repeat counts should be allowed in immediate operands. Given that the modern instructions allow larger immediate operands (up to 32 bits), this seems to me to be a very sensible proposal. A DC and an immediate operand bot

Re: HLASM "Anomaly"

Melvyn Maltz has proposed that repeat counts should be allowed in immediate operands. Given that the modern instructions allow larger immediate operands (up to 32 bits), this seems to me to be a very sensible proposal. A DC and an immediate operand both generate data in the current location.

Re: HLASM "Anomaly"

: HLASM "Anomaly" It would seem to me that perhaps the instruction operand parser should be re-evaluated, since it was probably originally written when all immediate operands were no longer than 1 byte and then extended for 2 byte operands, directed to the rightmost positions in

Re: HLASM "Anomaly"

It would seem to me that perhaps the instruction operand parser should be re-evaluated, since it was probably originally written when all immediate operands were no longer than 1 byte and then extended for 2 byte operands, directed to the rightmost positions in the target register. (I am

HLASM "Anomaly"

I think I have a clearer picture now than I had previously: for instructions, the operand parser evaluates expressions, while for DC/DS operands, the operand parser evaluates duplication factors. For example: LHI 0,2X'FF' is invalid because the operand is not an expression LHI 0.2*X'FF' is

Re: HLASM anomaly

On 2017-03-02, at 13:04, Ngan, Robert wrote: > However, I can use your code to strip the low order half off the value before > dividing by 65536, which resolves my issue of the value being potentially > "off by one" when a negative value is divided. > ... > The example "expression" I was

Re: HLASM anomaly

of X'0010'. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, March 6, 2017 9:11 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-06, at 10:01, Charles Mills wrote

Re: HLASM anomaly

On 2017-03-06, at 10:01, Charles Mills wrote: > A detail, right? In AMODE 64 I could load X'FFF0' into R1, ... > You could, but that's not the example I gave. And you can't code the USING. I'm disputing the operation not of the hardware but of the USING instruction. I don't know

Re: HLASM anomaly

: Re: HLASM anomaly On 2017-03-06, at 09:18, Charles Mills wrote: > Hardware address arithmetic has always allowed overflow, right? > > I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right? > Not in AMODE 64. The example I gave was (slightly adjusted) to loa

Re: HLASM anomaly

On 2017-03-06, at 09:18, Charles Mills wrote: > Hardware address arithmetic has always allowed overflow, right? > > I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right? > Not in AMODE 64. The example I gave was (slightly adjusted) to load X'7FFF' into R1. Then I

Re: HLASM anomaly

, March 6, 2017 6:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500 I noticed some time ago that HLASM fails to check properly for overflow during USING calculations, which in my opinion is a bug in HLASM. However, it's not just

Re: HLASM anomaly

Ref: Your note of Mon, 6 Mar 2017 07:43:25 -0500 I noticed some time ago that HLASM fails to check properly for overflow during USING calculations, which in my opinion is a bug in HLASM. However, it's not just a matter of checking each calculation for overflow, because intermediate calculations

Re: HLASM anomaly

On 2017-03-06, at 07:04, Thomas David Rivers wrote: >>> >>> that means, for this bright Monday morning - I'll have to enter a bug. >>> >> But here, I disagree with HLASM's behavior and believe DASM is doing >> the right thing. >> >> Which bug will you enter? > > The bug goes in with as "we

Re: HLASM anomaly

> > > > that means, for this bright Monday morning - I'll have to enter a bug. > > > But here, I disagree with HLASM's behavior and believe DASM is doing > the right thing. > > Which bug will you enter? > > -- gil > The bug goes in with as "we aren't the same as HLASM". It's surprising how

Re: HLASM anomaly

On 2017-03-06, at 05:43, Thomas David Rivers wrote: > Pieter Wiid wrote: >> >> Your USING should be USING X,R2 >> Didn't I say earlier that I'm not an Assembler programmer? >> Then, you get this with HLASM (z/OS 2.2) >> >> 2 1 R2 EQU 2

Re: HLASM anomaly

Pieter Wiid wrote: > > Your USING should be USING X,R2 > Then, you get this with HLASM (z/OS 2.2) > >2 1 R2 EQU 2 >3 2 R3 EQU 3 > 000 4 3 FOO CSECT >

Re: HLASM anomaly

On 06/03/2017 13:39, Thomas David Rivers wrote: Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 2017-03-05, at 14:40, Martin Truebner wrote: ... to have heard from either of the two commerical vendors of HLASM compatible cross-assemblers. Now I have seen one. What

Re: HLASM anomaly

Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > On 2017-03-05, at 14:40, Martin Truebner wrote: > > > >>> ... to have heard from either of the two commerical vendors of > >>> HLASM compatible cross-assemblers. > > > > Now I have seen one. What is the other (is there

Re: HLASM anomaly

On 2017-03-05, at 14:40, Martin Truebner wrote: > >>> ... to have heard from either of the two commerical vendors of >>> HLASM compatible cross-assemblers. > > Now I have seen one. What is the other (is there one?) ? > Dignus, Tachyon, (does MicroFocus have one?), and the non-commercial z390.

Re: HLASM anomaly

Tony, >> ... to have heard from either of the two commerical vendors of >> HLASM compatible cross-assemblers. Now I have seen one. What is the other (is there one?) ? Martin Trübner; everything around "PoOps of z/arch"

Re: HLASM anomaly

> > In passing, I'm a little surprised not to have heard from either of > the two commerical vendors of HLASM compatible cross-assemblers. > > Tony H. > Hi Tony, We try to not get too involved with opinions. I can say that mimic'ing the rather baroque methods HLASM uses (likely for

Re: HLASM anomaly

On 5 March 2017 at 13:03, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > And 64-bit expressions. It's difficult to fully exploit a 64-bit > architecture using a 32-bit language. Do you think 64-bit expressions are really what's needed, or should it be

Re: HLASM anomaly

On 2017-03-02, at 13:04, Ngan, Robert wrote: > I was interested in the top half of the fullword, your equates give me the > bottom half, which I do not need to do anything special for since HLASM > truncates the value correctly when used directly on the MVHHI instruction. > Ah. I forgot a

Re: HLASM anomaly

frame Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 01, 2017 20:40 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-01, at 17:35, Ngan, Robert wrote: > I noticed the new COBOL compiler was generating: > >

Re: HLASM anomaly

rame Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU > ] > On Behalf Of Paul Gilmartin > Sent: Wednesday, March 1, 2017 1:59 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: HLASM anomaly > > On 2017-03-01, at 13:24, Steve Smith wrote: > > > ASMA320W is i

Re: HLASM anomaly

Subject: Re: HLASM anomaly On 2017-03-01, at 10:00, Charles Mills wrote: > For sure! It's not a problem I lose sleep over -- perhaps because my > primary language is now C++, no longer assembler. > > I don't recall ever thinking about the issue until it came up on this list. >

Re: HLASM anomaly

age- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 1, 2017 1:59 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-01, at 13:24, Steve Smith wrote: > ASMA320W is imho, a total wimp-out

Re: HLASM anomaly

On 2017-03-01, at 13:24, Steve Smith wrote: > ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less > confusion if this was flagged as an *error*, which it is. It may sometimes > generate what the user wants, but the user didn't specify it correctly. > > And the case where the

Re: HLASM anomaly

ASMA320W is imho, a total wimp-out on IBM's behalf. There'd be less confusion if this was flagged as an *error*, which it is. It may sometimes generate what the user wants, but the user didn't specify it correctly. And the case where the assembler issues this for BR instructions is egregiously

Re: HLASM anomaly

On 2017-03-01, at 12:06, John Walker wrote: > This sounds like a C person trying to get Assembler to conform to C coding > expectations. Is that a correct perception? > Or, just expecting consistent behavior throughout HLASM. XEQU C'x' LHI R1,X ought to have the same

Re: HLASM anomaly

On 2017-03-01, at 00:03, John Dravnieks wrote: > > So if you code AHI 1,65535 then HLASM will give you this > > 00 A71A 0 2 ahi 1,65535 > ** ASMA320W Immediate field operand may have incorrect sign or magnitude > Should the Reference specify the effect

Re: HLASM anomaly

On 2017-03-01, at 10:00, Charles Mills wrote: > For sure! It's not a problem I lose sleep over -- perhaps because my primary > language is now C++, no longer assembler. > > I don't recall ever thinking about the issue until it came up on this list. > > I'm a "design elegance" guy. It would

Re: HLASM anomaly

RV.UGA.EDU Subject: Re: HLASM anomaly > Were I to rebut each of your hypothetical objections you could of > course rebut my rebuttals. I will only point out that often the coder > does not have > control over how flags are defined: they are defined in some system or > "external

Re: HLASM anomaly

> Were I to rebut each of your hypothetical objections you could of course > rebut my rebuttals. I will only point out that often the coder does not have > control over how flags are defined: they are defined in some system or > "external" DSECT or similar. I concede that readily. My thinking

Re: HLASM anomaly

al Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Boonie Sent: Wednesday, March 1, 2017 7:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly > It is perhaps a silly example. But suppose R1 was to contain a pair of >

Re: HLASM anomaly

> It is perhaps a silly example. But suppose R1 was to contain a pair > of flag byte values. Suppose the flags were equated. Now it might > make sense to code > > LHI R1,2AL1(MYFLAG1) > > Or something like that. Yes you can code the following but it is no > great exemplar of coding clarity:

Re: HLASM anomaly

GA.EDU Subject: Re: HLASM anomaly On 3/1/17, Brent Longborough <br...@longborough.org> wrote: > I really can't understand why we're making such an indigestible meal > of all this. > > Take for example, AHI R1,2X'FF'. What does that even *mean*? If it > *means* AHI R1,-1,

HLASM anomaly

I really can't understand why we're making such an indigestible meal of all this. Take for example, AHI R1,2X'FF'. What does that even *mean*? If it *means* AHI R1,-1, then write it like that, so that the unfortunate programmer who has to maintain your code doesn't have to cast runes to know what

Re: HLASM anomaly

I did point out that the expression analyser is a 32 bit operand processor - it does not know the origin or format of the original input, it is just operating on the 32 bit values and only at the end is there any consideration of the size of the target.. So at input, you might code any one of

Re: HLASM anomaly

On 2017-02-28, at 14:02, Melvyn Maltz wrote: > To restate what I'm asking for... > Now that we have 2 and 4-byte immediate values it would make sense > to allow both duplication factor and explicit length for these > Currently the instructions below would fail > AHI 1,2X'FF' > CFI

HLASM anomaly

To restate what I'm asking for... Now that we have 2 and 4-byte immediate values it would make sense to allow both duplication factor and explicit length for these Currently the instructions below would fail AHI 1,2X'FF' CFI 1,XL4'FF' Rather more contentious, I agree, is

Re: HLASM anomaly

> On Behalf Of Ngan, Robert > Sent: Monday, February 27, 2017 5:45 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: HLASM anomaly > > The ability to specify: > > IIHF R00,H'12345,0' > > to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would > be us

Re: HLASM anomaly

in an actual assembly yet, just guessing here. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ngan, Robert Sent: Monday, February 27, 2017 5:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly

Re: HLASM anomaly

: HLASM anomaly Have you not seen the many prior discussions of this excruciating topic? HLASM's hex notation is a PIA! 2s-complement is great for computers, not much so for humans. HLASM treats all hex constants as a 32-bit number, so if you need to specify a negative number in hex, you have

Re: HLASM anomaly

Have you not seen the many prior discussions of this excruciating topic? HLASM's hex notation is a PIA! 2s-complement is great for computers, not much so for humans. HLASM treats all hex constants as a 32-bit number, so if you need to specify a negative number in hex, you have to spell out all

Re: HLASM anomaly

On 2017-02-23, at 23:54, John Dravnieks wrote: > > Unless the assembler is redesigned to use just one expression processor, > there will always be differences in between instruction operands and DC > operands > I see little value in attempting to eliminate that difference and much value in

Rif: Re: HLASM anomaly

the two instructions AHI 1,-1 AHI 1,X'' - if they are compiled produce coding 90EC D00C 000C 5 STM 14,12,12 (13) 0004 A71A 6 AHI 1,-1 0008 A71A 7

Re: HLASM anomaly

Fellow listers I used to develop and maintain HLASM and there were lots of internal discussions about how to handle items like 16 bit immediate opearnds. One point is that internally the assembler has an expression processor for instruction operands, and it has another one for DC operands -

Re: HLASM anomaly

On 2017-02-23, at 23:26, Webster, Chris wrote: > HLASM correctly refers to POPs since it is not describing each instruction. > POPs uses 'treated as' for describing different operands. The term 'treated > as' is used frequently with different instructions and appears to accurately >

Re HLASM Anomaly

Another reason not to allow DC-type operands in immediate operands: consider AHI 0,(N)X'F' The Assembler can't tell that the instruction is indeed 4 bytes long. I suppose it could do some acrobatics, but the cost vs. value seems excessive. John

Re: HLASM anomaly

On 2017-02-23, at 11:16, Paul Gilmartin wrote: > > What are the limits on the operand of AHI? What of: > > AEQU -32768 > DC Y(A) > AHI R1,AOK, I believe. > > BEQU 32767 > DC Y(B) > AHI R1,BOK, I believe. > > cEQU 65535 >

Re: HLASM anomaly

On 02/23/2017 01:16 PM, Paul Gilmartin wrote: On 2017-02-23, at 10:31, Steve Thompson wrote: Informative? Or Warning? Do you then disagree with warnings on multiple base-displacement resolutions? I sometimes run into this, and can't figure out why the assembler even issued the message.

Re: HLASM anomaly

On 2017-02-23, at 10:31, Steve Thompson wrote: >>> >> Informative? Or Warning? Do you then disagree with warnings on >> multiple base-displacement resolutions? > > I sometimes run into this, and can't figure out why the assembler even issued > the message. But when it happens I do verify that

Re: HLASM anomaly

On 02/23/2017 10:09 AM, Paul Gilmartin wrote: On 2017-02-23, at 07:57, Steve Thompson wrote: Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they

Re: HLASM anomaly

On 2017-02-23, at 07:57, Steve Thompson wrote: > Ah, I see why you all are having a problem with this. > > And me, being an old ALC programmer, this is intuitively obvious. In fact, > there are several changes to HLASM that I disagreed with, because they then > caused programs I had written

Re: HLASM anomaly

Thompson Sent: Thursday, February 23, 2017 4:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the i

Re: HLASM anomaly

Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they

Re: HLASM anomaly

From: "Steve Thompson" Sent: Thursday, February 23, 2017 11:55 PM What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction Why? It is an Immediate

Re: HLASM anomaly

What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by

Re: HLASM anomaly

Sent: Wednesday, February 22, 2017 4:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly That's just the way it is... i.e. there is no reason. DC supports a whole bunch of stuff that immediate operands do not. Sometimes, you just have to ORG *-2 (or 4), and DC it. Be careful

Re: HLASM anomaly

That's just the way it is... i.e. there is no reason. DC supports a whole bunch of stuff that immediate operands do not. Sometimes, you just have to ORG *-2 (or 4), and DC it. Be careful with f-word-aligned data! e.g.: CNOP 2,4 LLILF R15,* ORG *-4 DC V(EXTRTN1) BASSM R14,R15 AFAIK, you

HLASM anomaly

Immediate operands won't accept a duplication factor...why not ? Can't find a reason in the HLASM manual Try these... CFI R1,4X'FF' CFI R1,X'' CFI R1,-1 AHI R1,2X'FF' AHI R1,X'' AHI R1,-1 Melvyn Maltz