> On Jan 25, 2018, at 1:43 PM, Seymour J Metz <[email protected] > <mailto:[email protected]>> wrote: > > CDS is an example of something more sophisticated than C statements, but even > on the S/360 there were instructions like TRT.
TRT has to be one of the most elegant instructions anyone ever thought up. I love it, but you still have to build the translation table. You have to build one in C too, so far as I know. The actual code in C is two or three lines, so yes, I would easily concede that TRT is more sophisticated than C code. ;) > 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. PDP-7. > > If you know VAX assembler, a great deal is missing from C. (grin) > > 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? > I thought it was something like that. Thanks! > "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. I think every Macro processor - at least until you get to SGML and up - is grossly inferior to Macro-11. To make up for it though, Macro-11 can be pretty impenetrable to figure out if you don’t work with it regularly! :) -Paul > > -- > 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
