Kompilator C pod PIC

Inna sprawa to to, że gcc jest napisany z myślą o płaskiej, połączonej przestrzeni adresowej danych i programu (von Neumanna), a taka '51 ma trzy różne przestrzenie adresowe, w Picach dwie + bankowanie pamięci. A port na avr musi się zadowalać protezami w postaci makr :]

Jan Dubiec napisał:

Bardzo dobrze. ;-) Przecież to koronny argument przeciwników basika - goto. Inna sprawa, że w prockach czasami pokusa jest zbyt duża. ;-)

pzdr Artur

TO nie bardzo jest goto. I w sumie nie kloci sie z optymalizacja ..

J.

Marcin E. Hamerla napisał:

A jest przy nich napisane, że można używać do celów komercyjnych?

pzdr Artur

Można.

Serdeczne

Artur napisał(a):

jeśli ktoś lubi sobie życie utrudniać, to niech się bawi w unikanie goto w imię niechęci do jakiegoś języka (;

w.

Nie jestem pewien czy gcc pisano z myślą o architekturze von Neumanna, ponieważ np. ARM-y wyższe niż 7, a na pewno te oparte o rdzeń ARM9TDMI, mają architekturę harwardzką i gcc (jakoś) je supportuje w standardzie. Tak czy inaczej, aby dobrze obsługiwać uC o architekturze harwardzkiej, trzebaby wprowadzić drobne(?) rozszerzenia do standardu C: chodzi np. o możliwość wskazania kompilatorowi w której przestrzeni adresowej mają być umieszczone zmienne i stałe - czyli to co można spotkać np. w kompilatorach dla PIC i MCS51. Zresztą ten problem dotyczy nie tylko uC, ale również i wielu DSP, które również są "harwardami".

BTW. Traktując wewnętrzny RAM jako zbiór rejestrów, to IMO MCS51 ma dwie przestrzenie adresowe. :-)

Regards, /J.D.

No co wiêcej mo¿e nawet samemu sprzedawaæ Linuxa czy OpenOffice i czerpaæ z tego dochody (np. na allegro tak robi±).

Marcin Stanisz napisał:

Hm... Jestem zaskoczony :-(. Właściwie to powinno być :-D.

pzdr Artur

Z opisów, które znalazłem wynika, że od strony sprzętowej 9 ma architekturę harvardzką, ale od strony programowej wszystko jest widoczne jako jedna przestrzeń adresowa (a przynajmniej nie znalazłem osobnych rozkazów do obsługi pamięci programu i pamięci danych).

C architektura harvardzka niemal nie przeszkadza - zostaje tylko malutki problem z danymi zainicjowanymi ktore trzeba w przestrzeni danych umiescic.

Bardziej mu przeszkadza brak 16 uniwersalnych rejestrow, klopot z adresowaniem danych na stosie, smiesznie maly RAM, zlamanie standardu w paru miejscach, gdzie mowi ze domyslny typ posredni ma byc int itp.

J.

On Sat, 07 May 2005 00:16:44 +0200, Zbych snipped-for-privacy@onet.pl wrote: [.....]

Również co nieco poczytałem i wychodzi na to że ARM9 są trochę oszukane. Owszem, rdzeń ARM9TDMI ma rozdzielne szyny dla instrukcji i danych, ale jest spięty ze światem zewnętrznym, w szczególności z pamięcią, jedną szyna systemową. Trick polega na tym, że procesory oparte o ten rdzeń mają dwie rozłączne pamięci cache dla instrukcji i danych. I do tego podwójne MMU. Ot, taki kompromis pomiedzy wydajnością architektury harwardzkiej a "prostotą" i wygodą arch. von Neumanna.

Regards, /J.D.

On Sat, 07 May 2005 01:29:58 +0200, J.F. <jfox snipped-for-privacy@poczta.onet.pl> wrote: [.....]

No, sekcję danych (a konkretnie zmiennych) zainicjalizowanych to trzeba przerzucić z pamięci nieulotnej do RAMu chyba zawsze, niezależnie od architektury uP/uC. :-)

Gorzej jest ze stałymi, które są umieszczane w sekcji "read only data", i aż się prosi, aby wylądowała ona w pamięci nieulotnej, której mamy zazwyczaj kilkadziesiąt razy więcej niż RAMu. Na architekturze von Neumanna nie ma problemu, ale jak np. dla AVR zrobić printf-a, który będzie potrafił wypisać zarówno stały ciąg znaków jak i zawartość dynamicznie zaalokowanego bufora? :-) Czyli albo zużywamy cenny RAM w którym dublujemy część ROM-u, albo pieprzymy się z dwiema wersjami printf-a. Nie wiem co lepsze. :-)

Regards, /J.D.