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

[Gravis]

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

[piotr5]

you're right, thanks for the helpful hints.

[dobkeratops]

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