Jakie są wszystkie rozkazy w procesorach Z80 i 8080 ? podzielmy się wiedzą!

=?ISO-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

Swoja droga, czy ktos potrafi wymienic te moim zdaniem 158 rozkazow?
albo 78 rozkazow 8080? Tylko dokladnie co do jednego, bo jakos nie
moge sie doliczyc jak to bylo liczone ..

J.

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

--
> Jarek Andrzejewski

Nie musisz korzystać ze wszystkich, wolny wybór.
Poza tym większa ilość rozkazów przekłada się na krótszy kod wynikowy.
Procesory Motoroli miały swoje środowiska okienkowe w czasach gdy na PC
był tylko DOS bo
Intel wymaga trzy razy więcej pamięci dla osišgnięcia tego samego efektu
co Motorola
(mało elastyczna lista rozkazów).
Rozkazy w RISCach wykonywane sš w jednym takcie zegara. Krótszy kod
powoduje szybsze wykonanie procedury.
AVR sš bogatsze sprzętowo i na jedno polecenie wymagajš jednego taktu
zegara PICe 4.
Wszystkie AVR sš reprogramowalne w PICach tylko 84.
Generalnie PICE poniekšd dobre chipy z których korzystam sš o klasę
gorsze.
A zatem hasło jak wyżej to lipa.

Janusz R.

Jaroslaw Andrzejewski napisał(a):

Rozkazy w RISCach wykonywane sš w jednym takcie zegara. Krótszy kod
powoduje szybsze wykonanie procedury.
AVR sš bogatsze sprzętowo i na jedno polecenie wymagajš jednego taktu
zegara PICe 4.

-)

Janusz Raniszewski napisał(a) w wiadomości:
<37AA1D0B.E7519FBE_at_nospam_man.koszalin.pl>...

Jaroslaw Andrzejewski napisał(a):

Rozkazy w RISCach wykonywane sš w jednym takcie zegara. Krótszy kod
powoduje szybsze wykonanie procedury.
AVR sš bogatsze sprzętowo i na jedno polecenie wymagajš jednego taktu
zegara PICe 4.

He chyba wlasnie RISC jest znacznie prostrzy niz zwykly procek :-) Wyobraz
sobie model PIC-a w VHDL - no taki uproszczony. Masz kostke FPGA, do niej
wszystkie nozki scalaka FLASH i scalaka RAM.

podeklarujemy sobie:

CLK :in std_logic
ram_addr :out std_logic_vector (15 downto 0);
flash_addr :out std_logic_vector (15 downto 0);
main_data :inout std_logic_vector (7 downto 0);
oppcode :inout std_logic_vector (3 downto 0); -- to bedzie prakujace
4 bity z 12 bitowego slowa
ram_wr_n :out std_logic;
ram_rd_n :out std_logic;
flash_wrn :out std logic;
ble ble
ram_ce_n ... itd ...
...
itd zdefiniujemy sobie wszystkie nozki hipotetycznego procesora jakby byl to
uklad na dyskretnych.
I teraz tak definiujemy sobie rejestr PC :-)

signal reg_PC :std_logic_vector (15 downto 0)

w scratch pad area FPGA zrobimy sobie kilka rejestrow wiecej, bo miejsca
kupa.

i zaczynamy zabawe - jesli nie uzywamy pipeline -ingu to nawet CLK moze miec
duty cycle 10/90 :-) A jak uzywamy to dodajemy CLK1 i fizycznie laczymy ten
sam zegar do 2-go wejscia zegara w FPGA, bo jak wiadomo, nie mozna w tym
samym okresie pracowac na roznych zboczach - dostaniemy polarity error.
Na malejacym zboczu ciagniemy rozkaz - kolejne slowo

i jedziemy kolejno - na kazdym narastajacym zboczu CLK mamy tyle
przezutnikow ile rozkazow i kazdy powiedzmy pod jakims tam warunkiem
inkrementuje PC albo dekrementuje lub robi cos innego

