From: "Rafał Pietrak" <embedded@ztk-rp.eu>
To: David Brown <david@westcontrol.com>, Ian Lance Taylor <iant@golang.org>
Cc: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,
Martin Uecker <muecker@gwdg.de>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: wishlist: support for shorter pointers
Date: Tue, 4 Jul 2023 16:46:18 +0200 [thread overview]
Message-ID: <a8e9b05c-0a2f-ea40-34ff-7230042b3f4c@ztk-rp.eu> (raw)
In-Reply-To: <eeddf4aa-9fd7-c843-eeef-56e4eb0ca107@westcontrol.com>
Hi,
W dniu 4.07.2023 o 14:38, David Brown pisze:
[---------]
> A key difference is that using 32-bit pointers on an x86 is enough
> address space for a large majority of use-cases, while even on the
> smallest small ARM microcontroller, 16-bit is not enough. (It's not
> even enough to access all memory on larger AVR microcontrollers - the
> only 8-bit device supported by mainline gcc.) So while 16 bits would
> cover the address space of the RAM on a small ARM microcontroller, it
> would not cover access to code/flash space (including read-only data),
> IO registers, or other areas of memory-mapped memory and peripherals.
> Generic low-level pointers really have to be able to access everything.
Naturaly 16-bit is "most of the time" not enough to cover the entire
workspace on even the smallest MCU (AVR being the only close to an
exception here), but in my little experience, that is not really
necessary. Meaning "generic low-level pointers really have to...", I
don't think so. I really don't. Programs often manipulate quite
"localized" data, and compiler is capable enough to distinguish and keep
separate pointers of different "domains". What makes it currently
impossible is tools (semantic constructs like pragma or named sections)
that would let it happen.
>
> So an equivalent of x32 mode would not work at all. Really, what you
> want is a 16-bit "small pointer" that is added to 0x20000000 (the base
> address for RAM in small ARM devices, in case anyone following this
> thread is unfamiliar with the details) to get a real data pointer. And
> you'd like these small pointers to have convenient syntax and efficient
> use.
more or less yes. But "with a twist". A "compiler construct" that would
be (say) sufficient to get the RAM-savings/optimization I'm aiming at
could be "reduced" to the ability to create "medium-size" array of "some
objects" and have them reference each other all WITHIN that "array".
That array was in my earlier emails referred to as segment or section.
So whenever a programmer writes a construct like:
struct test_s attribute((small-and-funny)) {
struct test_s attribute((small-and-funny)) *next, *prev, *head;
struct test_s attribute((small-and-funny)) *user, *group;
} repository[1000];
struct test_s attribute((small-and-funny)) *master, *trash;
compiler puts that data into that small array (dedicated section), so no
"generic low-level pointers" referring that data would need to exist
within the program. And if it happens, error is thrown (or
autoconversion happen).
>
> I think a C++ class (or rather, class template) with inline functions is
> the way to go here. gcc's optimiser will give good code, and the C++
> class will let you get nice syntax to hide the messy details.
OK. Thenx for the advice, but going into c++ is a major thing for me and
(at least for the time being) I'll stay with ordinary "big" pointers in
plain C instead.
> There is no good way to do this in C. Named address spaces would be a
> possibility, but require quite a bit of effort and change to the
> compiler to implement, and they don't give you anything that you would
> not get from a C++ class.
Yes. named address spaces would be great. And for code, too.
> (That's not quite true - named address spaces can, I believe, also
> influence the section name used for allocation of data defined in these
> spaces, which cannot be done by a C++ class.)
OK.
-R
next prev parent reply other threads:[~2023-07-04 14:46 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 12:26 Rafał Pietrak
2023-06-28 1:54 ` waffl3x
2023-06-28 7:13 ` Rafał Pietrak
2023-06-28 7:31 ` Jonathan Wakely
2023-06-28 8:35 ` Rafał Pietrak
2023-06-28 9:56 ` waffl3x
2023-06-28 10:43 ` Rafał Pietrak
2023-06-28 12:12 ` waffl3x
2023-06-28 12:23 ` Rafał Pietrak
2023-07-03 14:52 ` David Brown
2023-07-03 16:29 ` Rafał Pietrak
2023-07-04 14:20 ` Rafał Pietrak
2023-07-04 15:13 ` David Brown
2023-07-04 16:15 ` Rafał Pietrak
2023-06-28 7:34 ` waffl3x
2023-06-28 8:41 ` Rafał Pietrak
2023-06-28 13:00 ` Martin Uecker
2023-06-28 14:51 ` Rafał Pietrak
2023-06-28 15:44 ` Richard Earnshaw (lists)
2023-06-28 16:07 ` Martin Uecker
2023-06-28 16:49 ` Richard Earnshaw (lists)
2023-06-28 17:00 ` Martin Uecker
2023-06-28 16:48 ` Rafał Pietrak
2023-06-29 6:19 ` Rafał Pietrak
2023-07-03 15:07 ` Ian Lance Taylor
2023-07-03 16:42 ` Rafał Pietrak
2023-07-03 16:57 ` Richard Earnshaw (lists)
2023-07-03 17:34 ` Rafał Pietrak
2023-07-04 12:38 ` David Brown
2023-07-04 12:57 ` Oleg Endo
2023-07-04 14:46 ` Rafał Pietrak [this message]
2023-07-04 15:55 ` David Brown
2023-07-04 16:20 ` Rafał Pietrak
2023-07-04 22:57 ` Martin Uecker
2023-07-05 5:26 ` Rafał Pietrak
2023-07-05 7:29 ` Martin Uecker
2023-07-05 8:05 ` Rafał Pietrak
2023-07-05 9:11 ` David Brown
2023-07-05 9:25 ` Martin Uecker
2023-07-05 11:34 ` David Brown
2023-07-05 12:01 ` Martin Uecker
2023-07-05 9:42 ` Rafał Pietrak
2023-07-05 11:55 ` David Brown
2023-07-05 12:25 ` Rafał Pietrak
2023-07-05 12:57 ` David Brown
2023-07-05 13:29 ` Rafał Pietrak
2023-07-05 14:45 ` David Brown
2023-07-05 16:13 ` Rafał Pietrak
2023-07-05 17:39 ` David Brown
2023-07-06 7:00 ` Rafał Pietrak
2023-07-06 12:53 ` David Brown
2023-07-05 9:29 ` Martin Uecker
2023-07-05 10:17 ` Rafał Pietrak
2023-07-05 10:48 ` Martin Uecker
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=a8e9b05c-0a2f-ea40-34ff-7230042b3f4c@ztk-rp.eu \
--to=embedded@ztk-rp.eu \
--cc=Richard.Earnshaw@arm.com \
--cc=david@westcontrol.com \
--cc=gcc@gcc.gnu.org \
--cc=iant@golang.org \
--cc=muecker@gwdg.de \
/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).