I accept your criticism that the syntax for inlining HLASM in C/C++ is not good, and that my example should have used labels. I generally use HLASM wrapper routines where I need to, and have only used the inlining syntax a handful of times for some performance tweaking. The context of my post was to respond to someone who said that you couldn't use instructions like MVCIN in C/C++ - I'm certainly not saying that inlining in C/C++ is easier or better than just writing in HLASM or even PL/X.
I am surprised at your criticism of the four instructions that I used for inlining an MVCIN routine in C/C++ (and your PL/X pseudo code) - you don't seem to understand how to use the MVCIN instruction. Check the POP. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 5, 2018 at 12:54 PM, Jon Perryman <jperr...@pacbell.net> wrote: > 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. >
