On 27/03/2014 12:20 AM, Kirk Wolf wrote:
David,

I agree - this would be GREAT.   I've asked IBM about this and I think that
at the time they said that it was a "known requirement".   Will be asking
again next week.  In the meantime, I would suggest that all interested
submit your requirements.

I put that requirement in a couple of years ago with a list of use cases why it would be useful. To be fair the compiler guys in Toronto have been good wrt accepting my requirements in the past (PLO bif) and I appreciate they have a long list of features to implement. However, __asm() is an absolute must have for me. One of my use cases was a packed decimal class in C++. I notice in z/OS 2.1 they shipped all the PD instructions as BIFs so they threw a bone! Just not the one I wanted.

What we do (a lot) is to write XPLINK assembler leaf routines and call them
from (non-metal) C/C++.   It works better for 31-bit, since you can use the
XPLINK stack for your 31-bit work area.  For 64-bit or bi-amodal assembler,
we end up using __malloc31() and passing the workarea as a pointer, which
IMO is preferable to getting OS memory off the heap.  But inlining in
non-Metal wouldn't help with that.

We use the same technique. Grrr, __malloc31(), __malloc24() only supported in AMODE(64)! How brain damaged is that?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Tue, Mar 25, 2014 at 10:54 PM, David Crayford<dcrayf...@gmail.com>wrote:

On 26/03/2014 11:38 AM, Gord Tomlin wrote:

On 2014-03-25 22:11, David Crayford wrote:

I find that I rarely need Metal/C. What I do want to do is inline
assembler into LE code.

I have found Metal to be useful in a few situations where it is desirable
to have a self-contained program with inline Assembler and no dependencies
on the LE runtime. Admittedly these occasions are not that common; in my
experience it's not very often that a situation presents itself where C
with inline Assembler is preferable to pure Assembler.


I can think of plenty of situations, the most common being synchronization
primitives for multi-theaded code. They is no built-in for a membar in z/OS
C/C++ which is simple to code in gcc.

#define eieio() asm volatile("bcr 15,0" : : : "memory")

If I had that I can then port libraries like boosts lock free
http://www.boost.org/doc/libs/1_55_0/doc/html/lockfree.html. There's no
such thing as Metal/C++ ;).


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to