What is the performance impact of reporting alignment faults?

[Glenn Wolf]

We are porting an application from Alpha to Itanium, and want to keep an eye on alignment faults due to their performance impact.  The critical part of the application consists of a number of transaction server processes that field requests from other hosts on the network.  We already have instrumented these servers to track the transaction duration and a few other parameters; it seemed logical to add alignment fault count to our instrumentation.

To do this , we changed our server processes so that before it processes a transaction, it now calls SYS$START_ALIGN_FAULT_REPORT, and after the transaction has been processed, it calls SYS$GET_ALIGN_FAULT_DATA, followed by SYS$STOP_ALIGN_FAULT_REPORT.   All of this work is bracketed by a call to LIB$INIT_TIMER, and calls to LIB$STAT_TIMER to collect elapsed and CPU time, direct and buffered I/O and page fault counts.  This data, along with the number of fault entries returned by SYS$GET_ALIGN_FAULT_DATA is logged for this transaction.

The issue that we have is that adding the code to collect the number of alignment faults drastically increases the execution duration of the transaction, as reported by LIB$STAT_TIMER.  In a simple, isolated test, a transaction that without aliignment fault reporting takes 5 msec, executing the alignment fault reporting and collecting calls increases this time to almost 400msec.  In this case, 486 alignment faults were reported. We added the enabling and disabling of the alignment fault reporting via a logical name that is checked before each transaction is serviced, and the test results are very repeatable - Call the alignment fault reporting services, the transaction duration is about 400msec.  Don't call the alignment fault services, and the transaction duration is about 5msec.

This increase in elapsed time will not work in production - our application currently runs at about a 21 transactions/second rate, and can be very bursty.

I've tried both the AFR$C_BUFFERED and AFR$C_EXCEPTION approaches - both have similar performance impacts (the exception approach seems marginally worse).

My questions are:

1) Is the above implementation of these system services the way the are intended to work? Or should I just poll at the start of the transaction to clear any residual faults, and then poll at the end to get the count, leaving the reporting enabled the entire time the server is running?

2) Would I have better results with the SYS$PERM_REPORT_ALIGN_FAULT approach?

3) Has anyone else seen this kind of performance impact from using these system services?

By the way, our test environment is an HP rx2620  (1.60GHz/6.0MB) with 16GB of memory, running OpenVMS V8.3.  We see similar behavior on our intended production environment: HP BL860c i2  (1.60GHz/5.0MB) 16 cores with 32GB of memory, running OpenVMS V8.4.

[John Gillings]

Glenn,

   System service calls are potentially expensive. I suspect your observed problem is due to the START/STOP added to each transaction, not the tracing itself.

What happens if you move the START and STOP higher up the stack and just exectute the GET on the transaction? Don't worry about "clearing", just keep track of the previous value to calculate the cost per transaction.

You could also build a simple test program that measures the cost of the START/GET/STOP cycle, possibly with and without dummy loads with known numbers of alignment faults.  

My assumption is these services are really only of use during development to find sources of alignment faults. There's therefore no real incentive to make the services themselves very fast. One would hope that in a stable, production system, the number would be more or less constant, and not interesting enough to continue to track. Do you see any variation in transactions?

Can you identify what's generating the 486 faults you're seeing, eliminate them and then remove or disable the sampling code for production?

[John McL]

Is there any reason why you would expect the alignment faults to vary much when the code is on Production?  If not I'd take some typical data back to your development system and use it to refine the code, and then not include your diagnostic code when you go to Production.

Also, I wouldn't use LIB$INIT_TIMER and LIB$STAT_TIMER, the latter I ssume is called 4 times to get all the data you want.  Use SYS$GETTIM and SYS$GETJPI, the latter with an item list that includes all the requested values, and calculate the difefrences yourself. 

Minimising calls to LIB$ and SYS$ routines is a good idea because there's overheads like checking that you have write access to memory where output values will be written, and of course all the internal code in those routines to deal with different input. 

[John Gillings · Accepted solution]

Glenn,

   Simple experiment. attached. The routine "bad" performs 1000 unaligned additions. The first loop repeats the routine 100000 times. The second repeats it (to remove the influence of the image activation pagefault). The third does the same thing surrounded by your START/GET/STOP, the fourth moves the START and STOP outside the loop.

