> Gabriel Dos Reis wrote: >I guess I would need to get my feet wet with > 1. minimal free-standing C++ implementations without exceptions As for getting started, you'll find much of the collected knowledge about using C++ on AVRs in the AVR Freaks thread below. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453
There are some other issues that are not in that thread. For example, the long-used method for applications to define data residing in Flash (prog_char typedef, et al) causes warnings in C++ with newer compiler versions (circa avr-gcc 4.2.2 and later). See the AVR Freaks thread for more information. I haven't looked into how (or, in fact, if) the Arduino environment resolves this issue. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=57011 > Gabriel Dos Reis wrote: > 2. get support for RTTI (without exceptions) >RTTI data are generally const and should be best stored in read only location. The same is true for v-tbl information, too. However, in the current implementation the v-tbl is in RAM (initialized with data from Flash). See the AVR Freaks thread below for some discussion. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=9238 > 3. exceptions (assuming 1 and 2 are done successfully) I would guess that implementing unwinding would require frame pointers for all of the functions in the call hierarchy. Currently, frame pointers are turned off (-fomit-frame-pointer) with any optimization above -O0 (I think). This aspect of optimization would need to change for applications built with exception handling. A special version of avr-libc, built to support exception handling, may be required, too. This is all speculation on my part and may or may not be useful. Don Kinzer _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
