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