Here are the results.

 ELAPSED:    0 00:00:01.02  CPU: 0:00:01.03  BUFIO: 0  DIRIO: 0  FAULTS: 1
 ELAPSED:    0 00:00:01.02  CPU: 0:00:01.06  BUFIO: 0  DIRIO: 0  FAULTS: 0
 ELAPSED:    0 00:00:01.36  CPU: 0:00:01.35  BUFIO: 0  DIRIO: 0  FAULTS: 0
 ELAPSED:    0 00:00:00.94  CPU: 0:00:00.93  BUFIO: 0  DIRIO: 0  FAULTS: 0

As expected, the START/GET/STOP loop is more expensive, but curiously the one with just the GET is actually faster than the loops with no monitoring. Note that I'm seeing less than 350msec for 100000 repeats of the START/GET/STOP cycle, so I don't know where your numbers are coming from.

        .title timealign
$AFRDEF
reps=100000
        .psect data,rd,wrt,noexe,quad
l: .LONG
   .BYTE
a: .LONG
.align quad
BufSiz=1024
b: .BLKB BufSiz

        .psect code,rd,nowrt,exe
        .entry start,^M<R2>
        MOVL #reps,R2
        CALLS #0,G^LIB$INIT_TIMER
loop:   CALLS #0,bad
        SOBGTR R2,loop
        CALLS #0,G^LIB$SHOW_TIMER

        MOVL #reps,R2
        CALLS #0,G^LIB$INIT_TIMER
loop0:  CALLS #0,bad
        SOBGTR R2,loop0
        CALLS #0,G^LIB$SHOW_TIMER

        MOVL #reps,R2
        CALLS #0,G^LIB$INIT_TIMER
loop1:    PUSHL #BufSiz
          PUSHAL b
          PUSHL #AFR$C_BUFFERED
          CALLS #3,G^SYS$START_ALIGN_FAULT_REPORT
          CALLS #0,bad
          PUSHAL l
          PUSHL  #BufSiz
          PUSHAL b
          CALLS #3,G^SYS$GET_ALIGN_FAULT_DATA
          CALLS #0,G^SYS$STOP_ALIGN_FAULT_REPORT
        SOBGTR R2,loop1
        CALLS #0,G^LIB$SHOW_TIMER

        MOVL #reps,R2
          PUSHL #BufSiz
          PUSHAL b
          PUSHL #AFR$C_BUFFERED
          CALLS #3,G^SYS$START_ALIGN_FAULT_REPORT
        CALLS #0,G^LIB$INIT_TIMER
loop2:    CALLS #0,bad
          PUSHAL l
          PUSHL  #BufSiz
          PUSHAL b
          CALLS #3,G^SYS$GET_ALIGN_FAULT_DATA
        SOBGTR R2,loop2
        CALLS #0,G^LIB$SHOW_TIMER
        CALLS #0,G^SYS$STOP_ALIGN_FAULT_REPORT
        RET
        .ENTRY bad,^M<R3>
        MOVL #1000,R3
badloop: INCL a
        SOBGTR R3,badloop
        RET
        .END Start

[Dennis Handly]

On HP-UX, this can be 1 to 2 orders of magnitude since reporting requires a user signal handler and the emulation is done in the kernel or even in the CPU.

Also on HP-UX it isn't as bad, since the default is natural alignment and it aborts if not.  So most applications are compiled with the right options to prevent the alignment traps in the first place.

[Hoff]

That's not a default with that abort-penalty for an unaligned reference Dennis, that's a requirement.

The default on all of the OpenVMS compilers is natural alignment, which may or may not be the best model.

With OpenVMS, the programmer has to disable that alignment via directive, via compiler qualifier (switch), or via some code construct that the compiler writers either hadn't handled or hadn't foreseen. 

If there was an option to abort on unaligned references (with some decent traceback), I suspect some OpenVMS folks would use it.  Particularly given the (large) penalty for unaligned references within the Itanium architecture.

[jreagan]

Hoff, look closer at the defaults for COBOL and BASIC.  Not as aligned as you think.  However, the compiler will generate multiple instructions to load the data in pieces to avoid alignment faults.

Back to the question at hand.  Yes, there is certainly a Heisenberg effect with asking for fault reporting.

From the SRM Vol 1, User Mask

