[...] Pl. ne írjál stack igényes C programot egy PIC18-ra, mert ott bizony a stack csak egy szoftveres emuláció és ennek megfelelően igen lassú! A rom nem spórolós, csak nem megfelelő modellt választottál, vagy túl nagy feladatot próbálsz bepréselni a nemlétező helyre.
Eddig csak 2-3 kisebb PIC-es projektet csinaltam, PIC16/PIC18-as csaladokra, szoval az ketsegtelen hogy nincs annyi tapasztalatom ezekben mint nektek. Ettol fuggetlenul ezeknel az tunt fel a tobbi es/vagy hasonlo kontrollerekhez kepest hogy a generalt binaris az kb 2x akkora volt (mint pl AVR-en), es leginkabb az indirekcios megoldasok miatt szallt el a meret. Szoval nemcsak a stack a draga sajna hanem az ilyen value=object->member; konstrukciok, vagy altalaban a strukturapointerekkel valo jatek (parameternek atadni kulso fuggvenyhivas eseten, stb). Aztan kicsit jobban megnezve latszik hogy meg a legegyszerubb, legalapabb RISC architekturakon is ott van az LD/ST Rx,[Ry+offset] jellegu utasitas (beleertve mar az AVR-t is), es tkp ez az amit nagyon nehez osszerakni banklapozos hatteren. Jol megcsinalta az xc8-cc, nem az (a bitfield jellegu temakat leszamitva 1:1-ben hordozhato is volt a kod), csak ez az atlag 2x-es szorzo tunt fel. Nyilvan sebessegben is megjelenik ez, de az ott anno nem volt szuk keresztmetszet.