Np jmp zrobimy pod warunkiem, ze clk'event and clk='1' then if ble ble ble
porownanie oppcode i jesli oppcode=rozkazowi jump to reg_PC <= reg_PC +
main_data. Dalej dodajemy to do addr FLASH i wystawiamy nastepny adres i
idzie samo :-)
Operacje na wektorach polykaja duzo miejsca ale dla przykladu PIC by sie na
CPLD 512 makrocel chyba zmiescil. FPGA sa tansze, a jak zrobisz ASIC-a to
pojedyncze dolary.

i tak po kolei i mamy procesor :-) Zanosimy do fabryki i robimy PDF-a :-) i
sprzedajemy :-)

Bedzie core MP3 niebawem - moze do swiat mi sie uda. Ktos reflektuje ?
Licencja na przygotowanie do konkretnej aplikacji klienta czyli wejscie
rownolegle - wyjscie do przetwornika. Wydajnosc - hmmm megabajty na sekunde

-)

Juliusz

Ok. AVR to też RISC tylko do wykonania polecenia potrzebuje jednego taktu
oscylatora,
który stanowi jeden takt zegara systemowego w PICach cztery takty zegara

jeden takt zegara systemowego.
Myślę, że AVR powielajš oscylator razy cztery a potem dzielš licznikiem

cztery i układem kombinacyjnym
aby osišgnšć odpowiednio sfazowane impulsy sterujšce. Zresztš w RISCAch to

nowego.

Odnośnie MP3 sam się zastanawiałem czy to się uda na AVR. Z moich szacunków
wynika, że może się
udać dla słowa 8 bit i 20kHz próbkowania.

Odnośnie MP3 sam się zastanawiałem czy to się uda na AVR. Z moich szacunków
wynika, że może się udać dla słowa 8 bit i 20kHz próbkowania.

A po co procesor ? Mowie, ze FPGA wystarczy. Mysle, ze $5000 bedzie fair za
core. Chcesz kupic licencje ?

On Fri, 06 Aug 1999 22:02:37 GMT, Juliusz wrote:

Odnośnie MP3 sam się zastanawiałem czy to się uda na AVR. Z moich szacunków
wynika, że może się udać dla słowa 8 bit i 20kHz próbkowania.

A po co procesor ? Mowie, ze FPGA wystarczy. Mysle, ze $5000 bedzie fair za
core. Chcesz kupic licencje ?

A FPGA wystarczy do wszystkiego ? Lacznie z obluga przyciskow,katalogu
CDROM i wyswietlacza ?

Bo moze jednak procesorkiem prosciej i taniej - i to nawet DSP a nie
meczyc sie na AVR :-)

J.

Być może FPGA wystarczy, na pewno będzie szybszy (oczywiście o ile wystarczy
muzasobów). Niestety nie wiem jak przeprowadzić analizę FFT posługujšc się FPGA
(sinusy, cosinusy, float type). Być może jest jakiś myk, którego nie znam
Uważam, że należy po prostu przeprowadzić analizę widmowš sygnału i wycišć z
widma pršżki odpowiadajšce dżwiękom maskowanym. Potem mogę się pokusić o
odwrotnš FFT i rekonstrukcję sygnału. Analizę widmowš można przeprowadzić
rzucajšc sygnał na szereg filtrów równoległych, czy to się da przeprowadzić w
FPGA?

Słowem robię w tym w czym czuję się mocny.
DSP - owszem widziałem rozwišzania XEMICSa w sieci to by mi odpowiadało. Na
tradycyjne DSP chyba się nie skuszę.
Gigantyczne ilości nóżek a pobór pršdu pewnie jak w hucie.

Janusz R

"J.F." napisał(a):

A FPGA wystarczy do wszystkiego ? Lacznie z obluga przyciskow,katalogu
CDROM i wyswietlacza ?
Bo moze jednak procesorkiem prosciej i taniej - i to nawet DSP a nie
meczyc sie na AVR :-)

Być może FPGA wystarczy, na pewno będzie szybszy (oczywiście o ile wystarczy
muzasobów).

Niestety nie wiem jak przeprowadzić analizę FFT posługując się FPGA
(sinusy, cosinusy, float type).

-)

Analizę widmową można przeprowadzić
rzucając sygnał na szereg filtrów równoległych, czy to się da przeprowadzić w
FPGA?

Na
tradycyjne DSP chyba się nie skuszę.
Gigantyczne ilości nóżek a pobór prądu pewnie jak w hucie.

