On 20/07/2018 9:33 PM, Charles Mills wrote:
it's not idiomatic for the language
What do you mean? Serious question, not sarcasm.

Flipping bits is done with a ~ in C/C++. It just looks odd to me if I see negative magic numbers.

Certainly it is architecture dependent, but then, any time you cast a pointer 
to a long you are in architecture land.

Agreed but note the use of uintptr_t.


I wonder how much it's used by assembler programmers?
I personally do not, because we have made a decision to stick to ZS-3 (z9) for 
our assembler code. (The C code goes out the door ARCH(9) but it is trivial to 
recompile for any ARCH level.) The z9 is supported by V2R1 which itself is 
still on support. We will probably upgrade everything one of these days but (1) 
there is little incentive to change working non-critical-performance-path 
assembler and (2) we do very little new assembler.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of David Crayford
Sent: Friday, July 20, 2018 1:50 AM
To: [email protected]
Subject: Re: S0C6 in CSRC4RG1

I don't like using negative numbers in C code because it's not idiomatic
for the language and I'm pedantic :)

The C compiler uses a XILF instruction to implement to compliment
operator and does the AND with a NRK instruction. The distinct operand
facility is interesting.
It's for register constraint relief. I wonder how much it's used by
assembler programmers?

aligned_malloc
000006 |                   DS 0D
000006 |                   STM r6,r10,1928(r4)
000006 |                   LAY r4,-128(,r4)
End of Prolog

000011 |                   L r6,=A(malloc)(,r5,12)
000010 |                   ALHSIK r10,r2,H'-1'
000010 |                   ALHSIK r0,r2,H'3'
000007 |       * {
000008 |       *      void * ptr = NULL;
000008 |                   LA r8,0
000011 |                   L r5,=A(malloc)(,r5,8)
000009 |       *      // allocate storage area with space for an extra
pointer and alignment
000010 |       *      size += sizeof(void *) + (align - 1);
000010 |                   ALRK r9,r1,r0
000011 |       *      void * mem = malloc(size);
000011 |                   LR r1,r9
000011 |                   BASR r7,r6
000011 |                   NOP 6
000012 |       *      if (mem) {
000012 |                   CIJE r3,H'0',@2L2
000013 |       *          // point to the start of the aligned storage
to return
000014 |       *          ptr = (void **)((uintptr_t)(mem + size) &
~(align - 1));
000014 |                   LA r0,#AddressShadow(r9,r3,0)
000014 |                   XILF r10,F'-1'
000014 |                   NRK r8,r0,r10
000015 |       *          // store the address of the allocated memory
prior to the aligned storage
000016 |       *          ((void **) ptr)[-1] = mem;
000016 |                   STY r3,(*)void*(,r8,-4)
000016 |        @2L2       DS 0H
000017 |       * }
000018 |       *      return ptr;
000018 |                   LR r3,r8
000019 |       * }
000019 |        @2L3       DS 0H

Start of Epilog
000019 |                   LM r7,r10,2060(r4)
000019 |                   LA r4,128(,r4)
000019 |                   B 4(,r7)

Start of Epilog
000017 |                   LM r7,r9,2060(r4)
000017 |                   LA r4,128(,r4)
000017 |                   B 4(,r7)


On 19/07/2018 10:43 PM, Steve Smith wrote:
Thank-you Mr. Relson!

Oddly enough, in rerunning my test, it seems that it fails considerably
less than half the time.  That is, it usually aligns on a 16-byte
boundary.  This test version is configured to allocate the cpool anchor and
extent, plus four 160-byte buffers.  This is to stress-test buffer
exhaustion logic.  The production version uses 4091* buffers, making the
total space just under 640KB (which as we all know, should be enough for
anybody).  That has never failed to align correctly.

* The idea is to *avoid* buffer exhaustion, and presently, this seems to be
enough.

Re specification of rounding mask:  I do think -16, -8, etc. are an elegant
way to specify these, particularly as they correlate to 16-byte, 8-byte,
etc. boundaries.   I sure wish they were usable with NILL and NILF.

Well, I decided to check before complaining... and (surprise!):

0000028C 0000 0000               00000000    481          NILL
R15,-4
** ASMA031E Invalid immediate or mask
field
00000290 C0FB FFFF FFF0          00000000    482          NILF
R15,-16
                                               483
*

Sigh.

sas


On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson <[email protected]> wrote:

Problems:
1. Undocumented requirement to quad-word align CPOOL anchor and/or
extent
in 64-bit mode (and actually undocumented alignment requirements for
all).
2. Unable to guarantee quad-word alignment with malloc.
I will get the first taken care of. The anchor does not need to be
quad-word aligned.

For the second, as has been pointed out in C syntax but I think not in
words, you would do what everyone used to do prior to STARTBDY keyword of
GETMAIN / STORAGE OBTAIN -- round the start address up to the necessary
boundary, having gotten an additional 8 if you need the length to be some
specific value (or 15 if you do are not guaranteed that the area will at
least be on a doubleword boundary).

The rounding is typically "Add 15, AND with -16".

Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to