FPGARelated.com
Forums

nios c++ and ethernet [may by ot?]

Started by g.k. February 2, 2004
Hi all!
I just started to use an apex-board with nios-softcore and want to
write some programs using the plugs-library in c++!
I've already done some experiments and have two questions:

1. I would like to know if using c++ is okay or if there are
any backdrops (speed, size, ...)?

2. I was not able to put c++ together with the plugs library. The compiler
has no problems but the linker marks all calls to that library as
not resolveable (with standard c there is no such problem)!
Is anyone using this combination? Do I have overlooked anything?


TIA
g.k.


As there are no responces I'm wondering if there is anyone who has
used the plugs-library and/or c++ on the nios softcore?


"g.k." <replay@newsgroup> wrote in message news:<40278e06$1@e-post.inode.at>...
> As there are no responces I'm wondering if there is anyone who has > used the plugs-library and/or c++ on the nios softcore?
Sorry GK, I didn't catch your first post. Was on vacation far away from internet access :) I cannot be of too much help as I am not a c++ programmer, but I have seen one customer (quite a while ago) who used C++ to create an application with Plugs & Nios. It was a simple application to send/receive data with a custom TCP application on a PC -- so I know its possible. The one thing I remember that was special was includes were inside an "extern "C" { <includes here> } statement... like this: extern "C" { #include "excalibur.h" #include "plugs.h" #include "plugs_example_designs.h" } I don't believe there were any other special things required for the project to compile. I believe this is because the library files (plugs & Ethernet mac driver) are compiled C files with no C++ about them... as I said though I'm a c++ bonehead. Jesse Kempa Altera Corp. jkempa at altera dot com
> The one thing I remember that was special was includes were inside an > "extern "C" { <includes here> } statement... like this:
And for those C++ "boneheads" wondering what this does: It is equivalent to putting an extern "C" modifier in front of all the function declarations in the contained header file. Why is this needed? Because C++ uses "name-mangling" to turn the user-friendly names you see in your code into nearly unreadable function names that incorporate function name, type information of the arguments, and likely some other stuff. The reason it does this is that you can have overloaded functions that have same name and different argument types, but the compiler wants to generate object code that any old linker can properly link (I think). There are probably other reasons (like, where else would it store the type info?) that I can't think of. Bottom line, by saying extern "C" you're telling the compiler that the function will not have multiple variants and thus the compiler should use the straight-forward name, which is just the function name with a _ in front (assuming __cdecl calling convention) rather than the mangled name. This is needed because the library you are linking to (or C files) were compiled by a C-compliant compiler that did not mangle the names. Besides linking to C code, this can be handy when cutting down on the size of the debug information in your executable. And just in case you're a C/C++ coder and were confusing this with calling conventions (as I was until recently), C & C++ have the same default calling convention (__cdecl). That is, there is no difference in the way they pass function parameters and return values on the stack/registers -- they both pass parameters on the stack with the caller responsible for stack clean-up. Paul Leventis Altera Corp.
Many thanx for that great insight!

Regards
g.k.


kempaj@yahoo.com (Jesse Kempa) writes:

> The one thing I remember that was special was includes were inside an > "extern "C" { <includes here> } statement... like this: > > extern "C" { > #include "excalibur.h" > #include "plugs.h" > #include "plugs_example_designs.h" > }
This should have been done *inside* plugs.h: #ifndef _plugs_ #define _plugs_ #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif #endif // _plugs_ This type of structure is used in excalibur.h so it should have been done in plugs.h too (at least for consistency). Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
> This should have been done *inside* plugs.h:
Yes, it should be. I will file a Software Problem Report on this today. Paul Leventis Altera Corp.