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



Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!

Poprzedni Następny
Wiadomoœć
spis treści
From: jareka_at_nospam_dawid.com.pl (Jaroslaw Andrzejewski)
Subject: =?ISO-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Thu, 05 Aug 1999 15:01:31 GMT


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

Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Thu, 05 Aug 1999 20:27:47 GMT


On Thu, 05 Aug 1999 15:01:31 GMT, Jaroslaw Andrzejewski wrote:
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ł :-)

Ale jaka gruba byla ksiazka do niego.

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.



Poprzedni Następny
Wiadomoœć
spis treści
From: Marek Dzwonnik <mdz_at_nospam_pap.com.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Thu, 05 Aug 1999 22:44:20 +0200




"J.F." wrote:

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.



A czy ktos pamieta takie kuriozum jak polskie mnemoniki do 8080 ?

Do wypuszczonej przez CEMI, spóźnionej o 10 lat kopii 8080,
wymyślono polskojezyczny asembler.
Np zamiast MOV bylo LAD (czyli LADuj) itp. Zdaje się, że ktoś nawet
wziął za to jakąś nagrodę. Dla niedowiarków - opublikowano to cudo w
jakimś numerze Elektronizacji. :-)

M.Dz.

Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Fri, 06 Aug 1999 01:23:56 +0200


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ł :-)

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


Poprzedni Następny
Wiadomoœć
spis treści
From: "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
Subject: =?iso-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Fri, 06 Aug 1999 01:15:23 GMT



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




Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Fri, 06 Aug 1999 22:17:55 +0200




Juliusz napisał(a):

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 dajš
jeden takt zegara systemowego.
Myślę, że AVR powielajš oscylator razy cztery a potem dzielš licznikiem przez
cztery i układem kombinacyjnym
aby osišgnšć odpowiednio sfazowane impulsy sterujšce. Zresztš w RISCAch to nic
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. Może się przydać do kompresji mowy w
cyfrowych
systemach transmisyjnych.

Janusz R.


Poprzedni Następny
Wiadomoœć
spis treści
From: "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
Subject: =?iso-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Fri, 06 Aug 1999 22:02:37 GMT



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

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
dajš
jeden takt zegara systemowego.
Myślę, że AVR powielajš oscylator razy cztery a potem dzielš licznikiem
przez
cztery i układem kombinacyjnym
aby osišgnšć odpowiednio sfazowane impulsy sterujšce. Zresztš w RISCAch to
nic
nowego.

Ehh chyba cos nie tak :-) Ale niech ci bedzie :-)

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 ?

Juliusz



Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Sat, 07 Aug 1999 15:55:23 GMT


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.


Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Sun, 08 Aug 1999 02:39:03 +0200




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

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




Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Sun, 08 Aug 1999 20:28:40 GMT


On Sun, 08 Aug 1999 02:39:03 +0200, Janusz Raniszewski wrote:
"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).

Tylko co z tego ze bedzie szybszy? Zastosujesz 88kHz probkowania
zamiast 44? skrocisz czas reakcji na przycisk z 200 do 2 us ?

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

nie musi byc float, reszte sie tablicuje lub przybliza ... i zaczyna
zasobow brakowac, tym bardziej ze operacje arytmetyczne sa zasobozerne
-)

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

A to moze nawet prosciej - filtry sa dosc prosta operacja.

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.
Pytanie do czego - odtwarzacz samochodowy na brak zasilania raczej nie
cierpii.
TI sie np chwali poborem mocy 0.5mW/MIPS - to chyba nawet mniej niz
AVR, a ten MIPS to np 16 bitowe mnozenie..

J.



Poprzedni Następny
Wiadomoœć
spis treści
Date: Mon, 09 Aug 1999 00:55:45 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


"J.F." wrote:

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.

J.

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

MrWebsky



Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy =?iso-8859-1?Q?uk=B3ady?= PIC
Date: 9 Aug 1999 18:34:48 GMT


On Mon, 09 Aug 1999 00:55:45 +0200, MrWebsky <MrWebsky_at_nospam_friko6.onet.pl> wrote:
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.

Tylko ze w tej rodzinie sa i perelki po GIPS/GFLOPS, i takie
co maja MIPS niewiele i pobor mocy ponizej 100mW :-)

J.


