Will my VisualDSP++ code work with the GNU Toolchain?

I've got some code that I wrote with VisualDSP++, but now I want to use it in a project I'm doing on Linux using the Blackfin GNU Toolchain.  Will my code work with GCC/GAS etc or will I need to make changes?

Parents
  • You will almost certainly have to make some changes to your code in order to get it to work.  Both the GNU Toolchain and VisualDSP++ contain many extensions to improve performance or make life easier for the developer.  Unfortunately these also make life more difficult for the developer if they want to change toolchain.  Converting your code can be trivial and quick, but for more complex code it can be prohibitively time-consuming.

    There are six issues you may want to consider before continuing:

    1- The Compiler Driver - As soon as you try and compile, you will notice that most of the command-line switches you are calling are completely different and you will need to check the GCC documentation to find the appropriate equivilant.  The GNU compiler driver also treats file extensions differently than VDSP.  For instance, many VDSP assembly files are .asm, however the compiler driver will not recognise it as such (preferring .s or .S) and will assume it is an object to be linked.

    2- The Compiler - As already mentioned, there are many extensions in both compilers and equivilants will need to be found if they have been used.  Additionally, built-ins will need to be checked to ensure they use the same syntax.  Other considerations are pragmas (GCC tends to use attributes instead) and inline assembly.

    3- The Assembler - If your code contains hand written assembly, you will need to make various changes to make GAS accept it.  For instance, GAS doesn't accept the LO/HI or BITPOS builtins, as well as various other directive extensions.

    4- The Linker - Again, the linker command line syntax is different, but you also can't control memory placement like you do in a VDSP LDF if you're running under Linux.  Although there is equivilent (but differently syntaxed) linker script functionality for the GNU linker if you're running on bare-metal.

    5- Libraries - If your code depends on libraries, you will need to ensure an equivilant library exists for blackfin linux.

    6- Bare-Metal vs Linux - Running code under Linux is fundamentally different to running code on bare metal, like you do with VisualDSP++.  Since your code will be running in userspace, you can't talk directly to the hardware.   Instead the kernel manages the hardware and user mode applications have to talk to the hardware via a kernel driver.  The kernel also manages memory placement, meaning the application doesn't know where data has been placed.  If your algorithm relies on specific relative placement of certain data structures controlled by your LDF, you may run in to problems.

    If all of that hasn't scared you off, then you have some reading to do.  The following link gives a much more in depth look at exactly what needs to be done in order to port your code.

    http://docs.blackfin.uclinux.org/doku.php?id=visualdsp:port_program_to_linux

    Feel free to ask for advice on any specific problems you're having that aren't addressed by the link above.

    Stu

Reply
  • You will almost certainly have to make some changes to your code in order to get it to work.  Both the GNU Toolchain and VisualDSP++ contain many extensions to improve performance or make life easier for the developer.  Unfortunately these also make life more difficult for the developer if they want to change toolchain.  Converting your code can be trivial and quick, but for more complex code it can be prohibitively time-consuming.

    There are six issues you may want to consider before continuing:

    1- The Compiler Driver - As soon as you try and compile, you will notice that most of the command-line switches you are calling are completely different and you will need to check the GCC documentation to find the appropriate equivilant.  The GNU compiler driver also treats file extensions differently than VDSP.  For instance, many VDSP assembly files are .asm, however the compiler driver will not recognise it as such (preferring .s or .S) and will assume it is an object to be linked.

    2- The Compiler - As already mentioned, there are many extensions in both compilers and equivilants will need to be found if they have been used.  Additionally, built-ins will need to be checked to ensure they use the same syntax.  Other considerations are pragmas (GCC tends to use attributes instead) and inline assembly.

    3- The Assembler - If your code contains hand written assembly, you will need to make various changes to make GAS accept it.  For instance, GAS doesn't accept the LO/HI or BITPOS builtins, as well as various other directive extensions.

    4- The Linker - Again, the linker command line syntax is different, but you also can't control memory placement like you do in a VDSP LDF if you're running under Linux.  Although there is equivilent (but differently syntaxed) linker script functionality for the GNU linker if you're running on bare-metal.

    5- Libraries - If your code depends on libraries, you will need to ensure an equivilant library exists for blackfin linux.

    6- Bare-Metal vs Linux - Running code under Linux is fundamentally different to running code on bare metal, like you do with VisualDSP++.  Since your code will be running in userspace, you can't talk directly to the hardware.   Instead the kernel manages the hardware and user mode applications have to talk to the hardware via a kernel driver.  The kernel also manages memory placement, meaning the application doesn't know where data has been placed.  If your algorithm relies on specific relative placement of certain data structures controlled by your LDF, you may run in to problems.

    If all of that hasn't scared you off, then you have some reading to do.  The following link gives a much more in depth look at exactly what needs to be done in order to port your code.

    http://docs.blackfin.uclinux.org/doku.php?id=visualdsp:port_program_to_linux

    Feel free to ask for advice on any specific problems you're having that aren't addressed by the link above.

    Stu

Children
No Data