Porting C++ from PA_RISC to Itanium - HP UX

This is a discussion on Porting C++ from PA_RISC to Itanium - HP UX ; I'm trying to estimate the cost of moving a large C/C++ application from HP-UX 11.11 PA_RISC 32-bit, to 11.23 Itanium 32-bit. We intend to re-compile from source with aCC. I've read various transition guides and papers, but I'd be grateful ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Porting C++ from PA_RISC to Itanium

  1. Porting C++ from PA_RISC to Itanium

    I'm trying to estimate the cost of moving a large C/C++ application
    from HP-UX 11.11 PA_RISC 32-bit, to 11.23 Itanium 32-bit. We intend to
    re-compile from source with aCC.

    I've read various transition guides and papers, but I'd be grateful if
    anyone could answer the following queries:

    Is Itanium's byte ordering the same as PA_RISC (big-endian)? We have a
    lot of code that directly manipulates bytes in words, so this would be
    an issue. (I know the IA64 can do either orientation, but I'm hoping
    HP-UX sets it to big-endian).

    Is Itanium's default 32-bit structure alignment the same as PA_RISC? If
    fields move, or structures get bigger, this could be an issue for us.

    Is 11.23's 32-bit shared memory model the same on Itanium? PA_RISC
    limits us to shmem from Quadrants 3 and 4, and only three quarters of 4
    (ie. 1.75Gb in total).

    Are there any other surprises I should know about? :-)

    Cheers,
    -nick


  2. Re: Porting C++ from PA_RISC to Itanium

    Nick Battle wrote:
    > I'm trying to estimate the cost of moving a large C/C++ application
    > from HP-UX 11.11 PA_RISC 32-bit, to 11.23 Itanium 32-bit. We intend to
    > re-compile from source with aCC.
    >
    > I've read various transition guides and papers, but I'd be grateful if
    > anyone could answer the following queries:
    >
    > Is Itanium's byte ordering the same as PA_RISC (big-endian)? We have a
    > lot of code that directly manipulates bytes in words, so this would be
    > an issue. (I know the IA64 can do either orientation, but I'm hoping
    > HP-UX sets it to big-endian).


    Yes, HP-UX remains big-endian on IPF. Otherwise, running PA applications
    and reading data files generated on past releases would be a major pain.

    >
    > Is Itanium's default 32-bit structure alignment the same as PA_RISC? If
    > fields move, or structures get bigger, this could be an issue for us.


    Can't say for sure as that's up to the compiler, not the OS. I thought
    depending on field position was undefined behavior according to the C
    Standard, though -- the compiler can reorder structures as it sees fit
    as long as it makes the code read the right memory address when it comes
    time to use it. Certainly a 32-bit integer is the same size on IPF as
    on PA2.0W, so I wouldn't expect big surprises unless the compiler tries
    to do cacheline alignment/padding for you as well (cacheline sizes do
    vary across the platform, after all).

    >
    > Is 11.23's 32-bit shared memory model the same on Itanium? PA_RISC
    > limits us to shmem from Quadrants 3 and 4, and only three quarters of 4
    > (ie. 1.75Gb in total).


    Yes and no. The 32-bit default address space layout for processes is
    very similar to PA (one big difference is that the Memory Mapped I/O
    space is not reserved on IPF [that's the last 0.25Gb for PA Q4], so
    you have 2Gb of shared address space by default). However, IPF does
    have an alternate address space layout PA can't support: Mostly Private
    Address Space (MPAS). That uses aliasing such that a 32-bit MPAS
    process has the whole 4Gb to do whatever it wants to. If it wants a
    3Gb SysV segment, it can make one [each MPAS process attached uses a
    private alias to the shared segment...] Check the 11.23 Adaptive
    Address Space whitepaper:
    http://docs.hp.com/en/8681/aas_white_paper.pdf
    for more details.

    Be aware that aliasing isn't performance-free, it complicates the
    translation code when it has to take these paths... so I would
    recommend using it sparingly.

    If you are really pushing the 2Gb shared memory boundary, you'd be
    a lot better off giving serious consideration to going 64-bit as part
    of the transition rather than staving off the absolute 4Gb boundary
    for a little while longer.

    >
    > Are there any other surprises I should know about? :-)


    Nothing that leaps to my mind... But the non-kernel work I do that
    gets cross compiled tends to be small apps (debugging tools) or
    code designed to recreate issues, so a large user-space project may
    have foibles I don't hit in my day-to-day. Others will chime in,
    I'm sure.

    Don

    >
    > Cheers,
    > -nick
    >


  3. Re: Porting C++ from PA_RISC to Itanium

    On 8 Nov 2006 05:34:05 -0800, Nick Battle wrote:
    > Is Itanium's default 32-bit structure alignment the same as PA_RISC? If
    > fields move, or structures get bigger, this could be an issue for us.


    AFAIK, it's the same.


    > Are there any other surprises I should know about? :-)


    aCC appears to be a bit more strict in its interpretation of the C and C++
    languages on Itanium.


    Christof

    --
    http://cmeerw.org sip:cmeerw at cmeerw.org
    mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

  4. Re: Porting C++ from PA_RISC to Itanium

    On Nov 8, 4:14 pm, Don Morris wrote:
    > > Is Itanium's default 32-bit structure alignment the same as PA_RISC? If
    > > fields move, or structures get bigger, this could be an issue for us.

    > Can't say for sure as that's up to the compiler, not the OS. I thought
    > depending on field position was undefined behavior according to the C
    > Standard


    I've since had it confirmed (via the ITRC forums) that the Itanium
    compiler should layout structure fields the same way, though I think
    you're right that it would be at liberty to do as it pleases. In
    reality, I have to port "bad code" - code that makes assumptions that
    aren't necessarily portable. Rewriting would be very expensive.

    > The 32-bit default address space layout for processes is
    > very similar to PA (one big difference is that the Memory Mapped I/O
    > space is not reserved on IPF [that's the last 0.25Gb for PA Q4], so
    > you have 2Gb of shared address space by default).


    That will help. The application is sensitive to the largest contiguous
    block of shared memory it can allocate, so on PA we are affected by the
    Quadrant boundaries and the allocation policy (which influences the
    fragmentation). The extra 0.25Gb will mean we can go that bit further
    if we have to.

    > However, IPF does have an alternate address space layout PA can't support:
    > Mostly Private Address Space (MPAS).


    I need to look into this (for the future). I think it's unlikely that
    we'll have to go beyond 2Gb for the time being, and as you suggested,
    64-bits is probably the way to go if we have to anyway.

    Thanks for the input,

    Cheers,
    -nick


  5. Re: Porting C++ from PA_RISC to Itanium

    Nick Battle wrote:
    > I need to look into this (for the future). I think it's unlikely that
    > we'll have to go beyond 2Gb for the time being, and as you suggested,
    > 64-bits is probably the way to go if we have to anyway.


    Even if you don't plan on going 64-bit soon, it would be good to
    enable some of the migration warning options of the compiler(s) - at
    least from time to time. It will give you an idea of where things
    might need to be changed and may even help you find some latent bugs.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  6. Re: Porting C++ from PA_RISC to Itanium

    Nick Battle wrote:
    : I've since had it confirmed (via the ITRC forums) that the Itanium
    : compiler should layout structure fields the same way, though I think
    : you're right that it would be at liberty to do as it pleases.

    It normally does but making the port easier was of more importance.
    Note: for C++, the (non-POD) class layout is completely different.

    : reality, I have to port "bad code" - code that makes assumptions that
    : aren't necessarily portable. Rewriting would be very expensive.

    Since you say C++ above, you may have problems unless you are using PODs.

  7. Re: Porting C++ from PA_RISC to Itanium

    On Nov 11, 6:24 am, dhan...@convex.hp.com (Dennis Handly) wrote:
    > Nick Battle wrote:: I've since had it confirmed (via the ITRC forums) that the Itanium
    > : compiler should layout structure fields the same way, though I think
    > : you're right that it would be at liberty to do as it pleases.
    >
    > It normally does but making the port easier was of more importance.
    > Note: for C++, the (non-POD) class layout is completely different.

    [...]
    > Since you say C++ above, you may have problems unless you are using PODs.


    (Sorry for the delay in responding)

    I'll have to check this carefully. The code with the layout assumptions
    is likely to be old legacy C code that should just be structures of
    POD. The newer C++ non-POD code is much cleaner. But I understand the
    issue - and thanks for pointing this out.

    Cheers,
    -nick


+ Reply to Thread