From: Paul Koning <paulkoning@comcast.net>
To: MegaIng <trampchamp@hotmail.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Porting to a custom ISA
Date: Tue, 15 Aug 2023 09:01:01 -0400 [thread overview]
Message-ID: <3870A0E9-5E7E-4CDF-A113-1D2192075953@comcast.net> (raw)
In-Reply-To: <DU0PR03MB97290F0C873CB041133538C2A214A@DU0PR03MB9729.eurprd03.prod.outlook.com>
> On Aug 15, 2023, at 8:49 AM, MegaIng <trampchamp@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
next prev parent reply other threads:[~2023-08-15 13:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 11:37 MegaIng
2023-08-15 12:06 ` Richard Biener
2023-08-15 12:48 ` Paul Koning
[not found] ` <DU0PR03MB972974FA63A93A6D67754428A214A@DU0PR03MB9729.eurprd03.prod.outlook.com>
[not found] ` <D0E7DFB2-A980-4376-8DE4-6936A2714FC9@comcast.net>
2023-08-15 14:38 ` MegaIng
2023-08-21 14:16 ` Georg-Johann Lay
2023-08-15 12:40 ` Paul Koning
2023-08-15 12:49 ` MegaIng
2023-08-15 13:01 ` Paul Koning [this message]
2023-08-15 13:26 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3870A0E9-5E7E-4CDF-A113-1D2192075953@comcast.net \
--to=paulkoning@comcast.net \
--cc=gcc@gcc.gnu.org \
--cc=trampchamp@hotmail.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).