Deomid Ryabkov

i can say that it works fine on vanilla windows 10 with windows defender. you may have some other software that prevents it from opening a listening socket.

ok, some of the `movi /movi.n` difference can be attributed to jump address alignment and the denisty can be improved with `-mno-target-align`. this still leaves one `movi` where `movi.n`could be...

well, those seem unrelated to the issues i reported here that are about assembly code generation. that said - thank you for letting me know, i will see if i...

right, most of the movi/movi.n stuff was rectified with `-mno-target-align` - but not all. > and 4 bytes of litpool entry :) sure, but `0xffffffff` aka `-1` is widely used...

@Lapshin > Could you please check your project with these changes? we are using 5.2.1, and these were kind of difficult to apply after the big refactoring in https://github.com/espressif/esp-idf/commit/40be44f8274f4d160cd4bcd25e37a6d72141a929 but...

@Lapshin I did a quick test with current `release/v5.2` (https://github.com/espressif/esp-idf/commit/e5ffb3c57d59d8c94a4c662a8d0d76afa096bc13), and results are interesting: 1. Xtensa (ESP32) target binary size went down by almost 50K: 1632032 -> 1581616 2. Similar...

yep, that looks like a nice optimization. the only question is: when will we see it in IDF?

@jjsuwa-sys3175 thanks for the additional context, it's good to know. however, at least in our environment, we almost exclusively operate under the memory pressure, both RAM and flash, while cycles...

@Lapshin > You can analyze why it happens for your particular project using command idf_size.py --files --diff OLD_BUILD_MAP_FILE NEW_BUILD_MAP_FILE see attached diffs for ESP32 and ESP32-C3. what do you see?...

also, looks like idf_size.py has a bug computing .rodata size - no way pthread.c uses 150K+ of rodata. it seems that the first entry gets bogus size.