Operating System - OpenVMS
1748237 Members
3691 Online
108759 Solutions
New Discussion

Re: What is the performance impact of reporting alignment faults?

 
SOLVED
Go to solution
Dennis Handly
Acclaimed Contributor

Re: What is the performance impact of reporting alignment faults?

>I'll be scrounging for technical papers on the compiler and the operating system platform

 

http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/A.06.26_aCxx_Online%20Help/pragmas.htm#data-align

Hoff
Honored Contributor

Re: What is the performance impact of reporting alignment faults?

Thanks.  

 

There's what appears to be a typo in the "#pragma PACK" text in the documentation; likely should be "#pragma pack", based on the code examples, and based on what Microsoft uses for that.

 

And while I'm reviewing the documentation, demonstrating what is probably the "correct" or "preferred" push and pop syntax around the operations would help your readers write better and modular code.  While the examples are necessarily simple, they'll get copied and I'd presume y'all want folks to save and restore the settings around changes.  

 

And I'm really looking would would be a layer or two down from the pragmas and related dreck.  (If a compiler can't manage to generate correct code for a known declaration and a static compilation, then, well, it's time to either repair the compiler, or for the users to move to use a better compiler.)  

 

It's the dereferencing and more complex cases with unaligned that are what I'm interested in.  The __unaligned type qualifier would be typical in C here.  This related to this "Note: If you take the address of a data field and assign it to a pointer, it is not handled automatically and is likely to result in premature termination of the program if not handled appropriately." 

 

Now if you're stating that all the alignment processing has to be done with those pragmas or wth the __align type qualifier, well, that certainly requires careful code coverage.  

 

"If passing the address of a field to other code, consider the following example. Unless compiled with -DRECOVER on the command line and linked with -lunalign, the following example is likely to prematurely terminate with a bus error."

 

And while I'm commenting on the documentation, and based on the uncharacterized ISO/IEC 14882 reference I see in the next level up of that documentation, aC++ is ISO/IEC 14882:1998 (C++98) and not C++03 nor C++11.

 

On the plus side, the C99 compliance is better than what VMS has, though neither offers C11.

 

http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/A.06.26_aCxx_Online%20Help/getstarted.htm

 

And web page navigation in the pages of documentation in that area are poor; there are no obvious ways to navigate to related documentation.

 

Now I'm back digging for Itanium alignment stuff, and the -DERECOVER and -lunalign switches.  And yes, this is way off topic for this thread.

Dennis Handly
Acclaimed Contributor

Re: What is the performance impact of reporting alignment faults?

>There's what appears to be a typo in the "#pragma PACK" text in the documentation; likely should be "#pragma pack", based on the code examples, and based on what Microsoft uses for that.

 

You are going to have to provide a quote/snip of where you think the error is.  The syntax for the pragma is a mixture of N different other compilers, so it may be valid.

Ah, if you are talking about upper vs. lower case, it takes both.  At one time most pragmas had to be uppercase.

 

>demonstrating what is probably the "correct" or "preferred" push and pop syntax around the operations would help your readers write better and modular code.

 

The examples were probably written before the push/pop was added.

 

>(If a compiler can't manage to generate correct code for a known declaration and a static compilation

 

You are going to have to provide an example where you think the compiler is failing.  Try hand waving first.  :-)

If you are talking about here:

>It's the dereferencing and more complex cases with unaligned that are what I'm interested in.  The __unaligned type qualifier would be typical in C here.  This related to this "Note: If you take the address of a data field and assign it to a pointer,

 

This works correctly if you declare the pointer as a pointer to an unaligned type or use the +u# option.

The frontend does no pointer tracking.  The optimizer which does, trusts the frontend.

 

>Now if you're stating that all the alignment processing has to be done with those pragmas or with the __align type qualifier, well, that certainly requires careful code coverage.

 

Yes, unless you use the +u# option or give up and use allow_unaligned_data_access().

 

>And while I'm commenting on the documentation, and based ...

 

I'm not sure of your point here?

 

>On the plus side, the C99 compliance is better than what VMS has,

 

