Re: Questionable Instructions in Obtaining EAX documentation
1.. Wow. I did not know that, and I have been coding S/360 and follow-ons assembler since 1968. That would be an obscure bug-introducer. 2. I would argue that the preferred way (now -- not in 1968!) of loading a constant 256 into R2 is LHI R2,256. Avoids the problem below, is arguable\y more straightforward (no "address" anywhere in the picture) and might be faster on some machines. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bob Raicer Sent: Friday, November 8, 2019 1:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Questionable Instructions in Obtaining EAX documentation Well, the statement from Peter Relson (and others) which is essentially: -- LA R1,1 is exactly equivalent to LA R1,1(0). Just look at the generated object code. -- is not totally true. It all depends upon which USINGs are in effect. Take a peek at the following example (admittedly a bit unusual, but perfectly legitimate). Loc Object Code Addr1Addr2Stmt Source Statement 0008 1 EXAMPLE CSECT , R:9 2 USING 0,9 4120 9100 0100 3 LA 2,256 0004 4120 0100 0100 4 LA 2,256(,0) 5 END , If the intent is to place a truly non-relocatable value (e.g., a constant) into a GPR (which IS the intent of this example), then I believe the coding style of statement 4 is the preferred way to go; it is explicit and unambiguous. This applies to many other instructions which use base+displacement operands (examples: SLL, SRL, SLDL) which are not interpreted as address values.
Re: Questionable Instructions in Obtaining EAX documentation
Very interesting... I assembled this fragment on VSE and got a slight warning about the USING 0,9 with HLASM R6.0 R:9 0 3 USING 0,9 ** ASMA306W USING RANGE OVERLAPS IMPLICIT USING 0,0 But the generated code is as you showed... ( LA 2,256(0) is interpreted the same as LA 2,256 - no surprise there) Never thought about USING 0,r On Fri, 8 Nov 2019 at 16:15, Bob Raicer wrote: > Well, the statement from Peter Relson (and others) which is > essentially: > -- > LA R1,1 is exactly equivalent to LA R1,1(0). Just look at the > generated object code. > -- > is not totally true. It all depends upon which USINGs are in effect. > > Take a peek at the following example (admittedly a bit unusual, but > perfectly legitimate). > > Loc Object Code Addr1Addr2Stmt Source Statement > 0008 1 EXAMPLE CSECT , > R:9 2 USING 0,9 > 4120 9100 0100 3 LA 2,256 > 0004 4120 0100 0100 4 LA 2,256(,0) > 5 END , > > If the intent is to place a truly non-relocatable value (e.g., a > constant) into a GPR (which IS the intent of this example), then I > believe the coding style of statement 4 is the preferred way to go; it > is explicit and unambiguous. This applies to many other instructions > which use base+displacement operands (examples: SLL, SRL, SLDL) > which are not interpreted as address values. > > Bob >
Re: Questionable Instructions in Obtaining EAX documentation
Well, the statement from Peter Relson (and others) which is essentially: -- LA R1,1 is exactly equivalent to LA R1,1(0). Just look at the generated object code. -- is not totally true. It all depends upon which USINGs are in effect. Take a peek at the following example (admittedly a bit unusual, but perfectly legitimate). Loc Object Code Addr1 Addr2 Stmt Source Statement 0008 1 EXAMPLE CSECT , R:9 2 USING 0,9 4120 9100 0100 3 LA 2,256 0004 4120 0100 0100 4 LA 2,256(,0) 5 END , If the intent is to place a truly non-relocatable value (e.g., a constant) into a GPR (which IS the intent of this example), then I believe the coding style of statement 4 is the preferred way to go; it is explicit and unambiguous. This applies to many other instructions which use base+displacement operands (examples: SLL, SRL, SLDL) which are not interpreted as address values. Bob
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
I've seen nothing but technical posts (exc. the last), that have been perfectly civil. I can't imagine what awoke your curiosity. As for memory fragmentation relief, that's a secondary effect of virtual memory providing more address space(s). While that is important, I like Don's two fundamental raison d'etres for virtual memory (or DAT). sas On Fri, Nov 8, 2019 at 2:57 PM Keven wrote: > > > > > Just curious; are we being made party to some sort of feud and/or > ongoing disgruntlement between subscribers DG and SM? If so please cease > forthwith and desist any further public airing of your grievances on this > forum. > KH > > > > > > > > > > > On Fri, Nov 8, 2019 at 11:38 AM -0600, "Dan Greiner" > wrote: > > > > > > > > > > > Apologies, Seymour. I really knew better, but some muscle memory > machine-check must have occurred. > -- sas
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
I see no grievances. Just a spelling mistake and an associated apology. Ray On 11/8/2019 14:57, Keven wrote: Just curious; are we being made party to some sort of feud and/or ongoing disgruntlement between subscribers DG and SM? If so please cease forthwith and desist any further public airing of your grievances on this forum. KH On Fri, Nov 8, 2019 at 11:38 AM -0600, "Dan Greiner" wrote: Apologies, Seymour. I really knew better, but some muscle memory machine-check must have occurred.
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
Just curious; are we being made party to some sort of feud and/or ongoing disgruntlement between subscribers DG and SM? If so please cease forthwith and desist any further public airing of your grievances on this forum. KH On Fri, Nov 8, 2019 at 11:38 AM -0600, "Dan Greiner" wrote: Apologies, Seymour. I really knew better, but some muscle memory machine-check must have occurred.
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
Apologies, Seymour. I really knew better, but some muscle memory machine-check must have occurred.
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
That's Seymour! Actually, DAT has more than two uses. As an example, the use of DAT in OS/VS1 and SVS alleviated memory fragmentation, although it did not eliminate it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Dan Greiner Sent: Friday, November 8, 2019 11:02 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation) Seymore wrote: "ActualIy, I am interested, and was since it [prefixing] made its first appearance on S/360, but unless you're writing DAT-OFF code you don't need to deal with it." The association of DAT-off code and prefixing woke me up at 4am this morning, and it's been bugging me ever since. So, at the risk of being pedantic, a few words of clarification: Prefixing is the means by which multiple CPUs (i.e., threads) in a multiprocessor environment avoid stepping on each other's hardware-related environment such as interruption-old PSWs and interruption codes. During initialization, each CPU is assigned a separate 4 K-byte block of absolute storage to act as its own private real locations 0-4,095. A CPU's prefix register determines the location of this 4K block (and, through a clever trick called reverse prefixing, each CPU can access absolute zero). Prefixing is ALWAYS in effect, regardless of whether DAT is in effect. Dynamic address translation (DAT) is the means by which an OS can accomplish two separate — but equally important — functions: 1, Over-committing real storage (i.e., stuffing terabytes of data into a gigabyte bag) by means of paging to auxiliary storage. Historically, this is the more common understanding of DAT, since it was an attractive feature back in the 1970s when storage was expensive and SVS supported only a single address space. 2. Isolating the data of address spaces and data spaces from each other to improve reliability and security. This gets less ink in the PoO, but it is equally important with the first function (over-committing real storage). The OS can turn DAT on and off to suit its own processing needs. But, I agree with the original assertion that only 0.01% of programmers will ever care about prefixing.
Re: Prefixing (was Questionable Instructions in Obtaining EAX documentation)
Seymore wrote: "ActualIy, I am interested, and was since it [prefixing] made its first appearance on S/360, but unless you're writing DAT-OFF code you don't need to deal with it." The association of DAT-off code and prefixing woke me up at 4am this morning, and it's been bugging me ever since. So, at the risk of being pedantic, a few words of clarification: Prefixing is the means by which multiple CPUs (i.e., threads) in a multiprocessor environment avoid stepping on each other's hardware-related environment such as interruption-old PSWs and interruption codes. During initialization, each CPU is assigned a separate 4 K-byte block of absolute storage to act as its own private real locations 0-4,095. A CPU's prefix register determines the location of this 4K block (and, through a clever trick called reverse prefixing, each CPU can access absolute zero). Prefixing is ALWAYS in effect, regardless of whether DAT is in effect. Dynamic address translation (DAT) is the means by which an OS can accomplish two separate — but equally important — functions: 1, Over-committing real storage (i.e., stuffing terabytes of data into a gigabyte bag) by means of paging to auxiliary storage. Historically, this is the more common understanding of DAT, since it was an attractive feature back in the 1970s when storage was expensive and SVS supported only a single address space. 2. Isolating the data of address spaces and data spaces from each other to improve reliability and security. This gets less ink in the PoO, but it is equally important with the first function (over-committing real storage). The OS can turn DAT on and off to suit its own processing needs. But, I agree with the original assertion that only 0.01% of programmers will ever care about prefixing.
