> Mam wrażenie, że testujący założyli, że proponowany kod w C został
> napisany maksymalnie optymalnie albo kompilator niczym wróżka wywróży
> sobie co autor chciał zrobić i wygeneruje do tego jak najbardziej
> krótki kod :-). Pomijam zupełnie, że kompilujecie "pierdulamenty"
> (jakby powiedział Stachu) przez co programiści w asm mogli używać to
> jako argument za wyższością asm nad C.
>
> --
> Marek
Szanuję Twój pogląd, ale my tu o faktach decydujemy.
Nikt nie twierdzi, że język C jest zły.
Problem w tym, ze nie ma dobrego mostu między kodem w C, a wynikiem.
I to jest problem.
Kolega Jacek zadał sobie trud i przekompilował w 4 pozostałych
kompilatorach.
I już wiemy, że HI-Tech jest lepszy.
Więc podziękuj, a nie chodzisz jak żyd po pustym sklepie.
S.

do góry

> U mnie w programi pisanym w ASM liczba instrukcji wynosi: 57
> Instrukcje w głównej pętli sortującej: 20
W tym kompilatorze Hi-Tech 8.05PL2 główna pętla wykonuje się w 46
instrukcjach. procesor pic16f876A
W tym kompilatorze MPLAB C18 v3.12 (demo) 94 instrukcji. PIC18F2320
S.

do góry

Sylwester Łazar wrote:

>> U mnie w programi pisanym w ASM liczba instrukcji wynosi: 57
>> Instrukcje w głównej pętli sortującej: 20
> W tym kompilatorze Hi-Tech 8.05PL2 główna pętla wykonuje się w 46
> instrukcjach. procesor pic16f876A
> W tym kompilatorze MPLAB C18 v3.12 (demo) 94 instrukcji. PIC18F2320
> S.

Ciekawe czy to demo ma wyłączoną optymalizację czy też 'ten typ tak ma'.


jp

do góry

> W tym kompilatorze MPLAB C18 v3.12 (demo) 94 instrukcji. PIC18F2320
Oczywiście sama główna pętla.
Ta ostatnia, która sortuje.
S.

do góry

> >> U mnie w programi pisanym w ASM liczba instrukcji wynosi: 57
> >> Instrukcje w głównej pętli sortującej: 20
> > W tym kompilatorze Hi-Tech 8.05PL2 główna pętla wykonuje się w 46
> > instrukcjach. procesor pic16f876A
> > W tym kompilatorze MPLAB C18 v3.12 (demo) 94 instrukcji. PIC18F2320
> > S.
>
> Ciekawe czy to demo ma wyłączoną optymalizację czy też 'ten typ tak ma'.
Ma włączoną.
"MPLAB C18 v3.12 (demo)
Copyright 1999-2005 Microchip Technology Inc.
Days remaining until demo becomes feature limited: 56
WARNING: The procedural abstraction optimization will not be supported when
the demo becomes feature limited."
Czyli za 56 dni abstrakcyjna optymalizacja zostanie wyłączona.
Cokolwiek to znaczy. Może zacznie działać lepiej :-)

Widać, że ten C18 jest gorszy od HI-Techa.
Jednak, to że Microchip ma kiepski kompilator zauważył już dawno Zbych.
Ja tylko pokazałem jak to wygląda.

Problem jest taki, że średnio też jestem zadowolony z tego kodu HI-Techa.

Nie wiem na co są pisane naprawde dobre kompilatory.
Teraz zmienić procesor to nie jest duży problem.
Problemem jest dobry kompilator i obawiam się, że tendencja jest taka, aby
sprzedać marny produkt,
a wmawia się ludziom, że czyni cuda.
S.

do góry

> Nie wiem na co są pisane naprawde dobre kompilatory.
> Teraz zmienić procesor to nie jest duży problem.
> Problemem jest dobry kompilator i obawiam się, że tendencja jest taka, aby
> sprzedać marny produkt,
> a wmawia się ludziom, że czyni cuda.
> S.
W przeszłości programowałem 51; najpierw asm potem C, miałem jakiś spiracony
klucz sprzętowy na LPT do kompilatora Keil, pod DOS. A że znałem asm na 51
to porównywałem wynik kompilacji.
I powiem jedno: byłem pod wielkim wrażeniem generowanego kodu, przede
wszystkim jego zwartości.
Obecnie chyba jedyna rozsądna droga to ewoluowanie w kierunku gcc i
pochodnych nad rozwojem których pracuje z reguły więcej osób niż nad
rozwiązaniami korporacyjnymi.

