From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-h1p-028590.sys.comcast.net (resqmta-h1p-028590.sys.comcast.net [IPv6:2001:558:fd02:2446::8]) by sourceware.org (Postfix) with ESMTPS id 2514E3858000 for ; Tue, 15 Aug 2023 13:01:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2514E3858000 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net Received: from resomta-h1p-027909.sys.comcast.net ([96.102.179.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h1p-028590.sys.comcast.net with ESMTP id VtYIqU7StTVSqVtfUqn2yu; Tue, 15 Aug 2023 13:01:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1692104464; bh=t5bVYVVBr8BbhPNbXvyG0MmCmO7xAcPQgcvQinWBi3U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=wvS6F4snEoT695tRJ7bbPPOcdPq4JKj1eMNKng79YyZwPyVGgOnUrDdwRp97DFG62 4+baliiAmdup3ybCcnyKTHK03akwhy7Dj97JUuF+di7vFm2Td/eJvEUQzekKBrkfQV iLiL+gwAqQ+dzIwVE6hx1lkMczJEhphCV6h/SurGcmmPDzkwz/vC1IOrXKp8TUJQzW V2sR2Pn7dFenHJrQh30sGQ2izy/OI23yN/lT4zFxzioxTd5YeyBk8h7HLNwOoG0MVw ki6Snbamaxe3Zmw9AUJ5dxWmkUvK1e4ppNzmKfs2gLJamztjzh0LU3iTMkptlnKgv9 0jsswNyv79JZw== Received: from smtpclient.apple ([73.60.223.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h1p-027909.sys.comcast.net with ESMTPSA id VtfRqPr2UHhepVtfSqX4zq; Tue, 15 Aug 2023 13:01:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: Porting to a custom ISA From: Paul Koning In-Reply-To: Date: Tue, 15 Aug 2023 09:01:01 -0400 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <3870A0E9-5E7E-4CDF-A113-1D2192075953@comcast.net> References: To: MegaIng X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On Aug 15, 2023, at 8:49 AM, MegaIng wrote: >=20 >=20 > On Aug 15, 2023, at 7:37 AM, Paul Koning wrote: >=20 >>=20 >>> On Aug 15, 2023, at 7:37 AM, MegaIng via Gcc = wrote: >>>=20 >>> ... >>> 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. =20 paul