Kompilator C pod PIC

Kurciok napisał:

Jaja sobie robisz?

pzdr Artur

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

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

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.