ac flag : 0: unaligned data memory references may cause an Unaligned Data Reference fault.

               1: all unaligned data memory references cause an Unaligned Data Reference fault

Note the "may" in the 0 case.  The Itanium architecture allows implementations to handle some unaligned references totally 'on-chip'.  I suspect unaligned references inside the same cache line (or perhaps just within a 64-bit quadword) are handled 'on-chip' and VERY fast.

However, when you use the system services that you mention, the 'ac' flag gets set in the user mask.  So now EVERY unaligned memory reference causes a fault, traps to OpenVMS, which in turn takes out a spinlock in order to fix up the unaligned reference, and then in turn signals the unaligned access fault to the program.  So just by looking, you increase the overhead.

The same holds true for using SET BREAK/UNALIGNED in the debugger or even the SDA FLT support.

[abrsvc]

It would seem to me that the time cost of the monitoring is irrelevant.  I would expect that the developers use the instrumented code to locate the alignment faults in order to "fix" them.  Once "fixed" there is no longer a need for the instrumentation and thus no cost on the production system.  Lets face it, the goal is to avoid the alignment faults.  Once this has been accomplished during the testing phase, the instrumentation (specific to these faults) should be disabled.

Just my approach...

Dan

[jreagan]

I agree with Dan 100%

[Glenn Wolf]

John:

Thanks for taking the time to provide the example; it's very similar to the C example from Eight-Cubed, which I had already exercised.  It provided the assurance that I needed - yes, I was doing something wrong, and forced me to look closer at my code to find it.

It turns out that when changing my alignment fault reporting from exception based to buffered, I introduced a bug that caused it to continue to use the exception approach anyway, thus the "similarity" of my test results between the exception based and what-I-thought-was-buffered.  I should have verified that my code was really doing what I expected before posting.

Now that I've corrected THAT oversight, I see results very similar to yours - a millisecond or two to start the alignment fault collection, and nothing measurable to report it. 

It is the exception processing that was taking the extra time.  Yet another thing to be wary of (as has been reported in other posts) when moving to Itanium.

To answer some of the other questions, yes we may see some variability in the number of alignment faults by transaction.  The transactions process requests that are presented in a "query language" (think SQL, but not too hard), and we will see the query usage change over time.  Today our transactions vary in duration from a few milliseconds to hundreds of milliseconds, based on what they are doing, so I am quite willing to pay a millisecond or two to be able to correlate a rise in alignment faults to a particular transaction signature.  And, as it is coded today, we can easily turn on or off the alignment fault reporting in real time if it gets in the way.

We will certainly pursue the reported alignment faults and eradicate as many as possible, but I'm pretty certain that we won't get to zero.  This data will help us understand how close to zero we can get.

Thank you to all who responded. As always, this forum is of immense help in finding the solutions that I need.

Glenn

[Dennis Handly]

>That's not a default with that abort-penalty for an unaligned reference Dennis, that's a requirement.

I don't think I understand that you said?  From the subject of this topic, I assume the default on OpenVMS is to continue on unaligned accesses and be very slow.

>The default on all of the OpenVMS compilers is natural alignment, which may or may not be the best model.

I don't think there is anything wrong with it.  :-)

But this means the topic author isn't taking the default and is cheating and the compiler doesn't provide help.

>the 'ac' flag gets set in the user mask.  So now EVERY unaligned memory reference causes a fault, traps to OpenVMS, which in turn takes out a spinlock in order to fix up the unaligned reference

This sounds completely backwards and not how HP-UX does it.  There the default is set to 1 and the process aborts on an alignment trap.

If you set it to 0, then the kernel emulates the instruction, if the chip doesn't handle it.

This gives applications a choice and allows the chip to handle it.

[H.Becker]

>>> By the way, our test environment is an HP rx2620  (1.60GHz/6.0MB) with 16GB of memory, running OpenVMS V8.3.  We see similar behavior on our intended production environment: HP BL860c i2  (1.60GHz/5.0MB) 16 cores with 32GB of memory, running OpenVMS V8.4.

>>> It is the exception processing that was taking the extra time.  Yet another thing to be wary of (as has been reported in other posts) when moving to Itanium.

You should see much better exception performance on 8.4.

[Hoff]

:>That's not a default with that abort-penalty for an unaligned reference Dennis, that's a requirement.
:
:I don't think I understand that you said? From the subject of this topic, I assume the default on OpenVMS is to :continue on unaligned accesses and be very slow.

