Kompilator C pod PIC

Muszê ciê zmartwiæ - na 18 s± tylko licencjonowane i p³atne. Pozostaje tylko asembler MPLAB....lub trial kompilator

pozdr. józek

Kurciok napisał:

Jaja sobie robisz?

pzdr Artur

Nie zabardzo rozumiem w którym miejscu ?

Kurciok napisał:

Bo chcesz zarabiać pieniądze za pomocą narzędzi które dostajesz za darmo. ;-)

Ale zawsze możesz napisać maila do autora, z prośbą o pozwolenie na komercyjne wykorzystanie jego programu. Może się zgodzi.

pzdr Artur

Artur napisal(a):

O, kolega wlasnie zniknal Linuxa, OpenOffice i AVR-GCC. Grunt to logika.

Nie wierzę że darmowy kompilator będzie tak zoptymalizowany, dopracowany jak płatne wersje . Właściwie to jest niemożliwe zważając jeszce na mnogość procesorów.Lista obsługiwanych procków będzie mizerna/niepełna.

Kurciok napisał(a):

Swoją drogą jak ktoś udowodni że program był napisany w konkretnym kompilatorze, szczególnie że może być tajemnicą firmy?

Podobno hi-tech robi kod do 16kB przynajmniej w wersji trial, akurat nie sprawdzałem ale ktoś tak pisał, ale czy do komercji to nie wiem

PS Jedyne, uczciwe rozwiązanie to chyba stworzenie własnego kompilatora

No wiesz takie podej¶cie :) które polega na pisaniu wszystkiego samemu raczej nie jest odpowiednie :) to mo¿e odrazu napisaæ w³asny system operacyjny w³asnego worda itd. :) A je¶li chodzi o dopracowanie darmowych narzêdzi to z tym ró¿nie bywa, czasami ludziom op³aca siê pisaæ darmowe programy bo np. na swojej stronie albo w samym programie wy¶wietlaj± reklamy itd. inna sprawa to to ¿e programi¶ci np. w USA czêsto programuj± tylko dla zabawy a pieni±dze maj± bo pracuj± (niekoniecznie jako programista). Jak siê mieszka w bogatym kraju to sobie mo¿na pozwoliæ na takie rzeczy. S± serwisy internetowe które wspieraj± darmowe oprogramowanie np. sourceforge.net (tam mo¿na wp³acaæ nawet pieni±dze autorom oprogramowania i bardzo czêsto du¿e firmy to robi± wspieraj±c ich w ten sposób). A je¶li chodzi o kompilatory to np. ja uwa¿am ¿e AVR-GCC jest bardzo dobrym kompilatorem (wed³ug mnie nic mu nie brakuje) a jako¶ darmowy jest. A je¶li chodzi o napisanie w³asnego kompilatora to oczywi¶cie mo¿na (ale to jest co najmniej rok zabawy i to dla kogo¶ kto siê na tym zna).

szlovak napisał(a):

No to wyobraź sobie ze np. w zakresie kompilatorów C dostępnych na AVR , AVRGCC pod względem optymalizacji kodu ustępuje tylko produktowi IAR, a zostawia w tyle kilka uznanych produktów komercyjnych ....

Miłosz Kłosowicz napisal(a):

Jak widze nazwe IAR, to od razu przypominaja mi sie wszelkie bledy ich kompilatorow C dla 8051, z ktorymi musialem wojowac circa 10 lat temu.

Wlasciwie to dlaczego avr-gcc mialoby ustepowac czemukolwiek? Nie chce sie spolecznosci piszacej avr-gcc bardziej dopiescic optymalizera? Przeciez port gcc na avr'y znacznie sie rozni od gcc np. na ARMy i daje sie zastosowac optymalizacje specyficzne dla avr'ow (jak np. zapalanie/gaszenie bitu instrukcja cbi/sbi).

Chce czy nie chce. Nie jest to takie ³atwe pisanie kompilatorów to do¶æ trudna rzecz. A z nadmiaru dobrych chêci bior± siê b³êdy czêsto trudno do wychwycenia :) tak¿e lepiej aby by³ trochê mniej zoptymalizowany ni¿ optymalizowany na si³ê. A najgorsze jest to ¿e optymalizacje trzeba robiæ na ka¿dy typ asemblera z osobna, tak¿e traci siê na to do¶æ du¿o czasu. Np. z g³upiej optymalizacji w AVR-GCC moge wymieniæ while(1); jak siê j± wywo³a to dalsza czê¶æ programu jest odrzucana i w ogóle nie wpisywana do flasha niby s³uszanie bo po while(1) ju¿ w³a¶ciwie nic siê nie mo¿e dziaæ. No ale w uC mo¿na skakaæ pa pamiêci programu np. w przerwaniach (czy wstawkach asemblerowych) tak¿e czasami mo¿na siê na to naci±æ i g³ówkowaæ dlaczego niedzia³a. Pozatym znikaj±ca po³owa programu z flasha po wpisaniu while(1) jest bez senusu.

No tak. Najpierw robisz wstawkę asemblerową, a potem każesz optymalizatorowi zgadywać swoje intencje ;)

A przełącznik -O0 nie działa?

Pozdrawiam

On Mon, 02 May 2005 11:00:22 +0200, Miłosz Kłosowicz snipped-for-privacy@miklobit.WYTNIJTO.com> wrote: [.....]

W ciągu ostatniego roku miałem do czynienia z kompilatorem ARM-a dla ARM-ów :-) i Renesasa dla H8 - czyli tych, które teoretycznie powinny być najlepsze dla tych uC. W obu przypadkach nie były to najnowsze wersje, ale każdym bądź razie IMO gcc jest porównywalny z kompilatorem ARM-a, którego używałem, i lepszy od kompilatora Renesasa.

No, gcc był/jest wykorzystywany jako kompilator w komercyjnych IDE. To też o czymś świadczy.

Regards, /J.D.

On Tue, 3 May 2005 09:49:36 +0200, "Kurciok" snipped-for-privacy@poczta.BEZSPAMUonet.pl> wrote: [.....]

Ano słusznie.

Pisząc program w czystym C nie da się wskoczyć z jakiejś funkcji do wnętrza innej. Używając w kodzie w C wstawek assemblerowych (czyli funkcjonalności niestandartowej), koder musi sam zadbać o to, aby poprawnie obsłużyć takie skoki.

Poza tym w gcc chyba można wyłączyć "dead code elimination". Piszę chyba, ponieważ jeszcze nigdy nie potrzebowałem takiej opcji. :-)

Dlaczego? Ja tam jak najbardziej widzę w tym sens.

Regards, /J.D.

Jan Dubiec napisał(a):

właśnie zniknąłeś setjmp() i longjmp(), które są częścią standardu.

w.

Raczej o tym ze cieli koszty :-)

Natomiast co gcc: przed laty to byl calkiem dobry kompilator optymalizujacy, moze nawet lepszy od innych komercyjnych. "akademickie" pochodzenie owocowalo m.in. implementacja ciekawych algorytmow optymalizacji. A unixowe pochodzenie pozwalalo nie ograniczac sie do 640KB programu kompilatora :-) Konkurencja zreszta niekoniecznie robila cos lepszego, skoro mogla tanim kosztem przystowac standardowy cc.

Natomiast to jest niestety "powazny kompilator C", ktory "zle sie czuje" na malych 8-bit prockach. Ale na ARM powinien byc swietny.

J.

Masz rację. Ale z drugiej strony to chyba dobrze że je "zniknąłem". :-)

Regards, /J.D.