Re: S0C6 in CSRC4RG1
Tom Marchant wrote: On Thu, 19 Jul 2018 12:38:06 -0400, Thomas David Rivers David Crayford wrote: I don't think LE allows the stack to be above-the-bar XPLINK-64 allocates the stack above the bar. I don't know if that can be overridden. Thanks Tom! We are just now delving into the 64-bit LE world, on customer request; which is my apology for my ignorance... clearly a lot to discover! - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
David Crayford wrote: On 20/07/2018 12:38 AM, Thomas David Rivers wrote: David Crayford wrote: It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit Unless the stack is above-the-bar and you need below-the-bar memory... I mention this because the OP wrote that he is using __malloc31(). Good point! Although it's curious why the OP is using __malloc31() when calling CSRC4RG1 which is a 64-bit service. But for z/OS it would be probably be useful to have a aligned_malloc31() for such a requirement. Does Dignus C have something like aligned_malloc()? I don't think LE allows the stack to be above-the-bar, but in a 64-bit Dignus program it can certainly be there (and, by default, is...) It sure does. Check out the STACK64 LE runtime option. The C requirement for malloc() is that it be aligned to the maximum alignment required from any declarable datum, which would be 8 for z/Arch... (there's no C data type that requires quad-word alignment; in fact, there probably isn't one that _requires_ double-word alignment... so 4-byte aligning would be "OK" I think, but 8-byte is common...) But - now - we've introduced this alignment attribute which can take on new values... so since there is the possibiity of declaring a quad-word alignment datum; then it would be required of malloc() to always return quad-word aligned allocations. There is not a limit on the value you can specify in that attribute, so the malloc() implementation would, presumably, have to accomodate any alignment - which does seem to be outside the definition of malloc(). Your suggestion of a different function to accomplish aligned allocations is probably the way to go. *However* again, the declaration of __aligned__((16)) probably doesn't work for an automatic variable; because that would require that the function's stack allocation be so aligned (a 16-byte-aligned offset in a stack that itself is not 16-byte aligned is not 16-byte aligned.) So, while the attribute is there, I'm not sure the compiler technically honors it for automatic variables. (I'd check the generated code for the function to see if the stack alignment is properly managed in that case... and perhaps for something like __aligned__((1024)). ) The GCC documentation only discusses it for "global" variables, and even notes that you specify an alignment greater than what your linker supports; it may not work. Like many of the ideas in GCC, they seem to have been invented on a whim without thought to the language repurcussions... so, they work for the areas intended and not so great in the general sense... it's a wonderful platform for experimentation. - Dave - p.s. Thanks for the correction regarding the STACK64 option! -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Friday, July 20, 2018 1:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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
06 | DS 0D
06 | STM r6,r10,1928(r4)
06 | LAY r4,-128(,r4)
End of Prolog
11 | L r6,=A(malloc)(,r5,12)
10 | ALHSIK r10,r2,H'-1'
10 | ALHSIK r0,r2,H'3'
07 | * {
08 | * void * ptr = NULL;
08 | LA r8,0
11 | L r5,=A(malloc)(,r5,8)
09 | * // allocate storage area with space for an extra
pointer and alignment
10 | * size += sizeof(void *) + (align - 1);
10 | ALRK r9,r1,r0
11 | * void * mem = malloc(size);
11 | LR r1,r9
11 | BASR r7,r6
11 | NOP 6
12 | * if (mem) {
12 | CIJE r3,H'0',@2L2
13 | * // point to the start of the aligned storage
to return
14 | * ptr = (void **)((uintptr_t)(mem + size) &
~(align - 1));
14 | LA r0,#AddressShadow(r9,r3,0)
14 | XILF r10,F'-1'
14 | NRK r8,r0,r10
15 | * // store the address of the allocated memory
prior to the aligned storage
16 | * ((void **) ptr)[-1] = mem;
16 | STY r3,(*)void*(,r8,-4)
16 |@2L2 DS 0H
17 | * }
18 | * return ptr;
18 | LR r3,r8
19 | * }
19 |@2L3 DS 0H
Start of Epilog
19 | LM r7,r10,2060(r4)
19 | LA r4,128(,r4)
19 | B 4(,r7)
Start of Epilog
17 | LM r7,r9,2060(r4)
17 | LA r4,128(,r4)
17 | 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!):
028C 481 NILL
R15,-4
** ASMA031E Invalid immediate or mask
field
0290 C0FB FFF0 482 NILF
R15,-16
483
*
Sigh.
sas
On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson 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 STAR
Re: S0C6 in CSRC4RG1
> it's not idiomatic for the language
What do you mean? Serious question, not sarcasm.
Certainly it is architecture dependent, but then, any time you cast a pointer
to a long you are in architecture land.
> 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Friday, July 20, 2018 1:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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
06 | DS 0D
06 | STM r6,r10,1928(r4)
06 | LAY r4,-128(,r4)
End of Prolog
11 | L r6,=A(malloc)(,r5,12)
10 | ALHSIK r10,r2,H'-1'
10 | ALHSIK r0,r2,H'3'
07 | * {
08 | * void * ptr = NULL;
08 | LA r8,0
11 | L r5,=A(malloc)(,r5,8)
09 | * // allocate storage area with space for an extra
pointer and alignment
10 | * size += sizeof(void *) + (align - 1);
10 | ALRK r9,r1,r0
11 | * void * mem = malloc(size);
11 | LR r1,r9
11 | BASR r7,r6
11 | NOP 6
12 | * if (mem) {
12 | CIJE r3,H'0',@2L2
13 | * // point to the start of the aligned storage
to return
14 | * ptr = (void **)((uintptr_t)(mem + size) &
~(align - 1));
14 | LA r0,#AddressShadow(r9,r3,0)
14 | XILF r10,F'-1'
14 | NRK r8,r0,r10
15 | * // store the address of the allocated memory
prior to the aligned storage
16 | * ((void **) ptr)[-1] = mem;
16 | STY r3,(*)void*(,r8,-4)
16 |@2L2 DS 0H
17 | * }
18 | * return ptr;
18 | LR r3,r8
19 | * }
19 |@2L3 DS 0H
Start of Epilog
19 | LM r7,r10,2060(r4)
19 | LA r4,128(,r4)
19 | B 4(,r7)
Start of Epilog
17 | LM r7,r9,2060(r4)
17 | LA r4,128(,r4)
17 | 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!):
>
> 028C 481 NILL
> R15,-4
> ** ASMA031E Invalid immediate or mask
> field
> 0290 C0FB FFF0 482 NILF
> R15,-16
> 483
> *
>
> Sigh.
>
> sas
>
>
> On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson 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
Re: S0C6 in CSRC4RG1
I'll match you on pedantry any day. :-) You mean "complement" operator, as flattering a number isn't useful; and the distinct operand facility instructions don't save any registers, they save cycles. I use them some, but unless I missed something, they all can be replaced with an LR followed by a traditional instruction. E.g.: ALRK R9,R1,R0 == LR R9,R1 ALR R9,R0. So, not a lot of thrill there. Also, I'm sure you mean negative numbers aren't idiomatic for bit masks... I'll grant that, but my last word is that occasionally new idioms can be invented. sas On Fri, Jul 20, 2018 at 4:49 AM, David Crayford wrote: > 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
06 | DS 0D
06 | STM r6,r10,1928(r4)
06 | LAY r4,-128(,r4)
End of Prolog
11 | L r6,=A(malloc)(,r5,12)
10 | ALHSIK r10,r2,H'-1'
10 | ALHSIK r0,r2,H'3'
07 | * {
08 | * void * ptr = NULL;
08 | LA r8,0
11 | L r5,=A(malloc)(,r5,8)
09 | * // allocate storage area with space for an extra
pointer and alignment
10 | * size += sizeof(void *) + (align - 1);
10 | ALRK r9,r1,r0
11 | * void * mem = malloc(size);
11 | LR r1,r9
11 | BASR r7,r6
11 | NOP 6
12 | * if (mem) {
12 | CIJE r3,H'0',@2L2
13 | * // point to the start of the aligned storage
to return
14 | * ptr = (void **)((uintptr_t)(mem + size) &
~(align - 1));
14 | LA r0,#AddressShadow(r9,r3,0)
14 | XILF r10,F'-1'
14 | NRK r8,r0,r10
15 | * // store the address of the allocated memory
prior to the aligned storage
16 | * ((void **) ptr)[-1] = mem;
16 | STY r3,(*)void*(,r8,-4)
16 | @2L2 DS 0H
17 | * }
18 | * return ptr;
18 | LR r3,r8
19 | * }
19 | @2L3 DS 0H
Start of Epilog
19 | LM r7,r10,2060(r4)
19 | LA r4,128(,r4)
19 | B 4(,r7)
Start of Epilog
17 | LM r7,r9,2060(r4)
17 | LA r4,128(,r4)
17 | 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!):
028C 481 NILL
R15,-4
** ASMA031E Invalid immediate or mask
field
0290 C0FB FFF0 482 NILF
R15,-16
483
*
Sigh.
sas
On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson 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 lists...@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
Re: S0C6 in CSRC4RG1
On 20/07/2018 12:38 AM, Thomas David Rivers wrote: David Crayford wrote: It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit Unless the stack is above-the-bar and you need below-the-bar memory... I mention this because the OP wrote that he is using __malloc31(). Good point! Although it's curious why the OP is using __malloc31() when calling CSRC4RG1 which is a 64-bit service. But for z/OS it would be probably be useful to have a aligned_malloc31() for such a requirement. Does Dignus C have something like aligned_malloc()? I don't think LE allows the stack to be above-the-bar, but in a 64-bit Dignus program it can certainly be there (and, by default, is...) It sure does. Check out the STACK64 LE runtime option. - Dave R. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On Thu, 19 Jul 2018 12:38:06 -0400, Thomas David Rivers David Crayford wrote: > >I don't think LE allows the stack to be above-the-bar XPLINK-64 allocates the stack above the bar. I don't know if that can be overridden. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
David Crayford wrote: It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit Unless the stack is above-the-bar and you need below-the-bar memory... I mention this because the OP wrote that he is using __malloc31(). I don't think LE allows the stack to be above-the-bar, but in a 64-bit Dignus program it can certainly be there (and, by default, is...) - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
Done, although he's too nice of a person to have to keep explaining the inexplicable. :-) sas On Thu, Jul 19, 2018 at 11:23 AM, Charles Mills wrote: > So NILF takes -16 but NILL won't take -4? > > You should post that on the HLASM list. Jonathon Scott of HLASM > development is very responsive there. > > Charles > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
So NILF takes -16 but NILL won't take -4? You should post that on the HLASM list. Jonathon Scott of HLASM development is very responsive there. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, July 19, 2018 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 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!): 028C 481 NILL R15,-4 ** ASMA031E Invalid immediate or mask field 0290 C0FB FFF0 482 NILF R15,-16 483 * Sigh. sas On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson 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 lists...@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
Re: S0C6 in CSRC4RG1
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!): 028C 481 NILL R15,-4 ** ASMA031E Invalid immediate or mask field 0290 C0FB FFF0 482 NILF R15,-16 483 * Sigh. sas On Thu, Jul 19, 2018 at 8:01 AM, Peter Relson 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On 7/18/2018 4:12 PM, David Crayford wrote: NI FLAG1,X'FF'-BIT1 I often did this to try to help the next poor soul forced to look at my code: NOT EQU X'FF' NIFLAG1,NOT-BIT1 I'm not sure where I first saw that method - maybe from bits of UCC source code we were given in the 1980's. I always thought those folks had a good, readable style of assembler coding. As for the -16, I guessed at what it was doing but to be sure I had to get out my trusty hex calculator - also from the 1980's. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On 19/07/2018 12:18 AM, Charles Mills wrote: I thought -16 was kind of cool. It took me a second, but in the future I would "get" an & with -8 or -4 in a heartbeat. It just looks wrong to me ;) I don't know that ~15 or ~0xf is any clearer. ~ always worries me a little bit for some reason. Why does it worry you? To the majority of C programmers it's the natural way of ANDing bits. If you put your assembler programmers hat on flag &= ~(BIT1) isn't too dissimilar to NI FLAG1,X'FF'-BIT1 I probably would have coded 0xfff0 but "counting nibbles" is error-prone also. Much better IMO! Perhaps (-1) << 4 is arguably the most straightforward, but it's not obvious either. Perhaps put into a macro? Personally, I find that obscure. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Wednesday, July 18, 2018 5:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 On 18/07/2018 8:26 PM, Steve Smith wrote: Nice... So, you say 1s-complement is better than 2s-complement? Is ~15 clearer than -16? ;-) I say it's best to stick to the idioms of the language you're coding in :) My "native" language is assembler, and it doesn't have an easy way to specify the former. Bit twiddling in C can be tricky and not as intuitive as assembler. But it's trivial to write macros to make it easy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
I thought -16 was kind of cool. It took me a second, but in the future I would "get" an & with -8 or -4 in a heartbeat. I don't know that ~15 or ~0xf is any clearer. ~ always worries me a little bit for some reason. I probably would have coded 0xfff0 but "counting nibbles" is error-prone also. Perhaps (-1) << 4 is arguably the most straightforward, but it's not obvious either. Perhaps put into a macro? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Wednesday, July 18, 2018 5:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 On 18/07/2018 8:26 PM, Steve Smith wrote: > Nice... > > So, you say 1s-complement is better than 2s-complement? Is ~15 clearer > than -16? ;-) I say it's best to stick to the idioms of the language you're coding in :) > My "native" language is assembler, and it doesn't have an easy way to > specify the former. Bit twiddling in C can be tricky and not as intuitive as assembler. But it's trivial to write macros to make it easy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
My native language is assembler and not all assemblers are designed for the S/360 line. Ones complement is awkward on HLASM, but Twos Complement is awkward on, e.g., COMPASS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Wednesday, July 18, 2018 8:26 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: S0C6 in CSRC4RG1 Nice... So, you say 1s-complement is better than 2s-complement? Is ~15 clearer than -16? ;-) My "native" language is assembler, and it doesn't have an easy way to specify the former. sas On Wed, Jul 18, 2018 at 4:14 AM, David Crayford wrote: > I certainly wouldn't encourage anybody to use negative numbers for bit > mask values! > > Why not just write an aligned memory allocator which stashes an extra > pointer in a known location for easy freeing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
It's always best to get storage on the stack and avoid the heap if you can. z/OS C/C++ supports the GCC extensions that allow you to align storage using variable attributes. char buffer[1408] __attribute__((__aligned__(16))) ; // only works in 64-bit On 18/07/2018 2:44 AM, Steve Smith wrote: In assembler, STORAGE provides a BNDRY= keyword, which would be fine, but this is a Metal C program. malloc provides no such thing. Don's suggestion is doable, but it's fugly C code, and amounts to doing vascular surgery wearing oven mitts: *void realp = malloc(1408 + 15); long ip = (long)realp & -16; *Cpool p = (*CPool)ip; Yeah, that's clear to anyone. Although I'm sure it could be obfuscated. Note: If you think the 1st & 3rd lines are commented out, this thread is not for you :-) 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. Ugh. sas On Tue, Jul 17, 2018 at 1:41 PM, Don Poitras wrote: Add 15 bytes to whatever length you are asking for and copy the pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
On 18/07/2018 8:26 PM, Steve Smith wrote: Nice... So, you say 1s-complement is better than 2s-complement? Is ~15 clearer than -16? ;-) I say it's best to stick to the idioms of the language you're coding in :) My "native" language is assembler, and it doesn't have an easy way to specify the former. Bit twiddling in C can be tricky and not as intuitive as assembler. But it's trivial to write macros to make it easy. sas On Wed, Jul 18, 2018 at 4:14 AM, David Crayford wrote: I certainly wouldn't encourage anybody to use negative numbers for bit mask values! Why not just write an aligned memory allocator which stashes an extra pointer in a known location for easy freeing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
Nice... So, you say 1s-complement is better than 2s-complement? Is ~15 clearer than -16? ;-) My "native" language is assembler, and it doesn't have an easy way to specify the former. sas On Wed, Jul 18, 2018 at 4:14 AM, David Crayford wrote: > I certainly wouldn't encourage anybody to use negative numbers for bit > mask values! > > Why not just write an aligned memory allocator which stashes an extra > pointer in a known location for easy freeing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
On Tue, 17 Jul 2018 12:18:22 -0400, Peter Relson wrote: >As to have you been lucky? I guess so. You didn't show how you obtained >the extent area. Depending on size, some flavors of getmain will naturally >land on a page boundary. But others won't and would then have the default >of doubleword alignment. I think it also depends on whether or not the system has USEZOSV1R9RULES specified as YES or NO. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
Of course, don't forget to check malloc() :)
void * aligned_malloc(size_t size, size_t align)
{
// allocate storage area with space for an extra pointer and alignment
void * mem = malloc(size + sizeof(void*) + (align - 1));
if (!mem) return NULL;
// point to the start of the aligned storage to return
void * ptr = (void **)((uintptr_t)(mem + (align - 1) + sizeof(void
*)) & ~(align - 1));
// store the address of the allocated memory prior to the aligned
storage
((void **) ptr)[-1] = mem;
return ptr;
}
void aligned_free(void *ptr)
{
free(((void**) ptr)[-1]);
}
int main( int argc, char *argv[] )
{
return 0;
}
On 18/07/2018 4:14 PM, David Crayford wrote:
void * aligned_malloc(size_t size, size_t align)
{
// allocate storage area with space for an extra pointer and
alignment
void * mem = malloc(size + sizeof(void*) + (align - 1));
// point to the start of the aligned storage
void * ptr = (void **)((uintptr_t)(mem + (align - 1) + sizeof(void
*)) & ~(align - 1));
// store the address of the allocated memory prior to the aligned
storage
((void **) ptr)[-1] = mem;
return ptr;
}
void aligned_free(void *ptr)
{
free(((void**) ptr)[-1]);
}
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
I certainly wouldn't encourage anybody to use negative numbers for bit
mask values!
Why not just write an aligned memory allocator which stashes an extra
pointer in a known location for easy freeing?
void * aligned_malloc(size_t size, size_t align)
{
// allocate storage area with space for an extra pointer and alignment
void * mem = malloc(size + sizeof(void*) + (align - 1));
// point to the start of the aligned storage
void * ptr = (void **)((uintptr_t)(mem + (align - 1) + sizeof(void
*)) & ~(align - 1));
// store the address of the allocated memory prior to the aligned
storage
((void **) ptr)[-1] = mem;
return ptr;
}
void aligned_free(void *ptr)
{
free(((void**) ptr)[-1]);
}
On 18/07/2018 2:59 AM, Charles Mills wrote:
The lines beginning with * aren't C either . You want void *realp ...
Also, your second and third lines combine pretty well into one.
Cpool *p = (Cpool *)((long)realp & -16));
No one ever said system programming in C was pretty.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Tuesday, July 17, 2018 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0C6 in CSRC4RG1
In assembler, STORAGE provides a BNDRY= keyword, which would be fine, but
this is a Metal C program. malloc provides no such thing. Don's
suggestion is doable, but it's fugly C code, and amounts to doing vascular
surgery wearing oven mitts:
*void realp = malloc(1408 + 15);
long ip = (long)realp & -16;
*Cpool p = (*CPool)ip;
Yeah, that's clear to anyone. Although I'm sure it could be obfuscated.
Note: If you think the 1st & 3rd lines are commented out, this thread is
not for you :-)
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.
Ugh.
sas
On Tue, Jul 17, 2018 at 1:41 PM, Don Poitras wrote:
Add 15 bytes to whatever length you are asking for and copy the
pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
The lines beginning with * aren't C either . You want void *realp ... Also, your second and third lines combine pretty well into one. Cpool *p = (Cpool *)((long)realp & -16)); No one ever said system programming in C was pretty. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Tuesday, July 17, 2018 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 In assembler, STORAGE provides a BNDRY= keyword, which would be fine, but this is a Metal C program. malloc provides no such thing. Don's suggestion is doable, but it's fugly C code, and amounts to doing vascular surgery wearing oven mitts: *void realp = malloc(1408 + 15); long ip = (long)realp & -16; *Cpool p = (*CPool)ip; Yeah, that's clear to anyone. Although I'm sure it could be obfuscated. Note: If you think the 1st & 3rd lines are commented out, this thread is not for you :-) 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. Ugh. sas On Tue, Jul 17, 2018 at 1:41 PM, Don Poitras wrote: > Add 15 bytes to whatever length you are asking for and copy the > pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
Ugh indeed. Me C is getting rusty. void* realp = malloc(1408 + 15); long ip = (long)realp & -16; Cpool* p = (CPool*)ip; sas On Tue, Jul 17, 2018 at 2:44 PM, Steve Smith wrote: > In assembler, STORAGE provides a BNDRY= keyword, which would be fine, but > this is a Metal C program. malloc provides no such thing. Don's > suggestion is doable, but it's fugly C code, and amounts to doing vascular > surgery wearing oven mitts: > > *void realp = malloc(1408 + 15); > long ip = (long)realp & -16; > *Cpool p = (*CPool)ip; > > Yeah, that's clear to anyone. Although I'm sure it could be obfuscated. > Note: If you think the 1st & 3rd lines are commented out, this thread is > not for you :-) > > 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. > > Ugh. > sas > > > On Tue, Jul 17, 2018 at 1:41 PM, Don Poitras wrote: > >> Add 15 bytes to whatever length you are asking for and copy the >> pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) > > > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
In assembler, STORAGE provides a BNDRY= keyword, which would be fine, but this is a Metal C program. malloc provides no such thing. Don's suggestion is doable, but it's fugly C code, and amounts to doing vascular surgery wearing oven mitts: *void realp = malloc(1408 + 15); long ip = (long)realp & -16; *Cpool p = (*CPool)ip; Yeah, that's clear to anyone. Although I'm sure it could be obfuscated. Note: If you think the 1st & 3rd lines are commented out, this thread is not for you :-) 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. Ugh. sas On Tue, Jul 17, 2018 at 1:41 PM, Don Poitras wrote: > Add 15 bytes to whatever length you are asking for and copy the > pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
Yeah. Means you need to keep two pointers around: one with the GETMAIN address for use with FREEMAIN and one that is guaranteed quad-aligned -- but that's a small price to pay. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Tuesday, July 17, 2018 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C6 in CSRC4RG1 Add 15 bytes to whatever length you are asking for and copy the pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) In article you wrote: > Thanks Peter, > fwiw, the buffer pool stuff is combined (not packed) into a structure > obtained with __malloc31(). I'll have to research whether Metal C provides > a way to get Quad-word alignment. > sas > On Tue, Jul 17, 2018 at 12:18 PM, Peter Relson wrote: > > > > But who's at fault here... I'm just > > trying to use the service, and the book says nothing about Q-word aligning > > anything. AND, it's been working fine for almost 3 years... have I just > > been lucky that my cell pool getmains were Q-aligned until today? > > > > > > I'd say that it's our fault for not documenting, but it's a to-do for you. > > > > The AMODE 31 variants require doubleword alignment as they do CDS. > > The AMODE 64 variants requires quadword alignment as they do CDSG > > > > The example in the assembler services guide shows using IARV64 which will > > naturally get storage that accommodates the requirement. > > > > As to have you been lucky? I guess so. You didn't show how you obtained > > the extent area. Depending on size, some flavors of getmain will naturally > > land on a page boundary. But others won't and would then have the default > > of doubleword alignment. > > > > Peter Relson > > z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@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
Re: S0C6 in CSRC4RG1
Add 15 bytes to whatever length you are asking for and copy the pointer. 'And' the last nibble to 0. Voila! quad-aligned pointer. :) In article you wrote: > Thanks Peter, > fwiw, the buffer pool stuff is combined (not packed) into a structure > obtained with __malloc31(). I'll have to research whether Metal C provides > a way to get Quad-word alignment. > sas > On Tue, Jul 17, 2018 at 12:18 PM, Peter Relson wrote: > > > > But who's at fault here... I'm just > > trying to use the service, and the book says nothing about Q-word aligning > > anything. AND, it's been working fine for almost 3 years... have I just > > been lucky that my cell pool getmains were Q-aligned until today? > > > > > > I'd say that it's our fault for not documenting, but it's a to-do for you. > > > > The AMODE 31 variants require doubleword alignment as they do CDS. > > The AMODE 64 variants requires quadword alignment as they do CDSG > > > > The example in the assembler services guide shows using IARV64 which will > > naturally get storage that accommodates the requirement. > > > > As to have you been lucky? I guess so. You didn't show how you obtained > > the extent area. Depending on size, some flavors of getmain will naturally > > land on a page boundary. But others won't and would then have the default > > of doubleword alignment. > > > > Peter Relson > > z/OS Core Technology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
Thanks Peter, fwiw, the buffer pool stuff is combined (not packed) into a structure obtained with __malloc31(). I'll have to research whether Metal C provides a way to get Quad-word alignment. sas On Tue, Jul 17, 2018 at 12:18 PM, Peter Relson wrote: > > But who's at fault here... I'm just > trying to use the service, and the book says nothing about Q-word aligning > anything. AND, it's been working fine for almost 3 years... have I just > been lucky that my cell pool getmains were Q-aligned until today? > > > I'd say that it's our fault for not documenting, but it's a to-do for you. > > The AMODE 31 variants require doubleword alignment as they do CDS. > The AMODE 64 variants requires quadword alignment as they do CDSG > > The example in the assembler services guide shows using IARV64 which will > naturally get storage that accommodates the requirement. > > As to have you been lucky? I guess so. You didn't show how you obtained > the extent area. Depending on size, some flavors of getmain will naturally > land on a page boundary. But others won't and would then have the default > of doubleword alignment. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C6 in CSRC4RG1
But who's at fault here... I'm just trying to use the service, and the book says nothing about Q-word aligning anything. AND, it's been working fine for almost 3 years... have I just been lucky that my cell pool getmains were Q-aligned until today? I'd say that it's our fault for not documenting, but it's a to-do for you. The AMODE 31 variants require doubleword alignment as they do CDS. The AMODE 64 variants requires quadword alignment as they do CDSG The example in the assembler services guide shows using IARV64 which will naturally get storage that accommodates the requirement. As to have you been lucky? I guess so. You didn't show how you obtained the extent area. Depending on size, some flavors of getmain will naturally land on a page boundary. But others won't and would then have the default of doubleword alignment. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C6 in CSRC4RG1
Fully realizing this is an error that should be PMRed to IBM, I just find it unlikely that I'd be the only one to discover such a problem. Also, dealing with ibm.com is bad for my health and sanity. The abend occurs on a CDSG because the 2nd operand isn't Quad-word aligned. DATA AT PSW 015B942E - EB24 B030 003E * A774 FFE1 4100 B: /_1650F0E8 (address of the CSR4PEB) Per above, you can see this is true. But who's at fault here... I'm just trying to use the service, and the book says nothing about Q-word aligning anything. AND, it's been working fine for almost 3 years... have I just been lucky that my cell pool getmains were Q-aligned until today? As far as I can tell, none of the cell pool services specify *any* requirement for alignment. -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
