> On Aug 15, 2023, at 8:49 AM, MegaIng <trampch...@hotmail.de> wrote:
>
>
> 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?
It simply seems wrong. In pdp11.h UNITS_PER_WORD is 2, which is what the
machine requires. And that works fine.
Perhaps the issue is that the libgcc routines implement operations not handled
by the target hardware, or by expansion in the machine description. So for 16
bit machines you're going to need a bunch of 32 bit support routines, but
probably not 16 bit support routines. There are some examples, though. Not
all pdp11s have divide instructions so there is a udivhi3 function in libgcc,
and the pdp11 config files call for that to be included.
paul
