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.
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. Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Mar 25, 2014 at 10:54 PM, David Crayford <[email protected]>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 to [email protected] with the message: INFO IBM-MAIN
