I am not entirely sure. Could be that the 48K is used by the ROM.
ok, i actually miscalculated and it's 32K. but still, it is a big chunk of heap unaccounted for, would be nice to have it back or at least know that it's intentional. can you clarify it?
you could possibly use this by just pointing a pointer to the end of the code in IRAM and using it as a big buffer that way, but using it as heap is pretty much not possible for now, sorry. I'll see if I can change this, but because we'll have to overhaul it slightly after the ESP32 release, I'm not sure if it's worth the bother.
the difficulty with IRAM/IROM, at least on the 8266, is that access must be 32-bit aligned. either app needs to be super-careful, or something like this
needs to be done, which slows things down. being able to dynamically reconfigure memory segments would be a big plus, because not all apps are alike. in particular IRAM/ICACHE vs DRAM tradeoff would be different for different apps. we will definitely be looking at using that IRAM as heap one way or another.
also, can you clarify these entries from the spec please:
ICACHE - 0x40080000 - 3.5M
DCACHE - 0x3FE00000 - 512k
ICACHE - my understanding is that it's the memory-mapped region backed by SPI flash, accessed through a smaller RAM window. how big is the actual RAM window size? can't really be 3.5M, with 416K total SRAM on board.
DCACHE - this is interesting. where is that mapped to? is it SPI flash as well? what is the difference between ICACHE and DCACHE - access alignment requirements? write access?