Re: BASR to AMODE 64

2019-12-04 Thread Tom Marchant
>From: IBM Mainframe Assembler List on behalf >of Charles Mills >Sent: Wednesday, December 4, 2019 11:22 AM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: BASR to AMODE 64 > >Branch Relative handles an offset up to 4 GiB. > >Charles

Re: BASR to AMODE 64

2019-12-04 Thread Seymour J Metz
With a signed offset. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Wednesday, December 4, 2019 11:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64

Re: BASR to AMODE 64

2019-12-04 Thread Charles Mills
Branch Relative handles an offset up to 4 GiB. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, December 3, 2019 2:28 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64

Re: BASR to AMODE 64

2019-12-04 Thread Peter Relson
Gil wrote > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before

Re: BASR to AMODE 64 (Baseless code)

2019-12-03 Thread Seymour J Metz
Subject: Re: BASR to AMODE 64 (Baseless code) On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data d

Re: BASR to AMODE 64

2019-12-03 Thread Seymour J Metz
etz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Monday, December 2, 2019 10:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 What does CSECT size have to do with base regist

Re: BASR to AMODE 64

2019-12-03 Thread Seymour J Metz
2019 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 2019-12-03, at 07:10:42, Peter Relson wrote: > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are

Re: BASR to AMODE 64 (Baseless code)

2019-12-03 Thread Seymour J Metz
From: IBM Mainframe Assembler List on behalf of Ngan, Robert Sent: Tuesday, December 3, 2019 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) We use TWO LOCTR's, one for constants required to be within 4K of the base register and a second

Re: BASR to AMODE 64 (Baseless code)

2019-12-03 Thread Ngan, Robert
ce. I wish there was easy way to aggregate the LTORG literals specifically into pre and (potentially) post 4K LTORGs. Robert Ngan -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, December 2, 2019 19:51 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject

Re: BASR to AMODE 64

2019-12-03 Thread Ed Jaffe
On 12/3/2019 11:07 AM, Paul Gilmartin wrote: Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before execution. They have been supported since z/OS 1.7 or 1.8. Very handy to have!!! -- Phoenix Software International

Re: BASR to AMODE 64

2019-12-03 Thread Paul Gilmartin
On 2019-12-03, at 07:10:42, Peter Relson wrote: > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are cross-CSECT relative branches supported? That feels like an invitation to disaster:

Re: BASR to AMODE 64