jp

do góry

> W przeszłości programowałem 51; najpierw asm potem C, miałem jakiś
spiracony
> klucz sprzętowy na LPT do kompilatora Keil, pod DOS. A że znałem asm na 51
> to porównywałem wynik kompilacji.
> I powiem jedno: byłem pod wielkim wrażeniem generowanego kodu, przede
> wszystkim jego zwartości.
Ja jednak mam inne doświadczenia.
To znaczy nie analizowałem kodu po tłumaczeniu.
Jednak na 8051 zabrakło mi pamięci 64kB programu, przy tworzeniu
oprogramowania
na centralkę telefoniczną.
Musiałem się mocno gimnastykować, poprawiając kod w C, aby w ogóle się
zmieścić.
Wyciągnąłem wtedy wniosek, że kompilator robi straszną nadbudowę.
Jednak mogło być też i tak, że kod był mało optymalny.
Wtedy nauczyłem się wyciskać z C dosłownie kilobajty.
Doszedłem do tego, że istnieje już granica, której się nie przeskoczy.
Od tego momentu wybieram, czy piszę w C, czy w asm.
Jako, że człowiek jadł już z wielu piecy chleb... najczęściej wybieram ASM,
gdyż nie lubię, jak na LCD widać jak obraz wczytuje się niczym w ZX Spectrum
podczas wczytywania z taśmy:-)

> Obecnie chyba jedyna rozsądna droga to ewoluowanie w kierunku gcc i
> pochodnych nad rozwojem których pracuje z reguły więcej osób niż nad
> rozwiązaniami korporacyjnymi.
>
> jp
Nie sądzę, że jedyna.
Tam gdzie kupa ludzi, tam też i kupa ... błędów.
2) Wydaje mi się, że lepiej wypróbować kontakt z HI-Techem.
Widać, że są tam ludzie, którzy wiedzą o co chodzi.
Może im podpowiadać, czego będziemy oczekiwać.
Może zechcą rozijać się w kierunku prawdziwej optymalizacji.

3) Samemu stworzyć kompilator.
Jest to trudniejsze, ale jeśli się chce, to czemu nie.
Skoro tworzy się swoje uC z własną listą rozkazów?
4) Jak już, to stworzyć swój procesor z instrukcjami C, które działają
poprawnie.
Zresztą MCHIP w 18F już dołożył kilka drobnostek do FSRów, jak FSRx++,
FSRx--,++FSRx, FSRx+w.
Ale to drobnostki, ograniczone i 8-bitowe.
Zresztą adresowanie z przesunięciem już dawno miał INTEL.

Problem w tym, że trzeba mieć doświadczenie, a Hi-Tech (i inne też) mają
wieloletnie.
Dlatego opcja 2 wydaje się sensowna, jeśli zaskoczy.
Ale trzeba rozmawiać z konkretnymi programistami, a nie przez "sekretarkę".
Może zacząć od tego, że "Kocham Was i szanuję, chcę z Wami być, ale nie mam
co od Was kupić" :-)
S.

do góry

Użytkownik Sylwester Łazar napisał:
>> W przeszłości programowałem 51; najpierw asm potem C, miałem jakiś
> spiracony
>> klucz sprzętowy na LPT do kompilatora Keil, pod DOS. A że znałem asm na 51
>> to porównywałem wynik kompilacji.
>> I powiem jedno: byłem pod wielkim wrażeniem generowanego kodu, przede
>> wszystkim jego zwartości.
> Ja jednak mam inne doświadczenia.
> To znaczy nie analizowałem kodu po tłumaczeniu.
> Jednak na 8051 zabrakło mi pamięci 64kB programu, przy tworzeniu
> oprogramowania
> na centralkę telefoniczną.
> Musiałem się mocno gimnastykować, poprawiając kod w C, aby w ogóle się
> zmieścić.

A jakie to funkcje ta centralka miała? Niegdyś wystrugałem prostą
centralkę na 89C52, 1 linia zew, 4 wew, LCD znakowy do monitorowania
stanu, własny generator dzwonienia i dekoder DTMF. O ile pamiętam kod
miał jakieś 3kB, oczywiście pisany w asm.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

