Use additional ROM functions instead of libc versions

[earlephilhower]

The ROM provides versions of memcpy, memmove, and other standard C lib routines. Verify their functionality and then remove the copies present in the libc.a library to save program space.

Note that these libc.a versions are not stored in IRAM presently, so it is technically illegal to call them from an interrupt routine. The ROM versions have no such problem.

[TD-er]

Is there anything recently committed that may cause an increase of the iram usage on (stage) core 2.6.0 SDK2?
See build errors here
6 days ago the same PR was building fine.

N.B. I ask it here, since you've apparently been looking into resource hoggers the last few days. :)

[earlephilhower]

UMM (the memory manager) was significantly updated, that's probably the culprit. See #6274. This specific PR here, should have no effect either way on IRAM size, only on total flash usage.

[TD-er]

I just tried another branch (without the changed platformio.ini in the PR I linked) and it also cannot be built due to iram issues.
So apparently in the last 5 days something has been committed to master which does just add this little extra.

N.B. it is the build with SDK 2 (without extra define)
SDK 2.2.2 is built using -DPIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22y is building fine so it seems. (same set of code, only different SDK)

[earlephilhower]

Sorry, no idea then. Check git log, it should be straightforward to figure out.

[TD-er]

Could it be this one: 55539ae
I can imagine this change could lead to some extra code be generated.
And perhaps we were already a few bytes away from the max.

[earlephilhower]

I doubt that would actually change the assembly generated significantly. Your best bet is to look at the .MAPs and see the different sizes in the .TEXT/.TEXT1 areas (i.e. IRAM).

[TD-er]

I doubt that would actually change the assembly generated significantly. Your best bet is to look at the .MAPs and see the different sizes in the .TEXT/.TEXT1 areas (i.e. IRAM).

It appears almost all core 2.6.0 builds now run out of iram, but how do I see what amount is being used?
The build doesn't complete, so there is no ELF file to analyze.

Even the verbose build doesn't show it:

c:/users/gijs/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\test_core_260_sdk3_alpha_ESP8266_4M\firmware.elf section `.text1' will not fit in region `iram1_0_seg'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\test_core_260_sdk3_alpha_ESP8266_4M\firmware.elf] Error 1

[earlephilhower]

I'm on the phone d so can't check, but I think you get a map file even if the link fails. Check for*.map. If not, then the linker file for your chip and spiffs setting has a setting for the iram size you can increase. The elf will build properly, but you can't obviously run it on a real co. You can then look at the generated map or elf.

[TD-er]

There is no .map file.
But I will look into how to increase the iram limits.
Is there a list of things that will be mapped to the iram?
For example, are static functions mapped to iram?
To what I understand of the iram, it would not really make send yet if those functions would be mapped there.

What takes more (iram) memory?

• An enum (esp. if all are addressed in a switch statement)
• Set of defined, or which some may not be used in the code (not used in a switch statement, but ranged checked via if (... > X && ... < Y)

But I guess that maybe it is time to continue this discussion in its own issue?

[earlephilhower]

It's define by the linker file regwx matching as well as the coffee when you specify the attribute, so it's not clear cut. The larger iram will finish the link and then you just need to look at the map file.