Re: Curious compiler optimization

2021-11-14 Thread robin51
On 2021-11-14 03:10, Phil Smith III wrote: Unoptimised code typically has redundant instructions. For example, a store instruction to finish an assignment operation might be followed by a load from the same place in a following statement. That I could believe--the unoptimized code is dealing

Re: Curious compiler optimization

2021-11-12 Thread robin51
On 2021-11-13 01:04, Peter Relson wrote: When it needs zero, it merely copies it into anther register that it has allocated? Yes, but why not just store the register that they know already contains zero? Because they do not necessarily "know" that when the code is generated. It might

Re: Curious compiler optimization

2021-11-12 Thread robin51
On 2021-11-13 02:32, Phil Smith III wrote: Thanks to all for the replies. I had clearly forgotten what MVHI did (OK, I probably never knew-too many new instructions!). As I said, it's not a problem, but I'm a bit bothered by your comment, Peter: So this is not a curious "optimization". It is

Re: Curious compiler optimization

2021-11-11 Thread robin51
On 2021-11-12 13:50, Seymour J Metz wrote: When it needs zero, it merely copies it into anther register that it has allocated? Yes, but why not just store the register that they know a;ready contains zero? It's the code BEFORE optimisation.

Re: Add 1, Subtract 1

2021-03-11 Thread robin51
On 2021-03-12 00:41, Peter Relson wrote: To add to what Charles M posted, Don't forget that LA in AMODE 31 always zeroes bit 32, and LA in AMODE 24 zeroes bits 32-39 of the 64-bit GR. That's another way that they are not functionally equivalent, if that difference matters to you. A good rule

Re: Add 1, Subtract 1

2021-03-11 Thread robin51
On 2021-03-12 00:38, Paul Gilmartin wrote: On 2021-03-10, at 22:10:14, robi...@dodo.com.au wrote: ... You can use LA to subtract 1 if you have a negative value in a base register, subject to the same limit. Why would you do that, when BCTR R,0 will do it for free with even zero as the

Re: Add 1, Subtract 1

2021-03-10 Thread robin51
On 2021-03-11 15:56, Paul Gilmartin wrote: On 2021-03-10, at 18:21:11, Robin Vowels wrote: From: "Schmitt, Michael" Sent: Thursday, March 11, 2021 10:26 AM I was taught long ago to add 1 to a register using LA r#,1(,r#) and to subtract 1 using BCTR r#,0. Is the fastest way now to use AHI

Re: Reversed string macro

2020-10-23 Thread robin51
On 2020-10-23 23:06, Seymour J Metz wrote: MVCIN is not a BIF in HLASM. MVCIN is an instruction. Don't confuse what is available at run time with what is available at assembly time. Is there an RFE for a REVERSE BIF in HLASM? Is there a PL/I compile time REVERSE function?

Re: Reversed string macro

2020-10-22 Thread robin51
Have you tried MVCIN ? Em qui, 22 de out de 2020 18:08, Steve Smith escreveu: Submitted for your consideration... MACRO #REVSTR SETC DEQUOTE('') SETA DCLEN('') .* SETA .LOOPAIF ( LT 1).DONE SETC ''.''(,1) SETA AGO .LOOP .*

Re: John Ehrman Assembler Text

2020-08-13 Thread robin51
Tony, I have a copy of the Sysem z assembler text. It's 3.5mb. My I send it to you direct? On 2020-08-13 22:24, Tony Thigpen wrote: During a PC crash, I have lost a bunch of softcopy manuals including my copy of John's book and the downloadable material. It appears that Marist has re-done

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

2020-08-09 Thread robin51
On 2020-08-10 02:13, Seymour J Metz wrote: I'm fully conversant with UNPK, Obviously you are not, or you would not have said that the ASCII bit "only affects the handling of the sign nybble". including the fact that the zone it sets depends on the value of the ASCII bit. How is that relevant

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

2020-08-09 Thread robin51
On 2020-08-09 15:05, Seymour J Metz wrote: How is the ASCII bit relevant to teletypes? It only affects the handling of the sign nybble. You might want to check out the UNPK instruction. Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From:

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

