How to shrink your C++ code to fit on an Epiphany core

[Gravis]

While C++ is fully supported on the Epiphany, there are few things that will cause G++ to generate code too large to fit on an Epiphany core.

What to exclude from your C++ code:

• exceptions - any use of try, throw and catch will inflate your code.
• virtual functions - code generated to manage vtables is very large so any use of virtual inheritance is a bad idea.
• Run-Time Type Information - it's only useful when used with virtual functions, so dont use it.
• anything from the STL - the STL is great but it relies on the things mentioned above

G++ flags you should use:

Code: Select all

-Os -std=c++1y -fno-exceptions -fno-rtti -fno-threadsafe-statics -freg-struct-return -fno-default-inline

Explanation of flags:

• -Os - causes the compiler to optimize for size
• -std=c++1y - lets you use all the latest C++ features
• -fno-exceptions - excludes additional code needed for exception handling
• -fno-rtti - excludes Run-Time Type Information
• -fno-threadsafe-statics - excludes safety mechanism for static functions intended for multithreaded code
• -freg-struct-return - if you return a struct from a function it will try to fit it into a register
• -fno-default-inline - code in your class definition won't automatically be inlined (it does by default)

If you are serious about C++, this is worth reading: Using C++ Efficiently In Embedded Applications and Practical Guide to Bare Metal C++

[piotr5]

thanks for your hints and suggestions. there's one point I'm unsure of though: -fno-default-inline
as far as I have seen most people put only wrappers in the class-definition.
for example when porting a c-lib to c++ class structure. it makes sense to inline those!
everything else is then put elsewhere in the header or an external header file to be included there.
but then, maybe gcc will automatically optimize out wrapper functions anyway?
or will the wrapper function then linger around in the executable, never to be used?

also I should mention, using c++1y might not be a good idea. maybe better compromise for c++14?

as for not being allowed to use c++stdlib, anybody knows of a smaller lib?
any replacement for utf8 string-manipulation?

[Gravis]

there's one point I'm unsure of though: -fno-default-inline
as far as I have seen most people put only wrappers in the class-definition.
for example when porting a c-lib to c++ class structure. it makes sense to inline those!

the functions that will end up being smaller by inlining will be inlined. the just prevents the compiler from always inlining.

also I should mention, using c++1y might not be a good idea. maybe better compromise for c++14?

c++1y is currently the closest implementation to c++14 for gcc. your other option is c++11 which leaves out some nice fixes made in c++14. find the "-std=" options in the man page for e-gcc to see all the options.

as for not being allowed to use c++stdlib, anybody knows of a smaller lib?

you are probably best off just taking bits from another library and/or making your own code which is specific to the task.
here are some small libs:

• embxx - Embedded C++ Library
• uClibc++

any replacement for utf8 string-manipulation?

utf8 is backwards compatible with ascii, so they are binary compatible. however, the semantics to have full feature parity across all of UTF is far too large to fit. so long as you don't need to know details about individual characters, basic ascii manipulation will work just fine for utf8. however, i think the real question is why someone would be doing string manipulation on the epiphany.

[piotr5]

you're right, thanks for the helpful hints.

[dobkeratops]

virtual functions - code generated to manage vtables is very large so any use of virtual inheritance is a bad idea.

virtual functions were hugely problematic on the sony PS3 because they weren't even in the same address space.

Does the epiphany C++ compiler make any attempt to support them (perhaps generating some sort of stubs that dynamically read the required code in) or - like back on the PS3 - you're just much better off structuring code differently to avoid them altogether - sorting by types up-front, using a component architecture instead of OO.

[piotr5]

imho any hybrid-architecture like coprocessors and such is not fit for call-backs and the related stuff. maybe compilers should store a 2d-list of function-addresses, one entry per core? suppose you had an epiphany with 1024 cores, should every callback come with a list of 1025 function-variants and 1025 copies of that single function? I don't think so, 2 copies are enough, epiphany can execute code stored on other cores. if you're using callbacks you likely don't need high speed. however, c++ has an interesting feature, it can treat a fixed function as if it were a callback, thereby those functions are stored on the individual cores which can read the object. i.e. at compile-time the actual function being used is determined by template-parameters. with such a feature, what do you need vtables for? well, of course if datatype isn't known at compile-time...

[paran]

Thanks for hints. They are very helpful.