If I interprete "default" as indicating what happens when the compiler doesn't correctly predict data alignment, and when the run-time is "unforgiving" about that, then that is what I'd consider a "requirement" and not a "default".

If I interprete "default" as what happens when the compiler doesn't correctly predict data alignment" and the run-time is 'unforgiving', but you can switch either or both the compiler and (particularly) the run-time 'forgiving'", then that's a different design choice.

The VMS run-time is 'forgiving'. 

Whether the compiler misdetected the alignment is certainly debateable; generating the extra instructions unnecessarily is certainly bad, but mispredicting unaligned data is bad, too.

When the compiler misses on the data alignment (often enough), application performance craters.

Equivalent to 10,000 to 15,000 instructions per alignment fault.

Whether that performance hit really matters depends on various factors, including the numbers of faults and what else the code is doing.  (There are other things that will slow down application performance and to varying degrees, such as cache misses or most anything that'll trigger a bubble, I/O, etc.  And off the top, I don't recall the analogous "instruction" hit for I/O, but that's huge, too.)

VMS doesn't have anything that's really comparable to Vtune, unfortunately.

Handling unaligned references in a compiler with the insertion of "extra" instructions is normal.  Having to add extra instructions probably happened with VAX (been a while since I looked at that) and those extra instructions were commonplace on Alpha (both for data (un)alignment, and for dealing with instruction subsets), and it's a necessity on Itanium.  Having the compiler and the run-time trigger an application-level unaligned-data error (on VMS) isn't.

Itanium is variously perceived as either a limited-use architecture, and as being sufficiently weird that the typical code-scheduling optimizations implemented for other architectures can't automatically be reused, so there aren't many open-source compilers that target the architecture.  gcc is one of the few, and I don't know how actively that's being maintained and extended for Itanium.  One of the HP folks stated "the need for improved gcc performance for Itanium is urgent", and that was from around five years ago.  The LLVM folks report that that tool-chain has yet lower performance than gcc on Itanium, and there wasn't any activity with that back-end with Itanium when last I checked.

But if past code-generation improvements with compilers other architectures are any guide, I wouldn't expect a huge improvement even with a large investment in the Itanium compilers.  Barring degenerate cases - such as massive numbers of alignment faults, as can arise here - the performance-improvement percentages just aren't there with the compilers, as compared with other changes in computer designs.

[jreagan]

The VAX compilers accessed the memory without regard to alignment.  The VAX microcode did all work.  On machines like the 11/780, aligned vs unaligned didn't make much difference.  On later model VAXen, it did help to a small degree.  The biggest help was to longword align code labels.

On Alpha, the first revision of the architecture ONLY had longword and quadword memory accesses.  The compilers were required to fetch larger chunks of memory and mask/shift.  There is also the _U forms that mask the effective-address to fetch quadwords above or below (helpful in fetching unaligned data).  Note that fixing alignment faults on Alpha can help performance too.  The PAL code fixup isn't free.  The defaults on the Alpha compilers are still EV4-era instruction sets (ie, no word, no byte).  You need /ARCH=HOST or something to enable the newer instructions.

[Dennis Handly]

>If I interpret "default" as indicating what happens when the compiler doesn't correctly predict data alignment, and when the run-time is "unforgiving" about that, then that is what I'd consider a "requirement" and not a "default".

(Unfortunately, I no longer know what the last "that" is referring.)

On the HP-UX compilers, there is no predicting.  The compilers only do what they are told and will assume natural alignment unless options, pragmas, attributes or typedefs are used to indicate misaligned data.

>If I interpret "default" as what happens when the compiler doesn't correctly predict data alignment" and the run-time is 'unforgiving', but you can switch either or both the compiler and (particularly) the run-time 'forgiving'", then that's a different design choice.

On HP-UX, it really isn't the "runtime" since the work is done in the kernel.  Or on PA-RISC, in a bolted on signal handler library.

And on PA-RISC it is so slow, that reporting of the faults doesn't have to be much slower.

[Hoff]

So that compiler implementation transfers the Itanium alignment requirements and particularly pushes at least this aspect of the architecture from the compiler's analysis processing onto the programmer, and HP-UX enforces unalignment data errors at run-time.  

Certainly makes for simpler compiler designs, and vastly simpler code analysis.  And a far larger incentive for code coverage testing by programmers targeting HP-UX, certainly.

If there is no means to switch on code analysis and run-time handling of unaligned data, then the behavior is not really what I'd consider a "default".  This behavior is a requirement.  ("Default" implies there are alternatives.  And based on what I'm reading here, there aren't.  Unaligned data causes an HP-UX application to receive (what I presume is probably) a signal.  That the application would then fail.  

(It's conceivably that sufficiently gonzo programming requirements could lead to the implementation an application-level fix-up and some sort of a recovery, but I'd doubt most HP-UX programmers would bother.)

The VMS compilers do rather more here, and the run-time (which is also implemented in privileged code) fixes up cases where the data isn't alighed.

The OP has the answer, and certainly I've learned rather more about the design and code analysis features in the HP-UX compilers.  Thanks.

[jreagan]

Yeah, the VAX strongly influenced the compiler's ability to tightly pack data.  Partially for PDP-11 compatibility and partially since the first 11/780s shipped with 256KB of memory. :)  [I suspect that Dave Cutler had some hand in the decision as well.  Next time any of us sees Andy G, ask him.]

For instance, VAX Pascal will let you put a 32-bit integer on a BIT boundary!

PACKED RECORD

  F1: BOOLEAN;   (* One bit big, starting at offset 0 *)

  F2: INTEGER;    (* 32bits bit, starting at offset 1 *)

END;

Even on VAX, you have to extract from memory into a register, operate on the register, and insert it back.

When we ported to Alpha, we changed all the defaults so that F2 field would now aligned on at least a byte boundary for a PACKED record and 32-bit boundary for an "unpacked" record.  [We still have qualifier to get VAX packing rules in case you have old VAX binary data on disk.]

[Dennis Handly]

>and HP-UX enforces unaligned data errors at run-time.

(Actually the hardware does this.)

>And a far larger incentive for code coverage testing by programmers targeting HP-UX, certainly.

It depends.  To get misaligned data, you usually have to tell the compiler you are cheating for struct layout.  (Of course you can add non-portable casts that the compiler will warn about.)
 
>If there is no means to switch on code analysis and run-time handling of unaligned data

The code analysis warnings are always on.  You can optionally reset the flag to get the hardware and kernel to handle them.

>then the behavior is not really what I'd consider a "default".  This behavior is a requirement.  ("Default" implies there are alternatives.

(Ah, ok.  So you don't believe in "you can have any color you want, as long as it is black"?

But in this case, you can change the default by looking at the fine print.  :-)

>Unaligned data causes an HP-UX application to receive a signal.  That the application would then fail.

This is the default but it can be changed.  Either by enabling belts and suspenders code generation and/or passing the buck to the hardware and kernel.

>could lead to the implementation an application-level fix-up and some sort of a recovery

You could say this was what was done on PA-RISC.

>The VMS compilers do rather more here

I wouldn't necessarily say it does more, it's that its default is different.  ;-)