Poprzedni Następny
Wiadomoœć
spis treści
Date: Sat, 07 Aug 1999 18:49:36 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


Juliusz wrote:

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

Musisz dobudować jeszcze komunikacje z PC, obslugę FLASH-DYSKu,
sterowanie wyświetlaczem LCD, cyfrowe wyjście audio, klawiature
monitoring zasilania, equalizer, potencjometr cyfrowy,
zarządzanie mocą...

BTW jak się bootuje Virtex?

MrWebsky.



Poprzedni Następny
Wiadomoœć
spis treści
From: jareka_at_nospam_dawid.com.pl (Jaroslaw Andrzejewski)
Subject: =?ISO-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Fri, 06 Aug 1999 08:05:39 GMT


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

Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Fri, 06 Aug 1999 22:20:00 +0200




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"

Janusz R.


Poprzedni Następny
Wiadomoœć
spis treści
From: "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
Subject: =?iso-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Fri, 06 Aug 1999 22:06:41 GMT



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



Poprzedni Następny
Wiadomoœć
spis treści
Date: Sat, 07 Aug 1999 23:04:29 +0200
From: Juras <Juras_at_nospam_freenet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


Juliusz wrote:

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


Poprzedni Następny
Wiadomoœć
spis treści
From: "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
Subject: =?iso-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Sat, 07 Aug 1999 22:53:56 GMT



Juras napisał(a) w wiadomości: <37AC9F5D.E641EE4A_at_nospam_freenet.pl>...

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.


Pytam o PIC bo go nieznam, a wrecz nie mialem w reku. A wy kolego tez pewnie
pica nie znacie, ani niczego innego :-) I zapewne szukacie schematu
programatora:-) Natomiast nadajecie sie na konfidenta. Teraz takich
przyjmuja do UOP-u - bedziecie donosic na sasiadow i innych grupowiczow :-)
Taki macie charakter :-)

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

A w czym wam kolego moje posty po 40 kilo przeszkadzaja ? I w czym
przeszkadza wam moje uwagi do poczatkujacych zlodzieji ? Czy uwazacie, ze
profesja rozkodowywania to profesja, ktora beda wykonywac wasze dzieci ?
Mnie posty po 40k nie przeszkadzaja w niczym, a moze chcecie pogadac o
VHDL-u albo o aktualnie prowadzonych projektach ? Pochwalcie sie kolego co
robicie wlasnie, gdzie pracujecie i jakie macie osiagniecia ?

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

Wasze glowa, kolego to wam predzej uschnie lub odpadnie zanim ktos ja zlowi
-) 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.

A czemu wy kolego nie pomagacie ? Jakos nie widze waszych postow z
odpowiedziami na pytania ani zadnych innych ? Czyzbyscie kolego dopiero
zarobili na modem, ale na rachunki za sciaganie 40k juz nie ?


Juliusz



Poprzedni Następny
Wiadomoœć
spis treści
From: "NameNo" <nameno_at_nospam_free.com.pl>
Subject: Odp: pomocy układy PIC
Date: Tue, 10 Aug 1999 05:36:07 GMT


Tak trzymać !
NameNo




Poprzedni Następny
Wiadomoœć
spis treści
From: jareka_at_nospam_dawid.com.pl (Jaroslaw Andrzejewski)
Subject: =?ISO-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Tue, 10 Aug 1999 09:36:46 GMT


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 zarobia
na kradzionych radiach samochodowych :-) HEHE :-)
wypraszam sobie i oczekuję przeprosin! Programator już zrobiłem, a
paserem nie jestem.

--
Jarek Andrzejewski

Poprzedni Następny
Wiadomoœć
spis treści
From: "Juliusz" <juliusz_at_nospam_multi-ip.com.pl>
Subject: =?iso-8859-2?Q?Re:_pomocy_uk=B3ady_PIC?=
Date: Tue, 10 Aug 1999 09:43:17 GMT



Jaroslaw Andrzejewski napisał(a) w wiadomości:
<37b8f1ee.330272186_at_nospam_10.100.100.4>...
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
zarobia
na kradzionych radiach samochodowych :-) HEHE :-)
wypraszam sobie i oczekuję przeprosin! Programator już zrobiłem, a
paserem nie jestem.


TO nie do ciebie bylo :-)

Juliusz



