[Bug 168] Missing "section" GCC attribute in GDC

via D.gnu d.gnu at puremagic.com
Sat Apr 4 08:11:52 PDT 2015


http://bugzilla.gdcproject.org/show_bug.cgi?id=168

Jens Bauer <jens-bugzilla at gpio.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens-bugzilla at gpio.dk

--- Comment #1 from Jens Bauer <jens-bugzilla at gpio.dk> ---
Being able to select which section code, variables, arrays and other data will
go into is especially important when working with microcontrollers.

The following gives some insight of why this feature is useful on
microcontrollers:

For instance: Often the first N words of data is reserved for exception
vectors.
On ARM, for instance (any ARM architecture), the first 16 words which are
32-bit wide each, contain first an initial stack pointer value followed by core
vectors.
After those 16 vectors, the vendor may choose what interrupt vectors to add
(normally up to 256 vectors can be supported here).

In a linker-script, one would typically make a section called .isr_vectors and
then put an array of function-pointers in this section. Note: Such a section
may be read-only memory (eg. Flash memory or ROM), but in some cases it can be
RAM.

Other reasons for being able to specify sections include the ability to choose
which data goes into CCMRAM (CCM=Core Coupled Memory) on some devices,
NOR-Flash, NAND-Flash, Flash Bank 1, Flash Bank 2, SRAM1, SRAM2, SRAM3, SRAM4,
Local SRAM, SDRAM, External SRAM, ROM, and so forth; even SD/MMC card can be
written indirectly this way.

On some microcontrollers, it's very useful to have code (normally running in
the .text section) to be copied to SRAM for fast execution speed, as executing
code from the Flash memory might be up to 7 times slower than SRAM. Thus small
subroutines can often be placed in SRAM to improve speed greatly.

Since the D compiler already know about some sections, it would be convenient
having native support for it, which would not depend on the backend.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150404/50518465/attachment.html>


More information about the D.gnu mailing list