Re: Fair comparison C vs HLASM

://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> Sent: Sunday, February 11, 2018 7:18 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C

Re: Fair comparison C vs HLASM

n > behalf of Paul Raulerson <paul.rauler...@me.com> > 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 length

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

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

Re: Fair comparison C vs HLASM

Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> 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 stri

Re: Fair comparison C vs HLASM

://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> Sent: Saturday, February 10, 2018 12:14 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair com

Re: Fair comparison C vs HLASM

Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" <sme...@gmu.edu> 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

Re: Fair comparison C vs HLASM

wing it selectively. Use it in each procedure, on entry. From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Robin Vowels <robi...@dodo.com.au> Sent: Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga

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

Re: Fair comparison C vs HLASM

From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Bernd Oppolzer <bernd.oppol...@t-online.de> Sent: Thursday, February 8, 2018 4:02 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM All the instructions mentione

Re: Fair comparison C vs HLASM

.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> 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 op

Re: Fair comparison C vs HLASM

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

Re: Fair comparison C vs HLASM

listserv.uga.edu> on > behalf of Paul Raulerson <paul.rauler...@me.com> > 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 <robi...@dodo.com.au>

Re: Fair comparison C vs HLASM

behalf of Paul Raulerson <paul.rauler...@me.com> 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 <robi...@dodo.com.au> wrote: From: "Bernd Oppolzer" <bernd.oppo

Re: Fair comparison C vs HLASM

Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Paul Raulerson <paul.rauler...@me.com> 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 <robi...@dodo.com.au> wr

Re: Fair comparison C vs HLASM

stserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" <sme...@gmu.edu> 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 p

Re: Fair comparison C vs HLASM

] 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

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

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

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

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

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.

Re: Fair comparison C vs HLASM

t; 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" <sme...@gmu.edu> Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat

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

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.

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

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

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

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

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

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"

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.

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

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

Re: Fair comparison C vs HLASM

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

Re: Fair comparison C vs HLASM

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

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

Re: Fair comparison C vs HLASM

Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Charles Mills <charl...@mcn.org> 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 i

Re: Fair comparison C vs HLASM

rchie.mck...@gmail.com> 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 <charl...@mcn.org> wrote: > I am no expert but are there not "better" (FSVO better, of co

Re: Fair comparison C vs HLASM

edu> on behalf of Charles Mills <charl...@mcn.org> 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 go

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.

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

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

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

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

Re: Fair comparison C vs HLASM

) 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

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

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

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

Re: Fair comparison C vs HLASM

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 <jperr...@pacbell.net> wrote: > >> Jon Perryman wrote: > >> For large complicated problems, assembler is the languag

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 <

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,

Re: Fair comparison C vs HLASM

n 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

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

Re: Fair comparison C vs HLASM

. 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: &g

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

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

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

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

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

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

Re: Fair comparison C vs HLASM

IST@listserv.uga.edu> on behalf of Robin Vowels <robi...@dodo.com.au> Sent: Thursday, February 1, 2018 4:02 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Jon Perryman" <jperr...@pacbell.net> Sent: Thursday, February 01, 2018 1:49 AM > O

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.

Re: Fair comparison C vs HLASM

.au> Sent: Thursday, February 1, 2018 10:09 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Paul Raulerson" <paul.rauler...@me.com> Sent: Friday, February 02, 2018 12:55 AM > And as already been noted, C was first compile on a PDP-7, wh

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)

Re: Fair comparison C vs HLASM

<ASSEMBLER-LIST@LISTSERV.UGA.EDU> wrote on 02/01/2018 09:03:37 AM: > From: Charles Mills <charl...@mcn.org> > 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 <A

Re: Fair comparison C vs HLASM

nt: 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 doc

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:

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

Re: Fair comparison C vs HLASM

IST@LISTSERV.UGA.EDU> wrote on 01/31/2018 04:03:34 AM: > From: Robin Vowels <robi...@dodo.com.au> > 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 <ASSEMBLER-LIST@LISTSERV.

Re: Fair comparison C vs HLASM

IST@LISTSERV.UGA.EDU> wrote on 02/01/2018 09:03:37 AM: > From: Charles Mills <charl...@mcn.org> > 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 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> &

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

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

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.

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

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

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

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

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

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’

Re: Fair comparison C vs HLASM

: 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" <jperr...@pacbell.net> Sent: Wednesday, January 31, 201

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

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

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

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

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

Re: Fair comparison C vs HLASM

From: "Glen" <g...@ugcs.caltech.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> 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

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

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

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

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

Re: Fair comparison C vs HLASM

marc-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 indep

Re: Fair comparison C vs HLASM

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

Re: Fair comparison C vs HLASM

From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Martin Ward <mar...@gkc.org.uk> 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,

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

Re: Fair comparison C vs HLASM

On 01/31/2018 11:39 AM, Robin Vowels wrote: On 31/01/2018 2:53 PM, Paul Gilmartin wrote: On 2018-01-30, at 21:21:49, Robin Vowels wrote: The MVC and CLC instructions of the IBM /360 came years before Unix and C. ... and were available on all but the most primitive S/360 models. The 360

Re: Fair comparison C vs HLASM

On 2018-01-31, at 06:11:29, Jonathan Scott wrote: > Ref: Your note of 31 January 2018, 07:49:38 EST > > The MVST (move string) instruction provides the appropriate primitive to > implement strcpy() and strncpy(), and became available in the 390 > string-instruction facility at the same time as

Re: Fair comparison C vs HLASM

Robin Vowels <robi...@dodo.com.au> Sent: Wednesday, January 31, 2018 11:39 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM On 31/01/2018 2:53 PM, Paul Gilmartin wrote: > On 2018-01-30, at 21:21:49, Robin Vowels wrote: >> >> The MVC and CLC instru

Re: Fair comparison C vs HLASM

Thought I'd throw my $.02 in. In the mid 80's I was on the decision team that transitioned from Z80 assembler to C. Why? It was easier to train 30 people in C than it was to train them in 8086 assembler. At the time, the rest of the shop was primarily using Assembler-H. A couple of years

  1   2   3   >