Na
tradycyjne DSP chyba się nie skuszę.
Gigantyczne ilości nóżek a pobór prądu pewnie jak w hucie.

Zalezy - jak sie decydujesz na najszybszy model siegajacy GFLOPS, to
to musi zrec, ale sie do wizjii nadaje.

Gigantyczne ilości nóżek a pobór prądu pewnie jak w hucie.

Zalezy - jak sie decydujesz na najszybszy model siegajacy GFLOPS, to
to musi zrec, ale sie do wizjii nadaje.

Do wizji wystarczy rodzina TMS320.
Coś miedzy 55-60 stopni Celsjusza.

Bedzie core MP3 niebawem - moze do swiat mi sie uda. Ktos reflektuje ?
Licencja na przygotowanie do konkretnej aplikacji klienta czyli wejscie
rownolegle - wyjscie do przetwornika. Wydajnosc - hmmm megabajty na sekunde

-)

Juliusz

Jaroslaw Andrzejewski napisał(a):

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

--
> Jarek Andrzejewski

Sorry pomyłka odniosłem się do twierdzenia "AVR to syf. Ponad 120 rozkazów do
nauczenia"

Janusz R.

Jaroslaw Andrzejewski napisał(a):

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

--
>> Jarek Andrzejewski
>
>Sorry pomyłka odniosłem się do twierdzenia "AVR to syf. Ponad 120 rozkazów
do
>nauczenia"


To i tak same gadajace glowy wiec co sie przejmujesz ?;-) I tak nic nie
zrobia do czasu gdy nie zrobia sobie wlasnego programatora albo nie zarobia
na kradzionych radiach samochodowych :-) HEHE :-)

Juliusz

Janusz Raniszewski napisał(a) w wiadomości:
<37AB436F.E7B38CFC_at_nospam_man.koszalin.pl>...

Jaroslaw Andrzejewski napisał(a):

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

--
> >> Jarek Andrzejewski
> >
> >Sorry pomyłka odniosłem się do twierdzenia "AVR to syf. Ponad 120 rozkazów
> do
> >nauczenia"
>
> To i tak same gadajace glowy wiec co sie przejmujesz ?;-) I tak nic nie
> zrobia do czasu gdy nie zrobia sobie wlasnego programatora albo nie zarobia
> na kradzionych radiach samochodowych :-) HEHE :-)
>
> Juliusz

Dlaczego wypowiadasz sie w temacie Microchip z ktorego jestes cienki
Bolek
czego dowodzą zdradzajace skrajny dyletantyzm pytania o magistrale PIC'a
i kretynskie uwagi dotyczace KEELOQ'ow za ktore zreszta slusznie gosc
cie
zchrzanil. Poogladaj sobie plyte, website i posłuchaj.

Z reszta zachowujesz sie na tej liscie jak zwyczajny technik-wartownik.
Doszczekujesz
kazdemu kto sie niezbyt dokladnie wyrazi, opiepszasz początkujących
a na dodatek rozmawiasz ostatnio z dyskutanatami w VHDL'u sypiac 41kB
posty
z wyczynami twojego kompilatora. Jak cie rozpiera to zglos do lowcow
glow
niech ci zalatwia robote za granica a nie marnuj sie tu.
A jesli nie chcesz pomoc to sie lepiej nie odzywaj, moze ktos to zrobi
za ciebie
lepiej.

J

Dlaczego wypowiadasz sie w temacie Microchip z ktorego jestes cienki
Bolek
czego dowodzą zdradzajace skrajny dyletantyzm pytania o magistrale PIC'a
i kretynskie uwagi dotyczace KEELOQ'ow za ktore zreszta slusznie gosc
cie
zchrzanil. Poogladaj sobie plyte, website i posłuchaj.

Z reszta zachowujesz sie na tej liscie jak zwyczajny technik-wartownik.
Doszczekujesz
kazdemu kto sie niezbyt dokladnie wyrazi, opiepszasz początkujących
a na dodatek rozmawiasz ostatnio z dyskutanatami w VHDL'u sypiac 41kB
posty

z wyczynami twojego kompilatora. Jak cie rozpiera to zglos do lowcow
glow

-) Albo zlapia was za wspoludzial w przestepstwie za radia samochodowe :-)