2020-08-08 Thread robin51
Interesting are the two paragraphs on page 302, bottom RHS. Case says that nobody used the ASCII capability of the S/360. Padegs says that "none of our operating systems were [sic] programmed to turn in the [ASCII] bit". So, no-one was able to use the ASCII facility. On 2020-08-08 12:19, Jim

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 11:20, Gerhard adam wrote: There is no such thing as a sign before the value is packed or converted to binary. Since all numbers have a zone field of X’F’ there can be no discussion about a sign since it is not part of the number A zoned number has the sign in the more-signficant

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 11:41, Gerhard adam wrote: The sign is only going to be relevant if that is true.  If there is no sign then there is nothing to discuss.   According to the OP, there is a sign. The packed form of the number has the sign in the least-significant byte. On Thu, Jun 4, 2020 at

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 11:50, Seymour J Metz wrote: There is no "S/360 normal cycle time"; I quoted the time for the model 50. each model has its own processor and storage timings, Obviously, as you already quoted .75 uS. with a few duplications, e.g., 65 and 67. The core storage on the 360/65

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 11:20, Gerhard adam wrote: There is no such thing as a sign before the value is packed or converted to binary. Since all numbers have a zone field of X’F’ there can be no discussion about a sign since it is not part of the number In EBCDIC form, i.e. unpacked, the sign is in the

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 07:35, Seymour J Metz wrote: Yeah, 8 microsecond instead of .75 microsecond. The S/360 normal cycle time was 2 microseconds. -- Shmuel (Seymour J.) Metz From: robi...@dodo.com.au [robi...@dodo.com.au] Sent: Thursday, June 4, 2020

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 10:04, Seymour J Metz wrote: Clock cycle isn't everything. Clock cycle WAS everything then. Clock cycle of Pilot ACE was around 4 times faster than other machines of the 1950s, and hence a similar factor faster. "An addition could take anywhere from 64 microseconds to 1024

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 08:24, Seymour J Metz wrote: Thanks. My understanding is that delay lines using a solid medium were more reliable than Williams Tubes, That's right. so using them on slow machines seems reasonable.. Pilot ACE was the fastest machine in the world in 1951. DEUCE ran at the

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 03:45, Seymour J Metz wrote: I remember $.25/bit, but don't recall what year that was; too low for 1960, too high for 1969. Don't forget that there were two types of core memory for the S360 -- LCS used a product from India, with a much slower cycle time compared to IBM's normal

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-05 04:59, Seymour J Metz wrote: I see an error in that chart: the 370/135 did not use core storage. From the announcement letter: "The Model 135 uses the same innovative monolithic circuit memory introduced with System/370 Model 145" The 1957 and 1959 prices were not very helpful;

Re: Convert *signed* EBCDIC to packed decimal

2020-06-04 Thread robin51
On 2020-06-04 11:43, Dan Greiner wrote: In an interview in the "Communications of the ACM" (volume 30, number 4, April 1987), two of the original instruction-set architects — Andris Padegs and Richard Case — weighed in on EDIT and EDIT AND MARK. The interviewer, Alfred Spector, asked: "Did you

Re: *-*

2020-04-30 Thread robin51
On 2020-05-01 12:14, jba...@ngssallc.com wrote: I must really be getting old, because I actually remember the origin of the convention. The convention of "*-*" in a length field was based upon an interpretation of the expression "{address-of-last-byte}-{address-of-first-byte}" which

Re: *-*

2020-04-30 Thread robin51
On 2020-04-30 18:15, Martin Ward wrote: On 30/04/2020 03:48, robi...@dodo.com.au wrote: What's wrong with a comment? It *is* a comment (in the broader sense). No it isn't. *-* doesn't explain anything. If it did, people wouldn't be asking what on earth is it. A comment that explains

Re: *-*

2020-04-29 Thread robin51
On 2020-04-30 07:08, Kerry Liles wrote: I always thought that some programmers did that as an "eye catcher" to indicate that the value might nominally be zero but it will be dynamically modified elsewhere... (perhaps by an EX or worse - direct smashing) A naked zero is not remarkable but *-*

Re: CL8''

2020-04-20 Thread robin51
On 2020-04-21 11:44, Paul Gilmartin wrote: On 2020-04-20, at 18:31:19, robi...@dodo.com.au wrote: On 2020-04-21 02:29, Ed Jaffe wrote: On 4/19/2020 11:24 PM, Windt, W.K.F. van der (Fred) wrote: DCCL8'' For such a case, I will always code: DC CL8' ' Why not just apply the bug fix?

Re: CL8''

2020-04-20 Thread robin51
On 2020-04-21 02:29, Ed Jaffe wrote: On 4/19/2020 11:24 PM, Windt, W.K.F. van der (Fred) wrote: DCCL8'' For such a case, I will always code: DC CL8' ' Why not just apply the bug fix?

Re: ltorg question

