Topic
  • No replies
DaveyC
DaveyC
62 Posts

Pinned topic z/OS GENASM - Why C only!!

‏2011-02-15T05:13:38Z |
I've noticed the new GENASM feature in z/OS 1.12, very nice! Why is this a C only feature. What's technical reason is there
that prevents inlining assembler in a C++ program?
David Crayford
Updated on 2011-03-03T13:03:20Z at 2011-03-03T13:03:20Z by SystemAdmin
  • Visda
    Visda
    32 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-02-16T02:23:58Z  
    Hi David,

    Are you referring to using __asm in C++ code?
    By the way, which GENASM new feature in V1R12 are you referring to?

    Thanks,
    Visda
  • DaveyC
    DaveyC
    62 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-02-17T07:04:19Z  
    Yep, the __asm. Why is it not supported for C++?

    Also, if I've know got __asm in LE code why are __far pointers METAL only?

    David Crayford
  • Visda
    Visda
    32 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-02-25T19:48:48Z  
    • DaveyC
    • ‏2011-02-17T07:04:19Z
    Yep, the __asm. Why is it not supported for C++?

    Also, if I've know got __asm in LE code why are __far pointers METAL only?

    David Crayford
    We provide the __asm support within Metal C product. Metal C generates code independent of LE. If __asm is specified in a source code, it should be compiled with METAL and GENASM options, batch, and -qMETAL -S, USS. The Metal C product development team believes users who need to utilize __asm language extensions are mostly programming in an environment where Language Environment doesn't exist.
    It is due to this fundamental design decision that __asm is not supported in C++.
    Also no conventions have been defined for access registers in LE. Language Environment neither saves nor restores the contents of the access registers.
    Metal C however provides users access to data spaces using __far pointers.

    Thanks,
    Visda
  • SystemAdmin
    SystemAdmin
    196 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-02-28T15:25:01Z  
    • Visda
    • ‏2011-02-25T19:48:48Z
    We provide the __asm support within Metal C product. Metal C generates code independent of LE. If __asm is specified in a source code, it should be compiled with METAL and GENASM options, batch, and -qMETAL -S, USS. The Metal C product development team believes users who need to utilize __asm language extensions are mostly programming in an environment where Language Environment doesn't exist.
    It is due to this fundamental design decision that __asm is not supported in C++.
    Also no conventions have been defined for access registers in LE. Language Environment neither saves nor restores the contents of the access registers.
    Metal C however provides users access to data spaces using __far pointers.

    Thanks,
    Visda
    Dave,

    Let me provide another angle to explain why GENASM isn't offered for C++.
    The primary reason for offering __asm for Metal C was so the user can have a way to invoke the operating system services directly as there is no LE runtime for Metal C. With that the C compiler has to generate the code in assembler source code as the assembler step is needed to expand the system macros.
    For C++, a runtime environment is a must. Therefore it is a contradiction to one of the Metal C principles, i.e. LE independent. So there is no Metal C++ and thus there is no GENASM for C++.
  • DaveyC
    DaveyC
    62 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-03-01T04:04:45Z  
    Thanks for the explanations. I misunderstood what GENASM actually does. I was under the impression that it enabled __asm inline assembly in LE (non-Metal) C code.

    I can think of several use cases to form a strong argument why __asm should be supported in LE code. The C/C++ RTL doesn't always cut it so customers write their
    own small assembler subroutines. Sometimes, the routines are called from non-XPLINK and XPLINK clients, so it's either re-write the code or take a performance trade-off.
    __asm would solve that problem right away.

    The builtins are great, but not complete. C++ lacks (shocking!) packed decimal support. But the BIFs only provide ZAP! Give me __asm and I can easily knock up a Decimal
    template without having to write assembler leaf routines. Of course, linkage overhead would be reduced because it's easy to inline functions wrapping the __asm inlines.

    I'm a bit disappointed because I thought GENASM was a neat and very useful new feature.

    David Crayford
  • SystemAdmin
    SystemAdmin
    196 Posts

    Re: z/OS GENASM - Why C only!!

    ‏2011-03-03T13:03:20Z  
    • DaveyC
    • ‏2011-03-01T04:04:45Z
    Thanks for the explanations. I misunderstood what GENASM actually does. I was under the impression that it enabled __asm inline assembly in LE (non-Metal) C code.

    I can think of several use cases to form a strong argument why __asm should be supported in LE code. The C/C++ RTL doesn't always cut it so customers write their
    own small assembler subroutines. Sometimes, the routines are called from non-XPLINK and XPLINK clients, so it's either re-write the code or take a performance trade-off.
    __asm would solve that problem right away.

    The builtins are great, but not complete. C++ lacks (shocking!) packed decimal support. But the BIFs only provide ZAP! Give me __asm and I can easily knock up a Decimal
    template without having to write assembler leaf routines. Of course, linkage overhead would be reduced because it's easy to inline functions wrapping the __asm inlines.

    I'm a bit disappointed because I thought GENASM was a neat and very useful new feature.

    David Crayford
    David,

    Thank you for letting us know the issues. We'll certainly take your comments into consideration for our overall long term product plan.