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

[g.k.]

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.

 

[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?

 

[Jesse Kempa]

"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

 

[Paul Leventis (at home)]

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.

 

[g.k.]

Many thanx for that great insight!

Regards
g.k.

 

[Petter Gustad]

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?

 

[Paul Leventis (at home)]

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.