On Aug 15, 2023, at 7:37 AM, Paul Koning wrote:
On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc <gcc@gcc.gnu.org> wrote:
...
Also, on another backend I saw comments relating to libgcc (or newlib?) not
working that well on systems where int is 16bit. Is that still true, and what
is the best workaround?
I haven't seen that comment and it doesn't make sense to me. Libgcc certainly
is fine for 16 bit targets -- after all, GCC supports pdp11 which is such a
target. And while newlib doesn't have pdp11 support I have done some fragments
of pdp11 support for it, to give me a way to run the execution part of the GCC
test suite. One of these days I should do a better job. As far as I know it's
entirely doable.
The comment is in msp430.h and rl78.h, line 160. And it appears quite
common to artifically set `UNITS_PER_WORD` to 4 instead of the correct 2
or 1 when compiling libgcc accross other backends as well, including
avr, gcn. Is this out-of-date and no longer required for libgcc?
pdp11, in GCC, can have either 16 or 32 bit int, it's a compiler option.
Pointers are 16 bits, of course. And it does support larger types (even 64
bits), expanding into multiple instructions or libgcc calls. A lot of that is
handled by common code; the pdp11.md machine description handles a few of them
to optimize those cases beyond what the common code would produce. If you're
doing a 16 bit target you might look at pdp11 for ideas. One limitation is
that right now it does only C, mainly because the object format is a.out rather
than ELF. That could be fixed.
Thank you, I will take a closer look at pdp11.
paul