A jesli nie chcesz pomoc to sie lepiej nie odzywaj, moze ktos to zrobi
za ciebie.

Janusz Raniszewski napisał(a) w wiadomości:
<37AB436F.E7B38CFC_at_nospam_man.koszalin.pl>...

Jaroslaw Andrzejewski napisał(a):

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

To i tak same gadajace glowy wiec co sie przejmujesz ?;-) I tak nic nie
zrobia do czasu gdy nie zrobia sobie wlasnego programatora albo nie zarobia
na kradzionych radiach samochodowych :-) HEHE :-)

Fri, 06 Aug 1999 22:06:41 GMT, "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
napisał(-a):

Janusz Raniszewski napisał(a) w wiadomości:
<37AB436F.E7B38CFC_at_nospam_man.koszalin.pl>...

Jaroslaw Andrzejewski napisał(a):

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

To i tak same gadajace glowy wiec co sie przejmujesz ?;-) I tak nic nie
zrobia do czasu gdy nie zrobia sobie wlasnego programatora albo nie

na kradzionych radiach samochodowych :-) HEHE :-)

wypraszam sobie i oczekuję przeprosin! Programator już zrobiłem, a
paserem nie jestem.

Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski
<rniski_at_nospam_man.koszalin.pl> napisał(-a):

Jaroslaw Andrzejewski napisał(a):

Wed, 21 Jul 1999 23:51:46 +0200, Juras <juras_at_nospam_freenet.pl> napisał(-a):

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

--
> Jarek Andrzejewski

O jakości procesora oczywiście nie, ale o łatwości programowania tak

MrWebsky

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

O jakości procesora oczywiście nie, ale o łatwości programowania tak

On Sat, 07 Aug 1999 15:32:19 +0200, MrWebsky wrote:

AVR to syf. Ponad 120 rozkazów do nauczenia.
PIC ma tylko 33.

ROTFL: Z80 miał 157 rozkazów i jakoś działał :-)

A zatem hasło jak wyżej to lipa.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

O jakości procesora oczywiście nie, ale o łatwości programowania tak

W ktora strone? Mowisz o czasie czytania instrukcji, czy pozniejszego
programowania ?

J.

Które hasło? Ja pisałem tylko o Z80 i nabijałem się z opinii, że o
jakości procesora decyduje liczba rozkazów.

O jakości procesora oczywiście nie, ale o łatwości programowania tak

W ktora strone? Mowisz o czasie czytania instrukcji, czy pozniejszego
programowania ?

Ograniczona lista rozkazów zawęża potencjalne możliwości zaprogramowania
danego problemu a to powoduje, że szybciej dochodzi sie do rozwiązania
i jest to często rozwiązanie optymalne, bo po prostu nie ma manewru.

Nie musisz korzystać ze wszystkich, wolny wybór.
Poza tym większa ilość rozkazów przekłada się na krótszy kod wynikowy.
Procesory Motoroli miały swoje środowiska okienkowe w czasach gdy na PC
był tylko DOS bo
Intel wymaga trzy razy więcej pamięci dla osiągnięcia tego samego efektu
co Motorola (mało elastyczna lista rozkazów).

On Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski wrote:

Nie musisz korzystać ze wszystkich, wolny wybór.
Poza tym większa ilość rozkazów przekłada się na krótszy kod wynikowy.
Procesory Motoroli miały swoje środowiska okienkowe w czasach gdy na PC
był tylko DOS bo
Intel wymaga trzy razy więcej pamięci dla osišgnięcia tego samego efektu
co Motorola (mało elastyczna lista rozkazów).

Mowiac szczerze to w wielu zastosowaniach zdrowo przesadzasz.
Lista byla faktycznie niezbyt uniwersalna, ale kompilatorom to raczej
nie przeszkadza. Czasy programowania w assemblerze sie skonczyly.
Z nieuniwersalnej listy zwykle wynika skrocenie kodu - kod jest
krotszy na kazdym rozkazie o pare bitow - ktore kodowalyby te
dopelniajace do uniwersalnosci kombinacje.
Najwieksza strata jak nie wystarczalo 16 bit arytmetyki - wtedy
faktycznie kod intela [<386] przegrywal z 32 bitowa Motorola.

J.

