Może głupie pytanie, ale co to znaczy że mikroprocesor lub
mikrokontroler jest 8, 16 lub 32 bitowy? Czy ma to związek z szyną
danych czy adresową i ile może wynościć długośc szyny adresowej?

do góry

slawek7 pisze:
> Może głupie pytanie, ale co to znaczy że mikroprocesor lub
> mikrokontroler jest 8, 16 lub 32 bitowy? Czy ma to związek z szyną
> danych czy adresową i ile może wynościć długośc szyny adresowej?

Dotyczy to magistrali danych, ALU itp :)... popatrz, AVR jest 8-bitowy,
choć adresy są 16-bitowe (lub większe np w ATMEGA128). Nie zmienia to
faktu, że rejestry są 8-bitowe... i choć pewne operacje może wykonywać
na 16-bitach jest 8-bitowy ;)...
ARM7 - ma wszystkie rejestry 32 bitowe, wszystkie operacje wykonuje na
32 bitach itp, dlatego jest 32-bitowy ;)... choć faktem jest, że w ARMie
wszystko ma 32 bity (magistrala adresowa tez ;P)...
Generalnie procesory 8-bitowe to takie, które operują głównie na
liczbach 8-bitowych ;)...

Pozdrawiam
Konop

do góry

slawek7 pisze:
> Może głupie pytanie, ale co to znaczy że mikroprocesor lub
> mikrokontroler jest 8, 16 lub 32 bitowy? Czy ma to związek z szyną
> danych czy adresową i ile może wynościć długośc szyny adresowej?

Dotyczy to magistrali danych, ALU itp :)... popatrz, AVR jest 8-bitowy,
choć adresy są 16-bitowe (lub większe np w ATMEGA128). Nie zmienia to
faktu, że rejestry są 8-bitowe... i choć pewne operacje może wykonywać
na 16-bitach jest 8-bitowy ;)...
ARM7 - ma wszystkie rejestry 32 bitowe, wszystkie operacje wykonuje na
32 bitach itp, dlatego jest 32-bitowy ;)... choć faktem jest, że w ARMie
wszystko ma 32 bity (magistrala adresowa tez ;P)...
Generalnie procesory 8-bitowe to takie, które operują głównie na
liczbach 8-bitowych ;)...

Pozdrawiam
Konop

do góry

A ma to jakiś związek z instrukcjami rdzenia.
I jesli dobrze zrozumiałem to w ARM to przypadek że adresowanie jest
32bitowe i ważne że np RAM ma szerokość32 bitów tak jak rejesry, tak?

do góry

slawek7 pisze:
> A ma to jakiś związek z instrukcjami rdzenia.
> I jesli dobrze zrozumiałem to w ARM to przypadek że adresowanie jest
> 32bitowe i ważne że np RAM ma szerokość32 bitów tak jak rejesry, tak?


Mnie uczono ze szerokosc szyny danych okresla bitowosc procesora, za
moich czasow taki Z-80 mial szyne danych 8 bitowa adresowa 16 bitowa .

Z tym ze mozna bylo wykonywac w pewnycm zakresie operacje na liczbach 16
bitowych.
Im dluzsza szyna danych tym wieksza dana mozesz zapisac w jednej komorce
i obrobic w pewnym najmniejszym cyklu zegarowym. Niestety ale liczby
uzywane w rzeczywistosci nie sa az tak duze zeby stosowac procesory z
dluga szyna danych dlatego nie ma sensu zwiekszac szyny danych .

W efekcie mamy dzis programistow ktorzy pisza super programy w C++ ale
kod wynikowy zajmuje tyle miejsca w pamieci super systemow co kiedys
super gra dla ZX Spectrum.
Przerost formy nad trescia.

do góry

games pisze:
> slawek7 pisze:
>> A ma to jakiś związek z instrukcjami rdzenia.
>> I jesli dobrze zrozumiałem to w ARM to przypadek że adresowanie jest
>> 32bitowe i ważne że np RAM ma szerokość32 bitów tak jak rejesry, tak?
>
>
> Mnie uczono ze szerokosc szyny danych okresla bitowosc procesora, za
> moich czasow taki Z-80 mial szyne danych 8 bitowa adresowa 16 bitowa .
>
> Z tym ze mozna bylo wykonywac w pewnycm zakresie operacje na liczbach 16
> bitowych.
> Im dluzsza szyna danych tym wieksza dana mozesz zapisac w jednej komorce
> i obrobic w pewnym najmniejszym cyklu zegarowym. Niestety ale liczby
> uzywane w rzeczywistosci nie sa az tak duze zeby stosowac procesory z
> dluga szyna danych dlatego nie ma sensu zwiekszac szyny danych .
>
> W efekcie mamy dzis programistow ktorzy pisza super programy w C++ ale
> kod wynikowy zajmuje tyle miejsca w pamieci super systemow co kiedys
> super gra dla ZX Spectrum.
> Przerost formy nad trescia.
>


Zapomnialbym "Hello world" czyli porazka optymalizacji o czyms takim
jak JAVA nie wspomne bo to jest jak dla mnie sadzenie fasolki koparka.

do góry

