Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Masz problem? Zapytaj na forum elektroda.pl
From: JK <Janusz_k_at_nospam_um.bielsko.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Thu, 01 Mar 2001 15:25:41 +0100
1) czy jest za darmo?
W EP mozna mieć wersję 2K prawie za darmo, a nawet pełna wersja kosztuje niewiele
2) a jak w nim zrobisz unię, albo będziesz tę samš zmiennš
widział/traktował raz jako znak, a raz jako pole bitowe albo float-a,
albo
jeszcze co innego? (właśnie teraz tak mam- mam rekord o ustalonej
długości,
A po co mi takie kombinacje? takie traktowanie zmiennych przez C jest głównš
przyczynš
powstawania paskudnych błędów trudnych do debugowania.
3) co z procedurami z dużymi wymaganiami czasowymi?
To samo co w C ;-)) każdy kompilator generuje okreslony kod, jeżeli ktoś w
przerwaniach np próbuje robić
obsługe wyśw albo inne pracochłonne operacje to żaden język mu nie pomoże, to
jest kwestia stylu
programowania, a proste operacje przypisania zmiennych, arytmetyczne kompiluje w
miarę efektywnie i myślę
że niewiele odbiegajš one od C.
4) co z wywoływaniem procedury/funkcji przez niš samš?
Nie próbowałem i nie wiem , ale rekurencję można stosunkowo prosto zastapić pętlš
np: For lub Do.
Wszystko ma swoje zady i walety. To, o czym piszemy, to sš błędy w
implementacji/błędy przy tworzeniu kompilatora.
Wiem o tym i dlatego piszę że Bascom akurat pod tym względem jest dużo lepiej
napisany,
a w końcu zarzšdzanie zmiennymi to fundament.
Jeszcze jedna uwaga- algorytm napisany w C można przenieść bez
większych kłopotów (jeli się wie, co się robi :-) ) na innš platformę (a
łatwiej jest zmienić sprzęt, niż napisać od nowa oprogramowanie). Na ilu
platformach masz Bascoma?
A co na PC-ta przeniesiesz? Bascom jest też na AVR-y i w zupełności wystarczy,
proste
zastosowania to 51, bardziej wymagajšce to AVR, a programowanie w asm-ie na
AVR-erze to
już nie jest taka kaszka z mlekiem jak na 51, i tutaj takie narzędzie się
naprawdę przydaje.
Pozdrawiam,
Marcin.
PS. A ja to piszę tylko po to, żeby innym ew. oszczędzić szukania. Bo
tak w zasadzie mógłbym siedzieć cicho i niech się inni martwiš :-).
A czego szukania? i tak zawsze pozostaje asembler dla krytycznych procedur czy
dla pewnych efektów, a narzędzia wysokiego poziomu sš po to aby głównš ideę
programu robić
prosto i przejrzyście
Janusz K
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Fri, 02 Mar 2001 04:48:58 +0100
JK wrote:
1) czy jest za darmo?
W EP mozna mieć wersję 2K prawie za darmo, a nawet pełna wersja kosztuje niewiele
Niewiele- pojęcie względne.
2) a jak w nim zrobisz unię, albo będziesz tę samą zmienną
widział/traktował raz jako znak, a raz jako pole bitowe albo float-a,
albo
jeszcze co innego? (właśnie teraz tak mam- mam rekord o ustalonej
długości,
A po co mi takie kombinacje? takie traktowanie zmiennych przez C jest główną
przyczyną
powstawania paskudnych błędów trudnych do debugowania.
Już Ci mówię, po co. Bo taka jest specyfikacja, pod którą ma powstać program, bo
taka reprezentacja zajmuje mało/określoną (optymalne wykorzystanie zasobów) ilość
miejsca. I już. Pisanie programu sobie a muzom jest czczym zajęciem jak dla mnie, a
jeśli piszę dla kogoś, to on czasem ma pewne wymagania odnośnie tego, co mu wyślę
(formatu danych wyjściowych z '51). Bo czasem wygodnie jest zapisać dane (o których w
chwili zapisu wiadomo, co oznaczają) a póĽniej nie przejmować się już ich znaczeniem,
tylko je wytransmitować. Bo pola bitowe są dobrym sposobem na zrzucenie na kompilator
operacji w stylu 'na bitach od 3 do 6 zapisz zmienną "a"'. Tak, można ręcznie. I
wtedy właśnie zaczynają się błędy i kłopoty. A jeśli kompilator działa poprawnie
(SDCC nie działa poprawnie), to takie przypisanie jest, jak dla mnie, bardzo wygodne.
Tak, można na to zużyć cały bajt. Ale wtedy zmieści się mniej danych.
3) co z procedurami z dużymi wymaganiami czasowymi?
To samo co w C ;-)) każdy kompilator generuje okreslony kod, jeżeli ktoś w
przerwaniach np próbuje robić
obsługe wyśw albo inne pracochłonne operacje to żaden język mu nie pomoże, to
jest kwestia stylu
programowania,
To na pewno. Tylko że SDCC jest na tyle dobry, że spokojnie zrobiłem sobie na nim
na przerwaniach odbiór i nadawanie po RS-ie i działa na 115200. Mały i ładny kawałek
kodu. Bardzo prosty do napisania w C, ciężki w asmie. Ciekawe, jak w BASICu.
a proste operacje przypisania zmiennych, arytmetyczne kompiluje w
miarę efektywnie i myślę
że niewiele odbiegają one od C.
Nie wiem. Jedno wiem na pewno- zaletą _porządnego_ kompilatora C jest dobre
zarządzanie pamięcią- zwłaszcza tą potrzebną lokalnie, wew. procedury, na zmienne
tymczasowe. Wniosek- SDCC nie jest dobrym kompiltorem. Koniec.
4) co z wywoływaniem procedury/funkcji przez nią samą?
Nie próbowałem i nie wiem , ale rekurencję można stosunkowo prosto zastapić pętlą
np: For lub Do.
Nie zawsze. Są przypadki, kiedy to po prostu nie wychodzi. Przykład (może nie na
uC, ale i tu by się co znalazło)- analiza wyrażeń arytmetycznych z nawiasami. To, co
jest w nawiasach jest wyrażeniem, które jest wejściem z powrotem do procedury
analizującej. Nie wyobrażam sobie sensownego zapisu tego bez rekurencji. Ogólnie-
analiza wyrażeń języka bezkontekstowego.
Wszystko ma swoje zady i walety. To, o czym piszemy, to są błędy w
implementacji/błędy przy tworzeniu kompilatora.
Wiem o tym i dlatego piszę że Bascom akurat pod tym względem jest dużo lepiej
napisany,
a w końcu zarządzanie zmiennymi to fundament.
Zgoda. Ale SDCC ewoluuje. I mam do niego Ľródła. Nie mam czasu na poprawianie,
cóż, ale mógłbym, gdybym ten czas miał.
Poza tym- to jest Ľle napisany kompilator. Dość szczególny przypadek kompilatora
C.
Jeszcze jedna uwaga- algorytm napisany w C można przenieść bez
większych kłopotów (jeli się wie, co się robi :-) ) na inną platformę (a
łatwiej jest zmienić sprzęt, niż napisać od nowa oprogramowanie). Na ilu
platformach masz Bascoma?
A co na PC-ta przeniesiesz?
Tak, czasami. Np. analizę ramek ISDN jednego kanału D 8051 zrobi. Ale jak kanałów
będzie kilka, albo jak trzeba będzie przerobić wszystkie dane przed rozdzieleniem na
kanały D i B i cośtamjeszcze, to się już nie wyrobi. A po co pisać jeszcze raz
obsługę tego wszystkiego? Pobudki maso są mi obce.
Czasami to, co w procku ląduje jako część oprogramowania PC-ta- bardziej się
opłaca zrobić kartę PCI, niż szybki sprzęg szeregowy/równoległy i do tego dać procka
na tyle szybkiego, żeby sobie dał radę.
Poza tym czasami zmienia się konstrukcję sprzętową i przechodzi na zupełnie inny
procesor. Np. na 386EX. Albo na HC12. I co- znowu wszystko od nowa? To dopiero
starata czasu...
Bascom jest też na AVR-y i w zupełności wystarczy,
proste
zastosowania to 51, bardziej wymagające to AVR, a programowanie w asm-ie na
AVR-erze to
już nie jest taka kaszka z mlekiem jak na 51, i tutaj takie narzędzie się
naprawdę przydaje.
Nie będę polemizował. To w końcu Ty wiesz najlepiej, czy Ci się przydaje, czy
nie.
PS. A ja to piszę tylko po to, żeby innym ew. oszczędzić szukania. Bo
tak w zasadzie mógłbym siedzieć cicho i niech się inni martwią :-).
A czego szukania?
Ew. błędów. BądĽ dochodzenia- 'dlaczego mój program nie działa'. Po prostu- dla
tych, co być może chcą użyć SDCC. No bo- tak na dobrą sprawę- cóż mi z tego pisania?
-)
i tak zawsze pozostaje asembler dla krytycznych procedur czy
dla pewnych efektów, a narzędzia wysokiego poziomu są po to aby główną ideę
programu robić
prosto i przejrzyście
To zgoda. Ale staram się w asmie robić jak najmniej.
Pozdrawiam,
Marcin.
PS. Proponuję zakończyć wątek o wyższości świąt B.N. nad świętami W.N. MZS- to nie ma
sensu. Całym moim zamiarem było podzielenie się wiedzą z potencjalnymi użytkownikami
SDCC, a nie wykłócanie, co lepsze.
Mam swoje zdanie n.t. BASICa w ogólności. Raczej niepochlebne. Natomiast nie mam
monopolu na słuszność, więc...
M.
--
'My experience is that it is hard to find software producers that aren't fuzzy.'
From: JK <Janusz_k_at_nospam_um.bielsko.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Fri, 02 Mar 2001 09:27:20 +0100
PS. Proponuję zakończyć wštek o wyższości świšt B.N. nad świętami W.N.
Zgadzam się.
W sumie bardziej zmierzałem napisać że do 'domowych' i prostych zastosowań Bascom nie
jest taki zły
jak został 'zrównany z ziemiš' kiedyś na grupie, i tylko tyle.
MZS- to nie ma
sensu. Całym moim zamiarem było podzielenie się wiedzš z potencjalnymi użytkownikami
SDCC, a nie wykłócanie, co lepsze.
Mam swoje zdanie n.t. BASICa w ogólności. Raczej niepochlebne. Natomiast nie mam
monopolu na słuszność, więc...
Ja tez nie ;-)) Ale lekko próbowałem go bronić :), a porównanie do Stampa przez kogoś na
grupie to przesada.
Janusz K