• konkretne operacje np. arytmetyczne wykonujemy na dowolnym rejestrze a nie

• operacje bitowe sš o wiele prostsze, nie wymagajš maskowań i operacji

• operacje przesłań blokowych o ile majš wsparcie w liście rozkazów mogš się

• operacje wymiany miedzy rejestrami w ramach rejestru i wszelakie

Intel wymaga trzy razy więcej pamięci dla osiągnięcia tego samego efektu
co Motorola (mało elastyczna lista rozkazów). [..]

Myślę, że bogata lista sprzyja skróceniu kodu ponieważ:
- konkretne operacje np. arytmetyczne wykonujemy na dowolnym rejestrze a nie
tylko na akumulatorze, sprzyja to zmniejszeniu zbędnych przesłań
międzyrejestrowych

- operacje przesłań blokowych o ile mają wsparcie w liście rozkazów mogą się
znacznie uprościć

- operacje wymiany miedzy rejestrami w ramach rejestru i wszelakie
przesunięcia również (nie ładujemy wszystkiego do akumulatora)

Dlatego uważam, że lista Motoroli jest znacznie bardziej przemyślana.

Popatrz
na aplikacje przeniesione z Maca na PC,
te same programy potrzebują mniej pamięci i wolniejszego zegara.

Jeżeli chodzi o assembler to w przypadku "dużych komputerów" zgadzam się, w
przypadku mikrokontrolerów i techniki embedded absolutnie nie.

Mamy do dyspozycji małe proste procesorki i musimy je "wyżyłować" z zasobów pamięci i
w pełni panować nad wynikowym czasem wykonania operacji. Takie zabawki jak
Basic a nawet C mikrokontrolerów nie nadają się do budowy aplikacji silnie
czasowo uzależnionych.

"J.F." napisał(a):

On Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski wrote:

Nie musisz korzystać ze wszystkich, wolny wybór.
Poza tym większa ilość rozkazów przekłada się na krótszy kod wynikowy.
Procesory Motoroli miały swoje środowiska okienkowe w czasach gdy na PC
był tylko DOS bo
Intel wymaga trzy razy więcej pamięci dla osišgnięcia tego samego efektu
co Motorola (mało elastyczna lista rozkazów).

Mowiac szczerze to w wielu zastosowaniach zdrowo przesadzasz.
Lista byla faktycznie niezbyt uniwersalna, ale kompilatorom to raczej
nie przeszkadza. Czasy programowania w assemblerze sie skonczyly.
Z nieuniwersalnej listy zwykle wynika skrocenie kodu - kod jest
krotszy na kazdym rozkazie o pare bitow - ktore kodowalyby te
dopelniajace do uniwersalnosci kombinacje.
Najwieksza strata jak nie wystarczalo 16 bit arytmetyki - wtedy
faktycznie kod intela [<386] przegrywal z 32 bitowa Motorola.

J.

Myślę, że bogata lista sprzyja skróceniu kodu ponieważ:
- konkretne operacje np. arytmetyczne wykonujemy na dowolnym rejestrze a nie
tylko na akumulatorze, sprzyja to zmniejszeniu zbędnych przesłań
międzyrejestrowych
- operacje bitowe sš o wiele prostsze, nie wymagajš maskowań i operacji
logicznych
- operacje przesłań blokowych o ile majš wsparcie w liście rozkazów mogš się
znacznie uprościć
- operacje wymiany miedzy rejestrami w ramach rejestru i wszelakie
przesunięcia również (nie ładujemy wszystkiego do akumulatora)
Te wszyskie "zbędne" operacje trzeba wykonać dlatego marnuje się czas
procesora na ich wykonanie i "niepotrzebnie" zajmuje się pamięć.
Dlatego uważam, że lista Motoroli jest znacznie bardziej przemyślana. Popatrz
na aplikacje przeniesione z Maca na PC,
te same programy potrzebujš mniej pamięci i wolniejszego zegara.

Jeżeli chodzi o assembler to w przypadku "dużych komputerów" zgadzam się, w
przypadku mikrokontrolerów i techniki embedded absolutnie nie. Mamy do
dyspozycji małe proste procesorki i musimy je "wyżyłować" z zasobów pamięci i
w pełni panować nad wynikowym czasem wykonania operacji.

