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