From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: newlib@sourceware.org
Cc: "panda.trooper" <panda.trooper@protonmail.com>
Subject: Re: Why int32_t is long int on 32 Bit Intel?
Date: Thu, 27 Jul 2023 17:13:52 -0600 [thread overview]
Message-ID: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> (raw)
In-Reply-To: <Cqp71y7dEMZ7WbDaFFzEzr4idhvMET4sJ3SsYd7rvBAURIX_tQ93hhswdmp5dr9FTpwV6N_ZQ2D4GWyAJIgGLQFUXlMlyt2jyRoldYuMyDQ=@protonmail.com>
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 int 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 has
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 à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
next prev parent reply other threads:[~2023-07-27 23:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 11:55 panda.trooper
2023-07-27 23:13 ` Brian Inglis [this message]
2023-07-28 8:06 ` panda.trooper
2023-07-28 13:23 ` Anders Montonen
2023-07-28 14:15 ` Joel Sherrill
2023-07-28 15:49 ` [EXTERNAL]: " Mike Burgess
2023-07-28 16:11 ` Stefan Tauner
2023-07-28 16:26 ` Mike Burgess
2023-07-28 17:06 ` Richard Damon
2023-07-28 18:05 ` Grant Edwards
2023-07-28 18:27 ` panda.trooper
2023-07-28 20:23 ` Jon Beniston
2023-07-28 21:42 ` panda.trooper
2023-07-28 21:53 ` Jon Beniston
2023-07-29 12:47 ` Trampas Stern
2023-07-29 13:19 ` Stefan Tauner
2023-07-29 21:21 ` Grant Edwards
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=6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca \
--to=brian.inglis@shaw.ca \
--cc=newlib@sourceware.org \
--cc=panda.trooper@protonmail.com \
/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).