Sorry for being unclear (not that it's *entirely* my fault), I meant BRANCH RELATIVE.
sas On Wed, Mar 1, 2017 at 5:46 PM, Charles Mills <charl...@mcn.org> wrote: > > Should/does HLASM require that the target of BR is within the owning > CSECT? > > No and no. (Or should I say "No/no"?) > > 1. No, the target of a BR is quite often in another CSECT, and quite > happily > so: L R15,=V(some_entry_point)/BR R15 or LM R14,R12,12(R13)/BR R14 > > 2. No, it is not something the assembler has any way of knowing -- consider > the second example above. Unlike what we have been discussing, where the > assembler could "know" for example that 65535 is not a valid signed 16-bit > quantity, or "know" that OTOH X'FFFF' is a valid representation of a signed > 16-bit -1. (By "can know" I mean it would be generally discernible for an > assembler of the general architecture of HLASM; I understand that > internally > the expression processor is not quite in the right place at the right time > to figure this out, apparently.) > > Charles > > -----Original Message----- > 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 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 wrong. > > > Should/does HLASM require that the target of BR is within the owning CSECT? > -- sas
