1

I've been looking at the memory map for my code (written in c and compiled by the XC16 compiler), and see significant space allocated to powers, npowers, and dpowers in the .data segment.

Does anyone know what this allocation is used for?

My code uses the floating point library, as well as printf/scanf - could this be working space for these functions?

Here are two snippets from the map file:

section                    address      alignment gaps    total length  (dec)
-------                    -------      --------------    -------------------
...
.data._powers_              0x20b2                   0            0xb0  (176)
.data._npowers_             0x2162                   0            0xb0  (176)
.data.dpowers               0x2212                   0           0x140  (320)

...and...

.data._powers_      0x20b2         0xb0
.data._powers_
                    0x20b2         0xb0 c:/program files (x86)/microchip/xc16/v1.24/bin/bin/../../lib\libc-coff.a(powers.epo)
                    0x20b2                  _powers_

.data._npowers_
                    0x2162         0xb0
.data._npowers_
                    0x2162         0xb0 c:/program files (x86)/microchip/xc16/v1.24/bin/bin/../../lib\libc-coff.a(powers.epo)
                    0x2162                  _npowers_

.data.dpowers       0x2212        0x140
.data.dpowers      0x2212         0xa0 c:/program files (x86)/microchip/xc16/v1.24/bin/bin/../../lib\libc-coff.a(doprnt_cdfFnopsuxX.EPo)
.data.dpowers      0x22b2         0xa0 c:/program files (x86)/microchip/xc16/v1.24/bin/bin/../../lib\libc-coff.a(doprnt.epo)
EBlake
  • 735
  • 7
  • 14
  • Both floating point and formatted I/O are expensive in memory and CPU load terms. Formatted I/O is particularly expensive when it supports floating-point. Most embedded libraries have an option to remove floating-point support from stdio, and floating point operations can often be replaced with fixed-point code. – Clifford Feb 15 '15 at 08:52
  • You are correct that these are code/memory-intensive routines, but I would have expected the majority of the RAM requirements to be claimed from the stack, and lookup tables/constants could stay in ROM. The latter would consume more code doing page switching for PSV access (and as you point out, the routines are already slow), but the RAM savings would be considerable. – EBlake Feb 15 '15 at 19:59
  • I agree you would hope that the library implementation was optimal, but it is not a given. It does nothing to raise my already low opinion of all things Microchip. – Clifford Feb 15 '15 at 20:16

1 Answers1

2

You would have to look at the source for the version of libc to get a categorical answer. I did look at the source for one and found that, in that implementation, dpowers was a table of constants (powers of 10) used for output (doprnt). I suspect the others are similar.

Note - while constants, these are not in a read-only section due to language limitations.

DrC
  • 7,528
  • 1
  • 22
  • 37
  • What is the "language limitation" here? – Clifford Feb 15 '15 at 08:57
  • As I recall, basic C does not have const. – DrC Feb 15 '15 at 16:09
  • It does, and has since at least 1989. However it is not a language requirement to place `const` in ROM. Some compilers require extensions or specific directives to direct the compiler to locate data in ROM. – Clifford Feb 15 '15 at 19:06
  • @Clifford The dcPIC33E series that I am using has a bank-switching method (PSV) that allows direct access to ROM const data. Even if your routines don't work that way, you still have to copy the const data from ROM to RAM during initialization. – EBlake Feb 15 '15 at 20:01
  • @DrC Thanks for looking into it. It seems that my suspicion was correct. – EBlake Feb 15 '15 at 20:02
  • @EBlake : I am not sure of your point - I was merely pointing out that it is not a "language limitation". It may well be an architecture limitation. – Clifford Feb 15 '15 at 20:11