IBM Mainframe Forum

[chong_zhou]

The MVC instruction requires 'ternary address' for the destination operand: D(L,B). If you want to use default L, you must write it like this: D(,B). If the comma is omitted, say D(L), the number in brackets is treated as L rather than B.

However, in Metal-C, if I write it like the following:

Select all

int val1, val2 = 0;
__asm(" MVC    %0,%1"
      : "=m"(val1)
      : "m"(val2)
      : );
 

The compiler will generates code like the following:

Select all

 MVC    124(13),128(13)
 

This is definitely wrong. The programme will probably ABEND because the instruction will copy 13 bytes of data rather than 4, and causes 'buffer overrun'. Actually I really tried this, and got 0C4 / 4 which is not a surprise.

So the question is how I can make the Metal-C compiler generate operand in such form: num(num, num), or at least num(,num)?

Thank you guys!!

[steve-myers]

• What do you mean by "ternary address"? AMODE 64? Then the problem is persuading the compiler to use 64-bit addresses and LG instructions to load base registers
• MVC X(13),Y(13) assembles as MVC X(13,0),Y(13). If you think about it for a few seconds you can readily see the problem. Most Assembler programmers have done this several times in their careers. I certainly have!

Why not just write memcpy(x,y) where x and y are defined in the usual C fashion? I'd bet the compiler will write MVC X,Y with the appropriate base register assignment and the correct length. Much better than inline Assembler!

I admit I haven't done Metal C (or even much mainframe C), but memcpy strikes me as a much more usable approach! One of my early 16 bit C projects was a text window package. It used a lot of memcpy functions to build the elements of the window. No Assembler at all! Even on a single speed 8088 it was fast enough to please just about anyone even using the M$ Quick C compiler. Later on I got a copy of the M$ C Version 6 compiler and compiled my little package with it. I'm sure it was faster, but I couldn't see it!

[chong_zhou]

Thank you for the quick reply, Steve. By 'ternary address', I meant the address expression consisted of 3 parts: D(X,B) or D(L,B). Sorry for the bad terminology.

If you look at the sample code that I posted at the beginning, you will notice that the metal C compiler generated 'MVC 124(13),...' which is wrong. Because from the whole listing I can see that it is using R13 as the base register, and the variable 'val1' is at offset 124, so it should be 'MVC 124(4,13),...'. I have no idea how I can make the metal C compiler do the right thing.

I don't think it needs a PMR for IBM, because if it were the metal C compiler's fault, it would have been already found out. I am not the first metal C programmer after all.

memcpy is a better choice for the the sample code I posted, but in my the case, I am actually extracting 'fields' from an area, and I only have a huge dsect macro.

[enrico-sorichetti]

I remember doing an MVC using a pointer
something along the lines of

Select all

  __asm(" MVC 0(4,%0),%1"
            : "r"(_ptr1->var1)
            : "m"(var2)
            : );

but it was a Loong time ago and I cannot recover the source

[chong_zhou]

Thank you very much, enrico-sorichetti, and truly sorry for the super late reply.

You are right. For copying between full-word integers using METAL-C inline assembler, I have to use "r"(&var) instead of "m"(var) as you suggested, otherwise, the compiler can't generate correct address operand for D(X,B). Actually afterward, I kept working with METAL-C in a project and the compiler gave me endless issues/surprises. METAL-C saved me 90% of time on coding and wasted me 90% of time on fixing issues and finding walkarounds. Perfect.

Anyway, thank you again.

[enrico-sorichetti]

Glad that I could help