Poprzedni Następny
Wiadomoœć
spis treści
Date: Sat, 07 Aug 1999 15:32:19 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


Jaroslaw Andrzejewski wrote:

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





Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Sun, 08 Aug 1999 20:27:52 GMT


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.


Poprzedni Następny
Wiadomoœć
spis treści
Date: Mon, 09 Aug 1999 00:56:15 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


"J.F." wrote:

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.

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.

MrWebsky



Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy =?iso-8859-1?Q?uk=B3ady?= PIC
Date: 9 Aug 1999 17:38:08 GMT


On Mon, 09 Aug 1999 00:56:15 +0200, MrWebsky <MrWebsky_at_nospam_friko6.onet.pl> wrote:
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.

Taaak, optymalne, hi, hi.

Bawilem sie kiedys w porownywanie Z80 i 6502. Na konkretnych procedurkach,
typu np obsluga wyswietlacza multipleksowanego.

Co do jednego masz racje - Z80 wymagal zastanowienia, dalo sie to zrobic
na kilka sposobow, trzeba bylo pomyslec lub sprawdzic jak lepiej - a roznice
czasem minimalne.
6502 nie dawal takiej szansy - byl tylko jeden sposob, trzeba bylo miec
troche doswiadczenia zeby go znalezc. Sprobuj usunac jeden rozkaz z listy
6502 - procesor straci polowe funkcjonalnosci, bo to czesto rozkaz
niezastapiony.

Zeby bylo smieszniej, to czesto wychodzilo identycznie co do bajta kodu
i mikrosekundy [Z80 4MHz, 6502 1MHz]. Ale czasem jednak architektura
6502 dawala d*** niewymownie. Np - cykliczna rotacja bitow rejestru,
ale "krotka" - tzn wychodzacy bit od razu wchodzi na przeciwna pozycje.
Nie istnieje taki rozkaz w 6502, i zrob teraz optymalnie :-)
Albo zmniejszanie licznika 16 bitowego. No i w ogole cale operacje
16 bitowe - no ale zalozmy ze mamy sie ograniczyc do prockow 8 bitowych :-)

W sumie wole jednak bardziej kompletne listy rozkazow :-)

J.


Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Fri, 06 Aug 1999 10:50:03 GMT


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.


Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Fri, 06 Aug 1999 22:44:01 +0200




"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ż:
tylko na akumulatorze, sprzyja to zmniejszeniu zbędnych przesłań
międzyrejestrowych
logicznych
znacznie uprościć
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


Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Sat, 07 Aug 1999 15:54:30 GMT


On Fri, 06 Aug 1999 22:44:01 +0200, Janusz Raniszewski wrote:
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

Akurat x86 potrafil troche operowac na innych rejestrach niz
akumulator. Rozkazy na akumulatorze byly zas krotsze .. i szybsze.

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

Mowiac szczerze to ich sie rzadko uzywa. A juz programuj w jezyku
wyzszego poziomu - jeszcze rzadziej kompilator je wstawi.

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

Podobnie - x86 robilo to i na rejestrach.

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

Co prawda tych 16 rejestrow wyjatkowo doceniam, ale co do przemyslenia
.. motka to jest "brute force", intel ma przemyslana liste - niby
uboga, a jednak starcza. W praktyce to mi na intelu CZASEM brakowalo
jednego rejestru, CZASEM jednego indeksujacego, i CZASEM jednego
segmentowego. W trybie 8086, bo od 386 bylo lepiej ..

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

A ile w tym winy ... tfu, Windows ? Moze by porownac linuxa na x86
i 68k ?

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

Zgadzam sie, ale x86 to juz "duzy" komputer.

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.

Mowiac szczerze rynek powoli wchodzi i tutaj - bardziej sie oplaca dac
szybszy i silniejszy procesor i program ukonczyc szybciej niz zylowac
na kosztach. Szczegolnie gdy w perspektywie mamy przejscie na inna
rodzine. A programy sie wydluzaja, coraz wiecej funkcjonalnosci
wchodzi..

J.


Poprzedni Następny
Wiadomoœć
spis treści
Date: Sat, 07 Aug 1999 21:46:53 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


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



Poprzedni Następny
Wiadomoœć
spis treści
From: Janusz Raniszewski <rniski_at_nospam_man.koszalin.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC
Date: Sun, 08 Aug 1999 02:35:32 +0200