Takie zabawki jak Basic a nawet C mikrokontrolerów nie nadajš się
do budowy aplikacji silnie czasowo uzależnionych.
Pozdrowienia Janusz R

Janusz Raniszewski wrote:

"J.F." napisał(a):

On Fri, 06 Aug 1999 01:23:56 +0200, Janusz Raniszewski wrote:

Nie musisz korzystać ze wszystkich, wolny wybór.
Poza tym większa ilość rozkazów przekłada się na krótszy kod wynikowy.
Procesory Motoroli miały swoje środowiska okienkowe w czasach gdy na PC
był tylko DOS bo
Intel wymaga trzy razy więcej pamięci dla osišgnięcia tego samego efektu
co Motorola (mało elastyczna lista rozkazów).

Mowiac szczerze to w wielu zastosowaniach zdrowo przesadzasz.
Lista byla faktycznie niezbyt uniwersalna, ale kompilatorom to raczej
nie przeszkadza. Czasy programowania w assemblerze sie skonczyly.
Z nieuniwersalnej listy zwykle wynika skrocenie kodu - kod jest
krotszy na kazdym rozkazie o pare bitow - ktore kodowalyby te
dopelniajace do uniwersalnosci kombinacje.
Najwieksza strata jak nie wystarczalo 16 bit arytmetyki - wtedy
faktycznie kod intela [<386] przegrywal z 32 bitowa Motorola.

J.

Myślę, że bogata lista sprzyja skróceniu kodu ponieważ:
- konkretne operacje np. arytmetyczne wykonujemy na dowolnym rejestrze a nie
tylko na akumulatorze, sprzyja to zmniejszeniu zbędnych przesłań
międzyrejestrowych
- operacje bitowe sš o wiele prostsze, nie wymagajš maskowań i operacji
logicznych
- operacje przesłań blokowych o ile majš wsparcie w liście rozkazów mogš się
znacznie uprościć
- operacje wymiany miedzy rejestrami w ramach rejestru i wszelakie
przesunięcia również (nie ładujemy wszystkiego do akumulatora)
Te wszyskie "zbędne" operacje trzeba wykonać dlatego marnuje się czas
procesora na ich wykonanie i "niepotrzebnie" zajmuje się pamięć.
Dlatego uważam, że lista Motoroli jest znacznie bardziej przemyślana. Popatrz
na aplikacje przeniesione z Maca na PC,
te same programy potrzebujš mniej pamięci i wolniejszego zegara.

Nie uchroniło to jednak Motoroli przed klęskš na rynku PC. Bardzo dobra
lista
rozkazów nie szła w parze z równie dobrym hardwarem.
Intel wyprzedził Motorole w wielu momentach i to już w czasach
świetności
linii 68xxx. Przykłady?
-MMU
-cache
-koprocesor
-częstotliwości pracy

Jeżeli chodzi o assembler to w przypadku "dużych komputerów" zgadzam się, w
przypadku mikrokontrolerów i techniki embedded absolutnie nie. Mamy do
dyspozycji małe proste procesorki i musimy je "wyżyłować" z zasobów pamięci i
w pełni panować nad wynikowym czasem wykonania operacji.

Kompilatory dla systemów embeded znacznie różniš się od kompilatorów
znanych
z PC. Podstawowa różnica polega właśnie na tym, że da się dokładnie
panować
nad wykorzystaniem pamięci, rozmieszczeniem zmiennych co z reguły nie
jest
konieczne w PC. Podobnie jak w assemblerze można dokładnie określić,
gdzie
znajdzie sie dana zmienna i jak zostanie rozmieszczony w pamięci
skompilowany
program.

Takie zabawki jak Basic a nawet C mikrokontrolerów nie nadajš się
do budowy aplikacji silnie czasowo uzależnionych.
Pozdrowienia Janusz R

Bzdury piszesz. Widać po prostu, że nie wiesz jak BASIC i C sš
tłumaczone
na maszynówkę. Tak w ogóle jak cos się nie wyrabia to się bierze
mocniejszy
procesor i po sprawie.

MrWebsky

