This is too funny. Profess the virtues of C and provide actual examples that
look like they prove the point but when scrutinized actually disprove it. When
I provided these type of examples, it was considered a gross exaggeration. C is
a mindset that is common. Here's the proof I'm not exagerating at all.
> Kirk Wolf wrote:
> If you compile this with full optimization and look at the generated
> assembly, you will find a fancy unrolled loop.
> Who knows if MVCIN is any faster? It certainly won't handle len>256 cases.
This statement would be funny if it weren't so sad. The "fancy" loop would be a
simple loop to move each byte where the second operand starts at the end.
"optimization" never recognized this as an MVCIN loop but it really optimized
the code it produced. MVCIN is obviously many times faster than a single byte
loop to move each character (how can this even be a question). Can anyone tell
us how many times faster MVC 256 bytes is than 256 MVC 1 byte? To really prove
C is superior, MVCIN is limited to 256 byte moves. Is he saying a loop moving 1
byte is better than a loop of 256 bytes?
This is "motivated reasoning" to the extreme. Every sentence saying C is great
and using factless facts to have you questioning the value of HLASM. It was
logic like this that slowed the debate decades ago.
> Kirk Wolf wrote that MVCIN can be used directly in C and provided the C
> example.
C strongly discourages embedding ASM and the following is a typical example
why. His example is how to use a single instruction (MVCIN) in C. Here is what
I think is the PL/X code to use MVCIN. The PL/X program would have DCL's for
"source" and "dest" and I don't think there is any special code needed to
reference them. I suspect MVCIN is like TRTR (also reverse) where op2 points to
the end of the field.
generate
mvcin dest,source+L'dest
endgen
Below is Kirk Wolf's example on using MVCIN in C (he's a C advocate). Compare
it with the PL/X example and tell me I've been exaggerating. It's missing the
"+L'dest" which would make it more complicated. Make it into a loop like the C
code mentioned above and it becomes even more complicated. Replace the *+10 and
*-8 with labels for good coding practices and make it even more chaotic.
static void
HW_MVCIN(unsigned char* dest, unsigned char* src, unsigned char len) {
__asm (
" BRU *+10\n"
" MVCIN 0(*-*,%0),0(%1)\n"
" BCTR %2,0\n"
" EXRL %2,*-8\n"
: :
"a"(dest),
"a"(src),
"r"(len));
}
I use C and will continue to use C until something better comes along. To code
C, just accept it's blemishes without questioning why otherwise you will go
crazy. I think this is why C programmers are so adamant about C. Remember, good
friends won't let friends code C unless absolutely necessary.
Regards, Jon.
