From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resdmta-a1p-077303.sys.comcast.net (resdmta-a1p-077303.sys.comcast.net [IPv6:2001:558:fd01:2bb4::d]) by sourceware.org (Postfix) with ESMTPS id E9B50385842C for ; Tue, 15 Aug 2023 12:40:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E9B50385842C 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-a1p-077058.sys.comcast.net ([96.103.145.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-a1p-077303.sys.comcast.net with ESMTP id VsKbqHpY1oT90VtLEqJpud; Tue, 15 Aug 2023 12:40:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1692103208; bh=Z2NtsUCYJpM7Qb2ztKfsYwPFndD3V7+GQa8hzwDVF4g=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=XS07/l3hGYO5vnZA/BsdJUDaRvBVvD+y9DQ5iV6taHhq9Ohzw/PARWNBqgb13IP2q b4nhbJasYvG+PxKR7YZAZyZRAQvOTXRwaskXdnTIiYsvD+cSE6GKWg9Zv+FBjbT7ta ceQrFeAa4S+bKlziv79w5rd7X/MWfLHab0CnZaOQfwplknvb3GEjYkgIhXDYNXBWNU c2AlOcUKSeYMz7h4eKmDaQlXiED/I3vAwoGMv8o+HSgm+JpSeM1H/xQQuZd2oYDp7p z/JvQNTD0UE+8MXkHgQFLynsjtbv2x4ZYFT/GVbNw5jVwUR3SUY1EyLnxbFtcyuGGj sGneCS9fUBIuQ== 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-a1p-077058.sys.comcast.net with ESMTPSA id VtLCqU0PPnEG1VtLDqCasD; Tue, 15 Aug 2023 12:40:08 +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 08:40:06 -0400 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: 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 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. 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. paul