Thanks David!
I do not think I agree with all of it (e.g. sdcc is
actively developed with regular releases and supports
tiny devices which are used for extreme low-power
applications) and I do not personally think that only
C++ counts nowadays, especially in the embedded world,
but we do not need to discuss this now. I still very
much appreciate your input!
Note that I am involved with C standardization, but
TR 18307 precedes this.
Martin
Am Mittwoch, dem 05.07.2023 um 13:34 +0200 schrieb David Brown:
>
>
> On 05/07/2023 11:25, Martin Uecker wrote:
> > Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:
> > > On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
> >
> > ...
> > >
> > > In my personal opinion (which you are all free to disregard),
> > > named
> > > address spaces were an interesting idea that failed. I was
> > > enthusiastic
> > > about a number of the extensions in TR 18307 "C Extensions to
> > > support
> > > embedded processors" when the paper was first published. As I
> > > learned
> > > more, however, I saw it was a dead-end. The features are too
> > > under-specified to be useful or portable, gave very little of use
> > > to
> > > embedded programmers, and fit badly with C. It was an attempt to
> > > standardise and generalise some of the mess of different
> > > extensions
> > > that
> > > proprietary toolchain developers had for a variety of 8-bit CISC
> > > microcontrollers that could not use standard C very effectively.
> > > But
> > > it
> > > was all too little, too late - and AFAIK none of these
> > > proprietary
> > > toolchains support it. GCC supports some of the features to some
> > > extent
> > > - a few named address spaces on a few devices, for "gnuc" only
> > > (not
> > > standard C, and not C++), and has some fixed point support for
> > > some
> > > targets (with inefficient generated code - it appears to be
> > > little
> > > more
> > > than an initial "proof of concept" implementation).
> > >
> > > I do not think named address spaces have a future - in GCC or
> > > anywhere
> > > else. The only real use of them at the moment is for the AVR for
> > > accessing data in flash, and even then it is of limited success
> > > since
> > > it
> > > does not work in C++.
> >
> > Can you explain a little bit why you think it is a dead-end? It
> > seems an elegant solution to a range of problems to me.
>
> Named address spaces are not standardised in C, and I do not expect
> they
> ever will be. The TR18307 document is not anywhere close to being of
> a
> quality that could be integrated with the C standards, even as
> optional
> features, and much of it makes no sense in practice (I have never
> heard
> of the IO stuff being implemented or used).
>
> The few compilers that implement any of it do so in different ways -
> the
> "__flash" address space in AVR GCC is slightly different from the
> same
> extension in IAR's AVR compiler. For existing compilers, there is a
> strong inconsistency as to whether such things are "named address
> spaces", "extension keywords", "type qualifiers", "attributes", or
> other
> terms, all with subtly (or not so subtly) different effects on how
> they
> are used, what restrictions exist, conversions between types, and how
> errors can be diagnosed. Sometimes these features are considered
> part
> of the data type, sometimes of pointer types, sometimes they are just
> about data placement.
>
> Since every compiler targeting these small awkward microcontrollers
> has
> a different idea of what something like "const __flash int x = 123;"
> means, and has been implementing their own ideas for a decade or two
> before TR18307 ever proposed "named address spaces", the TR hasn't a
> hope of being a real standard.
>
> Named address spaces are not implemented at all, anywhere (AFAIK),
> for
> C++. (Some embedded toolchains have limited support for C++ on such
> microcontrollers, but these are again not really named address
> spaces.)
> Since C++ usage is heavily increasing in the small embedded system
> world, this is important. (GCC has much of the honour for that - as
> ARM
> took a bigger share of the market and GCC for ARM improved, the
> toolchain market was no longer at the mercy of big commercial vendors
> who charged absurd amounts for their C++ toolchains.) A feature
> which
> is only for C, and not supported by C++, is almost guaranteed to be
> dead-end.
>
> And of course the type of processor for which named address spaces or
> other related extensions are essential, are a dying breed. The AVR
> is
> probably the only one with a significant future. Part of the appeal
> of
> ARM in the embedded world is it frees you from the pains of
> target-specific coding with some of your data in "near" memory, some
> in
> "extended" memory, some in "flash" address spaces or "IO" address
> spaces. It all works with standard C or C++. The same applies to
> challengers like RISC-V, MIPS, PPC, and any other core - you have a
> single flat address space for normal data.
>
> >
> > I have no idea how much the GCC features are actually used,
> > but other compilers for embedded systems such as SDCC also
> > support named address spaces.
> >
>
> And the targets supported by SDCC are also dead-end devices - there
> is
> not a single one of them that I would consider for a new project.
> These
> microcontrollers are now used almost exclusively for legacy projects
> -
> updates to existing hardware or software, and rely on compatibility
> with
> existing C extensions (whether they are called "named address
> spaces",
> "extension keywords", or anything else).
>
>
> Now, there are things that I would like to be able to write in my
> code
> that could appear to be candidates for some kind of named address
> space.
> For example, I might want data that is placed in an external eeprom
> -
> it could be nice to be able to define, declare, read and write it
> like
> normal data in the code. But key to this would be the ability to
> define
> the way this works in /user/ code - named address spaces require
> changing the toolchain, which is out of the question in almost all
> use-cases. And it would spoil one of C's key advantages over
> alternative languages - to a fair extent (though not as completely as
> many people believe), you can guess what is happening from the code.
> You assume that "x = eeprom_var;" is small and efficient, while "x =
> read_eeprom(eeprom_var)" might take significant time to execute.
> People
> don't like hidden things in their C code.
>
> It would be conceivable for GCC to add extensions that could be used
> to
> define your own named address spaces in user code. But doing so
> would
> require a lot of syntax and features that already exist in C++.
>
> I would rather see better ways of controlling placement of data added
> to
> the compiler. In another post, I suggested allowing variable
> attributes
> - such as "section" - to be attached to types. I'd also like to see
> a
> way to specify the section name by compile-time evaluated code, not
> just
> a string literal. I'd like to be able to give sub-sections, and
> section
> flags in a convenient way. And - perhaps most importantly - I'd like
> to
> be able to use #pragma's to give sections for code or data for a
> block
> of code and data at a time, rather than having to specify it
> individually on each function. (That could perhaps also be done by
> allowing section attributes on namespaces in C++.)
>
>
> David
>