Sylwester Łazar wrote:

>> W przeszłości programowałem 51; najpierw asm potem C, miałem jakiś
> spiracony
>> klucz sprzętowy na LPT do kompilatora Keil, pod DOS. A że znałem asm na
>> 51 to porównywałem wynik kompilacji.
>> I powiem jedno: byłem pod wielkim wrażeniem generowanego kodu, przede
>> wszystkim jego zwartości.
> Ja jednak mam inne doświadczenia.
> To znaczy nie analizowałem kodu po tłumaczeniu.
> Jednak na 8051 zabrakło mi pamięci 64kB programu, przy tworzeniu
> oprogramowania
> na centralkę telefoniczną.
> Musiałem się mocno gimnastykować, poprawiając kod w C, aby w ogóle się
> zmieścić.
Ale robiłeś w Keilu?
Bo był jeszcze IAR, który faktycznie produkował kod, delikatnie mówiąc,
niezbyt optymalny.
>
>> Obecnie chyba jedyna rozsądna droga to ewoluowanie w kierunku gcc i
>> pochodnych nad rozwojem których pracuje z reguły więcej osób niż nad
>> rozwiązaniami korporacyjnymi.
>>
>> jp
> Nie sądzę, że jedyna.
> Tam gdzie kupa ludzi, tam też i kupa ... błędów.
I większa wymiana informacji, co pozwala na ich obejście, zastosowanie
innego rozwiązania.
> 2) Wydaje mi się, że lepiej wypróbować kontakt z HI-Techem.
> Widać, że są tam ludzie, którzy wiedzą o co chodzi.
Nie sądzę, ponieważ HiTech jest chyba obecnie częścia Microchipa (vide brak
kompilatorów dla innych platform) ze wszystkimi konsekwencjami, tzw. kultury
korporacyjnej.
> Może im podpowiadać, czego będziemy oczekiwać.
> Może zechcą rozijać się w kierunku prawdziwej optymalizacji.
Managment w wielkiej korporacji, za cel nadrzędny stawia sobie utrzymanie
się na stołkach, więc nie sądzę, żeby produkt był lepszy- raczej dodaje się
więcej czynnika marketingowego (w strukturze 4*P
(product,price,place,promotion).


jp
>
> 3) Samemu stworzyć kompilator.
> Jest to trudniejsze, ale jeśli się chce, to czemu nie.
> Skoro tworzy się swoje uC z własną listą rozkazów?
> 4) Jak już, to stworzyć swój procesor z instrukcjami C, które działają
> poprawnie.
> Zresztą MCHIP w 18F już dołożył kilka drobnostek do FSRów, jak FSRx++,
> FSRx--,++FSRx, FSRx+w.
> Ale to drobnostki, ograniczone i 8-bitowe.
> Zresztą adresowanie z przesunięciem już dawno miał INTEL.
>
> Problem w tym, że trzeba mieć doświadczenie, a Hi-Tech (i inne też) mają
> wieloletnie.
> Dlatego opcja 2 wydaje się sensowna, jeśli zaskoczy.
> Ale trzeba rozmawiać z konkretnymi programistami, a nie przez
> "sekretarkę". Może zacząć od tego, że "Kocham Was i szanuję, chcę z Wami
> być, ale nie mam co od Was kupić" :-)
> S.

do góry

> Ale robiłeś w Keilu?
> Bo był jeszcze IAR, który faktycznie produkował kod, delikatnie mówiąc,
> niezbyt optymalny.
Faktycznie IAR.

> Nie sądzę, ponieważ HiTech jest chyba obecnie częścia Microchipa (vide
brak
> kompilatorów dla innych platform) ze wszystkimi konsekwencjami, tzw.
kultury
> korporacyjnej.
Ale chyba, skoro przejęli HiTecha, to może chcą mieć lepszy kompilator dla
swoich chipów,
abyśmy je kupowali.
Nigdy nie wiadomo.

> Managment w wielkiej korporacji, za cel nadrzędny stawia sobie utrzymanie
> się na stołkach, więc nie sądzę, żeby produkt był lepszy- raczej dodaje
się
> więcej czynnika marketingowego (w strukturze 4*P
> (product,price,place,promotion).
Na dwoje babka wróżyła.
S.

do góry