2019-06-25 Thread robin51
On 2019-06-26 11:47, Mike La Martina wrote: Floating point is stored in double words. Floating-point can also be stored in a word (i.e., single precision). Most of the time the nominal value is 0, which looks the same in hex and Floating Point. The FD notation seems weird to me. But it

Re: BIC documentation - unclear?

2019-06-20 Thread robin51
On 2019-06-20 23:00, John McKown wrote: I am continuing my "education" in the newer instructions. I think that I understand what Branch Indirect on Condition (BIC) does. Instead of branching to the address in the instruction, it fetches the 8 bytes at that address and uses that as the branch

Re: Getting the Last Condition code

2018-12-06 Thread robin51
BALR should also lead the OP to other similar instructions to do what he wants. - Original Message - From: "IBM Mainframe Assembler List" @listserv.uga.edu> To: Cc: Sent:Thu, 6 Dec 2018 17:50:26 -0700 On 2018-12-06, at 16:07:36, Robin Vowels wrote: > BALR > What AMODE?

Re: An idea I got when researching a bug - warnings when a specific register is changed

2018-06-29 Thread robin51
The name has been PL/I after some earlier names, not PL/1 - Original Message - From: "IBM Mainframe Assembler List" @listserv.uga.edu> To: Cc: Sent:Fri, 29 Jun 2018 21:27:12 + Subject:Re: An idea I got when researching a bug - warnings when a specific register is changed The name

Re: storing and restoring condition code

2018-05-05 Thread robin51
SPM will set the condition code.

Re: storing and restoring condition code

2018-05-05 Thread robin51
BALR with second operand 0 will give you the condition code. - Original Message - From: "IBM Mainframe Assembler List" Sent:Sat, 5 May 2018 06:22:32 -0400 In 20+ years of heavy assembler coding, I never needed to store and restore the condition code,

Re: Dependent USING Does Not Work as Documented

2018-04-23 Thread robin51
Doesn't the operand "Byte" need to be a register number, not a DS statement? From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU [1]] On Behalf Of Ed Jaffe Sent: Sunday, April 22, 2018 6:59 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU [2] Subject: Dependent USING Does Not Work

Re: SDWA - SDWACMPC conversion

2018-04-16 Thread robin51
- Original Message - From: "IBM Mainframe Assembler List" Sent:Mon, 16 Apr 2018 09:06:37 -0400 On Sat, 14 Apr 2018 17:44:37 +1000, robi...@dodo.com.au wrote: >>Since the object is to convert four decimal digits (range 0-9) >>to EBCDIC, OC is

Re: SDWA - SDWACMPC conversion

2018-04-14 Thread robin51
Since the object is to convert four decimal digits (range 0-9) to EBCDIC, OC is sufficient. - Original Message - From: "IBM Mainframe Assembler List" To: Cc: Sent:Sat, 14 Apr 2018 08:52:19 +0200 >> OC

Re: Two string instruction questions

2018-03-15 Thread robin51
Use a TR as well. Works wonders. - Original Message - From: "IBM Mainframe Assembler List" To: Cc: Sent:Wed, 14 Mar 2018 21:06:36 -0600 Subject:Re: Two string instruction questions On 2018-03-14, at 20:32:18, Robin

Re: Pascal (was : comparison C vs HLASM)

2018-02-02 Thread robin51
From: "IBM Mainframe Assembler List" To: Cc: Sent:Fri, 2 Feb 2018 00:49:57 -0600 Subject:Re: Pascal (was : comparison C vs HLASM) > On Feb 1, 2018, at 9:13 PM, Robin Vowels wrote: > >> From: "Paul

Re: converting character to packed

2016-10-23 Thread robin51
Monetary fields tend to have the finny characters in known positions, commas (or periods)every third position. The decimal point (period or comma) also is in a fixed position.All these are in fixed positions relative to the least significant digit of the amount. - Original Message - From:

Re: converting character to packed

2016-10-18 Thread robin51
Using TR in a different way omits the commas and decimal point, sign, and any other funny characters. To do this, you swap the roles of the translate table and the string being translated. - Original Message - From: "IBM Mainframe Assembler List" To: Cc: Sent:Mon, 17 Oct 2016 16:24:18

Re: converting character to packed

2016-10-17 Thread robin51
Won't a TR followed by a PACK do this? - Original Message - From: "IBM Mainframe Assembler List" To: Cc: Sent:Mon, 17 Oct 2016 15:04:52 -0400 Subject:Re: converting character to packed since it was my original question and thanks for all of the suggestions, the data input was manual