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 there are more than 10 manuals DEDICATED to HLASM macro's (MVS services, MVS auth services, DFP, RACF, JES2, TSO and more)? 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. I must repeat, MVS would not exist without IBM ASM. Many of the technologies in UNIX evolved from z/OS. I've worked on and written products in IBM ASM that would not be maintainable in C (or almost every other language). The features from ASM should be integrated into other languages (e.g. Cobol). > Kirk Wolf wrote: > I would have thought that this kind of argument about the relative benefits > of assemblers vs compilers (or assembler vs C) would have been over a > couple of decades ago. Sadly, you can't always trust C programmers (look up "motivated reasoning"). They need C to be the best language. Just because C does the job doesn't mean it does it well. Here are real facts (not factless facts). I knew C didn't compete well with IBM ASM but now It's clear that C is the poor man's attempt at PLX. IBM (not management) gets bashed by C programmer's thru absolutely false accusations. PL/X is similar to C except that PL/X does it far better. E.g. PL/X generate allows you to truly integrate as much ASM as needed and able to reference data without all the confusing C definitions. Dave Cole's document is more relevant to C as to ASM or PL/X. Many C programs should have been written in a high level language. C programmers are the same as ASM programmers. Why maintain a duplicate DSECT's (C structs) in another language when you can just code it in the same language. PL/X doesn't have the DSECT issue. Many C programmers are so vested in C that they can't see the language for what it is. Apparently so much so that no matter how much proof, they will ignore the real facts. I'm not vested in ASM will readily admit it has many flaws. I will use any language that get's the job done and is maintainable. I've programmed a robot using 5 different languages at the same time. Switching languages it not too bad when you work in a single language for a few hours. On the other hand, Bouncing between languages can be very frustrating. I have no fear of programming in other languages and judge those languages based on their merit. Not on what I want to believe. 1. 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. 2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A)). In fact, several of the C standard functions have matching z instructions (or a few). What is the difference in using a C standard function or a zArch instruction? What is the real difference between a hand coded HLASM program compared to C program when many of the standard functions match a z instruction? IBM could have implemented any of the standard C functions as zArch instructions. There are several standard functions that are only relevant to application programmers and compiler writers (e.g. when did we need trig functions). Why bother creating instructions that are purely application level. The point is there is not much difference in zArch instructions and the important C standard functions. They are both a choice about the types of problems to be solved. When the C standard changes, then more zArch instructions may need to be added. 3. >> Kirk Wolf wrote: For all of the supposed byte-by-byte C programmers How can a C programmer not understand that C is a byte oriented language? Apparently it's questionable. Programmers have functions that do multi-byte functions (e.g. memcpy() ). Why not mention all the byte functions (e.g. isNumber). He also forgot to mention that not using the language can only deal with bytes unless you play tricks (e.g. fullword). Mentioned were arrays which again is dealing in bytes. Arrays however do allow you to create a fixed length field. 4. >> Kirk Wolf wrote:. Compilers can generate machine instruction implementations that takeadvantage of the instructions and architecture available. "can" optimize? It's hilarious how much C programmers stress optimization. The C compiler better optimize because the coding style causes inefficient source. Benefits of optimization on z/OS is questionable. Does anyone have any stats on hand coded ASM versus the same logic in optimized C? C optimization is incredibly important on platforms with very little or no hardware acceleration. Certainly compilers on z can make choices that operate better on the hardware but will it be as significant as other hardware. The terms for optimization mentioned before seem to be more relevant on other hardware. 5. >> Kirk Wolf wrote: repeated assertion that it means something significant that C was originally developed on a RISC machine ( I believe that it was a PDP-7) Mentioning RISC was not an assertion. It was an attempt to find out why and what was the reasoning. PDP-7 had a small set of instructions even including complex instructions. many of the characteristics of C look as if they matched the hardware limitations. Why are there comparison functions rather than supporting it thru the standard comparison primitive (==)? Regards, Jon.