It has full C99 support, HP-UX 11.31 is UNIX 2003 branded.

 

>And web page navigation in the pages of documentation in that area are poor; there are no obvious ways to navigate to related documentation.

 

From where to where, for example?

Hoff
Honored Contributor

Re: What is the performance impact of reporting alignment faults?

If the compiler permits both upper and lower case, then I would expect to see it show both upper and lower case in the pragma documentation.  Or pick whatever one is "correct", and use that.   PICKING A MIXture of PRaGMa cASINg LoOKs lIKE aN ErROR tO A c PROgraMMeR.

 

Specifically, I see ALIGN and align, and PACK and PACK and (in the example section) pack all listed.   From the cited page:

 

...

ALIGN Pragma
#pragma align N

...

PACK Pragma
#pragma PACK [n|[push|pop]|[, <name>][, n]|show]

...

Example:

struct S1 {
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S1)==12, alignment 4

#pragma pack 1

...

 

Pick one.  Or pick both.  But be consistent about it.  And don't assume I know that UX does both.

 

 

>I'm not sure of your point here? 

 

Read that statement as "While I am reviewing the documentation for HP-UX aC compiler, here is another problem/error/omission/bug/comment..."  It's incomplete documentation of the standards support.  Looks like what is posted there hasn't been reviewed and reworked since ISO/IEC 14882 became ISO/IEC 14882:1998.

 

"There" is one level up; specifically, here:

 

http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/A.06.26_aCxx_Online%20Help/index.htm

 

An overhaul would also benefit that documentation, but that's another discussion.  What is posted looks to have been aggregated over a decade and probably more (and which is typical of enterprise/legacy/established/mature products), and it certainly appears that there is substantial room to modernize what's there.  (And that's just a general comment on the content and layout, and before I start looking at the feature set of the compiler.)

 

Navigation?  From that page to the HP-UX product shelf.  From that page to the HP Enterprise website.  From what I see in the available navigation, all of the available navigation is within the warren of compiler documentation.   I can't fathom an obvious navigation model, site or section map, documentation architecture or web site layout (or whatever you want to call that) from the two web pages I've looked at.   The links offered imply I'm in a very isolated corner of what I know is a ginormous web site, and the only way to navigate elsewhere is to head over to DuckDuckGo/Blekko/Bing/Google and search, and loop back through that navigate the HP-UX web site.   (I've learned not to bother with the HP search engine.)

 

As I've told an HPer earlier this week, your user base is undergoing a massive shift, whether you realize it or not. Your newer users have different expectations, different experiences, and are definitely not the same folks that were the target readers for the original documentation for these products.  And while your existing users are aging out, they're also working with different priorities. 

 

Again, thanks for the pointers.   I'm going to close this (my participation in this thread) out.  I have what I expect are the available answers, and I've learned rather more about the state of and content of the HP-UX documentation and the HP tools for HP-UX on Itanium than I'd expected.

Dennis Handly
Acclaimed Contributor

Re: What is the performance impact of reporting alignment faults?

>What is posted looks to have been aggregated over a decade and probably more and it certainly appears that there is substantial room to modernize what's there.

 

Yes.

 

>Navigation?  From that page to the HP-UX product shelf.  From that page to the HP Enterprise website.

 

This is exactly the same as the documentation that ships with the product.  If it had more links as you suggested, they may no longer point to anything valid.  Remember the docs.hp.com fiasco.  :-(

And I would assume that users already know about HP-UX before they even get to the compiler.

 

>From what I see in the available navigation, all of the available navigation is within the warren of compiler documentation.

 

That's correct.  It is ONLY about the compiler, a Programmer's Guide.

 

>The links offered imply I'm in a very isolated corner of what I know is a ginormous web site

 

Yes.

 

>As I've told an HPer earlier this week, your user base is undergoing a massive shift, whether you realize it or not. Your newer users have different expectations, different experiences, and are definitely not the same folks that were the target readers for the original documentation for these products.

 

Thanks for your insights.  And one time it was leading edge, with about the first HP-UX online help with html and hyperlinks.