On Sat, 11 Jul 2009 19:38:54 +0200, games wrote:
>slawek7 pisze:
>> A ma to jakiś związek z instrukcjami rdzenia.
>> I jesli dobrze zrozumiałem to w ARM to przypadek że adresowanie jest
>> 32bitowe i ważne że np RAM ma szerokość32 bitów tak jak rejesry, tak?
>
>Mnie uczono ze szerokosc szyny danych okresla bitowosc procesora, za
>moich czasow taki Z-80 mial szyne danych 8 bitowa adresowa 16 bitowa .

Nawet za twoich czasow nie bylo tak prosto.

>Z tym ze mozna bylo wykonywac w pewnycm zakresie operacje na liczbach 16
>bitowych.

A jak mnozyc mozna 16*16 z wynikiem 32bit, pozostale operacje
wszystkie 32 bit, a szyna 8 bit ?

>Im dluzsza szyna danych tym wieksza dana mozesz zapisac w jednej komorce
>i obrobic w pewnym najmniejszym cyklu zegarowym. Niestety ale liczby
>uzywane w rzeczywistosci nie sa az tak duze zeby stosowac procesory z
>dluga szyna danych dlatego nie ma sensu zwiekszac szyny danych.

Wlasnie doczekalismy czasow gdy rozmiary danych przekraczaja 4GB - i
32 bity przestaly wystarczac.

A tak swoja droga .. czy pecet wykorzysta tyle pamieci ?
Pomijam jakies serwery baz danych, ale czy w jest szansa wykorzystania
takiej pamieci przez inne programy ?
No chyba ze jakas mapa Europy czy optymalizacja FPGA ..

>W efekcie mamy dzis programistow ktorzy pisza super programy w C++ ale
>kod wynikowy zajmuje tyle miejsca w pamieci super systemow co kiedys
>super gra dla ZX Spectrum.
>Przerost formy nad trescia.

Kiedys supergra nie musiala wspoldzialac z windows :-)

J.

do góry

games wrote:
> Niestety ale liczby
> uzywane w rzeczywistosci nie sa az tak duze zeby stosowac procesory z
> dluga szyna danych dlatego nie ma sensu zwiekszac szyny danych .

Zainteresuj się procesorami potrafiącymi wykonywać arytmetyke na
_BARDZO_ szerokich szynach danych. To się przydaje.

do góry

Sebastian Biały pisze:
> games wrote:
>> Niestety ale liczby uzywane w rzeczywistosci nie sa az tak duze zeby
>> stosowac procesory z dluga szyna danych dlatego nie ma sensu zwiekszac
>> szyny danych .
>
> Zainteresuj się procesorami potrafiącymi wykonywać arytmetyke na
> _BARDZO_ szerokich szynach danych. To się przydaje.


Kazdy odpowiednio spreparowny proc to potrafi ale czy rzeczywistosc tego
wymaga ?

do góry

J.F. wrote:

> On Sat, 11 Jul 2009 19:38:54 +0200, games wrote:
>>slawek7 pisze:
>>> A ma to jakiś związek z instrukcjami rdzenia.
>>> I jesli dobrze zrozumiałem to w ARM to przypadek że adresowanie jest
>>> 32bitowe i ważne że np RAM ma szerokość32 bitów tak jak rejesry, tak?
>>
>>Mnie uczono ze szerokosc szyny danych okresla bitowosc procesora, za
>>moich czasow taki Z-80 mial szyne danych 8 bitowa adresowa 16 bitowa .
>
> Nawet za twoich czasow nie bylo tak prosto.
>
>>Z tym ze mozna bylo wykonywac w pewnycm zakresie operacje na liczbach 16
>>bitowych.
>
> A jak mnozyc mozna 16*16 z wynikiem 32bit, pozostale operacje
> wszystkie 32 bit, a szyna 8 bit ?

to było dość rzadkie, na ogół wsio 32 bity, a szyna 8 bitów, na przykład
68008 był taki, oczywiście 32 bitowy procek.

>>Im dluzsza szyna danych tym wieksza dana mozesz zapisac w jednej komorce
>>i obrobic w pewnym najmniejszym cyklu zegarowym. Niestety ale liczby
>>uzywane w rzeczywistosci nie sa az tak duze zeby stosowac procesory z
>>dluga szyna danych dlatego nie ma sensu zwiekszac szyny danych.
>
> Wlasnie doczekalismy czasow gdy rozmiary danych przekraczaja 4GB - i
> 32 bity przestaly wystarczac.
>
> A tak swoja droga .. czy pecet wykorzysta tyle pamieci ?
> Pomijam jakies serwery baz danych, ale czy w jest szansa wykorzystania
> takiej pamieci przez inne programy ?
> No chyba ze jakas mapa Europy czy optymalizacja FPGA ..

mnie sie zdarza dość czesto. Niekoniecznie tyle potrzebne, ale dzieki temu,
ze mam 4GB program działa szybciej. Dane maja od 0.5 do 3.5GB, rzadko
troche wiecej.

>>W efekcie mamy dzis programistow ktorzy pisza super programy w C++ ale
>>kod wynikowy zajmuje tyle miejsca w pamieci super systemow co kiedys
>>super gra dla ZX Spectrum.
>>Przerost formy nad trescia.

A tu troche mieszasz pojecia. Programy pisane w C sa wieksze lub równe pod
wzgledem długości programom pisanym w assemblerze. Programy w C++ sa >=
programom w C.

Waldek

do góry