On 15.11.2015 11:14, Marek wrote:
>> 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ń.

Sprzętowy stos przeszkadza w przełączaniu wątków.
Ile jest zestawów "shadow registers"? Po jednym dla każdego wektora
przerwania? Bo dokumentacja microchipa jest jakoś skąpa w tym zakresie.

>> I czemu użytkownik oryginalnego kompilatora microchipa (picc18) musi
>> ręcznie przydzielać zmienne do banków
> jeślihttp://www.xargs.com/pic/picc18-vs-c18.html
>> 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.

Własny procek microchipa i jego własny (płatny!) kompilator nie był w
stanie ukryć upierdliwości (czy może przyjaznej dla kompilatorów)
architektury.

XC8 nie testowałem, bo parę lat wstecz gdy wybierałem kompilator na PIC,
to XC8 generował większy kod na PIC18 i sypał dużą ilością warningów na
stosie TCP/IP microchipa. Stwierdziłem, że nie chcę być królikiem
doświadczalnym. Opłacanie prawa do aktualizacji też nie nastawiało
optymistycznie:

If your HPA has expired, you are entitled to download all compiler
versions that have been released up to the time of the expiration.

> 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ść.

8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd ten
pomysł?

> Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?

Normalnie, adres jest 16-bitowy (albo dłuższy).

>> 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.

Cytat ze strony: http://www.xargs.com/pic/picc18-vs-c18.html
Zwróć uwagę na ostatnie zdanie.

PICC-18 allows RAM objects of any size to be declared, though some
limitations exist that require balancing objects between C source files
in certain cases. C18 does not support RAM objects larger than 256 bytes
by default; creating such objects requires editing linker control files
and adding pragmas to the C source which include hard-coded variable
addresses. These objects can only be accessed through pointers, not
directly.