From: David Brown <david@westcontrol.com>
To: "Rafał Pietrak" <embedded@ztk-rp.eu>,
"Jonathan Wakely" <jwakely.gcc@gmail.com>
Cc: waffl3x <waffl3x@protonmail.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: wishlist: support for shorter pointers
Date: Tue, 4 Jul 2023 17:13:42 +0200 [thread overview]
Message-ID: <007e332d-99a2-516d-bdf6-ab929a6352de@westcontrol.com> (raw)
In-Reply-To: <ff5522e5-c6a2-2353-8851-c743cd0dfe15@ztk-rp.eu>
On 04/07/2023 16:20, Rafał Pietrak wrote:
>
>
> W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
>> Hi David,
>>
> [--------------]
>>> 4. It is worth taking a step back, and thinking about how you would
>>> like to use these pointers. It is likely that you would be better
>>> thinking in terms of an array, rather than pointers - after all, you
>>> don't want to be using dynamically allocated memory here if you can
>>> avoid it, and certainly not generic malloc(). If you can use an
>>> array, then your index type can be as small as you like - maybe
>>> uint8_t is enough.
>>
>> I did that trip ... some time ago. May be I discarded the idea
>> prematurely, but I dropped it because I was afraid of cost of
>
> I remember now what was my main problem with indexes implementation:
> inability to express/write chain "references" with them. Table/index
> semantic of:
> t[a][b][c][d].
> is a "multidimentional table" which is completely different from
> "pointer semantic" of:
> *t->a->b->c->d
>
> It is quite legit to do a full circle around a circular list this way,
> while table semantics doesn't allow that.
>
> Indexes are off the table.
>
> -R
If you have a circular buffer, it is vastly more efficient to have an
array with no pointers or indices, and use head and tail indices to
track the current position. But I'm not sure if that is what you are
looking for. And you can use indices in fields for chaining, but the
syntax will be different. (For some microcontrollers, the
multiplications involved in array index calculations can be an issue,
but not for ARM devices.)
next prev parent reply other threads:[~2023-07-04 15:13 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 [this message]
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
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=007e332d-99a2-516d-bdf6-ab929a6352de@westcontrol.com \
--to=david@westcontrol.com \
--cc=embedded@ztk-rp.eu \
--cc=gcc@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=waffl3x@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).