2019-12-03 Thread Steve Smith
...inline... On Tue, Dec 3, 2019 at 9:10 AM Peter Relson wrote: > Steve Smith wrote > > I found that a couple of > IBM AMODE 64 callable routines expect R15 to be set to their EPA, although > most do not. I discovered these when I made the calls using JASL ( > > I trust you are aware that

Re: BASR to AMODE 64

2019-12-03 Thread Tom Marchant
On Tue, 3 Dec 2019 09:10:42 -0500, Peter Relson wrote: >I suggest that you look up what the value in reg 15 >means for this case (it should be documented somewhere), and for the other >system-assisted linkage cases. It is documented. For example:

Re: BASR to AMODE 64

2019-12-03 Thread Peter Relson
Steve Smith wrote I found that a couple of IBM AMODE 64 callable routines expect R15 to be set to their EPA, although most do not. I discovered these when I made the calls using JASL ( I trust you are aware that "callable" really does mean using "CALL" (whether in a HLL or, in assembler, by

Re: BASR to AMODE 64

2019-12-02 Thread Charles Mills
o argument with your assertion that small is good. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 2, 2019 11:08 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 Ob

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Charles Mills
-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) Even when using "baseless" code, I like to keep ONE register as the base/entry point of the module (plus what ever is needed for constant/data areas beyond the first 4K). Having a register thus set makes looking at a d

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Charles Mills
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, December 2, 2019 2:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On 2019-12-02, at 13:02:39, Tom Marchant wrote: > > On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: >

Re: BASR to AMODE 64

2019-12-02 Thread Seymour J Metz
From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, December 2, 2019 5:42 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 2019-12-02, at 09:48:39, Ed Jaffe wrote: > > On 12/2/2019 7:

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Paul Gilmartin
On 2019-12-02, at 13:02:39, Tom Marchant wrote: > > On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: > >> Even when using "baseless" code, I like to keep ONE register >> as the base/entry point of the module (plus what ever is >> needed for constant/data areas beyond the first 4K). > >

Re: BASR to AMODE 64

2019-12-02 Thread Paul Gilmartin
On 2019-12-02, at 09:48:39, Ed Jaffe wrote: > > On 12/2/2019 7:58 AM, Kerry Liles wrote: >> Or >> >> LR 12,15 >> USING entrypointname,12 > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > That strikes me as

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Ed Jaffe
On 12/2/2019 12:02 PM, Tom Marchant wrote: Locating your constants at the beginning of the program allows you to do that without sacrificing a register. Prezactly! That's what we do (using LOCTRs)... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Ed Jaffe
On 12/2/2019 12:02 PM, Tom Marchant wrote: Locating your constants at the beginning of the program allows you to do that without sacrificing a register. Prezactly! That's what we do (using LOCTRs)... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Tom Marchant
On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: >Even when using "baseless" code, I like to keep ONE register >as the base/entry point of the module (plus what ever is >needed for constant/data areas beyond the first 4K). Locating your constants at the beginning of the program allows you

Re: BASR to AMODE 64 (Baseless code)

2019-12-02 Thread Keith Moe
spirins. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, December 2, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 12/2/2019 7:58 A

Re: BASR to AMODE 64

2019-12-02 Thread Seymour J Metz
From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, December 2, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 12/2/2019 7:58 AM, Kerry Liles wrote: > Or > > LR 12,15 >

Re: BASR to AMODE 64

2019-12-02 Thread Steve Smith
I just had that discussion on a different forum with a guy who converted a program to AMODE 64 and got surprised by that. "Why was my program loaded at x'FF02', and why do I get a S0C4?" However, that really only applies to system-controlled linkage. Normal linkage can be, and often is used

Re: BASR to AMODE 64

2019-12-02 Thread Kerry Liles
Point taken! Thanks for clarification and I agree about base registers in general. On Dec 2, 2019 11:48 AM, "Ed Jaffe" wrote: > On 12/2/2019 7:58 AM, Kerry Liles wrote: > >> Or >> >> LR 12,15 >> USING entrypointname,12 >> > > > And, of course, R15 is not even loaded with the entry

Re: BASR to AMODE 64

2019-12-02 Thread Ed Jaffe
On 12/2/2019 7:58 AM, Kerry Liles wrote: Or LR 12,15 USING entrypointname,12 And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ These days, one is expected to issue LARL/USING to your program constants. There is

Re: BASR to AMODE 64

2019-12-02 Thread Kerry Liles
Or LR 12,15 USING entrypointname,12 On Mon, 2 Dec 2019 at 10:03, John McKown wrote: > On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote: > > > Yep, serious, at least as far as a moot & hypothetical discussion of > > history goes. There are (hypothetically) other ways to handle

Re: BASR to AMODE 64

2019-12-02 Thread John McKown
On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote: > Yep, serious, at least as far as a moot & hypothetical discussion of > history goes. There are (hypothetically) other ways to handle those > issues. > > Having R15 as the incoming EPA has never been more than a convenience > anyway. The first

Re: BASR to AMODE 64

2019-12-02 Thread Steve Smith
Yep, serious, at least as far as a moot & hypothetical discussion of history goes. There are (hypothetically) other ways to handle those issues. Having R15 as the incoming EPA has never been more than a convenience anyway. The first example program in my first assembler class (long before

Re: BASR to AMODE 64

2019-11-28 Thread Paul Gilmartin
> On 2019-11-27, at 11:24:20, Jonathan Scott wrote: > > Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500 > >> My point is that XA took away 7 bits that were used for various purposes. >> Taking all 8 wouldn't have been a lot more painful. >> >> sas > > Are you serious? > He's serious.

Re: BASR to AMODE 64

2019-11-28 Thread Paul Gilmartin
On 2019-11-28, at 07:08:16, Peter Relson wrote: > > > there's a little-known "mini-bar" at the high-end of the 31-bit address > space > > (I'd be grateful if citations of earlier plies included the Sender and Date so I might consult the entire text. And if the (old-fashioned) ">" quotation

Re: BASR to AMODE 64

2019-11-28 Thread Peter Relson
there's a little-known "mini-bar" at the high-end of the 31-bit address space True. The x'7000' page of the address space is intentionally not mapped in virtual and accessing that location in an address space (assuming AMODE 31 or 64) will always program check. Maybe some day we'll do

Re: BASR to AMODE 64

2019-11-27 Thread Jonathan Scott
Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500 > My point is that XA took away 7 bits that were used for various purposes. > Taking all 8 wouldn't have been a lot more painful. > > sas Are you serious? The main problem with going from 24-bit to 32-bit addressing was that the standard

Re: BASR to AMODE 64

2019-11-27 Thread Steve Smith
Actually, my real point is that XA could have been the transition that got us completely away from "dirty" addresses. And btw, a 'LLG24' instruction would be nice to have. The total cost of changing GET/PUT/READ/WRITE to using SR/ICM must world-wide represent the waste of dozens of dollars in

Re: BASR to AMODE 64

2019-11-27 Thread Steve Smith
I must fall back on "I know very little about Intel architecture". They do have different modes, which are actually more involved than just addressing. I get the impression some of the older ones have been abandoned. They have far less assembler code to worry about carrying forward. Regardless,

Re: BASR to AMODE 64

2019-11-27 Thread Paul Gilmartin
On 2019-11-27, at 10:26:35, Seymour J Metz wrote: > > TSS/360 used an explicit length at offset -4 from the parameter list, so the > end-of-list bit wasn't an issue. > > The addresses transition from 7FFF_ to 8000_ is a > z/OS issue rather than an architectural issue. >

Re: BASR to AMODE 64

2019-11-27 Thread Tom Marchant
On Wed, 27 Nov 2019 12:47:44 -0500, Steve Smith wrote: >Notwithstanding all the expert opinions, from my point of view, XA would >have better gone to 32-bit addressing from the get-go. I don't see the >benefit of the amode being part of the address. Seems to me it's been a >lot of unnecessary

Re: BASR to AMODE 64

2019-11-27 Thread Steve Smith
Good grief. I really wonder why the BX* instructions don't use logical compares, like I assumed they did. In any case, that quote is almost nonsense, as address wrap-around has been a feature since the dawn of time. 2^31-1 + 1 = 0, for addressing purposes. And yet the BX* instructions treat

Re: BASR to AMODE 64

2019-11-27 Thread Tom Marchant
On Wed, 27 Nov 2019 17:26:35 +, Seymour J Metz wrote: >TSS/360 used an explicit length at offset -4 from the parameter list, so the >end-of-list bit wasn't an issue. >The addresses transition from 7FFF_ to 8000_ is a z/OS >issue rather than an architectural issue.

Re: BASR to AMODE 64

2019-11-27 Thread Seymour J Metz
From: IBM Mainframe Assembler List on behalf of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, November 27, 2019 11:41 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On Tue, 26 Nov 2019 10:29:32

Re: BASR to AMODE 64

2019-11-27 Thread Tom Marchant
On Tue, 26 Nov 2019 10:29:32 -0700, Paul Gilmartin wrote: >I believe the greater accommodation was the hardware architecture's >expanding from 24-bit addressing to only 31 rather than 32 because >software so pervasively uses the sign bit for a flag. I don't think so. I don't have any information

Re: BASR to AMODE 64

2019-11-27 Thread Charles Mills
I believe the greater accommodation was the hardware architecture's expanding from 24-bit addressing to only 31 rather than 32 because software so pervasively uses the sign bit for a flag. My guess was that "2 GB of addressability is all that anyone could ever possibly need!" Charles

Re: BASR to AMODE 64

2019-11-27 Thread Peter Relson
z/OS does never allocate virtual addresses from 0x8000 to 0x. Not quite true. Never say never :-) . History: XA architecture in effect introduced the "line", an obvious differentiating point between 24-bit and 31-bit storage at 16M. z/OS (not z/Architecture) introduced the "bar", a

Re: BASR to AMODE 64

2019-11-26 Thread Paul Gilmartin
> On 2019-11-25, at 09:37:13, John McKown wrote: > > On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote: >> ... >> There's more to it than that, of course. But the developers of z/OS >> decided that 31-bit programs should be minimally impacted by 64-bit >> addressability. >> > I'd much perfer

Re: BASR to AMODE 64

2019-11-26 Thread Rob van der Heij
On Sat, 23 Nov 2019 at 01:11, Bernd Oppolzer wrote: > As others have pointed out, the different OSes have different strategies; > z/OS does never allocate virtual addresses from 0x8000 to 0x. > I sometimes wish the Principles of Operation would along those lines avoid to allocate

Re: BASR to AMODE 64

2019-11-25 Thread John McKown
On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote: > Yes, hardware translation uses the translation tables maintained by the > software. If the translation tables indicate a specific virtual page > does not have a corresponding real memory frame, it returns a program > check; it is up to the

Re: BASR to AMODE 64

2019-11-25 Thread Gary Weinhold
Yes, hardware translation uses the translation tables maintained by the software.  If the translation tables indicate a specific virtual page does not have a corresponding real memory frame, it returns a program check; it is up to the software how to respond to the program check: assign a frame,

Re: BASR to AMODE 64

2019-11-22 Thread Bernd Oppolzer
Am 22.11.2019 um 23:23 schrieb Paul Gilmartin: Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? the translation of the virtual addresses to real addresses is not done by software only; there is some hardware support.

Re: BASR to AMODE 64

2019-11-22 Thread Keven
The “dead zone” is an OS-specific restriction.  Processes running under Linux on z/Architecture see the whole 64-bit address space, for example. Keven On Fri, Nov 22, 2019 at 4:23 PM -0600, "Paul Gilmartin"

Re: BASR to AMODE 64

2019-11-22 Thread Paul Gilmartin
On 2019-11-22, at 08:14:13, Dougie Lawson wrote: > > ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as > the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we > were in 24-bit or 31-bit. > > So the 64-bit guys decided that the easiest fix was to

Re: BASR to AMODE 64

2019-11-22 Thread Tom Marchant
On Fri, 22 Nov 2019 15:14:13 +, Dougie Lawson wrote: >ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as >the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we >were in 24-bit or 31-bit. > >So the 64-bit guys decided that the easiest fix was to

Re: BASR to AMODE 64

2019-11-22 Thread Steve Smith
The original "dead zone" was x'8000 ' to x' '. I think I remember my first IARVx giving me address x' 0001 ', but that was long ago. This has been expanded up to the 32gb uh... border (x' 0008 ') some years ago. Rumor is Java uses this area to have 32gb of

Re: BASR to AMODE 64

2019-11-22 Thread Dougie Lawson
ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we were in 24-bit or 31-bit. So the 64-bit guys decided that the easiest fix was to completely disallow any address from 800 through to 8FFF,

Re: BASR to AMODE 64

2019-11-22 Thread Joseph Reichman
My mistake was jumping the gun and not looking at the reason code It clearly stated that S0C4 Reason code 38 Had to do with AMODE 64 when the high order bit of a 31 bit pointer ( which is not part of the address in amode 31 but is in amode 64 ) it is best practice to do a LLGTR RX before

Re: BASR to AMODE 64

2019-11-22 Thread Peter Relson
I continue not to understand why you repeatedly fail to provide the information necessary for the good folks on this list to help you. So I have LOAD a module amode 64 rmode 24 Your module does not need to match the RMODE of your DCB unless your DCB is physically resident in the module,

Re: BASR to AMODE 64

2019-11-22 Thread Joseph Reichman
I understand haven’t program that much in amode 64 Thanks Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Nov 22, 2019, at 5:50 AM, Jonathan Scott > wrote: > > Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500 > > BASR doesn't switch AMODE. If you want to switch AMODE you

Re: BASR to AMODE 64

2019-11-22 Thread Jonathan Scott
Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500 BASR doesn't switch AMODE. If you want to switch AMODE you need to use BASSM (and return using BSM, as the return address will be odd for AMODE 64). If you BASR staying in AMODE 64, the high word of the register needs to be zero. If you're not

Re: BASR to AMODE 64

2019-11-22 Thread Mike Shaw
Or maybe a question instead of a musing? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Nov 22, 2019, 1:00 AM Keven wrote: > > > > > The paucity of detail makes answering your inquiry a matter of > inductive supposition. Maybe you should post additional information

Re: BASR to AMODE 64

2019-11-21 Thread Keven
The paucity of detail makes answering your inquiry a matter of inductive supposition.  Maybe you should post additional information such as: Source code?Assembly listing?ABEND code?SysLog? Keven On Thu, Nov 21, 2019 at 9:26 PM