From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by sourceware.org (Postfix) with ESMTPS id E23323855592 for ; Fri, 28 Jul 2023 14:16:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E23323855592 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-f181.google.com with SMTP id 5614622812f47-3a38953c928so1719520b6e.1 for ; Fri, 28 Jul 2023 07:16:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690553766; x=1691158566; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QRfeqFLpFooXaXXXbaa+gzobttuXakQqCw4bC6f6W+k=; b=XRKiFRdM6sM0MlWxg3AKtzboN9skYdsTG33r6QX7ZmWJsn+G6pRg5ZYWlLYgg8C184 nzGAodZnpMLJwhmeR/RjyTaaJgUafZKsrz3eORnLIysGPWcp2aliOzuYTwxd4nLkspPC P6HA8jdbovUjEkaqIJWDYGGAuMHznAVegsK9okLDhfI/dIsQlfTu9sNzcWxXXIxUuylj HAT2TJ//SlU5uT/gCt0ypfIsq+BayyKZzZD83snkC/k4HH7MMbkYaz1W4oNFYpqJ/JQ7 Q19fLxRdK/Qw5hou3Gz1IGYGiEcAM9h/pGJdIQ6WYqsNCYtAr63K1GOOAYqxuvBJ+8pW /Zww== X-Gm-Message-State: ABy/qLY2xwjoiyfAPjD1iQCmdL5I80fMGbAnnOPupNO2hiLFRgt5LiA3 9qzQO3707TjkDbkxB6Ui5vpCwz3NNNM= X-Google-Smtp-Source: APBJJlF36owDmhvG6wWc7z8KrPbEfQqfkjrX25bDHXjhL7oRJowxWPSkWJyaPld8rLqAZa/wgvgQ4Q== X-Received: by 2002:a05:6808:181c:b0:3a4:1441:531d with SMTP id bh28-20020a056808181c00b003a41441531dmr3420495oib.48.1690553766380; Fri, 28 Jul 2023 07:16:06 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com. [209.85.210.53]) by smtp.gmail.com with ESMTPSA id r2-20020a056808210200b003a6fafd3fe0sm368480oiw.26.2023.07.28.07.16.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 07:16:05 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-6b9a2416b1cso1817167a34.2 for ; Fri, 28 Jul 2023 07:16:05 -0700 (PDT) X-Received: by 2002:a05:6358:94a9:b0:134:c815:f067 with SMTP id i41-20020a05635894a900b00134c815f067mr2708813rwb.11.1690553765598; Fri, 28 Jul 2023 07:16:05 -0700 (PDT) MIME-Version: 1.0 References: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> <18BB0DD5-57EA-4B82-8807-72AEA51CA719@iki.fi> In-Reply-To: <18BB0DD5-57EA-4B82-8807-72AEA51CA719@iki.fi> Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 28 Jul 2023 09:15:53 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Why int32_t is long int on 32 Bit Intel? To: Anders Montonen Cc: "panda.trooper" , newlib@sourceware.org Content-Type: multipart/alternative; boundary="000000000000ac1ba906018cb8dd" X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: --000000000000ac1ba906018cb8dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my experience which dates back to the 80s including 80186 development and decades with RTEMS, an int matches the native register size. As a general rule, 16-bit CPUs have 16 bit int, 32-bit CPUs have 32-bit int, and 64-bit CPUs have 64-bit ints. There may be compiler options to change the register model but this means all source must be compiled with this option. The aarch64 has LP64 (native 64-bit) and ILP32 (like 32-bit ARM) and this is the option description from GCC: -mabi=3Dname Generate code for the specified data model. Permissible values are =E2=80= =98ilp32=E2=80=99 for SysV-like data model where int, long int and pointers are 32 bits, and = =E2=80=98 lp64=E2=80=99 for SysV-like data model where int is 32 bits, but long int a= nd pointers are 64 bits. The default depends on the specific target configuration. Note that the LP64 and ILP32 ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries. If you look at the C standard, you want to look at "5.2.4.2.1 Sizes of integer types " in C99. This defines the minimum ranges of each integer type. Picking one of the values at random, this is a typical description: =E2=80=94 maximum value for an object of type int INT_MAX +32767 // 2 15 =E2=88=92 1 If you want another esoteric area, char may be signed or unsigned and it varies based on architecture even with GCC. I don't remember the exact distribution but RTEMS supports 18 processor architectures and I think the split is about 1/3 one way. --joel sherrill RTEMS On Fri, Jul 28, 2023 at 8:23=E2=80=AFAM Anders Montonen wrote: > Hi, > > > On 28 Jul 2023, at 11:06, panda.trooper > wrote: > > > >> On 2023-07-27 05:55, panda.trooper wrote: > >> > >>> 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 i= nt > when using newlib? > >> > >> > >> 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 h= as > >> limitations. > >> > >> [The ancient PDP-11 is still supported by gcc 13: > >> > >> > https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-= options/pdp-11-options.html > >> > >> probably because it may still be exemplary CISC ISA in comp arch > courses using > >> simulators like SimH et al.] > >> > >> -- > >> Take care. Thanks, Brian Inglis Calgary, Alberta, Canada > >> > >> 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 mor= e to > cut > >> -- Antoine de Saint-Exup=C3=A9ry > > > > 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? > > > > I am on x86 (32 bit) and have C++ code like this: > > > > void foo(long) {} > > void foo(int) {} > > > > Now this compiles with bot, my native Linux GCC and with my newlib based > i686-elf cross compiler. If I change this to this: > > > > void foo(long) {} > > void foo(int32_t) {} > > > > 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. > > > > 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 --000000000000ac1ba906018cb8dd--