To, że pic16 (18F) jest przyjazny dla C.nie oznacza że Microchipowa
implementacja C jest przyjazna dla użytkownika :-), ale po kolei:

On Sun, 15 Nov 2015 10:31:51 +0100, Zbych <z...@o...pl> wrote:
> A co jest przyjaznego w stronicowaniu RAMu co 256B, stronicowaniu
flasha

Stronicowanie flasha jest w corach pic14 (16F i mniejsze), core'y
pic16 (18F) tego nie mają.
Problem stronicowanie w pic14 nie dotyczy programowania C, np. SDCC
na pic14 obsługuje to przezroczyscie dla programisty. Oczywiście inną
kwestią jest wpływ na wydajność takiego stronicowania.


> i sprzętowym stosie?

W czym to przeszkadza, skoro on jest tylko używany do call/return a
kompilator i tak używa własny stos, którego wielkość można dowolnie
ustalać? Po za tym są "shadowed registers", które sprzętowo
wspomagają zachowywanie/odtwarzanie rejestrów przy obsłudze przerwań.

> I czemu użytkownik oryginalnego kompilatora
> microchipa (picc18) musi ręcznie przydzielać zmienne do banków
jeśli
> chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne?

Ależ to są głównie problemy C18 (kompilatora i linkera), użyj inny
kompilator. W SDCC np. nie ma problemu z rozróżnianiem wskaźników do
flash i ram. W XC8 też już tego nie ma.

Trzeba też brać pod uwagę, że mówimy o 8 bitiwcach. Rejestry są 8
bitowe więc dostęp do pamięci większej niż 256 bajtów będzie zawsze
się odbywał przez paradygmat stronicowania, bez względu jak
technicznie będzie to zrealizowane (segment:offset, przełączanie
banków, łączenie rejestrów itp). Oczywiście kompilator/linker może to
"ukryć", ale to już kwestia implementacji, ale ona może mieć wpływ na
wydajność.
Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?


>Albo
> czemu musi tablice przekraczające 256B adresować tylko z użyciem
wskaźników?

? w C18 nigdy nie miałem problemu z adresowaniem dużych tablic,
poproszę o szczegóły/przykład. W SDCC jest/był problem z dużymi
tablicami ale to dotyczy core'ow pic14.

--
Marek