Masz rację nie wiem, bawiłem się tymi zabawkami i otrzymywałem kod. Przyznaję, że
nawet nie próbowałem wnikać w to jak jest zbudowany ani jak go zoptymalizować. Być
może komercyjne kompilatory zrobiš to, lecz nadal nie będę miał pewności czy aby
nie można tego poprawić. Po prostu nie wierzę, że tak napisany program jest w pełni
zoptymalizowany pod względem czasu lub szybkości wykonania. Przecież określone
procedury np BIN-BCD możemy wykonać różnie i jeszcze raz różnie w zależności od
ilości konwertowanych bajtów a bezmyślna maszyna wstawi tam jednš procedurę, którš
ma w bibliotece.
Podobnie istniejš programy do pisania muzyki i wierszy, czy ktoś słyszał o wybitnym
dziele napisanym przez komputer? To będzie tylko zlepek fraz.

Niestety nie zamienię AVR (max 20 MIPS) na 386 (ok. 20 MIPS) bo musiałbym dołożyć
sporo kości i energii.

Janusz R

Janusz Raniszewski wrote:

Masz rację nie wiem, bawiłem się tymi zabawkami i otrzymywałem kod.

nawet nie próbowałem wnikać w to jak jest zbudowany ani jak go

może komercyjne kompilatory zrobiš to, lecz nadal nie będę miał pewności

nie można tego poprawić. Po prostu nie wierzę, że tak napisany program

zoptymalizowany pod względem czasu lub szybkości wykonania. Przecież

procedury np BIN-BCD możemy wykonać różnie i jeszcze raz różnie w

ilości konwertowanych bajtów a bezmyślna maszyna wstawi tam jednš

ma w bibliotece.
Podobnie istniejš programy do pisania muzyki i wierszy, czy ktoś słyszał

dziele napisanym przez komputer? To będzie tylko zlepek fraz.

Niestety nie zamienię AVR (max 20 MIPS) na 386 (ok. 20 MIPS) bo

sporo kości i energii.

Janusz R

Rzeczywiście twoja uwaga dotycząca bibliotek jest absolutnie słuszna.
Moje przekonanie
o przydatności C do pisania krytycznych czasowo programów oparłem na
milczącym za-
łożeniu, że mam kontrolę nad każdym kawałkiem kodu zrobionego przez
kompilator
a tę kontrolę tracę właśnie w momencie gdy kompilator zaczyna wywoływać
biblioteki.

Z nieznanych mi przyczyn kompilatory na 8 bitowe procesory nie mają
narzędzi do
podglądania i disassemblowania plików *.OBJ i *.LIB co pozwoliłoby na
szybkie
wyjaśnienie wątpliwości dotyczących efektyności kodu zawartego w
firmowych
bibliotekach.

MrWebsky

[...]
Nie uchroniło to jednak Motoroli przed klęską na rynku PC. Bardzo dobra
lista rozkazów nie szła w parze z równie dobrym hardwarem.

Intel wyprzedził Motorole w wielu momentach i to już w czasach
świetności linii 68xxx. Przykłady?
-MMU
-cache
-koprocesor

-częstotliwości pracy

Takie zabawki jak Basic a nawet C mikrokontrolerów nie nadają się
do budowy aplikacji silnie czasowo uzależnionych.
Pozdrowienia Janusz R

Bzdury piszesz. Widać po prostu, że nie wiesz jak BASIC i C są
tłumaczone na maszynówkę.

Tak w ogóle jak cos się nie wyrabia to się bierze mocniejszy
procesor i po sprawie.

On Sat, 07 Aug 1999 21:46:53 +0200, MrWebsky wrote:

[...]
Nie uchroniło to jednak Motoroli przed klęską na rynku PC. Bardzo dobra
lista rozkazów nie szła w parze z równie dobrym hardwarem.

Szla, szla,

Intel wyprzedził Motorole w wielu momentach i to już w czasach
świetności linii 68xxx. Przykłady?
-MMU
-cache
-koprocesor

Byly i do 68k

-częstotliwości pracy

porownaj jeszcze czasy wykonywania instrukcji. 100MHz nie zawsze jest
rowne 100MHz w innym procesorze, szczegonie lak porownac
np 8051 i M6800 12=1.5 :-)

