compatibility problems between gnu and diab - VxWorks

This is a discussion on compatibility problems between gnu and diab - VxWorks ; Hi everybody, this is the HW/SW configuration I'm using: HW configuration: - SBC DY4181, with PowerPC 7410 processor, enhanced with Altivec technology SW configuration: - Tornado2.2.1/VxWorks5.5.1 (support for both the Gnu and Diab toolchains) - BSP for the DY4181 by ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: compatibility problems between gnu and diab

  1. compatibility problems between gnu and diab

    Hi everybody, this is the HW/SW configuration I'm using:

    HW configuration:
    - SBC DY4181, with PowerPC 7410 processor, enhanced with Altivec
    technology
    SW configuration:
    - Tornado2.2.1/VxWorks5.5.1 (support for both the Gnu and Diab
    toolchains)
    - BSP for the DY4181 by DY4, Rel. 1.4

    Do you think it's possible to do the following:

    1. Creating a kernel containing only C code, without any C++ runtime
    support included, and building it using the Gnu toolchain (that is,
    from the Tornado2.2.1 IDE I create a bootable application for the
    PPC604gnu toolchain, then, from the VxWorks tab of the workspace view,
    I remove the C++ components, being careful NOT TO ADD any C++ source
    file to the bootable application)

    2. Creating a C++ downloadable application where in some way (I don't
    know how at the moment) I have included the Diab C++ runtime and
    building it using the Diab toolchain (this time from the Tornado
    project facility I create a downloadable application and choose
    PPC604diab as toolchain, then in some way I add the Diab C++ runtime
    support in the form of static libraries or .o modules, finally I add
    all C++ source files that make up the C++ application)

    3. Boot the target and, once the kernel is up and running, download the
    C++ application using the target shell (ld < myCPPApplication.out) and
    launch it invoking from the target shell its entry point

    The underlying question is whether the incompatibilities among binaries
    generated by different compilers derive exclusively from the presence
    of C++ code or there is something more involved...

    Thank you,

    Luca


  2. Re: compatibility problems between gnu and diab

    lcdll@libero.it wrote:
    > Hi everybody, this is the HW/SW configuration I'm using:
    >
    > HW configuration:
    > - SBC DY4181, with PowerPC 7410 processor, enhanced with Altivec
    > technology
    > SW configuration:
    > - Tornado2.2.1/VxWorks5.5.1 (support for both the Gnu and Diab
    > toolchains)
    > - BSP for the DY4181 by DY4, Rel. 1.4


    First, Wind promises that the Diab and GNU compiler C compilers
    are totally compatible, and someone over there told me they have
    a specific test suite to prove the compatibility. Also, they
    explicit;ly say the C++ compilers are *totally* incompatible,
    for anumberof reasons.

    >
    > Do you think it's possible to do the following:
    >
    > 1. Creating a kernel containing only C code, without any C++ runtime
    > support included, and building it using the Gnu toolchain (that is,
    > from the Tornado2.2.1 IDE I create a bootable application for the
    > PPC604gnu toolchain, then, from the VxWorks tab of the workspace view,
    > I remove the C++ components, being careful NOT TO ADD any C++ source
    > file to the bootable application)

    Yes. But I recommend that you *do* configure in the Diab C++
    support routines to set up for the next step.

    > 2. Creating a C++ downloadable application where in some way (I don't
    > know how at the moment) I have included the Diab C++ runtime and
    > building it using the Diab toolchain (this time from the Tornado
    > project facility I create a downloadable application and choose
    > PPC604diab as toolchain, then in some way I add the Diab C++ runtime
    > support in the form of static libraries or .o modules, finally I add
    > all C++ source files that make up the C++ application)

    Yes.
    >
    > 3. Boot the target and, once the kernel is up and running, download the
    > C++ application using the target shell (ld < myCPPApplication.out) and
    > launch it invoking from the target shell its entry point

    Yes.
    >
    > The underlying question is whether the incompatibilities among binaries
    > generated by different compilers derive exclusively from the presence
    > of C++ code or there is something more involved...

    Supposedly only the C++ code is incompatible (i.e. not inter-linkable).

    However, if you avoid linking together GNU C++ object files with Diab
    C++ object files, and you build two applications, a purely GNU one, and
    a Diab one, and build the kernel with C++ runtime support for both
    tools, you should be able to run either application or both
    concurrently. It's just that they can communicate only through system
    calls.




    >
    > Thank you,
    >
    > Luca
    >


  3. Re: compatibility problems between gnu and diab

    Hi Bill, tahnk you for your answer, there's something not clear in it
    for me:
    You wrote:
    "Yes. But I recommend that you *do* configure in the Diab C++
    support routines to set up for the next step. "
    I cannot understand what you mean here...

    Anyway, given that incompatibility among Diab and Gnu compilers derive
    from the presence of C++ code, what still remains to discover is how to
    add/remove C++ runtime for Diab to/from bootables or
    downloadables...Let me show you in more detail:

    My starting point is:
    A C kernel based on the Gnu tool chain where I removed gnu C++ runtime
    (this can easily be made from the workspace view of the tornado IDE).

    (Note that I'm using a DY4181 SBC for which DY4 only released a
    Gnu-compliant BSP, so, when I create the bootable application from the
    Tornado IDE project facility and choose to base it on the project
    located in $(WIND_BASE)/target/config/proj/dy4181/dy4181_vx.wpj, I
    cannot choose the toolchain, I'm forced to use the Gnu toolchain)

    Now, I have to deal with Diab C++ runtime; I have to coices here:
    1. include the Diab C++ runtime into the kernel (I don't know how to
    do)
    2. leave the kernel without any Diab C++ runtime and include it into my
    dowloadable application (I don't know how to do this too)

    Can you help me in some way or give me references to documentation I
    can read about the subject?

    Thank you very much

    Luca


  4. Re: compatibility problems between gnu and diab

    Hi Luca,

    You may want to check and see if the BSP/board vendor has plans to
    support VxWorks Diab compiler.
    The other option you have is to port the BSP on your own to support the
    Diab toolchain.
    The only difficulty you'd anticipate is the inline assembly calls which
    quite different in GNU and Diab.

    Cheers

    AK


  5. Re: compatibility problems between gnu and diab

    Hi Luca,

    You may want to check and see if the BSP/board vendor has plans to
    support VxWorks Diab compiler.
    The other option you have is to port the BSP on your own to support the
    Diab toolchain.
    The only difficulty you'd anticipate is the inline assembly calls which
    quite different in GNU and Diab.

    Cheers

    AK


  6. Re: compatibility problems between gnu and diab

    Hi macabbi,

    > You may want to check and see if the BSP/board vendor has plans to
    > support VxWorks Diab compiler.


    unfortunately DY4 has no plans to release a Diab compliant version of
    the BSP for the DY4181 SBC...

    Modifying the BSP is something I would like to avoid as much as
    possible....

    Thanks,

    Luca


  7. Re: compatibility problems between gnu and diab

    > Bill wrote:
    > "Yes. But I recommend that you *do* configure in the Diab C++
    > support routines to set up for the next step. "
    > I cannot understand what you mean here...


    I generally try to configure compiler runtime support into the kernel
    no matter which compiler is used, and I'm told that configuring both
    GNU and Diab runtimes into the kernel is possible. I haven't done it,
    however. I recommend this because I assume that there will be multiple
    applications that will use each of the runtime packages. If this
    weren't the case, then you would get the same memory size by packaging
    the compiler runtime into the one application as you would packaging
    it into the kernel.

    And, no, I can't tell you how to do the packaging with the project
    tool. I've rarely used it. Sorry.

    > Anyway, given that incompatibility among Diab and Gnu compilers derive
    > from the presence of C++ code, what still remains to discover is how to
    > add/remove C++ runtime for Diab to/from bootables or
    > downloadables...Let me show you in more detail:
    >
    > My starting point is:
    > A C kernel based on the Gnu tool chain where I removed gnu C++ runtime
    > (this can easily be made from the workspace view of the tornado IDE).
    >
    > (Note that I'm using a DY4181 SBC for which DY4 only released a
    > Gnu-compliant BSP, so, when I create the bootable application from the
    > Tornado IDE project facility and choose to base it on the project
    > located in $(WIND_BASE)/target/config/proj/dy4181/dy4181_vx.wpj, I
    > cannot choose the toolchain, I'm forced to use the Gnu toolchain)
    >
    > Now, I have to deal with Diab C++ runtime; I have to coices here:
    > 1. include the Diab C++ runtime into the kernel (I don't know how to
    > do)
    > 2. leave the kernel without any Diab C++ runtime and include it into my
    > dowloadable application (I don't know how to do this too)
    >
    > Can you help me in some way or give me references to documentation I
    > can read about the subject?
    >
    > Thank you very much
    >
    > Luca
    >


+ Reply to Thread