CDS is an example of something more sophisticated than C statements, but even on the S/360 there were instructions like TRT.
I'm not sure whether ++ and -- came from the PDP-11 or from the earlier PDP-7/PDP-9. A decent compiler would have optimized x=x+1 and x=x-1 to utilize the increment and decrement features of those machines without having to add them to the language. If you know VAX assembler, a great deal is missing from C. The "good reason" is that they were using a machine with a small memory. A large subroutine library is no substitute for a good macro facility. It can be argued that the 650 was a more powerful machine than the 7030, but will anybody believe the argument? "Must have missed the DEC PDP and VAX line..." Close but no cigar. The C preprocessor is also grossly inferior to, e.g., Macro-11. E Unibus plurum. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Paul Raulerson <[email protected]> Sent: Wednesday, January 24, 2018 11:54 PM To: [email protected] Subject: Re: Fair comparison C vs HLASM > On Jan 24, 2018, at 10:14 AM, Seymour J Metz <[email protected]> wrote: > > Like many old sayings, it's worth what you paid for it. The z instruction set > includes operations far more powerful than anything in C, and the lack of a > Turing complete macro language makes C highly inflexible. > I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language? Not that they are exactly comparable to be honest, but curiosity gets the better of me here. The C language was actually modeled on the PDP-11 instruction set, and designed to make writing programs on a very rudimentary UNIX possible. Check out the AT&T Bell Laboratories Technical Journal, October 1984, Vol 63, No 8., Part 2 for just tons and tons of interesting details about that. But long and short, if you know PDP-11 or VAX assembler, a great deal of the C language is very familiar to you. That happened in about 1972. In 1973, the entire kernel for the then new Unix operating system was rewritten in C. To this day, the greatest part of any UNIX or UNIX derived kernel is still written in C, and it works just fine as a system programming language. As for Macros, well, C macros are generally much simpler than HLASM, though with good reason. Most of the functionality embedded in Macros off HLASM is provided by the standard C libraries. Want to open a file? It is the same call on just about any platform. The c libraries are specific to each platform. Want to cross compile for a totally different platform? Easy peasy, just add a flag into the compile indicating the platform. And so on and so on. I think it can be argued that the c library provides a complete, and easily extended or modified equivalent of HLASM macro processing. Now, when you get into modern C with typing and so many other built in libraries, you can *still* make an argument. :) But the most probably truth is that C is far more efficient to program in than HLASM. A few years ago, a friend of mine declared he could write anything faster than the GCC C compiler, and his program would run faster. Oh, I couldn’t resist… I asked him to write a program to add 1 to a value 100 million times then print out the answer. He dived in and wrote a sweet little assembler program, assembled and linked it (under z/Linux) and it ran like greased lightening. Of course, the C compiler took this: #include <stdio.h> int main(int argc, char *argv[]) { int c=0; int x=0; for (x=0; x< 100000000; x++) { c++; } printf ("\nThe final value is [%d]\n", c); } and optimized it during compile time. In fact it optimized it so much it simply generated a LHI of a register with 100000000 in it. (grin) Needless to say, it ran somewhat faster than my friend’s program. Even counting the screen print. :) > C may be similar to SOAP 2 on the 650; it's certainly not similar to any > assembler that I used in the last half century. Must have missed the DEC PDP and VAX line... > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Assembler List <[email protected]> on > behalf of Martin Ward <[email protected]> > Sent: Tuesday, January 23, 2018 4:26 PM > To: [email protected] > Subject: Re: Fair comparison C vs HLASM > > There is an old saying "C combines the power of assembly language > with the flexibility of assembly language": the point being > that C as a language is very close to assembly language. > > C has few of the powerful abstraction features found in modern > programming languages: automated memory allocation and > garbage collection, first class functions, higher order functions, > closures, hash tables, abstract data types and so on. > > C and HLASM both have support for basic, low-level programming > features such as prodecure calls, conditional statements > and while/repeat loops. Both require the programmer to express > their code at a very low level: "close to the metal". > > The main advantage of C over HLASM is that C has an optimising compiler. > If performance is of ultimate importance (and why would anyone > use such low-level languages otherwise?) then the C compiler > can automatically provide register allocation, loop unrolling > and procedure inlining where heuristics indicate these > transformations will improve performance. > > A good assembler programmer might make reasonable choices > for register allocation on first writing the program: > but will they be willing to recalculate a new register > allocation after each addition or modification to the program? > Will they choose to write optimal, but unstructured > and unmaintainable spaghetti code or readable but > less efficient structured code? With a compiler, > the programmer can write structured code and allow > the optimiser to apply common subexpression elimination, > pointer chasing, loop unrolling, procedure inlining, > and so on, creating mode efficient code which would be > unmaintainable if it had been written that way > in the first place. > > Finally, modern C compilers, such as gcc, can perform > whole program optimisation, applying interprocedural > optimisation to all functions and variables, including > statically-linked libraries. > > -- > Martin > > Dr Martin Ward | Email: [email protected] | http://www.gkc.org.uk > G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
