Re: Fair comparison C vs HLASM
You may believe whatever you want, but that won't change the facts. There's a difference between an explanation and an unsupported assertion. EDMK works on raw data with not attributes. Would you claim that it is not a (packed) decimal instruction? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Sunday, February 11, 2018 7:18 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM I believe you are simply wrong here, PL/I has String data types and those data types have plenty of attributes. All those functions you are talking about? They work on the String type, not on raw data with no types or attributes, such as MVC. I think I already answered this with a more accurate definition of a string and a bit of explanation??? -Paul > On Feb 11, 2018, at 2:49 PM, Seymour J Metz wrote: > > "special knowledge" is not relevant. The string operations in PL/I have no > special knowledge of strings either; the compare, concatenate and copy > regardless of the language of the text. Nor is the length fixed at compile > time. > > String processing is older than ISPF. How are purported limitations in. e.g., > SuperC, relevant? > > Usually character strings are defined as strings of characters. > > MVST et al also wok with comma delimited strings and LF delimited strings. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Thursday, February 8, 2018 5:46 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > > Because they don’t have any special knowledge of strings, only untyped data. > And the lengths of the data they operate on is fixed and defined at compile > time, not at run time. > > How about taking as a definition of a string any text that SuperC will search > for? Or a text string in ISP? > > Obviously, what a string is and how it is defined varies from language to > language. But usually they are not defined as binary data. Unicode excepted. > > Just by the way, a NULL as a string terminator seems to make sense. > > MVST (Move String), CLST (Compare String), SRST (Search String) are all > instructs and all work with null terminated strings. Translate Extended is > needed to work with Unicode without loosing one’s mind… > > - Paul > > > >> On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: >> >> WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only >> consider it to be a string if it conforms to the abominable C use of 0 as a >> string delimiter? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> ________ >> From: IBM Mainframe Assembler List on >> behalf of Paul Raulerson >> Sent: Monday, February 5, 2018 10:53 PM >> To: ASSEMBLER-LIST@listserv.uga.edu >> Subject: Re: Fair comparison C vs HLASM >> >>> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >>> >>> From: "Bernd Oppolzer" >>> Sent: Tuesday, February 06, 2018 1:23 AM >>> >>> >>>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>>> And, BTW, the historic facts are simply wrong: >>>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>>> string instructions on z/Arch. >>> >>> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >>> are all string instructions. Most of these were available in 1965 with the >>> S/360. Long before C. >> >> Oh my - but no. These are >character< operators, not string operators. Much >> more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in >> part, to emulate them.) >> >> CLST, CUSE, MVST, SRTST, and the later generations of these and other >> instructions work on strings. Albeit, I think the definition of “string” in >> this case is a little dodgy. >> >> I must say, it is a lot of fun to read some of these postings. I don’t >> necessarily agree with a lot of them, but they are fun to read. >> >> z/OS as the epitome of a portable OS? HLASM more portable that C? Does >> anyone really buy into that? I assumed it was a just leg pulling… :) >> >> -Paul
Re: Fair comparison C vs HLASM
I believe you are simply wrong here, PL/I has String data types and those data types have plenty of attributes. All those functions you are talking about? They work on the String type, not on raw data with no types or attributes, such as MVC. I think I already answered this with a more accurate definition of a string and a bit of explanation??? -Paul > On Feb 11, 2018, at 2:49 PM, Seymour J Metz wrote: > > "special knowledge" is not relevant. The string operations in PL/I have no > special knowledge of strings either; the compare, concatenate and copy > regardless of the language of the text. Nor is the length fixed at compile > time. > > String processing is older than ISPF. How are purported limitations in. e.g., > SuperC, relevant? > > Usually character strings are defined as strings of characters. > > MVST et al also wok with comma delimited strings and LF delimited strings. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Thursday, February 8, 2018 5:46 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > > Because they don’t have any special knowledge of strings, only untyped data. > And the lengths of the data they operate on is fixed and defined at compile > time, not at run time. > > How about taking as a definition of a string any text that SuperC will search > for? Or a text string in ISP? > > Obviously, what a string is and how it is defined varies from language to > language. But usually they are not defined as binary data. Unicode excepted. > > Just by the way, a NULL as a string terminator seems to make sense. > > MVST (Move String), CLST (Compare String), SRST (Search String) are all > instructs and all work with null terminated strings. Translate Extended is > needed to work with Unicode without loosing one’s mind… > > - Paul > > > >> On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: >> >> WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only >> consider it to be a string if it conforms to the abominable C use of 0 as a >> string delimiter? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> ________ >> From: IBM Mainframe Assembler List on >> behalf of Paul Raulerson >> Sent: Monday, February 5, 2018 10:53 PM >> To: ASSEMBLER-LIST@listserv.uga.edu >> Subject: Re: Fair comparison C vs HLASM >> >>> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >>> >>> From: "Bernd Oppolzer" >>> Sent: Tuesday, February 06, 2018 1:23 AM >>> >>> >>>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>>> And, BTW, the historic facts are simply wrong: >>>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>>> string instructions on z/Arch. >>> >>> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >>> are all string instructions. Most of these were available in 1965 with the >>> S/360. Long before C. >> >> Oh my - but no. These are >character< operators, not string operators. Much >> more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in >> part, to emulate them.) >> >> CLST, CUSE, MVST, SRTST, and the later generations of these and other >> instructions work on strings. Albeit, I think the definition of “string” in >> this case is a little dodgy. >> >> I must say, it is a lot of fun to read some of these postings. I don’t >> necessarily agree with a lot of them, but they are fun to read. >> >> z/OS as the epitome of a portable OS? HLASM more portable that C? Does >> anyone really buy into that? I assumed it was a just leg pulling… :) >> >> -Paul
Re: Fair comparison C vs HLASM
> -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Paul Gilmartin > Sent: 11 February 2018 20:55 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Fair comparison C vs HLASM > > On 2018-02-11, at 13:46:22, Seymour J Metz wrote: > > > Only in languages descended from C is there an issue with nulls in strings. > Certainly PL/I doesn't treat NULL any differently than any other character. > > > FSVO "descended from". I suspect the convention is older than C. > Someone mentioned BCPL, which is an ancestor, not descendant of C. > Whilst "B" used null terminated strings, BCPL appears to use a length character, but I never programmed in BCPL. > -- gil Dave
Re: Fair comparison C vs HLASM
On 2018-02-11, at 13:46:22, Seymour J Metz wrote: > Only in languages descended from C is there an issue with nulls in strings. > Certainly PL/I doesn't treat NULL any differently than any other character. > FSVO "descended from". I suspect the convention is older than C. Someone mentioned BCPL, which is an ancestor, not descendant of C. -- gil
Re: Fair comparison C vs HLASM
"special knowledge" is not relevant. The string operations in PL/I have no special knowledge of strings either; the compare, concatenate and copy regardless of the language of the text. Nor is the length fixed at compile time. String processing is older than ISPF. How are purported limitations in. e.g., SuperC, relevant? Usually character strings are defined as strings of characters. MVST et al also wok with comma delimited strings and LF delimited strings. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Thursday, February 8, 2018 5:46 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM Because they don’t have any special knowledge of strings, only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… - Paul > On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: > > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>> string instructions on z/Arch. >> >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >> are all string instructions. Most of these were available in 1965 with the >> S/360. Long before C. > > Oh my - but no. These are >character< operators, not string operators. Much > more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in > part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? Does > anyone really buy into that? I assumed it was a just leg pulling… :) > > -Paul
Re: Fair comparison C vs HLASM
Only in languages descended from C is there an issue with nulls in strings. Certainly PL/I doesn't treat NULL any differently than any other character. I'm perfectly aware that NULL is at code point 0. There's nothing magic about that. ANSI (nee ASA) include NULL in ASCII for a good and sufficient reason, and it wasn't as a string terminator. It already is a control character; K&R hijacked it for a different use in C. There are a lot of control characters that I wouldn't use in a document, e.g., BELL. That doesn't mean that they aren't characters. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Saturday, February 10, 2018 12:14 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On Feb 9, 2018, at 11:11 PM, Paul Raulerson wrote: MM- I think you misread a comment I left, which was a bit unclear, and have rather gone off on a bit of a tangent. When I said ‘unless the null terminates the string” in a previous comment, what I was saying was “unless in this particular instance you choose to use a null to terminate the string.” Very clearly, in most (all) implementations of a string class, object, type, or anything similar I am aware of, a NULL character is not a valid character. Also, I really thought that other fellow was joking, but apparently he was serious. Given that, see comments below. > On Feb 9, 2018, at 4:47 PM, Seymour J Metz wrote: > > "Because they don’t have any special knowledge of strings, only untyped data." > > "special knowledge" is not relevant. The string operations in PL/I have no > special knowledge of strings either; the compare, concatenate and copy > regardless of the language of the text. Nor is the length fixed at compile > time. A formal definition of a string in a computer would be something along the lines of a “a finite sequence of symbols that are chosen from an alphabet.” Finite, because it is definitely a subset of all possible choices, and chosen because somebody had to sit down and make hard choices about what would and what would not be included in it. And yes, it is a bit mathematical, but it is also a much more precise definition. You simply contend that your idea of a string includes a NULL character in it’s alphabet, and not as a reserved character. And - that’s perfectly OK. But, pease do consider that a NULL has a code point of zero in most alphabets - including EBCDIC and UNICODE. When would you ever use it in normal writing or communications? The fact that you would not use it in a document makes it a very good choice to reserve as a control character - if you want to. > > "And the lengths of the data they operate on is fixed and defined at compile > time, not at run time." > > No. EX is not rocker science. You have to compute the lengths and fill in the size of the MVC. You are right that is computing the length of a string (or in this case, an array) at run time. Nope, using EX isn’t rocket science. But it also a poor engineering solution to use in application level code. IMO, YMMV, etc. > > "How about taking as a definition of a string any text that SuperC will > search for? Or a text string in ISP?" > > String processing is older than ISPF. How are purported limitations in. e.g., > SuperC, relevant? Through a few nulls in your source file and see if it is relevant or not… :) > > "Obviously, what a string is and how it is defined varies from language to > language. But usually they are not defined as binary data. Unicode excepted." > > Usually character strings are defined as strings of characters. NULL is a > character. With a code point of zero, meaning it is utterly meaningless in a text document, unless one uses it a it’s designation suggests - as control character zero. See the more precise definition of a string above, but I have already said numerous times the if you want to include nulls in your string handling routines, more power to you. Do NOT expect to find NULLS included in the alphabets most string routines in the world use to define exactly what a string is. To them that is. I would contend strongly that you do not have string manipulation with MVC and it’s brethren, but merely have a way to copy in memory arrays around. MVC does not pay attention at all to the data type, and will happily move any kind of data anywhere, without paying attention to alignment or other usage considerations. That is not string handling in my opinion, but again, YMMV and you are welcome to your own just as valid opinion. > > "Just by the way, a NULL as a string terminator seems to make sense." > > Only to someone who has never had to work with start/stop devices a
Re: Fair comparison C vs HLASM
"It can do whatever you want." No, it can only do those things that the PL/I language provides for. There is no time machine function. If you want to be able to view past values of the variables then somebody must record those values. By the time the ON unit is invoked it's too late. What you write about later is no code in the ON unit, but code in the rest of the program. Adding code to record the value before and after each assignment statement still does not give you the functionality of a debugger. You still need code to scroll forward and back in time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Saturday, February 10, 2018 7:25 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Friday, February 09, 2018 6:41 AM > A traceback is not a trace. An ON unit can display *current* values of a > variable, It can do whatever you want. For example, you could stack the values of any given variable in the current procedure, and use the ON-unit to print some or all generations. Stacking can also be done for any variables in procedures called earlier, and their values displayed through an ON-unit in those procedures (use RESIGNAL). > not past values. I have no idea what you mean by "A trace is trivial with > PROCEDURENAME." PROCNAME returns the name of the current procedure. You can either write that out to a file, or stack it, to be retrieved later, along with values of any relevant variables. > or how it provides a complete history of the program's execution, much less > an interface for > viewing it selectively. Use it in each procedure, on entry. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM > As an example, some debuggers log a trace of the program > and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. > in order to track down when, where and how variables acquired unexpected > values. --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1FE12FpsT12eYdkSTXv1V4oFjem1vAAIJO7u6-znXJTtyBxfwfQiGg_KjI-c6o3fV_wrVSv-iV0HvP9m8-1G74opcUk-1mdasWR8-uVaYeXz5TIJHMVyVs8H261w7Q5CmmLNw8AWyQ-7eWmryoENXe409DF5vYHdts5Ii6WU1O0l-Y2Qh_XYtonT9y0giQxQhCJg7hFJssvaw3oC_eb_VjUMumyPuzIMST96gGc7gRTSXjNBWaZfju6pZN6-jn8GvaRxqPuEsYdhNpPT1HoSzHH1XxJFGpwPZRPqzVcady6f4Kwb9PbcmHFVsn8t4eQa1bDJ95Wphi9qLGjA3YvB9GFuIsZn5kxurCZQJZC6zX79b8HFano1CjwF9TwL0ea-857vNY44iuvhxZqZmFDCM4zbGdr1Hfq4xS5ha5PBlMXZhTld8hM4v5SY31HTxueBK/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Friday, February 09, 2018 6:41 AM A traceback is not a trace. An ON unit can display *current* values of a variable, It can do whatever you want. For example, you could stack the values of any given variable in the current procedure, and use the ON-unit to print some or all generations. Stacking can also be done for any variables in procedures called earlier, and their values displayed through an ON-unit in those procedures (use RESIGNAL). not past values. I have no idea what you mean by "A trace is trivial with PROCEDURENAME." PROCNAME returns the name of the current procedure. You can either write that out to a file, or stack it, to be retrieved later, along with values of any relevant variables. or how it provides a complete history of the program's execution, much less an interface for viewing it selectively. Use it in each procedure, on entry. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM As an example, some debuggers log a trace of the program and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. in order to track down when, where and how variables acquired unexpected values. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On Feb 9, 2018, at 11:11 PM, Paul Raulerson wrote: MM- I think you misread a comment I left, which was a bit unclear, and have rather gone off on a bit of a tangent. When I said ‘unless the null terminates the string” in a previous comment, what I was saying was “unless in this particular instance you choose to use a null to terminate the string.” Very clearly, in most (all) implementations of a string class, object, type, or anything similar I am aware of, a NULL character is not a valid character. Also, I really thought that other fellow was joking, but apparently he was serious. Given that, see comments below. > On Feb 9, 2018, at 4:47 PM, Seymour J Metz wrote: > > "Because they don’t have any special knowledge of strings, only untyped data." > > "special knowledge" is not relevant. The string operations in PL/I have no > special knowledge of strings either; the compare, concatenate and copy > regardless of the language of the text. Nor is the length fixed at compile > time. A formal definition of a string in a computer would be something along the lines of a “a finite sequence of symbols that are chosen from an alphabet.” Finite, because it is definitely a subset of all possible choices, and chosen because somebody had to sit down and make hard choices about what would and what would not be included in it. And yes, it is a bit mathematical, but it is also a much more precise definition. You simply contend that your idea of a string includes a NULL character in it’s alphabet, and not as a reserved character. And - that’s perfectly OK. But, pease do consider that a NULL has a code point of zero in most alphabets - including EBCDIC and UNICODE. When would you ever use it in normal writing or communications? The fact that you would not use it in a document makes it a very good choice to reserve as a control character - if you want to. > > "And the lengths of the data they operate on is fixed and defined at compile > time, not at run time." > > No. EX is not rocker science. You have to compute the lengths and fill in the size of the MVC. You are right that is computing the length of a string (or in this case, an array) at run time. Nope, using EX isn’t rocket science. But it also a poor engineering solution to use in application level code. IMO, YMMV, etc. > > "How about taking as a definition of a string any text that SuperC will > search for? Or a text string in ISP?" > > String processing is older than ISPF. How are purported limitations in. e.g., > SuperC, relevant? Through a few nulls in your source file and see if it is relevant or not… :) > > "Obviously, what a string is and how it is defined varies from language to > language. But usually they are not defined as binary data. Unicode excepted." > > Usually character strings are defined as strings of characters. NULL is a > character. With a code point of zero, meaning it is utterly meaningless in a text document, unless one uses it a it’s designation suggests - as control character zero. See the more precise definition of a string above, but I have already said numerous times the if you want to include nulls in your string handling routines, more power to you. Do NOT expect to find NULLS included in the alphabets most string routines in the world use to define exactly what a string is. To them that is. I would contend strongly that you do not have string manipulation with MVC and it’s brethren, but merely have a way to copy in memory arrays around. MVC does not pay attention at all to the data type, and will happily move any kind of data anywhere, without paying attention to alignment or other usage considerations. That is not string handling in my opinion, but again, YMMV and you are welcome to your own just as valid opinion. > > "Just by the way, a NULL as a string terminator seems to make sense." > > Only to someone who has never had to work with start/stop devices and never > had to work with 3270s. I have spent a great deal of time with old devices, and not only with devices from IBM. Your assumptions are wrong. I also suggest if you are still using ancient teletypewriters or IBM Selectrics as terminals, or using a 3270 terminal emulator that actually needs nulls to operate, you should consider upgrading. Cheap, and that kind of still has not been a commonplace problem in decades. :) :) :) :) :) :) :) :) :) :) (And yes, that was pretty much a joke. If you don’t want to take it that way, well - your choice. But it isn’t my fault if your send of humor is on the fritz. Maybe you need to insert a few more nulls? :) ) > > "MVST (Move String), CLST (Compare String), SRST (Search String) are all > instructs and all work with null terminated strings. " > > And comma delimited strings, and LF delimited strings. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 >
Re: Fair comparison C vs HLASM
None of the inst5ructions mentioned have their lengths determined at compile time. If I do an EX of a CLC, it remains a CLC. How does a string stop being a string if I remove the VARYING keyword? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Bernd Oppolzer Sent: Thursday, February 8, 2018 4:02 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM All the instructions mentioned below have their lengths determined at compile time. String instructions (and strings in the sense of this thread) are strings with lengths varying at run time. This can be done on the mainframe using EX or MVCL, CLCL etc ... but not with the instructions mentioned below. In my post, I really meant instructions to support null-terminated strings at a hardware level, which were introduced into z-Arch a long time AFTER the first commercially available C compiler (C/370) was introduced by IBM and widely used by customers. I worked with C/370 on the mainframe starting in the early 1990s, and the string instructions in z/Arch came about 10 years later, IIRC. I may be wrong with the years, but the 10 years delay should be correct ... Kind regards Bernd Am 08.02.2018 um 21:14 schrieb Seymour J Metz: > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>> string instructions on z/Arch. >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >> are all string instructions. Most of these were available in 1965 with the >> S/360. Long before C. > Oh my - but no. These are >character< operators, not string operators. Much > more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in > part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? Does > anyone really buy into that? I assumed it was a just leg pulling… :) > > -Paul >
Re: Fair comparison C vs HLASM
"Because they don’t have any special knowledge of strings, only untyped data." "special knowledge" is not relevant. The string operations in PL/I have no special knowledge of strings either; the compare, concatenate and copy regardless of the language of the text. Nor is the length fixed at compile time. "And the lengths of the data they operate on is fixed and defined at compile time, not at run time." No. EX is not rocker science. "How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP?" String processing is older than ISPF. How are purported limitations in. e.g., SuperC, relevant? "Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted." Usually character strings are defined as strings of characters. NULL is a character. "Just by the way, a NULL as a string terminator seems to make sense." Only to someone who has never had to work with start/stop devices and never had to work with 3270s. "MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. " And comma delimited strings, and LF delimited strings. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Thursday, February 8, 2018 5:46 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM Because they don’t have any special knowledge of strings, only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… - Paul > On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: > > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>> string instructions on z/Arch. >> >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >> are all string instructions. Most of these were available in 1965 with the >> S/360. Long before C. > > Oh my - but no. These are >character< operators, not string operators. Much > more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in > part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? Does > anyone really buy into that? I assumed it was a just leg pulling… :) > > -Paul
Re: Fair comparison C vs HLASM
The terminator is specified in R0. It could be anything - want to parse CSV data? ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Raulerson Sent: February-08-18 2:46 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Because they don’t have any special knowledge of strings, only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… - Paul > On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: > > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es > metz3&d=DwIFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=RI5WP1B > N1KW_B4HrO2twbFFOhk97OdY6xsy0TwKReZE&m=3iRL-2thHu8_n1iTzmP0Cez2237D1Qy > HUBAC3uDHYGQ&s=W9ZQBeJXKBySzvdYR8sPm3s-4CpxJwskuRzTTgn9dtA&e= > > > From: IBM Mainframe Assembler List > on behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there >>> were string instructions on z/Arch. >> >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string >> instructions. Most of these were available in 1965 with the S/360. >> Long before C. > > Oh my - but no. These are >character< operators, not string operators. > Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was > built, in part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? > Does anyone really buy into that? I assumed it was a just leg pulling… > :) > > -Paul
Re: Fair comparison C vs HLASM
Because they don’t have any special knowledge of strings, only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… - Paul > On Feb 8, 2018, at 2:14 PM, Seymour J Metz wrote: > > WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only > consider it to be a string if it conforms to the abominable C use of 0 as a > string delimiter? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List on > behalf of Paul Raulerson > Sent: Monday, February 5, 2018 10:53 PM > To: ASSEMBLER-LIST@listserv.uga.edu > Subject: Re: Fair comparison C vs HLASM > >> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: >> >> From: "Bernd Oppolzer" >> Sent: Tuesday, February 06, 2018 1:23 AM >> >> >>> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >>> And, BTW, the historic facts are simply wrong: >>> IBM had a C compiler for MVS (and VM, I believe) long before there were >>> string instructions on z/Arch. >> >> MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT >> are all string instructions. Most of these were available in 1965 with the >> S/360. Long before C. > > Oh my - but no. These are >character< operators, not string operators. Much > more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in > part, to emulate them.) > > CLST, CUSE, MVST, SRTST, and the later generations of these and other > instructions work on strings. Albeit, I think the definition of “string” in > this case is a little dodgy. > > I must say, it is a lot of fun to read some of these postings. I don’t > necessarily agree with a lot of them, but they are fun to read. > > z/OS as the epitome of a portable OS? HLASM more portable that C? Does > anyone really buy into that? I assumed it was a just leg pulling… :) > > -Paul
Re: Fair comparison C vs HLASM
All the instructions mentioned below have their lengths determined at compile time. String instructions (and strings in the sense of this thread) are strings with lengths varying at run time. This can be done on the mainframe using EX or MVCL, CLCL etc ... but not with the instructions mentioned below. In my post, I really meant instructions to support null-terminated strings at a hardware level, which were introduced into z-Arch a long time AFTER the first commercially available C compiler (C/370) was introduced by IBM and widely used by customers. I worked with C/370 on the mainframe starting in the early 1990s, and the string instructions in z/Arch came about 10 years later, IIRC. I may be wrong with the years, but the 10 years delay should be correct ... Kind regards Bernd Am 08.02.2018 um 21:14 schrieb Seymour J Metz: WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only consider it to be a string if it conforms to the abominable C use of 0 as a string delimiter? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Monday, February 5, 2018 10:53 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: From: "Bernd Oppolzer" Sent: Tuesday, February 06, 2018 1:23 AM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string instructions. Most of these were available in 1965 with the S/360. Long before C. Oh my - but no. These are >character< operators, not string operators. Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in part, to emulate them.) CLST, CUSE, MVST, SRTST, and the later generations of these and other instructions work on strings. Albeit, I think the definition of “string” in this case is a little dodgy. I must say, it is a lot of fun to read some of these postings. I don’t necessarily agree with a lot of them, but they are fun to read. z/OS as the epitome of a portable OS? HLASM more portable that C? Does anyone really buy into that? I assumed it was a just leg pulling… :) -Paul
Re: Fair comparison C vs HLASM
WTF? How are CLC, MVC, TR and TRT not string instructions? Or do you only consider it to be a string if it conforms to the abominable C use of 0 as a string delimiter? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Raulerson Sent: Monday, February 5, 2018 10:53 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM > On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: > > From: "Bernd Oppolzer" > Sent: Tuesday, February 06, 2018 1:23 AM > > >> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >> And, BTW, the historic facts are simply wrong: >> IBM had a C compiler for MVS (and VM, I believe) long before there were >> string instructions on z/Arch. > > MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT > are all string instructions. Most of these were available in 1965 with the > S/360. Long before C. Oh my - but no. These are >character< operators, not string operators. Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in part, to emulate them.) CLST, CUSE, MVST, SRTST, and the later generations of these and other instructions work on strings. Albeit, I think the definition of “string” in this case is a little dodgy. I must say, it is a lot of fun to read some of these postings. I don’t necessarily agree with a lot of them, but they are fun to read. z/OS as the epitome of a portable OS? HLASM more portable that C? Does anyone really buy into that? I assumed it was a just leg pulling… :) -Paul
Re: Fair comparison C vs HLASM
A traceback is not a trace. An ON unit can display *current* values of a variable, not past values. I have no idea what you mean by "A trace is trivial with PROCEDURENAME." or how it provides a complete history of the program's execution, much less an interface for viewing it selectively. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM > As an example, some debuggers log a trace of the program > and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. > in order to track down when, where and how variables acquired unexpected > values. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Friday, February 2, 2018 8:07 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM > That deepends on what you mean by debugging facilities. PL/I has features > bthat help in debugging, > but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1X43gsO1-tAojvlzLeZEDhLK99LItHT-drxM42-QZLfXVzFXBd_Ow2LCznCwEn-e6bXwjufz9lJ1zBi4gi0HNeZJLZglBVR_KGn4v7VlqzzD8cTBAbK2w3dLC4xrZ0lkxRIpvbjrAsFVMDUocLCCC4pdqvYgKjgjaSXIbUqX3kN_qQNQL6LOdJNb5lKK3KtQL7RBEoGdvJ-KdZdhJsep7a6cU5tI2C3mQMWOGJTWkXcwnA5wUXKivavy_FNFixqq07t37djhRMj059JlnStNYKhhi3Ttbs3TQLLMgFs85HWR9CJRqSVVbTXm9SHCH19Xc_ARC8XlbiSGXgFckgn5ZpfKLlZHup5T3OmRewPRJRPD1aToBQB0smj3vYjwCZZjwxtVZS1cXe9sCJBxaenI83-sKQmpS1n1VncRLH9S-Z4Y6BQBBN0EczKdBTEXKXYGb/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Fair comparison C vs HLASM
WTF? Since when does Algol 60 store local variables on a heap. Note that the original wiki article does not mention the heap. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@listserv.uga.edu] on behalf of Martin Ward [mar...@gkc.org.uk] Sent: Thursday, February 8, 2018 9:50 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On 08/02/18 14:29, Jon Perryman wrote: > knowing full well I wouldn't waste my time learning a language that is > irrelevant to me. I'm not sure why you think I am asking you to learn a new language. If you are not sure what the Algol 60 code for the "man or boy test" actually does, and (not unreasonably) don't want to have to learn Algol 60 to find out, then there are implementations of the test in 72 other languages (including C and C++) on the Rosetta Code page: http://secure-web.cisco.com/1bC0_QAEYGYJRvCgWOUCWiO6Dk7sl_MyLtKRggLYC18Z7bNH6Xe_hqJ8ngjjVwuV2-_thRmF7SaHB0FRFyUc8nINzDvkmPNT2X1jb5quCkn6ZauJqJW-OTofedRUN5mVeyDhnhRTd8-BaCKAfemWhXfrWWe7E-H0gCWX4WwRHplt-q5O0nfguyrvaJ083-Dih-QHkL6ZIeawsP3t5pSxIaZcx2b5tbddxf05CHBXm-NUTzOQit9hwsXdaiBaqDGJkXFGeLbZzQptnL9LFGF9ZTEiWBysE6h5eMe5uWElyEpi2RHC9vwOGDxXupzS66DY9Pfwh7G9Ult1NtGv5Pe9w0ootN8FWSevXsqFteAe9d4SpaQ2JzXpd1LVcK6bt4MPmB5fjo5wdEyyD8IhUevjipiNYuo7i_sJcQF1Ud-3cu99LJ3bCnYkedFLJaLxRU0Yz/http%3A%2F%2Frosettacode.org%2Fwiki%2FMan_or_boy_test -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
On 08/02/18 14:29, Jon Perryman wrote: knowing full well I wouldn't waste my time learning a language that is irrelevant to me. I'm not sure why you think I am asking you to learn a new language. If you are not sure what the Algol 60 code for the "man or boy test" actually does, and (not unreasonably) don't want to have to learn Algol 60 to find out, then there are implementations of the test in 72 other languages (including C and C++) on the Rosetta Code page: http://rosettacode.org/wiki/Man_or_boy_test -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
Dr. Martin Ward, could you at least show us the parts of HLASM OOP you can figure out? You've seen OOP languages, so you should know the basics. I would love to show how easy it is to use HLASM OOP. > Dr. Martin Ward wrote: > The man or boy test Kudo's for being disrespectful without being disrespectful. The last line shows you were intending this for me, knowing full well I wouldn't waste my time learning a language that is irrelevant to me. > Dr. Martin Ward wrote: > My message was a response to the rather broad claim that> the functionality > of any non-trivial macro cannot be made > "available / usable / maintainable in ANY other language" Of all the C programmers who've made many absurd statements in this group, you are by far the worst. The PLI & PLX actually showed me that they can do it in their language and I agreed once I understood. You were too inept to piggyback off them. Instead, you use a very feeble example and totally ignore the spirit of my point. Jon.
Re: Fair comparison C vs HLASM
On 07/02/18 23:51, Tony Thigpen wrote: Does GEN_MOVE, ZC_CONV, ZC_PACK31 (and other major macros) in zCOBOL demonstrate enough of the OOP standard that our OOP evangelist here will accept that OOP can be added to HLASM using macros such as those examples? zCOBOL does not include any of the new object oriented COBOL features. My message was a response to the rather broad claim tha the functionality of any non-trivial macro cannot be made "available / usable / maintainable in ANY other language" -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
So, here is the question: Does GEN_MOVE, ZC_CONV, ZC_PACK31 (and other major macros) in zCOBOL demonstrate enough of the OOP standard that our OOP evangelist here will accept that OOP can be added to HLASM using macros such as those examples? Tony Thigpen Martin Ward wrote on 02/07/2018 01:55 PM: On 05/02/18 05:54, Jon Perryman wrote: Pick any non-trivial macro (e.g. not save or return) and tell us how you could make the functionality available / usable / maintainable in ANY other language. zCOBOL is an open source portable mainframe COBOL compiler. The zcobol compiler translates COBOL source language programs into executable code by translating each COBOL verb into a macro call. The macros in COBOL verb macro library parse the parameters for each verb, access global macro symbol table, and call code generation macros to generated executable code. One of these macros is GEN_MOVE, which translates the COBOL MOVE verb. The macro definition is 2,101 lines long and contains numerous calls to other macros: ZC_CONV is 96 lines, ZC_PACK31 is 91 lines, and there may be others I have missed. So it is decidely non-trivial. The functionality of GEN_MOVE is available in COBOL via the code: MOVE A TO B :-)
Re: Fair comparison C vs HLASM
On 05/02/18 05:54, Jon Perryman wrote: Pick any non-trivial macro (e.g. not save or return) and tell us how you could make the functionality available / usable / maintainable in ANY other language. zCOBOL is an open source portable mainframe COBOL compiler. The zcobol compiler translates COBOL source language programs into executable code by translating each COBOL verb into a macro call. The macros in COBOL verb macro library parse the parameters for each verb, access global macro symbol table, and call code generation macros to generated executable code. One of these macros is GEN_MOVE, which translates the COBOL MOVE verb. The macro definition is 2,101 lines long and contains numerous calls to other macros: ZC_CONV is 96 lines, ZC_PACK31 is 91 lines, and there may be others I have missed. So it is decidely non-trivial. The functionality of GEN_MOVE is available in COBOL via the code: MOVE A TO B :-) -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
Pick any non-trivial macro (e.g. not save or return) and tell us how you could make the functionality available / usable / maintainable in ANY other language. FWIW, there might be others, but one such language is PL/X. Not that that helps you any because PL/X is not available in general. The functional language and its macro language were created for exactly this purpose. As was mentioned with respect to PL/I, the macro processing is a pre-processor. It has all the flexibility of the HLASM processor and much more power. What it cannot do are the things that HLASM's macro processor can do because it is not a pre-processor, namely take advantage of things (such as the data type of a variable, the length of variable) known only by having done some of the assembly. That has not proven to be a significant stumbling block for us Peter Relson z/OS Core Technology Design
Re: Fair comparison C vs HLASM
On Tue, 6 Feb 2018 01:16:46 + Jon Perryman wrote: > > Shmuel wrote: > > While PL/I macros can't extract the attributes of variable > names, > > they are in most regards as powerful as HLASM > > > macros and syntactically cleaner. > > Would anyone be interested in my CALC macro. Yes. I would be very interested. Thanks, Manfred > To me, the most > important feature is getting a CB address without all the USING and > load statements. It may take a few days to find and make usable > outside my macro environment. > In the following example, it loads R3 > with the TSO PSCB address: > > #CALC .(R3)=PSATOLD=>TCBJSCB=>JSCBPSCB > USING PSCB,R3 > > HLASM macro language is a hodgepodge and could definitely use a major > face lift. It has many important features but not completely. > Fortunately the macro language is robust enough that there is almost > always other ways to do something even though you may not love it. My > #CALC is a good example of some of the compromises you need to make. > > I don't know PLI macro's so I did a little research. The deal breaker > is that it appears to be a pre-processor language rather than macro > language. Is there a way to call the same macro in different > locations with parms for tailoring? > > Regards, Jon.
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM As an example, some debuggers log a trace of the program and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. in order to track down when, where and how variables acquired unexpected values. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Friday, February 2, 2018 8:07 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 06/02/18 03:53, Paul Raulerson wrote: z/OS as the epitome of a portable OS? HLASM more portable that C? Does anyone really buy into that? I assumed it was a just leg pulling… :) :-) Here is another gem from Jon: 2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A)) Just a few of the differences: (1) MVC can only handle sizes of 1 to 256 bytes, memcpy can handle any size from zero upwards; (2) MVC processes overlapping data areas in a specified way: allowing you to fill an area of memory with a single byte. memcpy is undefined when the areas overlap (C has memmove to correctly handle overlapping areas and memset to fill a memory area with a byte); (3) memcpy can handle variable length moves, MVC requires an EXecute or self-modifying code to change the length of the move at runtime. This point illustrates what I mean about assembler, and to a lesser extent C, forcing the programmer to think at a very low level. There are several machine code instructions for copying data from one memory location to another: MVC, MVCL, MVCLE etc. Which instruction should you use? Is MVC more efficient than MVCL? If so, at what point does a loop of MVC instructions become less efficient than MVCL or MVCLE? Should you use Duff's device to unroll the loop of MVC instructions? Etc. etc. All the above could be handled by a generic MOVE macro which does the calculations and generates the most efficient sequence of instructions in each case. But hardly any assembler programmers use such a macro (as I know from analysing millions of lines of assembler code). The C programmer can just write memcpy (if they know for certain that the areas will not overlap), or memmove, and leave the compiler to generate the most efficient code sequence in each case. In a higher level language you just write: A := B and the compiler handles allocating memory, sharing sub-structures between A and B to avoid copying, freeing the memory used by whatever was in A before (if it is no longer needed), and so on, leaving the programmer to treat A and B as variables holding values in an abstract data type. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
On 05/02/18 23:01, Jon Perryman wrote: I agree. The C compiler is good about discarding useless code but never bothers to issue a warning. I am not sure which compiler you are calling "*the* C compiler", but Clang carries out extensive static analysis including warning about unreachable code. The HLASM assembler does not, however, carry out any static analysis and does not warn about unreachable code. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
From: "Paul Raulerson" Sent: Tuesday, February 06, 2018 2:53 PM On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: From: "Bernd Oppolzer" Sent: Tuesday, February 06, 2018 1:23 AM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string instructions. Most of these were available in 1965 with the S/360. Long before C. Oh my - but no. But yes. These instructions process character strings, that is, strings of one or more characters. In the cases of MVCL and CLCL, these also handle zero-length strings. These are >character< operators, not string operators. There are instructions, not operators. Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in part, to emulate them.) CLST, CUSE, MVST, SRTST, and the later generations of these and other instructions work on strings. Albeit, I think the definition of “string” in this case is a little dodgy. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 12:16 PM Shmuel wrote: While PL/I macros can't extract the attributes of variable > names, they are in most regards as powerful as HLASM macros and syntactically cleaner. I don't know PLI macro's so I did a little research. The deal breaker is that it appears to be a pre-processor language rather than macro language. Is there a way to call the same macro in different locations with parms for tailoring? Yes. It is also called a macro preprocessor. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
> On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: > > From: "Bernd Oppolzer" > Sent: Tuesday, February 06, 2018 1:23 AM > > >> Am 05.02.2018 um 14:42 schrieb Gord Tomlin: >> And, BTW, the historic facts are simply wrong: >> IBM had a C compiler for MVS (and VM, I believe) long before there were >> string instructions on z/Arch. > > MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT > are all string instructions. Most of these were available in 1965 with the > S/360. Long before C. Oh my - but no. These are >character< operators, not string operators. Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in part, to emulate them.) CLST, CUSE, MVST, SRTST, and the later generations of these and other instructions work on strings. Albeit, I think the definition of “string” in this case is a little dodgy. I must say, it is a lot of fun to read some of these postings. I don’t necessarily agree with a lot of them, but they are fun to read. z/OS as the epitome of a portable OS? HLASM more portable that C? Does anyone really buy into that? I assumed it was a just leg pulling… :) -Paul
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 6:50 AM Back then, saving bytes was the norm and would not be considered moronic. 2 bytes could radically increase the size of your programs. No they couldn't. A few extra bytes added to transfer time. A few bytes was significant. It's startling how difficult it can be to shift paradigm beyond "two modes of thought" and invent another. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 6:27 AM Jon Perryman wrote:>> Keith is talking about dump analysis. Show original message Robin Vowels wrote: Perhaps. But even if he was, the link map and assembly listing deals with that issue. Think of optimization as a chaotic programmer. The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in. PL/I is an application programming language where the compiler has knows enough to give you everything you need to debug the problem. PL/I is a general-purposed language, and was designed as a system programming language too. The MULTICS operating system was written in PL/I. System level programs are very different and often require a dump. They might, but if in PL/I, the required information would generally be obtained using its own (HLL) facilities. Multi-tasking requires dumps because you need to know about tasks PL/I can't possibly know about. PL/I can multi-task, and can produce information about the tasks. PL/I doesn't know about CB chains so you may need to find out how you arrived at the wrong CB. If there is a storage overlay, then your program may not be the cause. PL/I knows about anything that it is programmed to do. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Charles Mills" Sent: Tuesday, February 06, 2018 1:51 AM My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe. No problems with S/390 performance. At that time I don't think the x86 architecture had any "string" instructions either -- strcpy() was implemented for PC-DOS as a software loop. The 8088 had a repeat instruction, and when prefixed to another instruction, carried out a loop until a given condition was met. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Bernd Oppolzer" Sent: Tuesday, February 06, 2018 1:23 AM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string instructions. Most of these were available in 1965 with the S/360. Long before C. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate. Kind regards Bernd --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
> Shmuel wrote: > While PL/I macros can't extract the attributes of variable > names, they are > in most regards as powerful as HLASM > macros and syntactically cleaner. Would anyone be interested in my CALC macro. To me, the most important feature is getting a CB address without all the USING and load statements. It may take a few days to find and make usable outside my macro environment. In the following example, it loads R3 with the TSO PSCB address: #CALC .(R3)=PSATOLD=>TCBJSCB=>JSCBPSCB USING PSCB,R3 HLASM macro language is a hodgepodge and could definitely use a major face lift. It has many important features but not completely. Fortunately the macro language is robust enough that there is almost always other ways to do something even though you may not love it. My #CALC is a good example of some of the compromises you need to make. I don't know PLI macro's so I did a little research. The deal breaker is that it appears to be a pre-processor language rather than macro language. Is there a way to call the same macro in different locations with parms for tailoring? Regards, Jon.
Re: Fair comparison C vs HLASM
Nazi should be capitalized. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Monday, February 5, 2018 2:48 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Ah... another grammar nazi. I suppose you could read it as "will be [Chinese food] and [a bag of lead balls]".
Re: Fair comparison C vs HLASM
> Gord Tomlin wrote: > As I've said before, I'm not here to defend C; it has some serious > defects > and, FWIW, Dave Cole's piece was not specific to C. HLASM has > its place, and I continue to do the majority of my work in it (because > of the nature of my work), but its place isn't "everywhere". I'm just a > little taken aback by the complete dismissal of the advantages of > compiled languages in general, and I'm a bit puzzled by the vitriol. I never meant to dismiss the advantages of compiled languages. The point I'm making is that HLASM is far more powerful that most people realize. Those features are not specific to assembler and I've never seen any of those features implemented so well as in HLASM. If these features were implemented in other languages, that language would be extremely powerful. Cobol for instance has OOP which is runtime. These features are compile time and far less overhead. I never said that Dave Cole's piece was specific to C. I said it applies more to C than HLASM. Every language "has it's place". Dave Cole is highly respected in this community and when he says things like this without any qualification, they take on hidden meanings specific to each reader. In this case, C advocates were using this article to say you should avoid HLASM and use C because it's superior. I can't remember for sure but I think it sited C as an HLL that could be used in lieu of HLASM. z/OS Metal C is great for user exits if you don't have HLASM programmers. On the other hand, you will never write a system product in it. Regards, Jon.
Re: Fair comparison C vs HLASM
> Jim Mulder wrote: > With regard to the effects of optimization on understanding > the translation, that can be a mixed bag. I agree. The C compiler is good about discarding useless code but never bothers to issue a warning. You have to love those who say I'll fix it later since it doesn't bother anything. Regards, Jon.
Re: Fair comparison C vs HLASM
Ah... another grammar nazi. I suppose you could read it as "will be [Chinese food] and [a bag of lead balls]". The traditional punishment from the 14th Century is hanging, drawing, and quartering <https://en.wikipedia.org/wiki/Hanged,_drawn_and_quartered>. Based on the principle of causing the most pain, and making the biggest possible mess. They didn't waste ammo on executions. And to semi-justify this terribly off-topic digression: MVCIN does indeed require the source operand to address the last byte. HLASM does not do this for you. sas On Mon, Feb 5, 2018 at 5:35 PM, Charles Mills wrote: > Surely he did not mean "anyone who USES [the unnamed successor to M3] will > be take out and shot." > > Is "being take out" anything like "being toast"? > > Also "hung" refers to pictures and also an R-rated meaning. The capital > punishment is to be hanged. http://grammarist.com/usage/hanged-hung/ > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Paul Gilmartin > Sent: Monday, February 5, 2018 1:53 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Fair comparison C vs HLASM > > On 2018-02-05, at 14:29:32, Seymour J Metz wrote: > > > You just mentioned a macro language whose name is the letter m followed > by a digit. > > > No, although that's probably what he intended to do. See: > https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction > > > _ > > From: John McKown > > Sent: Monday, February 5, 2018 12:17 PM > > > >> Anyone who mentions "m4" will be take out and shot. Then hung. Then > quartered. > -- sas
Re: Fair comparison C vs HLASM
Surely he did not mean "anyone who USES [the unnamed successor to M3] will be take out and shot." Is "being take out" anything like "being toast"? Also "hung" refers to pictures and also an R-rated meaning. The capital punishment is to be hanged. http://grammarist.com/usage/hanged-hung/ Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, February 5, 2018 1:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM On 2018-02-05, at 14:29:32, Seymour J Metz wrote: > You just mentioned a macro language whose name is the letter m followed by a > digit. > No, although that's probably what he intended to do. See: https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction > _ > From: John McKown > Sent: Monday, February 5, 2018 12:17 PM > >> Anyone who mentions "m4" will be take out and shot. Then hung. Then >> quartered.
Re: Fair comparison C vs HLASM
I accept your criticism that the syntax for inlining HLASM in C/C++ is not
good, and that my example should have used labels.
I generally use HLASM wrapper routines where I need to, and have only used
the inlining syntax a handful of times for some performance tweaking.
The context of my post was to respond to someone who said that you couldn't
use instructions like MVCIN in C/C++ - I'm certainly not saying that
inlining in C/C++ is easier or better than just writing in HLASM or even
PL/X.
I am surprised at your criticism of the four instructions that I used for
inlining an MVCIN routine in C/C++ (and your PL/X pseudo code) - you don't
seem to understand how to use the MVCIN instruction. Check the POP.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Mon, Feb 5, 2018 at 12:54 PM, Jon Perryman wrote:
> This is too funny. Profess the virtues of C and provide actual examples
> that look like they prove the point but when scrutinized actually disprove
> it. When I provided these type of examples, it was considered a gross
> exaggeration. C is a mindset that is common. Here's the proof I'm not
> exagerating at all.
>
> > Kirk Wolf wrote:
> > If you compile this with full optimization and look at the generated
> > assembly, you will find a fancy unrolled loop.
> > Who knows if MVCIN is any faster? It certainly won't handle len>256
> cases.
>
> This statement would be funny if it weren't so sad. The "fancy" loop would
> be a simple loop to move each byte where the second operand starts at the
> end. "optimization" never recognized this as an MVCIN loop but it really
> optimized the code it produced. MVCIN is obviously many times faster than a
> single byte loop to move each character (how can this even be a question).
> Can anyone tell us how many times faster MVC 256 bytes is than 256 MVC 1
> byte? To really prove C is superior, MVCIN is limited to 256 byte moves.
> Is he saying a loop moving 1 byte is better than a loop of 256 bytes?
>
> This is "motivated reasoning" to the extreme. Every sentence saying C is
> great and using factless facts to have you questioning the value of HLASM.
> It was logic like this that slowed the debate decades ago.
>
> > Kirk Wolf wrote that MVCIN can be used directly in C and provided the C
> example.
>
> C strongly discourages embedding ASM and the following is a typical
> example why. His example is how to use a single instruction (MVCIN) in C.
> Here is what I think is the PL/X code to use MVCIN. The PL/X program would
> have DCL's for "source" and "dest" and I don't think there is any special
> code needed to reference them. I suspect MVCIN is like TRTR (also reverse)
> where op2 points to the end of the field.
>
> generate
> mvcin dest,source+L'dest
> endgen
>
> Below is Kirk Wolf's example on using MVCIN in C (he's a C advocate).
> Compare it with the PL/X example and tell me I've been exaggerating. It's
> missing the "+L'dest" which would make it more complicated. Make it into a
> loop like the C code mentioned above and it becomes even more complicated.
> Replace the *+10 and *-8 with labels for good coding practices and make it
> even more chaotic.
>
> static void
> HW_MVCIN(unsigned char* dest, unsigned char* src, unsigned char len) {
> __asm (
> " BRU *+10\n"
> " MVCIN 0(*-*,%0),0(%1)\n"
> " BCTR %2,0\n"
> " EXRL %2,*-8\n"
> : :
> "a"(dest),
> "a"(src),
> "r"(len));
> }
>
>
> I use C and will continue to use C until something better comes along. To
> code C, just accept it's blemishes without questioning why otherwise you
> will go crazy. I think this is why C programmers are so adamant about C.
> Remember, good friends won't let friends code C unless absolutely necessary.
>
> Regards, Jon.
>
Re: Fair comparison C vs HLASM
On 2018-02-05, at 14:29:32, Seymour J Metz wrote: > You just mentioned a macro language whose name is the letter m followed by a > digit. > No, although that's probably what he intended to do. See: https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction > _ > From: John McKown > Sent: Monday, February 5, 2018 12:17 PM > >> Anyone who mentions "m4" will be take out and shot. Then hung. Then >> quartered. -- gil
Re: Fair comparison C vs HLASM
The 8088 had a repeat instruction that made character move loops faster than they would otherwise have been, but not as fast as what you would expect from SS instructions. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Monday, February 5, 2018 9:51 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe. No problems with S/390 performance. At that time I don't think the x86 architecture had any "string" instructions either -- strcpy() was implemented for PC-DOS as a software loop. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, February 5, 2018 6:23 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: > On 2018-02-05 00:54, Jon Perryman wrote: >> C is NOT portable. Portable languages must be usable (acceptable) on >> a platform's as it exists. zArch became a portable platform after >> hardware changes added String (and other) instructions. These >> instructions were not added for MVS because we lived without them for >> several years. > > This is the best example of "motivated reasoning" that I have seen in > this lengthy thread. The world is full of packages written in C (and > many other languages) that can be run on numerous different platforms; > in most cases, all that is required is running a build for that > platform. Conversely, you cannot run HLASM on a computer that does not > support z/Architecture or its ancestors, unless you have a legal or > illegal product that emulates said hardware architecture to run it on. And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate.
Re: Fair comparison C vs HLASM
You just mentioned a macro language whose name is the letter m followed by a digit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of John McKown Sent: Monday, February 5, 2018 12:17 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On Mon, Feb 5, 2018 at 10:26 AM, Charles Mills wrote: > I am no expert but are there not "better" (FSVO better, of course) macro > languages, either for C, or generic in their capabilities? > Good question. But the question is not only "do they exist", but "are they available on z/OS (or z/VSE or CMS or ...)"? Anyone who mentions "m4" will be take out and shot. Then hung. Then quartered. > > Charles > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown
Re: Fair comparison C vs HLASM
It would help if IBM would add the QUAL statement from IBMAP, but that would still not give you the OOP paradigm. or scoping. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Monday, February 5, 2018 12:44 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM IMHO the biggest lack in HLASM in this sort of regard is lack of variable scope. The support for named DSECTs got us halfway there, but symbols still must be unique. If I want to define a struct for C I can blithely name my variables input and output and count and size and so forth. In an HLASM DSECT I have to "fake" scope by naming my symbols CM_input, CM_output, CM_count, CM_size and so forth -- and still hope for the best -- there is still no guarantee of no name collisions. The assertion that you can do OOP in HLASM just reflects the poster's lack of knowledge of OOP. To your list, add inheritance, overloading, virtual functions, ... I guess you can kind of do inheritance in HLASM. You could define your own DCBD extensions and piggyback them on the end of the IHADCB DSECT -- whatever additional fields you wanted to associate with a DCB such a buffer pointers, counts, NOTE words, etc. In a sense you have defined a child class of IHADCB. You could then GETMAIN storage for this combined DSECT, kind of like instantiating a child class. (Yes, many differences. The weakness of my example kind of proves the larger point: HLASM is not an OOP language.) Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Ward Sent: Monday, February 5, 2018 9:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM On 05/02/18 15:03, Jon Perryman wrote: > C has functions to reduce complication. C++ and other OOP languages > have objects. Assembler can easily do this thru macro's and it has > other tools to greatly reduce complexity. How do you define a function using assembler macros? How do you define objects? In particular, how do you stop the programmer from taking the address of an object and examining/modifying the object's internals without using the defined interface?
Re: Fair comparison C vs HLASM
> Kirk Wolf wrote:> Pity there is no z/OS port of bash that supports > local > spawn, which is important in many cases. Pipes and spawn go against z/OS fundamental philosophy. Spock's famous Star Trek saying summed it up best. The needs of the business outweigh the needs of the employee. Pipes and spawn are designed around being selfish. They can suck the life out of a machine and I've seen it happen when compiling programs in MVS Unix. Talk to your sysprog for methods that are more z/OS appropriate. Pipes, spawn and many of selfish Unix facilities rely on knowledge programmers don't have. Business priorities (programmers are low priority unless solving a critical problem). Hardware / software configuration (Single real machine with multiple lpars). These facilities exist in z/OS but they are heavily controlled. z/OS has admins who make these decisioins and change the system according to business requirements (e.g. Compiles in batch to limit concurrent compiles). Unix has admins but there isn't much they can change. Instead, every programmer makes decisions that may conflict with others. I suspect admins were happy when the PKILL command was added. It allowed them to kill all tasks that matched the pkill text. Unix programmers on z/OS should be trained to avoid their instincts. In fact, they should program in Cobol for a few months to get rid of their Unix habits that don't apply to z/OS. If you don't have access to those features, you are more likely to ask what is the correct way to do it is and often find out z/OS already does it for you. Regards, Jon.
Re: Fair comparison C vs HLASM
> Paul Gilmartin wrote: > Who made that moronic "single byte" rule!? Back then, saving bytes was the norm and would not be considered moronic. 2 bytes could radically increase the size of your programs. A few extra bytes added to transfer time. A few bytes was significant. > It's startling how difficult it can be to shift paradigm > beyond "two modes of thought" and invent another. It's not difficult all. There are 3 paradigm (structured, unstructured and a mix of both). Consider the worst case scenario (unstructured). Think of it like a book where you must read thru it to find what you need. Add a table of contents and index will give will give you a mix where reading the book may not be necessary. We are continually shifting the paradigm. We started with records. I believe next was ISAM followed by databases & VSAM. Databases were significant because we could finally move to a mix of unstructured data. You could apply additional structure to the data as it was discovered. The next step will probably be within "big data". Regards, Jon
Re: Fair comparison C vs HLASM
>> Jon Perryman wrote:>> Keith is talking about dump analysis. Show original >> message > Robin Vowels wrote: > Perhaps. But even if he was, the link map and assembly listing deals with > that issue. >> Think of optimization as a chaotic programmer. > The last time I used a dump to find bugs in a compiled program was about 35 >years ago. > PL/I provides all the information required because it has debugging > facilities built in. PL/I is an application programming language where the compiler has knows enough to give you everything you need to debug the problem. System level programs are very different and often require a dump. Multi-tasking requires dumps because you need to know about tasks PL/I can't possibly know about. PL/I doesn't know about CB chains so you may need to find out how you arrived at the wrong CB. If there is a storage overlay, then your program may not be the cause. Regards, Jon.
Re: Fair comparison C vs HLASM
Ref: Your note of Mon, 5 Feb 2018 17:32:28 + Martin Ward wrote: > Jon Perryman wrote: > > C has functions to reduce complication. C++ and other OOP languages > > have objects. Assembler can easily do this thru macro's and it has > > other tools to greatly reduce complexity. > > How do you define a function using assembler macros? > How do you define objects? In particular, how do you stop > the programmer from taking the address of an object > and examining/modifying the object's internals > without using the defined interface? I was hoping to resist joining in this potentially infinite digression about other programming languages, but I've failed... Back in the 1990s, I implemented the IBM CICS authorized cross-memory (AXM) servers (used for coupling facility access) using a form of "object-oriented structured programming assembler" using macros and a lot of OPSYN stuff. Of course, it didn't do everything in an object-oriented way (especially given Assembler name scope limitations) but it had quite a lot of useful object-oriented function. Data structures were enclosed in CLASS/ENDCLASS and RECORD/ENDREC macros (optionally nested) which among other things automatically created an overall definition of the structure and its length. These data structures could include standard macros such as DCBs and system data area mapping macros. The header of a CLASS structure identified the owning module and any friend modules. If the structure was included in a module other than the owning module, any DC statements were automatically changed to DS and it was converted from a CSECT to a DSECT. Any RECORD section could be marked as PUBLIC or PRIVATE. If a data structure was included in a module which was neither the owning module nor a friend, the field names for any PRIVATE sections were suppressed, so they couldn't be referenced explicitly. (This involved some complex tricks if the labels were referenced in ORG or similar). A class could contain methods, which were implemented via a macro which defined the entry point address within the initial value of the object and defined some assembler fields to pass information to other macros. The macro for calling a procedure would detect whether it had been declared as a method and if so would automatically pass the address of the associated object in R0. The method procedure header declared a "context" register which was set from R0 on entry to the procedure and used as a base for the object. Storage for a structure could be allocated dynamically by the ALLOCATE macro. The normal convention was to establish a USING statement with a suitable base register first, in which case it was not necessary to specify the register on the ALLOCATE. The ALLOCATE statement would then acquire storage for the structure, set the base register specified on the USING (which involves a bit of trickery), locate the static initial value for the structure (using an address constant) and copy the initial value into the dynamic area. If the allocated object was actually owned by a different module, the code to allocate the structure picked up the structure size from the initial value prefix addressed via an adcon. This meant that if the structure included private fields which were at the end, it was not necessary to recompile the module if the owning module made changes which only affected the private section. I followed the rule that objects are declared near the start, before they are used, which meant that macros working with objects could pick up the actual object length and for example automatically generate multiple MVCs to copy an object exceeding 256 bytes. Some of the language features I implemented in macros (such as my LIKE macro for declaring a structure like a previous one) felt like a step too far, and I avoided using them in production code because I felt that they would need too much specialist knowledge to use and maintain, and moved rather too far away from the standard HLASM language. (I feel similarly about the HLASM structured programming macros; I use the basic IF/ELSE/ENDIF all the time, but usually only with condition codes, not with instructions as operands, as I feel that the extended notation introduces yet another new "language" to be understood). Another feature I made good use of is AREAD. For example, I can have a section of code containing messages laid out as ordinary text, with markers such as &1 for inserts, and with macros around it to convert it automatically into the relevant data definitions. Similarly, I could include special debugging code in the source with macros around it that use AREAD to quietly swallow up the debugging code when assembled for production use. On the other hand, when I needed to rewrite the HTML processing for the Charlotte web browser, which was not performing well in REXX, I chose to use Systems Programming C/370 rather than Assembler. That environment did not have any C library stuff at all, so I reimpleme
Re: Fair comparison C vs HLASM
This is too funny. Profess the virtues of C and provide actual examples that
look like they prove the point but when scrutinized actually disprove it. When
I provided these type of examples, it was considered a gross exaggeration. C is
a mindset that is common. Here's the proof I'm not exagerating at all.
> Kirk Wolf wrote:
> If you compile this with full optimization and look at the generated
> assembly, you will find a fancy unrolled loop.
> Who knows if MVCIN is any faster? It certainly won't handle len>256 cases.
This statement would be funny if it weren't so sad. The "fancy" loop would be a
simple loop to move each byte where the second operand starts at the end.
"optimization" never recognized this as an MVCIN loop but it really optimized
the code it produced. MVCIN is obviously many times faster than a single byte
loop to move each character (how can this even be a question). Can anyone tell
us how many times faster MVC 256 bytes is than 256 MVC 1 byte? To really prove
C is superior, MVCIN is limited to 256 byte moves. Is he saying a loop moving 1
byte is better than a loop of 256 bytes?
This is "motivated reasoning" to the extreme. Every sentence saying C is great
and using factless facts to have you questioning the value of HLASM. It was
logic like this that slowed the debate decades ago.
> Kirk Wolf wrote that MVCIN can be used directly in C and provided the C
> example.
C strongly discourages embedding ASM and the following is a typical example
why. His example is how to use a single instruction (MVCIN) in C. Here is what
I think is the PL/X code to use MVCIN. The PL/X program would have DCL's for
"source" and "dest" and I don't think there is any special code needed to
reference them. I suspect MVCIN is like TRTR (also reverse) where op2 points to
the end of the field.
generate
mvcin dest,source+L'dest
endgen
Below is Kirk Wolf's example on using MVCIN in C (he's a C advocate). Compare
it with the PL/X example and tell me I've been exaggerating. It's missing the
"+L'dest" which would make it more complicated. Make it into a loop like the C
code mentioned above and it becomes even more complicated. Replace the *+10 and
*-8 with labels for good coding practices and make it even more chaotic.
static void
HW_MVCIN(unsigned char* dest, unsigned char* src, unsigned char len) {
__asm (
" BRU *+10\n"
" MVCIN 0(*-*,%0),0(%1)\n"
" BCTR %2,0\n"
" EXRL %2,*-8\n"
: :
"a"(dest),
"a"(src),
"r"(len));
}
I use C and will continue to use C until something better comes along. To code
C, just accept it's blemishes without questioning why otherwise you will go
crazy. I think this is why C programmers are so adamant about C. Remember, good
friends won't let friends code C unless absolutely necessary.
Regards, Jon.
Re: Fair comparison C vs HLASM
IMHO the biggest lack in HLASM in this sort of regard is lack of variable scope. The support for named DSECTs got us halfway there, but symbols still must be unique. If I want to define a struct for C I can blithely name my variables input and output and count and size and so forth. In an HLASM DSECT I have to "fake" scope by naming my symbols CM_input, CM_output, CM_count, CM_size and so forth -- and still hope for the best -- there is still no guarantee of no name collisions. The assertion that you can do OOP in HLASM just reflects the poster's lack of knowledge of OOP. To your list, add inheritance, overloading, virtual functions, ... I guess you can kind of do inheritance in HLASM. You could define your own DCBD extensions and piggyback them on the end of the IHADCB DSECT -- whatever additional fields you wanted to associate with a DCB such a buffer pointers, counts, NOTE words, etc. In a sense you have defined a child class of IHADCB. You could then GETMAIN storage for this combined DSECT, kind of like instantiating a child class. (Yes, many differences. The weakness of my example kind of proves the larger point: HLASM is not an OOP language.) Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Ward Sent: Monday, February 5, 2018 9:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM On 05/02/18 15:03, Jon Perryman wrote: > C has functions to reduce complication. C++ and other OOP languages > have objects. Assembler can easily do this thru macro's and it has > other tools to greatly reduce complexity. How do you define a function using assembler macros? How do you define objects? In particular, how do you stop the programmer from taking the address of an object and examining/modifying the object's internals without using the defined interface?
Re: Fair comparison C vs HLASM
On 05/02/18 15:03, Jon Perryman wrote: C has functions to reduce complication. C++ and other OOP languages have objects. Assembler can easily do this thru macro's and it has other tools to greatly reduce complexity. How do you define a function using assembler macros? How do you define objects? In particular, how do you stop the programmer from taking the address of an object and examining/modifying the object's internals without using the defined interface? -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
On Mon, Feb 5, 2018 at 10:26 AM, Charles Mills wrote: > I am no expert but are there not "better" (FSVO better, of course) macro > languages, either for C, or generic in their capabilities? > Good question. But the question is not only "do they exist", but "are they available on z/OS (or z/VSE or CMS or ...)"? Anyone who mentions "m4" will be take out and shot. Then hung. Then quartered. > > Charles > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown
Re: Fair comparison C vs HLASM
On 05/02/18 16:26, Charles Mills wrote: I am no expert but are there not "better" (FSVO better, of course) macro languages, either for C, or generic in their capabilities? Scheme has hygienic macros, whose expansion is guaranteed not to cause the accidental capture of identifiers, a pattern-matching language and a low-level facility for writing macros. The former allows macros to be written declaratively, while the latter allows the implementation of alternative frontends for writing macros. https://en.wikipedia.org/wiki/Hygienic_macro Perl 6 supports both hygienic and unhygienic macros. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Fair comparison C vs HLASM
I am no expert but are there not "better" (FSVO better, of course) macro languages, either for C, or generic in their capabilities? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Monday, February 5, 2018 7:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM On Mon, Feb 5, 2018 at 9:03 AM, Jon Perryman wrote: > >> Jon Perryman wrote: > >> For large complicated problems, assembler is the language of choice. > > Martin Ward wrote: > > For large complicated problems a domain-specific language, targeted > > at the problem domain, is the language of choice. > > IBM assembler is the only language that I know which is easily > tailored by the programmer to be domain specific. C has functions to > reduce complication. C++ and other OOP languages have objects. > Assembler can easily do this thru macro's and it has other tools to > greatly reduce complexity. E.g. non-linear programming allows you to > easily group source code that assembles in multiple locations in the module. > What I am generally getting from all of this is that you like HLASM's __macro__ capability. Not that you necessarily think that (for lack of a better word) "raw" assembler is "better" than . There are a number of DSLs written in Java. I am not knowledgeable enough about DSLs to have a real opinion. Hum, it would be stupid of me, but I sort of wonder if it would be "interesting" to write some HLASM macros which are designed to emit C code (via PUNCH). Kind of like Metal C's emitting of HLASM.
Re: Fair comparison C vs HLASM
Amen. The "motivated reasoning" charge Perryman levels at virtually the entire world is very ironic. Besides the straw-man arguments, there has been a whole lot of comparing apples to locomotives. sas On Mon, Feb 5, 2018 at 9:18 AM, Tom Marchant < 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > On Mon, 5 Feb 2018 08:42:55 -0500, Gord Tomlin wrote: > > >I'm just a > >little taken aback by the complete dismissal of the advantages of > >compiled languages in general, and I'm a bit puzzled by the vitriol. > > And I'm puzzled that Mr. Perryman continues so persistently with his > crusade, adding little new with each post. It has become quite tiring. > > -- > Tom Marchant > -- sas
Re: Fair comparison C vs HLASM
On Mon, Feb 5, 2018 at 9:03 AM, Jon Perryman wrote: > >> Jon Perryman wrote: > >> For large complicated problems, assembler is the language of choice. > > Martin Ward wrote: > > For large complicated problems a domain-specific language, > > targeted at the problem domain, is the language of choice. > > IBM assembler is the only language that I know which is easily tailored by > the programmer to be domain specific. C has functions to reduce > complication. C++ and other OOP languages have objects. Assembler can > easily do this thru macro's and it has other tools to greatly reduce > complexity. E.g. non-linear programming allows you to easily group source > code that assembles in multiple locations in the module. > What I am generally getting from all of this is that you like HLASM's __macro__ capability. Not that you necessarily think that (for lack of a better word) "raw" assembler is "better" than . There are a number of DSLs written in Java. I am not knowledgeable enough about DSLs to have a real opinion. Hum, it would be stupid of me, but I sort of wonder if it would be "interesting" to write some HLASM macros which are designed to emit C code (via PUNCH). Kind of like Metal C's emitting of HLASM. > > > Martin Ward wrote: > > Does assembler encourage good coding practices? > > No, assembler does not. However, it gives you the tools create really good > coding practices and IBM has set a really good example thru their use of > macro's to reduce complexity. > > Regards, Jon. > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown
Re: Fair comparison C vs HLASM
Sorry -- long former COMPANY wrote ... Recalling more details now: we used the old SAS C. We did not trust the IBM C dependence on a local runtime (LE) as opposed to being a "complete" executable that we could ship. SAS C is utterly an example of the incorrectness of @Jon's logic. If I recall the stories correctly, Dr. Jim Goodnight, the founder and "guru" of SAS -- who knows more about computer languages than most of us put together -- felt that SAS had become too large a product to continue to be developed in assembler. He felt so strongly C would be a better choice (and apparently finding the IBM offering lacking) that they acquired the Lattice C compiler and ported it to OS/390, initially for internal use, and then as a published product. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Monday, February 5, 2018 6:52 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe. No problems with S/390 performance. At that time I don't think the x86 architecture had any "string" instructions either -- strcpy() was implemented for PC-DOS as a software loop. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, February 5, 2018 6:23 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: > On 2018-02-05 00:54, Jon Perryman wrote: >> C is NOT portable. Portable languages must be usable (acceptable) on >> a platform's as it exists. zArch became a portable platform after >> hardware changes added String (and other) instructions. These >> instructions were not added for MVS because we lived without them for >> several years. > > This is the best example of "motivated reasoning" that I have seen in > this lengthy thread. The world is full of packages written in C (and > many other languages) that can be run on numerous different platforms; > in most cases, all that is required is running a build for that > platform. Conversely, you cannot run HLASM on a computer that does not > support z/Architecture or its ancestors, unless you have a legal or > illegal product that emulates said hardware architecture to run it on. And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate.
Re: Fair comparison C vs HLASM
>> Jon Perryman wrote: >> For large complicated problems, assembler is the language of choice. > Martin Ward wrote: > For large complicated problems a domain-specific language, > targeted at the problem domain, is the language of choice. IBM assembler is the only language that I know which is easily tailored by the programmer to be domain specific. C has functions to reduce complication. C++ and other OOP languages have objects. Assembler can easily do this thru macro's and it has other tools to greatly reduce complexity. E.g. non-linear programming allows you to easily group source code that assembles in multiple locations in the module. > Martin Ward wrote: > Does assembler encourage good coding practices? No, assembler does not. However, it gives you the tools create really good coding practices and IBM has set a really good example thru their use of macro's to reduce complexity. Regards, Jon.
Re: Fair comparison C vs HLASM
My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe. No problems with S/390 performance. At that time I don't think the x86 architecture had any "string" instructions either -- strcpy() was implemented for PC-DOS as a software loop. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, February 5, 2018 6:23 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: > On 2018-02-05 00:54, Jon Perryman wrote: >> C is NOT portable. Portable languages must be usable (acceptable) on >> a platform's as it exists. zArch became a portable platform after >> hardware changes added String (and other) instructions. These >> instructions were not added for MVS because we lived without them for >> several years. > > This is the best example of "motivated reasoning" that I have seen in > this lengthy thread. The world is full of packages written in C (and > many other languages) that can be run on numerous different platforms; > in most cases, all that is required is running a build for that > platform. Conversely, you cannot run HLASM on a computer that does not > support z/Architecture or its ancestors, unless you have a legal or > illegal product that emulates said hardware architecture to run it on. And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate.
Re: Fair comparison C vs HLASM
Am 05.02.2018 um 14:42 schrieb Gord Tomlin: On 2018-02-05 00:54, Jon Perryman wrote: C is NOT portable. Portable languages must be usable (acceptable) on a platform's as it exists. zArch became a portable platform after hardware changes added String (and other) instructions. These instructions were not added for MVS because we lived without them for several years. This is the best example of "motivated reasoning" that I have seen in this lengthy thread. The world is full of packages written in C (and many other languages) that can be run on numerous different platforms; in most cases, all that is required is running a build for that platform. Conversely, you cannot run HLASM on a computer that does not support z/Architecture or its ancestors, unless you have a legal or illegal product that emulates said hardware architecture to run it on. And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate. Kind regards Bernd
Re: Fair comparison C vs HLASM
On Mon, 5 Feb 2018 08:42:55 -0500, Gord Tomlin wrote: >I'm just a >little taken aback by the complete dismissal of the advantages of >compiled languages in general, and I'm a bit puzzled by the vitriol. And I'm puzzled that Mr. Perryman continues so persistently with his crusade, adding little new with each post. It has become quite tiring. -- Tom Marchant
Re: Fair comparison C vs HLASM
On 2018-02-05 00:54, Jon Perryman wrote: C is NOT portable. Portable languages must be usable (acceptable) on a platform's as it exists. zArch became a portable platform after hardware changes added String (and other) instructions. These instructions were not added for MVS because we lived without them for several years. This is the best example of "motivated reasoning" that I have seen in this lengthy thread. The world is full of packages written in C (and many other languages) that can be run on numerous different platforms; in most cases, all that is required is running a build for that platform. Conversely, you cannot run HLASM on a computer that does not support z/Architecture or its ancestors, unless you have a legal or illegal product that emulates said hardware architecture to run it on. Calling z/Architecture a "portable platform" is inverting the whole concept of portability (actually, "cross platform applications"). You port the software to the hardware. As I've said before, I'm not here to defend C; it has some serious defects and, FWIW, Dave Cole's piece was not specific to C. HLASM has its place, and I continue to do the majority of my work in it (because of the nature of my work), but its place isn't "everywhere". I'm just a little taken aback by the complete dismissal of the advantages of compiled languages in general, and I'm a bit puzzled by the vitriol. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Fair comparison C vs HLASM
It's disappointing that so many in this group don't realize the true power of HLASM. I respect Dave Cole's opinions but his comment "ASM has it's place" makes me think even he has underestimated it's power. People have played down my using DCB to show the power of HLASM. Do you realize that there are more than 10 manuals DEDICATED to HLASM macro's (MVS services, MVS auth services, DFP, RACF, JES2, TSO and more)? Pick any non-trivial macro (e.g. not save or return) and tell us how you could make the functionality available / usable / maintainable in ANY other language. I must repeat, MVS would not exist without IBM ASM. Many of the technologies in UNIX evolved from z/OS. I've worked on and written products in IBM ASM that would not be maintainable in C (or almost every other language). The features from ASM should be integrated into other languages (e.g. Cobol). > Kirk Wolf wrote: > I would have thought that this kind of argument about the relative benefits > of assemblers vs compilers (or assembler vs C) would have been over a > couple of decades ago. Sadly, you can't always trust C programmers (look up "motivated reasoning"). They need C to be the best language. Just because C does the job doesn't mean it does it well. Here are real facts (not factless facts). I knew C didn't compete well with IBM ASM but now It's clear that C is the poor man's attempt at PLX. IBM (not management) gets bashed by C programmer's thru absolutely false accusations. PL/X is similar to C except that PL/X does it far better. E.g. PL/X generate allows you to truly integrate as much ASM as needed and able to reference data without all the confusing C definitions. Dave Cole's document is more relevant to C as to ASM or PL/X. Many C programs should have been written in a high level language. C programmers are the same as ASM programmers. Why maintain a duplicate DSECT's (C structs) in another language when you can just code it in the same language. PL/X doesn't have the DSECT issue. Many C programmers are so vested in C that they can't see the language for what it is. Apparently so much so that no matter how much proof, they will ignore the real facts. I'm not vested in ASM will readily admit it has many flaws. I will use any language that get's the job done and is maintainable. I've programmed a robot using 5 different languages at the same time. Switching languages it not too bad when you work in a single language for a few hours. On the other hand, Bouncing between languages can be very frustrating. I have no fear of programming in other languages and judge those languages based on their merit. Not on what I want to believe. 1. C is NOT portable. Portable languages must be usable (acceptable) on a platform's as it exists. zArch became a portable platform after hardware changes added String (and other) instructions. These instructions were not added for MVS because we lived without them for several years. 2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A)). In fact, several of the C standard functions have matching z instructions (or a few). What is the difference in using a C standard function or a zArch instruction? What is the real difference between a hand coded HLASM program compared to C program when many of the standard functions match a z instruction? IBM could have implemented any of the standard C functions as zArch instructions. There are several standard functions that are only relevant to application programmers and compiler writers (e.g. when did we need trig functions). Why bother creating instructions that are purely application level. The point is there is not much difference in zArch instructions and the important C standard functions. They are both a choice about the types of problems to be solved. When the C standard changes, then more zArch instructions may need to be added. 3. >> Kirk Wolf wrote: For all of the supposed byte-by-byte C programmers How can a C programmer not understand that C is a byte oriented language? Apparently it's questionable. Programmers have functions that do multi-byte functions (e.g. memcpy() ). Why not mention all the byte functions (e.g. isNumber). He also forgot to mention that not using the language can only deal with bytes unless you play tricks (e.g. fullword). Mentioned were arrays which again is dealing in bytes. Arrays however do allow you to create a fixed length field. 4. >> Kirk Wolf wrote:. Compilers can generate machine instruction implementations that takeadvantage of the instructions and architecture available. "can" optimize? It's hilarious how much C programmers stress optimization. The C compiler better optimize because the coding style causes inefficient source. Benefits of optimization on z/OS is questionable. Does anyone have any stats on hand coded ASM versus the same logic in optimized C? C optimization is incredibly important on platforms with very little or no hard
Re: Fair comparison C vs HLASM
As an example, some debuggers log a trace of the program and allow you to scroll the log back from the point of failure in order to track down when, where and how variables acquired unexpected values. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Friday, February 2, 2018 8:07 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1rv0_ViDBnAq9E8I77eef45o03MlwZh4vPHvDJmEisiHJgBhueEZPc-V95SjOy0Os2IRU8WOc6DF-3qReefpLJrMt3SzV3dQjExWbVFrng5hTtnutqAqPGp8b6mRCKbmdF_7K47JyEXz6v907KNPnnVDptwR3MW7vi-BwxHmwg79KlDsy2QWSa1oNk-ZEAddQQwtqzeprl4BT7KUMw7Q0I4b7EGxDWHJiSs_NXRCX-TK4KjGM9cnOebHNP4SPnFIbGM6DK9vcfqhlCtB0U4GtnvafGlfujxyRPCCjLpj_dtinMCnyad89nfLluF6YugTtOA4uy3QxYKHftD9GNiypxSI5i8IJGV5shcWD4lgl724TDMPeHjrgQ6Lahgex1O0PczIPUiyj3tDl_iYqRNheSb06saL2azbIYtZL_BsKnBlT8YyoHwA4ecH3FQxf4Z-i/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 2018-02-01, at 23:56:19, Jim Mulder wrote: > ... simplistic environments > where all of your problems can be recreated with an unoptimized compiles while > running under an interactive debug tool. We certainly do not have that > luxury in the operating system. > BTDT. Ouch! The debug option should not conceal any flaws manifest under optimizatization. > ... PL/X is compiled into assembler source code. > ... My limited dealings with the > pseudo-assembler listings generated by the IBM C compiler suggest that > the IBM C compiler really sucks in that regard, at least compared to PL/X. > The Pascal compiler I was working on generated pseudo-assembler listings. I worked to make them valid assembler, if only to confirm the validity of the generation. Never quite completed the chore. Likewise, the "cc" command has the option of generating pseudo-JCL. But that's a cop-out. It ought to be verifiable by actually running the job. -- gil
Re: Fair comparison C vs HLASM
That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Thursday, February 1, 2018 4:02 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Jon Perryman" Sent: Thursday, February 01, 2018 1:49 AM > On Wednesday, January 31, 2018 1:00 AM, Robin Vowels > wrote: > > From: "Keith Moe" > Sent: Tuesday, January 30, 2018 11:08 AM > >>> Keith Moe wrote: > >>> One of the downsides to such great optimization >>> is the added difficulty in debugging. > >> Robin Vowels wrote: >> Such optimisations are rarely requested >> during debugging, when all the facilities of the >> compiler - such as subscript bounds checking,> check for uninitialized >> variables, etc, are >> employed. > > > Keith is talking about dump analysis. Perhaps. But even if he was, the link map and assembly listing deals with that issue. However, as I said, optimising is not usually requested during debugging. > Think of optimization as a chaotic programmer. The stronger the > optimization, the more chaos. > The best optimization will often make following the machine logic very > difficult. The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in. --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1T7auVlKJl3jtYyELTghGHKTSIY3lXyMMtMtr3d2gHlR0l9iDo5ZzNRe51Z0RiEeP4Khaka3FYceH5wm12Pe510sxM1FOFc4Ajx-yibc57VzC7USfuBQRxdr-IFVFS8n2rR8TfcQo-Y83g8QIX57qnwohnoFW0gCYc_UKSMqI7oiph-UA-wDrykmss_f5uOXsoN77PaB-kP5g3dwiBHGyt7qUKbJbrJaaA26lvlAiW5KCfzY4FstGBP-ac0nxvUV0MyuOpF50a2Oc_UOsEFkJ4-ToDFJTM90dGjZZkgPhZqeweThdWUVgLScfXHEMsaxOIZ4VABWTfcpvxYL0qOxTQi0wkgl7x0H35OpbfWnZ4oHZNORiSTuyCrKkB2flarP1GSID3b_RS6DtioTHkcODFz9j_9xTge6IgjHVYF1Lhr3yJQubzckxfTeVtvYhgt3j/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Fair comparison C vs HLASM
On 2018-02-01, at 19:11:07, Paul Raulerson wrote: > > Huh - may not know what I am talking about here, but any C program on a *nix > variant, like AIX, can open and handle as many pipes as you want. > STDIN/STDOUT is > just one set, > Yes. > and you can reopen them as many times as you want. > I believe not. Once a descriptor is closed it's gone. But you can dup() the descriptor (fork() does that automatically) before close and open the duplicate. You can use duplicate descriptors for the effect of FANINANY. > Timing is usually done with signal and/or semaphores - or better yet with > message > queues. :) -- gil
Re: Fair comparison C vs HLASM
The descriptor was part of the implementation, not part of the language. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Thursday, February 1, 2018 10:09 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Paul Raulerson" Sent: Friday, February 02, 2018 12:55 AM > And as already been noted, C was first compile on a PDP-7, which had a simple > instruction set but > was most definitely a CISC machine too. ;) > It also explains one of the reasons why strings in C are null terminated. > There were two modes of thought back in those days, ‘Pascal’ strings, > which have the string size encoded in a single byte at the start of the > string, > and ‘C’ strings, which terminate a string with a NULL. And PL/I strings, which used a descriptor in which the length up to 32767 was specified. > Pascal string length was obviously limited by the max value of a byte - The length was not embedded in the langage; it was an arbitrary limit imposed by the implementer. They could have, for example, used 2 bytes at the start of the string. > null terminated strings could be just about any possible size. Yes, but with two disadvantages -- 1. if you wanted to know the length of the string, it was necessaary to search the entire string. 2. A byte of zero could not be part of the string -- completely useless when processing arbitrary data (such as image data, and compressed data). > Record eliminators of course, are an entirely different thing, > but a C string could easily be a few thousand bytes long. > Handy indeed for things like text processing, which is what the AT&T > guys were selling Unix and C to their bosses for. --- This email has been checked for viruses by Avast antivirus software. https://secure-web.cisco.com/1aDPxzoB6XT6tDTG2XCN51vxrZjtl-UqxQz7Y3L-Y6b9aduYaVJ61OZHLBqWo8Vzg9UzaUzp8dQ0fBzbSV4Cl3A8192WYRIzDEqQUZpENM9Col3WaafoViCOjKJ2T_xZciM85PvFsW2KJYLSBuk1QDqr8TRXKM50_NOAViJtdkQrFpw-3XJNa10phD6k_bmX3ZgVwDQt37AEFqCM6B6kh1CyoVgJHNf30-gB3pjbpogUpBxmcLwvOE1pTV_N0HcAgOgRarc5g_wuVxkVe6C2Gl0qua9B8CNK--CAwx80-JHxfpi_5nC7T7K1wOHQ5tSyoA0dEbcqDS3AK-uTAPZzvVG4szc1QGKwtiTLX-1itIyIZZOtL9L0xLODC5X_WMHoM_7Xgqu9seOtXnlH1WK9HAQ/https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Fair comparison C vs HLASM
On 2018-02-02 09:45, Charles Mills wrote: I wonder, have machines changed at all since 1989? Any new instructions on the Z? The "problem" is fixed in C++ -- Google std:string. or std::string -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Fair comparison C vs HLASM
I might argue that MVS is sui generis, something of a special case. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jim Mulder Sent: Thursday, February 1, 2018 10:15 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Much of MVS is written in a compiled language (PL/X and its predecessors), and I have spent the past 38 years making a living by debugging it using dumps. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List wrote on 02/01/2018 09:03:37 AM: > From: Charles Mills > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 02/02/2018 01:00 AM > Subject: Re: Fair comparison C vs HLASM Sent by: IBM Mainframe > Assembler List > > > The last time I used a dump to find bugs in a compiled program was > about 35 years ago. > > Right! I think if you are using a classic "core dump" to find logic > errors in a compiled language program then you are doing something wrong. > > To find an error in some big table or something, sure, but then the > arrangement of the compiled machine instructions should not matter.
Re: Fair comparison C vs HLASM
I wonder, have machines changed at all since 1989? Any new instructions on the Z? The "problem" is fixed in C++ -- Google std:string. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Clem Clarke Sent: Friday, February 2, 2018 4:13 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM Tests I did in 1989 and earlier showed that the null terminated strings are up to 26 times slower that using PL/I and Pascal strings. And they are dangerous. I have put some tests and documentation here: http://start.oscar-jol.com/fast-c-strings and an early message about the problem here: http://start.oscar-jol.com/fast-c-strings/original-message-re-c-strings Bill Gates had someone reply to me too, and his company's response is at the bottom of this page: http://start.oscar-jol.com/fast-c-strings Here's a table showing the relative speeds of various copies. The ASM copy refers to the 8086 equivalent of the 370 MVC. I did do some tests on Z/OS when I worked at IBM - however I am unable to find the results now. They were similar, though! Essentially, having to search for the binary zero at the end of a string to find it's length is costing approximately 20 times more CPU power that doing strings the way PL/I, Pascal and other languages utilise strings. In addition, C String methods can (and do) overwrite storage accidentally when a long string is copied to a short string. Let's fix the problem, once and for all!
Re: Fair comparison C vs HLASM
Tests I did in 1989 and earlier showed that the null terminated strings are up to 26 times slower that using PL/I and Pascal strings. And they are dangerous. I have put some tests and documentation here: http://start.oscar-jol.com/fast-c-strings and an early message about the problem here: http://start.oscar-jol.com/fast-c-strings/original-message-re-c-strings Bill Gates had someone reply to me too, and his company's response is at the bottom of this page: http://start.oscar-jol.com/fast-c-strings Here's a table showing the relative speeds of various copies. The ASM copy refers to the 8086 equivalent of the 370 MVC. I did do some tests on Z/OS when I worked at IBM - however I am unable to find the results now. They were similar, though! Essentially, having to search for the binary zero at the end of a string to find it's length is costing approximately 20 times more CPU power that doing strings the way PL/I, Pascal and other languages utilise strings. In addition, C String methods can (and do) overwrite storage accidentally when a long string is copied to a short string. Let's fix the problem, once and for all! Clem Clarke PS: If the table isn't displayed clearly in this message, please look at it here: http://start.oscar-jol.com/fast-c-strings/original-message-re-c-strings __ | | | Elapsed Time for DUMMY CPY (Loop Overhead) 2.00 | | | | Elapsed Time for ASM CPY is 7.00 | | | | Elapsed Time for MEMCPY CPY is 12.00 | | | | Elapsed Time for STRCPY CPY is 31.00 | | | | Elapsed Time for INCRCPY (Slowest) CPY is 136.00 | | | | Elapsed Time for INCRCPY (using Register Vars) CPY is 67.00 | |__| | | | Type of Copy Elap Loop Real Ratio | | Time Overhd Copy | |__| | | | Copying a 66 byte string 30 times | | = | | | | INCRCPY (Static Pointers) 136.00 2.00 134.00 1.00 | | INCRCPY (Register Pointers) 67.00 2.00 65.00 2.061538 | | STRCPY 31.00 2.00 29.00 4.620690 | | MEMCPY 12.00 2.00 10.00 13.40 | | ASM 7.00 2.00 5.00 26.80 | | ^ | | | | | Note -| | |__| Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, January 31, 2018 3:48 PM On 2018-01-30, at 21:17:05, Robin Vowels wrote: On 31/01/2018 3:27 AM, Jon Perryman wrote: Exactly my point. I suspect that the C group considered Null-terminated strings cost exactly the same as fixed length fields. ... But if you just want the length, a fixed-length string wins. In PL/I, a varying-length string also wins, because the current length is kept with descriptor, so it isn't necessary to search through the string in order to find the end. And strings with descriptors (address, length) make it easy to define substrings. Just create a new descriptor. A C partisan once told me, just save a character, overlay it with a NUL, then put it back when you're done with the substring. I've used a language that defined substrings by creating descriptors, then handled garbage collection properly -- any byte not governed by one or more descriptors was subject to reclaim. That is how strings are implemented in XPL (from c. 1966). A substring was obtained by merely pointing a descriptor at the first character ; the required number of characters being inserted in the descriptor. No characters of the string were moved. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 2 February 2018 at 03:11, Paul Raulerson wrote: > > Timing is usually done with signal and/or semaphores - or better yet with > message > queues. :) > With 'relative timing' I mean the flow of records in two parallel paths, for example selecting a subset of the records to modify, and then combine the two streams again. When stages would buffer records, you would need to number records so you merge in the right order. I don't suppose you would seriously suggest implementing a messaging system to pass records between stages in the pipeline that each take a few dozen instructions to do their work. For one of the things I work on, the application runs some 15,000 stages in parallel (just a 64K buffer between them would add up to 1 GB). It's true that systems are 3-4 orders of magnitude larger than when the dispatcher in CMS Pipelines was written, but it has been demonstrated that a 'straightforward' implementation in Java even today is too resource intensive to be practical. Rob
Re: Fair comparison C vs HLASM
Here in the MVS development shop, we test and debug the code compiled at the optimization level with which it will be shipped. Doing otherwise would mask the source code bugs which have consequences only at a higher optimization level, and would also mask the compiler code generation bugs which are only present at the higher optimization level. Your suggested techniques might make sense for simplistic environments where all of your problems can be recreated with an unoptimized compiles while running under an interactive debug tool. We certainly do not have that luxury in the operating system. Since we are routinely working with dumps, we have a great need to understand the translation from the source code language to the assembler or machine code. PL/X is compiled into assembler source code. We depend heavily on the PL/X compiler to generate symbol names which are relatable to the variable and field names in the source program, to aid us in understanding the translation. Fortunately for me, I don't deal much with C. My limited dealings with the pseudo-assembler listings generated by the IBM C compiler suggest that the IBM C compiler really sucks in that regard, at least compared to PL/X. With regard to the effects of optimization on understanding the translation, that can be a mixed bag. Some optimizations (especially those that move things a long distance) can increase the degree of difficulty. Others that reduce the amount of generated code by avoiding a lot of register reloading can make things easier, especially when you are tracing your way though some code (since there is less of it to trace). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List wrote on 01/31/2018 04:03:34 AM: > From: Robin Vowels > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 01/31/2018 12:23 PM > Subject: Re: Fair comparison C vs HLASM > Sent by: IBM Mainframe Assembler List > > From: "Keith Moe" > Sent: Tuesday, January 30, 2018 11:08 AM > > > > One of the downsides to such great optimization is the added > difficulty in debugging. > > Such optimisations are rarely requested during debugging, > when all the facilities of the compiler - such as subscript bounds checking, > check for uninitialized variables, etc, are employed. > > > Programs will often have code that leaves footprints and saves > various values > > in work areas for diagnostic reasons. > > They might, but at run time, should an error occur in a PL/I program > the error-recovery unit can print the values of any requested variables. > > Also, for diagnostic purposes (either during debugging or during production), > values can be written to a file. > > > Many optimization algorithms will detect > > that these area are "never referenced" after being set and eliminate > > the code that sets or stores these values. > > See previous note. > > > Another optimization that makes debugging difficult is the > inlining of subroutines > > that are only called in one place to save the overhead of the linkage. > > But the generated mapping of the source to the generated machine > code/assembler > > does not match the original source statements to the generated machine code. > > I suppose it is possible, but the PL/I optimising compilers clearly > show where any moved code is placed. This is shown in the > assembler listing. > > > Sure, there are various tricks that can be done to prevent such > optimization, > > Such as not requesting optimising. > > > but that partially defeats the value of using a high level > language when you have to think about > > how to defeat it. > > > When you spend a lot of time debugging problems occurring in > customer production environments, > > life can be difficult. > > See earlier note about printing values from the error-recovery unit. > > > Optimization is great until it isn't! > > Keith Moe > Lead Developer > BMC Software, Inc. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >
Re: Fair comparison C vs HLASM
Much of MVS is written in a compiled language (PL/X and its predecessors), and I have spent the past 38 years making a living by debugging it using dumps. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List wrote on 02/01/2018 09:03:37 AM: > From: Charles Mills > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 02/02/2018 01:00 AM > Subject: Re: Fair comparison C vs HLASM > Sent by: IBM Mainframe Assembler List > > > The last time I used a dump to find bugs in a compiled program was > about 35 years ago. > > Right! I think if you are using a classic "core dump" to find logic > errors in a compiled language program then you are doing something wrong. > > To find an error in some big table or something, sure, but then the > arrangement of the compiled machine instructions should not matter. > > Charles > > > > On Wednesday, January 31, 2018 1:00 AM, Robin Vowels > wrote: > > ... > > The last time I used a dump to find bugs in a compiled program was > about 35 years ago. > PL/I provides all the information required because it has debugging > facilities built in. >
Re: Fair comparison C vs HLASM
From: "Paul Raulerson" Sent: Friday, February 02, 2018 12:55 AM And as already been noted, C was first compile on a PDP-7, which had a simple instruction set but was most definitely a CISC machine too. ;) It also explains one of the reasons why strings in C are null terminated. There were two modes of thought back in those days, ‘Pascal’ strings, which have the string size encoded in a single byte at the start of the string, and ‘C’ strings, which terminate a string with a NULL. And PL/I strings, which used a descriptor in which the length up to 32767 was specified. Pascal string length was obviously limited by the max value of a byte - The length was not embedded in the langage; it was an arbitrary limit imposed by the implementer. They could have, for example, used 2 bytes at the start of the string. null terminated strings could be just about any possible size. Yes, but with two disadvantages -- 1. if you wanted to know the length of the string, it was necessaary to search the entire string. 2. A byte of zero could not be part of the string -- completely useless when processing arbitrary data (such as image data, and compressed data). Record eliminators of course, are an entirely different thing, but a C string could easily be a few thousand bytes long. Handy indeed for things like text processing, which is what the AT&T guys were selling Unix and C to their bosses for. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
> On Feb 1, 2018, at 1:10 PM, Paul Gilmartin
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
>
>> With bash you can handle multiple pipes at once without explicit named
>> pipes ("process redirection"),
>>
> Also Korn Shell. I'm aware of the construct; I haven't mastered
> it -- I try to stay in POSIX for portability. But does it have
> the flexibility of either C or CMS Pipelines? I could wish
> /bin/sh had the equivalent of Rexx "SYSCALL pipe" (sort of like
> ADDPIPE/ADDSTREAM).
>
> Interestingly, while z/OS shell indicates syntax error on an
> attempted process redirection, it reports with a unique message.
> Apparently the authors were aware but chose not to implement it.
>
Huh - may not know what I am talking about here, but any C program on a *nix
variant, like AIX, can open and handle as many pipes as you want. STDIN/STDOUT
is
just one set, and you can reopen them as many times as you want.
Timing is usually done with signal and/or semaphores - or better yet with
message
queues. :)
Re: Fair comparison C vs HLASM
On 1 February 2018 at 20:10, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
>
> > and you can also get a completion statusarray ("PIPESTATUS[i]")
> > from a multi-stage pipe.
> >
> Valuable indeed. I often wish for it. (How would I do that
> with CMS Pipelines?
>
I'm not deep enough in UNIX to know, and I'm not sure oranges and bananas
compare, but it sounds like 'streamstate all' is where you look.
It's mostly useful to write stages that behave differently when some
streams are not connected (but it's just a matter of time before I regret
such design).
Even more subtle is when you act on relative timing differences between
streams (like arrival of a new key on the secondary of a cipher stage). I
don't see an analogy with buffered streams.
Sir Rob the Plumber
Re: Fair comparison C vs HLASM
On 2018-02-01, at 10:28:47, Kirk Wolf wrote:
> With bash you can handle multiple pipes at once without explicit named
> pipes ("process redirection"),
>
Also Korn Shell. I'm aware of the construct; I haven't mastered
it -- I try to stay in POSIX for portability. But does it have
the flexibility of either C or CMS Pipelines? I could wish
/bin/sh had the equivalent of Rexx "SYSCALL pipe" (sort of like
ADDPIPE/ADDSTREAM).
Interestingly, while z/OS shell indicates syntax error on an
attempted process redirection, it reports with a unique message.
Apparently the authors were aware but chose not to implement it.
> and you can also get a completion statusarray ("PIPESTATUS[i]")
> from a multi-stage pipe.
>
Valuable indeed. I often wish for it. (How would I do that
with CMS Pipelines?
> Pity there is no z/OS
> port of bash that supports local spawn, which is important in many cases.
>
True.
> On Thu, Feb 1, 2018 at 10:12 AM, Rob van der Heij wrote:
>
>> On 1 February 2018 at 16:40, Paul Gilmartin wrote:
>
> On Thu, Feb 1, 2018 at 10:12 AM, Rob van der Heij wrote:
>>
>>
with a multi-stream pipeline topology ...
>>>
>>> That restriction is a myth. C programs can deal with multi-stream
>>> pipe topologies. In shell that requires named pipes.
>>
>> Because CMS Pipelines does not buffer the data, the flow of records in
>> different segments of the pipeline is predictable. Without that, even
>> simple plumbing does not work as I would expect.
>>
I agree.
>> With named pipes you have a bunch of programs using each others output, and
>> you don't really care when they do it.
>>
You might want to care; you just aren't allowed to.
-- gil
Re: Fair comparison C vs HLASM
With bash you can handle multiple pipes at once without explicit named
pipes ("process redirection"), and you can also get a completion status
array ("PIPESTATUS[i]") from a multi-stage pipe. Pity there is no z/OS
port of bash that supports local spawn, which is important in many cases.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Feb 1, 2018 at 10:12 AM, Rob van der Heij wrote:
> On 1 February 2018 at 16:40, Paul Gilmartin <
> 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
>
> > > with a multi-stream pipeline topology ...
> >
> > That restriction is a myth. C programs can deal with multi-stream
> > pipe topologies. In shell that requires named pipes.
> >
>
> Because CMS Pipelines does not buffer the data, the flow of records in
> different segments of the pipeline is predictable. Without that, even
> simple plumbing does not work as I would expect.
> With named pipes you have a bunch of programs using each others output, and
> you don't really care when they do it.
>
> Rob
>
Re: Fair comparison C vs HLASM
On 1 February 2018 at 16:40, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > with a multi-stream pipeline topology ... > > That restriction is a myth. C programs can deal with multi-stream > pipe topologies. In shell that requires named pipes. > Because CMS Pipelines does not buffer the data, the flow of records in different segments of the pipeline is predictable. Without that, even simple plumbing does not work as I would expect. With named pipes you have a bunch of programs using each others output, and you don't really care when they do it. Rob
Re: Fair comparison C vs HLASM
On 2018-02-01, at 02:33:03, Rob van der Heij wrote: > > Indeed, traditional CMS programs all have their own logic to identify data > sources, though we can access Shared File System directories as if it were > a mini disk and have most programs handle the data there. Exploitation of > FILEDEF and NAMEDEF is minimal, as far as I know. > Too few classic CMS programs have interfaces as pipeline connections; too often such wheels must be reinvented in a pipeline stage. Too few classic CMS programs access SFS files directly; the SFS directory must be ACCESSed as a drive letter. I's painful to run out of drive letters. How do classic CMS programs deal with BFS files? In z/OS, UNIX files can be ALLOCATEd to DDNAMEs with JCL or with DYNALLOC. > CMS Pipelines allows programs to be chained together like stdin and stdout > let you do on UNIX. It comes with a suite of efficient built-in programs > and provides a programming framework to write your own (REXX) programs > operate on input and output streams. CMS Pipelines goes beyond UNIX pipes > with a multi-stream pipeline topology ... > That restriction is a myth. C programs can deal with multi-stream pipe topologies. In shell that requires named pipes. > ... and coordinated error handling to > Very true. But a C program (not shell) can get completion status from individual pipe stages. > write real world applications with pipes. > https://en.wikipedia.org/wiki/CMS_Pipelines -- gil
Re: Fair comparison C vs HLASM
-Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal; they came later with, e.g. UCSD. Too true -- Wirth's Pascal was useless for any real work. Character arrays only. UCSD Pascal had strings and async block I/O. Coming from the mainframe, I really liked that. Pieter --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 2018-02-01, at 06:55:29, Paul Raulerson wrote: > > It also explains one of the reasons why strings in C are null terminated. > There were two modes of thought back in those days, ‘Pascal’ strings, which > have the string size encoded in a single byte at the start of the string, and > ‘C’ strings, which terminate a string with a NULL. > > Pascal string length was obviously limited by the max value of a byte ... > Who made that moronic "single byte" rule!? o It should be two pointers, first byte and last byte + 1. o And having the length contiguous meant that substrings could not be created without copying. It's startling how difficult it can be to shift paradigm beyond "two modes of thought" and invent another. BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal; they came later with, e.g. UCSD. -- gil
Re: Fair comparison C vs HLASM
RISC comes along late in the game. Think about it: REDUCED instruction set. Reduced from what? Reduced from the standard sort of design at the time. The relative history is pretty easy to sort out: "C was originally developed by Dennis Ritchie between 1969 and 1973 at Bell Labs" -- https://en.wikipedia.org/wiki/C_(programming_language) "Michael J. Flynn views the first RISC system as the IBM 801 design which began in 1975 by John Cocke, and completed in 1980." -- https://en.wikipedia.org/wiki/Reduced_instruction_set_computer (Who the heck is Michael J. Flynn? "He was the founding chairman of IEEE Computer Society's Technical Committee on Computer Architecture (TCCA) and Association for Computing Machinery's Special Interest Group on Computer Architecture, ACM SIGARCH (initially SICARCH).") Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robin Vowels Sent: Thursday, February 1, 2018 12:26 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Fair comparison C vs HLASM From: "Jon Perryman" Sent: Wednesday, January 31, 2018 3:19 PM >> Robin Vowels wrote: > >> And I understand that RISC processors came long after C. > > C was developed on a PDP-11. I believe that the PDP-11 was a RISC machine. > Even so, I think it had byte instructions. The PDP-11 was NOT a RISC computer, it was a CISC (Complex Instruction Set Computer). It had a variety of instruction formats, and various instruction lengths. RISC computers are characterised by instructions of a fixed length, each of which can be executed in a fixed amount of time. The various stages of the instruction fetch and execute cycle can be overlapped with other instructions. This genre (RISC) was not developed until many years later.
Re: Fair comparison C vs HLASM
> The last time I used a dump to find bugs in a compiled program was about 35 > years ago. Right! I think if you are using a classic "core dump" to find logic errors in a compiled language program then you are doing something wrong. To find an error in some big table or something, sure, but then the arrangement of the compiled machine instructions should not matter. Charles > On Wednesday, January 31, 2018 1:00 AM, Robin Vowels > wrote: ... The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in.
Re: Fair comparison C vs HLASM
And as already been noted, C was first compile on a PDP-7, which had a simple instruction set but was most definitely a CISC machine too. ;) It also explains one of the reasons why strings in C are null terminated. There were two modes of thought back in those days, ‘Pascal’ strings, which have the string size encoded in a single byte at the start of the string, and ‘C’ strings, which terminate a string with a NULL. Pascal string length was obviously limited by the max value of a byte - null terminated strings could be just about any possible size. Record eliminators of course, are an entirely different thing, but a C string could easily be a few thousand bytes long. Handy indeed for things like text processing, which is what the AT&T guys were selling Unix and C to their bosses for. -Paul > On Feb 1, 2018, at 2:26 AM, Robin Vowels wrote: > > From: "Jon Perryman" > Sent: Wednesday, January 31, 2018 3:19 PM > > >>> Robin Vowels wrote: >>> And I understand that RISC processors came long after C. >> C was developed on a PDP-11. I believe that the PDP-11 was a RISC machine. > >> Even so, I think it had byte instructions. > > The PDP-11 was NOT a RISC computer, it was a CISC (Complex Instruction Set > Computer). > > It had a variety of instruction formats, and various instruction lengths. > > RISC computers are characterised by instructions of a fixed length, > each of which can be executed in a fixed amount of time. > The various stages of the instruction fetch and execute cycle can be > overlapped > with other instructions. > > This genre (RISC) was not developed until many years later. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On Wed, 31 Jan 2018 15:41:11 +, Martin Ward wrote: >gdb can analyse a core dump from an optimised program: >providing a backtrace, allowing examination of variable values >and linking executable code to source code line numbers. gdb can analyze a SYSMDUMP or SVCDUMP? It is hard to imagine that it knows enough about MVS structures to be of much use. -- Tom Marchant
Re: Fair comparison C vs HLASM
On Wed, 31 Jan 2018 10:25:40 -0600, Mark Hammack wrote: >While it >is difficult to find C/C++ programmers coming out of college, it is all but >impossible to find anyone using or willing to train to use HLASM. But we >can find Java programmers all day long. Over the last few years, we have hired well over a dozen new college graduates and trained them to use assembler. -- Tom Marchant Compuware
Re: Fair comparison C vs HLASM
On 29 January 2018 at 20:16, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2018-01-29, at 11:55:56, Seymour J Metz wrote: > > > While the DOS I/O was very device dependent, there was the DTFDI with > limited device independence. > > > Insofar as "device independence" means restricting every device > type to the capabilities of a card reader/punch. > > CMS is similarly limited. Pipelines adds some flexibility. > > I knew we could drag this on into February ;-) Indeed, traditional CMS programs all have their own logic to identify data sources, though we can access Shared File System directories as if it were a mini disk and have most programs handle the data there. Exploitation of FILEDEF and NAMEDEF is minimal, as far as I know. CMS Pipelines allows programs to be chained together like stdin and stdout let you do on UNIX. It comes with a suite of efficient built-in programs and provides a programming framework to write your own (REXX) programs operate on input and output streams. CMS Pipelines goes beyond UNIX pipes with a multi-stream pipeline topology and coordinated error handling to write real world applications with pipes. https://en.wikipedia.org/wiki/CMS_Pipelines When you write your business logic as a pipeline (even when done as monolithic piece of procedural REXX logic) the same logic can be used independent of where the data resides. This is also convenient during development and testing of applications because you don't have to run the logic against some test data or capture intermediate results of the process. And if you have CMS Pipelines on z/OS, you can run the same business logic there and just provide a small wrapper to identify the data sources. Sir Rob the Plumber
Re: Fair comparison C vs HLASM
From: "Glen" To: Sent: Thursday, February 01, 2018 3:10 AM Subject: Re: Fair comparison C vs HLASM The 360/20 has MVC and CLC, but, strangely, not LR. The model 20 was not strictly of the 360 family. (You can use SR and AR instead, so no need for LR.) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Thursday, February 01, 2018 1:49 AM On Wednesday, January 31, 2018 1:00 AM, Robin Vowels wrote: From: "Keith Moe" Sent: Tuesday, January 30, 2018 11:08 AM Keith Moe wrote: One of the downsides to such great optimization is the added difficulty in debugging. Robin Vowels wrote: Such optimisations are rarely requested during debugging, when all the facilities of the compiler - such as subscript bounds checking,> check for uninitialized variables, etc, are employed. Keith is talking about dump analysis. Perhaps. But even if he was, the link map and assembly listing deals with that issue. However, as I said, optimising is not usually requested during debugging. Think of optimization as a chaotic programmer. The stronger the optimization, the more chaos. The best optimization will often make following the machine logic very difficult. The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, January 31, 2018 3:48 PM On 2018-01-30, at 21:17:05, Robin Vowels wrote: On 31/01/2018 3:27 AM, Jon Perryman wrote: Exactly my point. I suspect that the C group considered Null-terminated strings cost exactly the same as fixed length fields. ... But if you just want the length, a fixed-length string wins. In PL/I, a varying-length string also wins, because the current length is kept with descriptor, so it isn't necessary to search through the string in order to find the end. And strings with descriptors (address, length) make it easy to define substrings. Just create a new descriptor. A C partisan once told me, just save a character, overlay it with a NUL, then put it back when you're done with the substring. I've used a language that defined substrings by creating descriptors, then handled garbage collection properly -- any byte not governed by one or more descriptors was subject to reclaim. That is how strings are implemented in XPL (from c. 1966). A substring was obtained by merely pointing a descriptor at the first character ; the required number of characters being inserted in the descriptor. No characters of the string were moved. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Wednesday, January 31, 2018 3:19 PM Robin Vowels wrote: And I understand that RISC processors came long after C. C was developed on a PDP-11. I believe that the PDP-11 was a RISC machine. Even so, I think it had byte instructions. The PDP-11 was NOT a RISC computer, it was a CISC (Complex Instruction Set Computer). It had a variety of instruction formats, and various instruction lengths. RISC computers are characterised by instructions of a fixed length, each of which can be executed in a fixed amount of time. The various stages of the instruction fetch and execute cycle can be overlapped with other instructions. This genre (RISC) was not developed until many years later. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On Wed, Jan 31, 2018 at 10:22 AM, Glen wrote:
>
>> I think I at least somewhat understand what he means.
> It occurred to me some time ago, that there is no C library
> routine to do what MVCIN does. Not that it is hard to do,
> but there just isn't one. I doubt many compilers compile
> the appropriate for loop into MVCIN.
>
> There are some interesting "hardware built-in functions" in z/OS XLC/C++
that cover many interesting instructions, but MVCIN didn't make the cut.
(BTW: MVCIN is an instruction that I will *never* forget, and not because
I've actually used it before. :-)
Its possible to roll your own using the "__asm" inlining support, which now
works in C, Metal C, and C++.
The syntax for using this is as wacky as HLASM macros, but I think that
this is right for MVCIN:
static void
HW_MVCIN(unsigned char* dest, unsigned char* src, unsigned char len) {
__asm (
" BRU *+10\n"
" MVCIN 0(*-*,%0),0(%1)\n"
" BCTR %2,0\n"
" EXRL %2,*-8\n"
: :
"a"(dest),
"a"(src),
"r"(len));
}
The compiler will inline this in the calling function if it can and decides
that it should.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
PS> Of course, you would start with the following and forget it until you
found that you actually need to tune it in the context of what you are
doing:
void memcpy_reversed(char *dest, char *src, size_t len)
{
src = src + len - 1; /* last character */
while (len--)
*dest++ = *src--;
}
If you compile this with full optimization and look at the generated
assembly, you will find a fancy unrolled loop.
Who knows if MVCIN is any faster? It certainly won't handle len>256 cases.
Re: Fair comparison C vs HLASM
Well, perhaps I should have written *limited* instead of limited. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, January 29, 2018 2:16 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On 2018-01-29, at 11:55:56, Seymour J Metz wrote: > While the DOS I/O was very device dependent, there was the DTFDI with limited > device independence. > Insofar as "device independence" means restricting every device type to the capabilities of a card reader/punch. CMS is similarly limited. Pipelines adds some flexibility. -- gil
Re: Fair comparison C vs HLASM
One point to keep in mind about hand-optimized code is that what makes it run faster on one processor might make it run slower on another. You're better of worrying first about readability and maintainability, then about efficient algorithms and only last about efficiency. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Gord Tomlin Sent: Tuesday, January 30, 2018 12:59 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On 2018-01-30 12:33, Kirk Wolf wrote: > My favorite comments related to this subject came from Dave Cole on the > Assembler-List last October, which I will re-post below because it deserves > more bits of storage. Kirk, I was sorely tempted over the last few days to dig out this gem and post it. It's very instructive to read the HLASM code generated by the compilers when optimization is in effect. Attempting to achieve the same level of pipeline and cache friendliness, etc., when hand-writing HLASM is a big chore and a definite impediment to programmer productivity. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: Fair comparison C vs HLASM
No language encourages good coding practices. You want good coding, start with good training and good management. A bad language, e.g., C, can make it harder, but a good language does not suffice in the absence of other factors. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Martin Ward Sent: Wednesday, January 31, 2018 1:59 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On 28/01/18 06:07, Jon Perryman wrote: > For large complicated problems, assembler is the language of choice. For large complicated problems a domain-specific language, targeted at the problem domain, is the language of choice. At least, according to the theory of "Language Oriented Programming": see the paper with that title published in Software--Concepts and Tools, Volume 15 (4), pp 147-161, 1994 http://www.gkc.org.uk/martin/papers/middle-out-t.pdf Other than utilities which need to dive into the guts of the operating system, I am not sure if there are any domains for which assembler is the ideal language: but I am not personally familiar with all the various problem domains of conmputing. For the XML parsing problem, perl and the XML::Parser package would appear to be a good choice. It offers a choice of parsing methods: Debug: just prints out the document in outline form Subs: call the appropriately named subroutines for each element Tree: return a parse tree Objects: like Tree but creates a hash object for each element Stream: call callback routines at various points > There are certainly features that would be nice in ASM but a good > optimizing language doesn't make up for a language that encourages > good coding practices (e.g. XML parse). Does assembler encourage good coding practices? I am not asking "is it possible to write programs using good coding practices in assembler", but rather "does learning to code in assembler automatically encourage programmers to use good coding practices?" In theory, this seems to be unlikely. Learning to code in assembler involves thinking of a program as a sequence of "instructions" to be executed by a "machine". This encourages the creation of spaghetti code consisting of a mass of labels and branches. When the programmer learns about structured macros, they will have to unlearn their original unstructured coding style. Very few organisations enforce the use of structured macros, but much of the benefit of structured macros is lost if they are mingled with unstructured branches. In practice, I have analysed some tens of millions of lines of assembler (as part of my research, and working for Software Migrations Ltd), and "good coding practices" appear to be extremely rare. Some examples from a recent study (presented at the GSE UK Conference in 2016): US State Government Department: 870,000 LOC Bugs Detected: 550 per MLOC (Million Lines Of Code) Self-Modifying Code: 2,347 per MLOC Complex Subroutine Linkage: 74% of modules Non-Standard Module Linkage: 60% of modules Large Insurance Company: 1.8 million lines of code Bugs Detected: 274 per MLOC Self-Modifying Code: 590 per MLOC Complex Subroutine Linkage: 37% of modules Non-Standard Module Linkage: 14% of modules Human Resource Company (Payroll Systems): 350,000 lines of code Bugs Detected: 302 per MLOC Self-Modifying Code: 127 per MLOC Complex Subroutine Linkage: 53% of modules Non-Standard Module Linkage: 78% of modules Here "Complex Subroutine Linkage" includes any unstructured subroutine code, eg branching out of the middle of a subroutine into main code or another subroutine, subroutines with multiple entry points or multiple exit points, and so on. Non-Standard Module Linkage includes any module calls which do not use the standard calling convention. For example, passing parameters in random registers, returning to an offset of the return address, passing parameters as inline data, and so on. "Progress will only be achieved in programming if we are willing to temporarily fully ignore the interconnection between our programs (in textual form) and their implementation as executable code... ... In short: for the effective understanding of programs, we must learn to abstract away from the existence of computers." -- Edsgar W. Dijkstra -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
