From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by sourceware.org (Postfix) with ESMTPS id 9743B3858CDA for ; Fri, 28 Jul 2023 13:23:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9743B3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=iki.fi Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kapsi.fi DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=k/0HSniQ3Z+JT7+xmzBVlwzP3C8zcr5cHJcBH2lbsq4=; b=CwDQG2jaJmyOPo+uZvoQcuooxo vUmGGgT0Ebgk6Ut/cEhxGcqmjpzMJ1C9Hz/uuPKlHrZBRgkExSAaHgRK7taZQSfOGUIbfqofVKLtV VC3G+baFtpyOpYG9kCp66zXW4nzCYIbuE3Ot2FIJ1lwHXu678bcAHDy22bUku2srvul8EeM8znHvx HWvqaf9BqUY1+JZx1mlyD0XNah+7bnY2vs+dcci2e2ZE01ld7Tuu+w2lXNiE3dHW8pDM1JhkNawwb 822HnzOOo+Jzs5ay7FMkFhxVQUtrnKETXF1GgI60mkz/RLIn4e6YX8875AvwJzt2M5Wl4ULMbwnzK cxWgFrjA==; Received: from 84-253-254-23.bb.dnainternet.fi ([84.253.254.23] helo=[192.168.1.137]) by mail.kapsi.fi with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qPNRK-00AFru-1j; Fri, 28 Jul 2023 16:23:30 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: Why int32_t is long int on 32 Bit Intel? From: Anders Montonen In-Reply-To: Date: Fri, 28 Jul 2023 16:23:29 +0300 Cc: newlib@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <18BB0DD5-57EA-4B82-8807-72AEA51CA719@iki.fi> References: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> To: "panda.trooper" X-Mailer: Apple Mail (2.3445.104.21) X-SA-Exim-Connect-IP: 84.253.254.23 X-SA-Exim-Mail-From: Anders.Montonen@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, > On 28 Jul 2023, at 11:06, panda.trooper = wrote: >=20 >> On 2023-07-27 05:55, panda.trooper wrote: >>=20 >>> Hi, can somebody explain what is the reason behind the architectural = decision that on x86 the type of int32_t is long int by default and not = int when using newlib? >>=20 >>=20 >> Lots of embedded processors have 16 bit int and 32 bit long, and = 80186 >> compatibles are still being produced and sold, although gcc -m16 now = has >> limitations. >>=20 >> [The ancient PDP-11 is still supported by gcc 13: >>=20 >> = https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-o= ptions/pdp-11-options.html >>=20 >> probably because it may still be exemplary CISC ISA in comp arch = courses using >> simulators like SimH et al.] >>=20 >> -- >> Take care. Thanks, Brian Inglis Calgary, Alberta, Canada >>=20 >> La perfection est atteinte Perfection is achieved >> non pas lorsqu'il n'y a plus rien =C3=A0 ajouter not when there is no = more to add >> mais lorsqu'il n'y a plus rien =C3=A0 retirer but when there is no = more to cut >> -- Antoine de Saint-Exup=C3=A9ry >=20 > Ok, I understand, some embedded systems have 16 bit int. But why not = looking first if int is 32 bit and if yes, selecting that type as = int32_t, and if the size doesn't fit, look for other types? >=20 > I am on x86 (32 bit) and have C++ code like this: >=20 > void foo(long) {} > void foo(int) {} >=20 > Now this compiles with bot, my native Linux GCC and with my newlib = based i686-elf cross compiler. If I change this to this: >=20 > void foo(long) {} > void foo(int32_t) {} >=20 > then it will still compile with native Linux GCC (int32_t is int) but = will fail with newlib i686-elf cross GCC, because both types are the = same. The newlib behavior is kind of unintuitive to me. It is correct, = because the standard only defines the size of the type, not the exact = type. But I would not expect to get different types on the same CPU = architecture with the same compiler just because I am using a different = standard C library. >=20 > Is this expectation wrong? I am unsure. The representation of data types is determined by the ABI. Most, if not = all, x86-32 ABIs use 4-byte longs. These things would probably have been = decided in the 80s, when the i386 was introduced. http://agner.org/optimize/calling_conventions.pdf http://www.sco.com/developers/devspecs/abi386-4.pdf -a=