Faktem jest ze w czasach jak pecetowym standardem bylo P100/32MB,
to mac na 68k radzil sobie z obrazkami lepiej. No fakt - to byl
model o rozszerzonym RAM - do calych 12MB, a obrazki po 100 MB :-)

A wygral Intel .... dzieki glupocie i sile nazwy IBM. Gdyby to nie byl
IBM - przegralby jak wiele innych konkurencji. Gdyby IBM byl madry -
nigdy by nie uzyl 8088 do konstrukcji :-)

Takie zabawki jak Basic a nawet C mikrokontrolerów nie nadają się
do budowy aplikacji silnie czasowo uzależnionych.
Pozdrowienia Janusz R

Bzdury piszesz. Widać po prostu, że nie wiesz jak BASIC i C są
tłumaczone na maszynówkę.

Zwykle kiepsko. Programista wie znacznie lepiej czego sie spodziewac.

Tak w ogóle jak cos się nie wyrabia to się bierze mocniejszy
procesor i po sprawie.

Tylko ze cena rosnie i moze przekroczyc akceptowalny przez klienta
poziom :-)

J.

Nie uchroniło to jednak Motoroli przed klęską na rynku PC. Bardzo dobra
lista rozkazów nie szła w parze z równie dobrym hardwarem.

Szla, szla,

Mógłbym prosić o przykłady? (Pytam z ciekawości. Nie zamierzam
polemizować).

Intel wyprzedził Motorole w wielu momentach i to już w czasach
świetności linii 68xxx. Przykłady?
-MMU
-cache
-koprocesor

Byly i do 68k

Dla jasności:
-Motorola stosunkowo późno wprowadziła zintegrowane z procesorem MMU, co

niewątpliwie
opóźniło zastosowanie pamięci wirtualnej w systemach typu Amiga i Atari.

-Motorola zbyt ostrożnie i powoli wprowadzała cache do swych procesorów, a
to jak sądze stanowiło istotny element dzieki którym od pewnego momentu
procesory Intela zaczeły wygrywać

-Pisząc o koprocesorze nie chodziło mi o ich brak (bo istotnie były w
rodzinie 68xxx od samego początku), ale o fakt że Intel pierwszy
zintegrował
go z procesorem, dzięki czemu znacznie wzrosła moc obliczeniowa przy
szybko malejącej cenie chip'a.

-częstotliwości pracy

[...]
Chodziło mi jedynie o zaznaczenie faktu, że Intel bardzo wcześnie
postawił na prostackie zwiekszanie prędkości przez podnoszenie
częstotliowości pracy, co dobrze przykrywało nieefektywność wykonywania
rozkazów w porównaniu do Motoroli.

Cała sztuka polega na tym, by tak pisać kod w języku wysokiego poziomu
tak aby wynik kompilacji, dawał możliwie optymalny kod.

Coś na kształt znanego
przykładu by zamiast dzielić przez 2 pomożyć przez 0.5, bo mnożenie leci
szybciej. Często kompilator daje sie nabrać (w pozytywną stronę) na
takie manewry.

Dlatego uwa=BFam, =BFe lista Motoroli jest znacznie bardziej przemy=B6=

na aplikacje przeniesione z Maca na PC,
te same programy potrzebuj=B9 mniej pami=EAci i wolniejszego zegara.

=

Nie uchroni=B3o to jednak Motoroli przed kl=EAsk=B1 na rynku PC. Bardzo=

lista
rozkaz=F3w nie sz=B3a w parze z r=F3wnie dobrym hardwarem.
Intel wyprzedzi=B3 Motorole w wielu momentach i to ju=BF w czasach
=B6wietno=B6ci
linii 68xxx. Przyk=B3ady?
-MMU
-cache
-koprocesor
-cz=EAstotliwo=B6ci pracy

=

Takie zabawki jak Basic a nawet C mikrokontroler=F3w nie nadaj=B9 si=

do budowy aplikacji silnie czasowo uzale=BFnionych.
Pozdrowienia Janusz R

=

Bzdury piszesz. Wida=E6 po prostu, =BFe nie wiesz jak BASIC i C s=B1
t=B3umaczone
na maszyn=F3wk=EA. Tak w og=F3le jak cos si=EA nie wyrabia to si=EA bie=

mocniejszy
procesor i po sprawie.

=

MrWebsky