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 

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 

4. >> Kirk Wolf wrote:. Compilers can generate machine instruction 
implementations that takeadvantage of the instructions and architecture 

"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 

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.

Reply via email to