Hi,
W dniu 5.07.2023 o 19:39, David Brown pisze:
[--]
I'm not sure what this means? At compile time, you only have literals,
so what's missing?
The compiler knows a lot more than just literal values at compile time -
lots of things are "compile-time constants" without being li
Hi,
W dniu 5.07.2023 o 16:45, David Brown pisze:
On 05/07/2023 15:29, Rafał Pietrak wrote:
[---]
OK. I don't see a problem here, but I admit that mixing semantics
often lead to problems.
I think it also allows better generalisation and flexibility if they are
separate. You mi
Hi,
W dniu 5.07.2023 o 14:57, David Brown pisze:
[]
My objection to named address spaces stem from two points:
1. They are compiler implementations, not user code (or library code),
which means development is inevitably much slower and less flexible.
2. They mix two concepts th
Hi,
W dniu 5.07.2023 o 13:55, David Brown pisze:
On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:
[--]
Wouldn't it be easier and more natural to make the "named spaces" a
synonym to specific linker sections (like section names, or section
name prefix when instead
Hi
W dniu 5.07.2023 o 11:29, Martin Uecker pisze:
Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
[--]
Then again ... apparently you are guessing the answer. Incidentally,
that would be my guess, too. And while such "syntax" is not really
desirable (since such att
Hi,
W dniu 5.07.2023 o 11:11, David Brown pisze:
On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
[---]
type) would then be smaller. At least, this is my understanding
of how it could work.
Note that this only applies to pointers declared to be of the address
space specific type
Hi,
W dniu 5.07.2023 o 09:29, Martin Uecker pisze:
Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
[---]
And if it's so ... there is no mention of how does it show up for
"simple user" of the GCC (instead of the use of that "machinery" by
creators of particular GCC port).
Hi,
W dniu 5.07.2023 o 00:57, Martin Uecker pisze:
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
[]
Yes. named address spaces would be great. And for code, too.
While certainly some work, implementation effort for
new kinds of named address spaces does not s
W dniu 4.07.2023 o 17:55, David Brown pisze:
On 04/07/2023 16:46, Rafał Pietrak wrote:
[--]
Yes. named address spaces would be great. And for code, too.
It is good to have a wishlist (and you can file a wishlist "bug" in the
gcc bugzilla, so that it won't be forgotten). But it
W dniu 4.07.2023 o 17:13, David Brown pisze:
[]
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
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 memo
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
W dniu 3.07.2023 o 18:57, Richard Earnshaw (lists) pisze:
On 03/07/2023 17:42, Rafał Pietrak via Gcc wrote:
Hi Ian,
[-]
And WiKi reporting up to 40% performance improvements in some corner
cases is impressive and encouraging. I believe, that the reported
average of 5-8
Hi Ian,
W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze:
On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc wrote:
[]
I was thinking about that, and it doesn't look as requiring that deep
rewrites. ABI spec, that could accomodate the functionality could be as
little a
Hi David,
W dniu 3.07.2023 o 16:52, David Brown pisze:
[]
But, before I dive into learning C++ (forgive the naive question)
isn't it so, that C++ comes with a heavy runtime? One that will bloat
my tiny project? Or the bloat comes only when one uses particular
elaborated class
Hi everybody,
I hope this is not inappropriate question for this list, since internet
provides "some" means to get it done:
https://stackoverflow.com/questions/8259447/give-structure-offset-attribute-to-assembler,
https://forum.microchip.com/s/topic/a5C3l00M24UEAS/t238022?
Hi Richard,
W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze:
[---]
I think I understand what you're asking for but:
1) You'd need a new ABI specification to handle this, probably involving
register assignments (for the 'segment' addresses), the initialization
of those at star
ed register
loads already within their instruction sets. So in reality the cost will
be a single ADD instruction before dereference, because the segment
register would be initialized outside the loops.
-R
R.
-R
Best,
Martin
Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pie
ough I have hints on such mechanism behavior, I have no
skills to even imagine where to tweak the sources to achieve that.
-R
Best,
Martin
Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pietrak via Gcc:
Hello everybody,
I'm not quite sure if this is correct mailbox for this
Hi Alex,
W dniu 28.06.2023 o 14:12, waffl3x pisze:
[--]
them having some sort of fancy pointers in there somewhere. Realistically
though,
it will take some time to get used to all the C++isms before you would be able
to
be proficient with anything Boost would provide. I don't mean to b
Hi Alex,
W dniu 28.06.2023 o 11:56, waffl3x pisze:
Here's a quick and dirty example of how this function could be rewritten with
modern C++. I omitted some necessary details, particularly the implementation
of the
linked list iterator. I also wrote it out quickly so I can't be certain it's
100
Hi Alex,
W dniu 28.06.2023 o 09:34, waffl3x pisze:
[--]
---
y->next = NULL;
if (our) { out->next = a;
for (y = t->HD; y && y->next; y = y->next)
if (y) y->next = a;
fit-
Hi Jonathan,
W dniu 28.06.2023 o 09:31, Jonathan Wakely pisze:
On Wed, 28 Jun 2023, 08:14 Rafał Pietrak via Gcc,
[-]
how it looks like. I have a lot of code like this scattered around:
---
y->next = N
Hi Alex!
W dniu 28.06.2023 o 03:54, waffl3x pisze:
I want to preface this stating that I have little to no experience in compiler
development, I am only merely just getting into it. With that said, I have
messed around
with library design a fair amount, and this seems like something that could
Hello everybody,
I'm not quite sure if this is correct mailbox for this suggestion (may
be "embedded" would be better), but let me present it first (and while
the examples is from ARM stm32 environment, the issue would equally
apply to i386 or even amd64). So:
1. Small MPU (like stm32f103) w
W dniu 13.09.2021 o 13:41, David Brown pisze:
> On 13/09/2021 11:51, Rafał Pietrak via Gcc wrote:
>> Hi,
>>
>> Thenk you for very prompt reply.
>
>
> (I'm not sure how much this is a "gcc development list" matter, rather
> than perhaps a &quo
Hi,
Thenk you for very prompt reply.
W dniu 13.09.2021 o 10:44, Jonathan Wakely pisze:
> On Mon, 13 Sept 2021 at 07:55, Rafał Pietrak via Gcc wrote:
[-]
>> #elif VARIANT_WORKING
>> struct cr_s a = (struct cr_s) {
>>
Hi everybody,
I've been using GCC for a varety of ARM micro controller project. With
embedded systems, one often has to access specific memory locations,
which contain hardware registers, that control device behavior.
"traditionally" or "commonly" that's codded by programmers using
"#define", thus
28 matches
Mail list logo
