Re: comparison C vs HLASM

From: "Jon Perryman" Sent: Tuesday, February 06, 2018 5:54 AM 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.

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 wer

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

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 pro

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(

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

Re: Pascal

From: "Martin Ward" Sent: Saturday, February 03, 2018 6:40 AM On 02/02/18 19:03, Paul Gilmartin wrote: On 2018-02-02, at 06:28:54, Martin Ward wrote: The original Pascal string used a single byte for the length at a time when a $70K machine had a mere 4K words of memory. I don't recall see

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

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

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 "everywher

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 bo

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 . Based on the principle of causing the mo

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/ Charl

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 t

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 > ___

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 Asse

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: ASSEMB

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:

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

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 ho

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

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 def

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 exagerati

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

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?

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

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-mat

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,

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

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 choic

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

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 easi

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 -Or

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

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 n

Re: Pascal

On Fri, 2 Feb 2018 19:40:41 +, Martin Ward wrote: >A typical CDC 6500 had 64K of 60 bit words (about 500kB) >and cost over $60 million in 2017 dollars. I suspect that >today $60 million will buy you a machine with over 500GB of RAM, >so the million-to-one ratio still holds. I'd be surprised i

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 wit