You have to order the HP-UX compilers to use different alignments and packing and then there are options to handle the non-typesafe coding cases.

[Hoff]

OK; now I'm completely confused.

I know what Itanium is (not) doing, but whatever HP-UX is doing here seems, well, just as differently-odd as Itanium itself.

Off to read some HP-UX compiler documentation.

[Hoff]

John: based on a quote from DEC for a VAX-11/780 to VAX-11/785 upgrade, eight megabytes of VAX-11/780 memory cost US$36,000 back about 1985.  (That was MS780-E series)  We ended up doing that upgrade with used memory (MS780-C series), and that was "only" US$10,000 for that part of the upgrade.  At the time, an 8 MB VAX-11/785 was a very large VAX box.

I'm well aware of the data packing and padding on VAX, Alpha and Itanium running OpenVMS, and the related compiler pragmas and such.  (That's for C, other languages vary.)  And its history, for that matter.

It's the "completely different world" of HP-UX and its compilers that's the oddity (to me) here. 

But then HP-UX and its compilers on Itanium is presently only a curiosity here (for me), for reasons not germane to this discussion.  And as mentioned in another reply of mine, I'll be scrounging for technical papers on the compiler and the operating system platform, if anyone has suggestions.

[Dennis Handly]

>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]

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]

>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]

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]

>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.