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!
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
