I agree; in general, I don't see why immediate instructions shouldn't have the same power as the non-immediates. i.e. anything one can define with DC.
However, I foresee that making a business case that out-weighs the cost and effort will be a problem. sas On Fri, Mar 17, 2017 at 8:17 AM, Charles Mills <charl...@mcn.org> wrote: > Without having taken the time to parse every detail below I think I agree > with @Martin. > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of 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 > 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. > The only difference is that a DC has to specify the length of the data to > be generated, while for an immediate operand the length is specified in the > instruction. So we can use expressions such as 2*X'FF' in an immediate > operand, while in a DC we have to define the expression in a way which > specifies the length, eg: > A(2*X'FF') or Y(2*X'FF') > > I have been following the discussion on the list with interest: > it seems to me that most of the comments are actually arguments in favour > of the proposal. > > John Ehrman <john.ehr...@comcast.net> wrote: > > LHI 0,2X'FF' is invalid because the operand is not an expression > > The point of the proposal is that terms such as 2X'FF' *should* be allowed > as an expression. > > > LHI 0,2*X'FF' is valid, and the operand has value X'1FE' > > > > DC 2X'FF' generates X'FFFF' > > Given that 2X'FF' generates the same two bytes as X'FFFF', there is no > reason why we should not be allowed to replace the latter by the former. > > > DC 2*X'FF' is invalid because the operand is not a duplication factor > > 2*X'FF' is invalid here because it does not give any indication of the > length of the data to be generated. > > Steve Smith <sasd...@gmail.com> wrote: > > 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! > > That sounds like a perfect argument for extending the ways to define an > immediate operand. ORGing back over code and overwriting it with data is > either horrible coding or (if there really is no other way) a bug > workaround. > > So, lets fix the bug so that the workaround is not needed. > > Steve Thompson <ste...@copper.net> wrote: > > Replication would then expand outside of the instruction and into > > the instruction stream. > > That would be a warning flagged by the assembler, in just the same way > that using too many digits in an immediate value gives a warning. > Given that the required size is know, the value would be truncated to that > size and would not overflow. > > Paul Gilmartin <paulgboul...@aim.com> writes: > > But can a self-defining term contain a replication factor? > > I see no reason why not. 2X'FF' unambiguously defines the value X'FFFF' > which is 65535. > > Paul Gilmartin <paulgboul...@aim.com> writes: > > "The second operand is two bytes in length and is treated > as a > 16-bit signed binary integer." > > A 16-bit signed binary integer means that the valid range of values is > -32768 to 32767 inclusive, or X'8000' to X'7FFF'. > The value X'FFFF' when treated as a 16 bit signed binary integer means -1, > not 65535 (currently, the parser gives a warning for this). > > Brent Longborough <br...@longborough.org> writes: > >"The moral is this: say what you *mean*, not any old gibberish >that > gets what you think you need into the object code." > > So if you *mean* a 32 bit immediate consisting of two halfwords, each of > which has the value 1234, then allowing 2H'1234' in the instruction enables > you to say what you *mean*, and not have to "hack" > the parser with some complex expression such as 1234*65536+1234 or some > meaningless value such as 80872658. > > So this is another argument supporting the proposal. > > -- > Martin > > Dr Martin Ward STRL Principal Lecturer & Reader in Software Engineering > mar...@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4 > G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/ > Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc > -- sas