MrWebsky napisał(a):

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


Poprzedni Następny
Wiadomoœć
spis treści
Date: Mon, 09 Aug 1999 00:56:28 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC


Janusz Raniszewski wrote:

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

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


Poprzedni Następny
Wiadomoœć
spis treści
From: "NameNo" <nameno_at_nospam_free.com.pl>
Subject: Odp: pomocy układy PIC
Date: Tue, 10 Aug 1999 05:46:13 GMT



Użytkownik MrWebsky <MrWebsky_at_nospam_friko6.onet.pl> w wiadomości do grup
dyskusyjnych napisał:37AE0B1C.83DA63DE_at_nospam_friko6.onet.pl...
Janusz Raniszewski wrote:

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

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.

Dziwne, jak uruchomisz debuger (a takie zawsze są) to możesz sobie
prześledzić kod bibloteki bez problemu.
NameNo


MrWebsky




Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy układy PIC
Date: Sun, 08 Aug 1999 20:27:43 GMT


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.


Poprzedni Następny
Wiadomoœć
spis treści
Date: Mon, 09 Aug 1999 00:55:32 +0200
From: MrWebsky <MrWebsky_at_nospam_friko6.onet.pl>
Subject: Re: pomocy =?iso-8859-2?Q?uk=B3ady?= PIC



"J.F." wrote:

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,

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.
Pewną odpowiedzialność
ponoszą ich producenci, który zwlekali z zastosowaniem wyposażonych w
MMU
procesorów.
-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ć
z linią 68xxx.
-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

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

Swięta racja.
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.

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.

W kompilacji najlepiej wychodzą stałe fragmenty programu jak pętle i
warunki. Znacznie gorzej obliczenia i przerzuty pamięci. Fatalnie
manewry
na wskaznikach i zmiennych indeksowanych. Jeśli procesor nie na dodatek
słabo przygotowany na takie okazje (brak rejestów indeksowych,
sprzętowego
wsparcia arytmetyki, niesymetria zbioru rejestrów), to assembler jest
nie
do pobicia.
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.

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.



Poprzedni Następny
Wiadomoœć
spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: pomocy =?iso-8859-1?Q?uk=B3ady?= PIC
Date: 9 Aug 1999 18:17:06 GMT


On Mon, 09 Aug 1999 00:55:32 +0200, MrWebsky <MrWebsky_at_nospam_friko6.onet.pl> 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,
Mógłbym prosić o przykłady? (Pytam z ciekawości. Nie zamierzam
polemizować).

Musialbym pojsc na wysypisko po makulature, ale kiedys sie temu przygladalem
dokladniej i naprawde 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
Dla jasności:
-Motorola stosunkowo późno wprowadziła zintegrowane z procesorem MMU, co

Ale byla niezintegrowana z prockiem. Co to za roznica - plyta glowna
i tak sie z wielu kosci skladala :-)

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

Tylko zobacz ze w owym czasie pecet byl na 8088 w ktorym MMU tez nie
uswiadczyles, potem byl na 80286, gdzie pewna namiastka byla, ale w pecetach
w zasadzie juz nie do wykorzystania, dopiero 386 mialo MMU z prawdziwego
zdarzenia. A to juz bylo kiedy swietnosc 68k w zasadzie juz przeminela.
Tzn nadal byla swietna, ale PC niekompatybilna :-)

-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ć

Oj, mialem Ci ja w reku opis cache kontrolera motki w reku, chyba wtedy
pierwszy 386 kupilismy. 386 byla jeszcze bez cache, nastepne chyba do konca
mialy cache "jednotorowy", a ta kostka robila "4-way". Oczywiscie - mozna
ja bylo wsadzic lub nie. Ale dopiero 486 mialo wewnetrzny cache, a i tak
lepiej dzialalo z dodatkowym zewnetrznym.

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

Tylko znow popatrz ze to byl wiek schylkowy 68k - juz jej prawie nikt nie
chcial, bo Windows na tym nie chodzil.
Nie pamietam juz daty, ale bylem na jakim seminarium Mot i padlo cos takiego
"dzis mozemy umiescic 4mln tranzystorow na chipie, za pol roku bedzie to
6mln. Nie mamy pojecia co z nimi zrobic - musicie nam powiedziec co chcecie".
Jakos niedlugo pozniej sugestia sie pojawila - ktos anonsowal procesor
z 2MB cache na pokladzie - "w niezbyt wymagajacych zastosowaniach procesor
nie bedzie potrzebowal zewnetrznego RAM" :-) Znaczy sie to byly czasy
gdy zaczeto sprzedawac pecety 386/4MB, a standardem u uzytkownikow w kraju
bylo 286/1MB - juz troche za malo na Windows 3.0

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

Tego wlasnie nie jestem pewien - o ile sobie przypominam to predkosci
efektywne przez dlugi czas byly dosc porownywalne. A de fakto 32 bitowa
architektura pozwalala zaoszczedzic wielu instrukcji w wielu programach.
Oczywiscie - 500MHz to brzmi dumnie, nawet jesli wyrob konkurencji
liczy szybciej, ale ma tylko 250 MHz :-)

O - przypomnialem sobie - znajomi liczyli jednoczesnie na 286/10MHz,
i jakims jugoslowianskim wyrobie na 68010. Pecet byl w miare
biezacy, mogly do sluzby wchodzic 16, przestarzalosc
wyrobu byla nieznana - i chyba liczyl wolniej. Ale unix na tym byl [a wiec
i MMU], tablice mozna bylo na 2MB zalozyc [RAM na osobnej plycie, wiec
moglo i to spowalniac] a nawet na wiecej, choc dysk na swap nie pozostawial
wiele, program nie zwalnial jak przypadki do 65tys przeliczono, no i
zadanie mozna bylo w tle puscic :-)

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

Mowiac szczerze juz dawno przestalem to robic. Potem zmieniasz
narzedzie lub system docelowy i jest nieoptymalnie a w dodatku nie mozna
zrozumiec o co projektantowi chodzilo.

Inna sprawa ze przestalem uzywac assemblera na peceta, gdy turbo C
dosc specyficzny program skompilowalo do postaci zaledwie 3 razy wolniejszej..

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.

Kiedys kolega odkryl ze np Turbo Pascal znacznie szybciej liczy
x+x niz 2*x. Normalne. Przyszla nastepna wersja ... zrobilo sie odwrotnie

J.



Poprzedni Następny
Wiadomoœć
spis treści
From: Rafal Kolano <rkolano_at_nospam_lucent.com>
Subject: Re: pomocy =?iso-8859-1?Q?uk=B3ady?= PIC
Date: Mon, 09 Aug 1999 08:42:26 +0200


MrWebsky wrote:

Dlatego uwa=BFam, =BFe lista Motoroli jest znacznie bardziej przemy=B6=
lana. Popatrz
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=
dobra
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

Niczego nie wyprzedzil. Poparz na modele motoroli 68020, 68040, 68060

=

Takie zabawki jak Basic a nawet C mikrokontroler=F3w nie nadaj=B9 si=
=EA
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=
rze
mocniejszy
procesor i po sprawie.

Typowe podejscie programistow piszacych programy na platwormy PC: "Za wol=
no dziala ???
Zmien procesor na szybszy i kup wiecej pamieci".
W ten wlasnie sposob dzisiejszy Windows98 potrzebuje min 64Mb RAM proceso=
ra pentium 2xx
lub II, a sam system zajmuje 200Mb dysku twardego :(((
Odeszly w niepamiec czasy kiedy bardzo dobry system wielozadaniowy Workbe=
nch 3.0 miescil
sie na 5-ciu dyskietkach 850 Kb, a dyskietki te widywalo sie tylko raz po=
dczas instalacji
systemu na czystym dysku (czyt. "nie potrzebne bylo ciagle przeinstalowyw=
anie systemu jak
w Windowsie").
Zawsze mozna napisac super bipper programik, ktory robi cuda i wymaga Pen=
tium III 900MHz,
512Mb RAM, 10Gb HDD, ale wiekszym problemem jest napisanie tego programu=
na 386, 4Mb RAM
i 400kb HDD (ale komu sie chce ???)




=

MrWebsky

-- =

|
|
+ \
\\.G_.*=3D. Rafal Kolano
`(#'/.\| rkolano_at_nospam_lucent.com
.>' (_--.
_=3D/d ,^\
~~ \)-' '
/ |
---'--'-------------------------------