On Sun, 7 Feb 2016 11:28:05 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Osobna pamiec programu ... program w C

FYI Microsoft Windows od wersji 1.0 pozwala określić kod jako
DISCARDABLE, co umożliwia wywalenie go z RAM.

Ogólnie mylicie teoretyczne koncepcje architektury (HarVard wow!) z
tym że komputery są jakie są (np. pamięć slow i fast w Amidze) i nie
zawsze w praktyce jest tak prosto.

Język C ma standard. I ten standard jest po to aby nie trzeba było
zgłębiać architektury procesora, znać rozkazy czy wiedzieć czy dysk
jest magnetyczny czy SSD. Jeżeli w programie będzie const int, to
kompilator ma się zatroszczyć o to co z tym zrobić.

do góry

On Tue, 9 Feb 2016 00:53:13 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Podobnie w C nie mogles napisac funcji, ktora by dostala adres portu
> jako parametr. Musial byc staly i znany juz w czasie kompilacji.

Bo nie można było użyć switch ew. zwykłego if ???

do góry

Użytkownik "slawek" napisał w wiadomości grup
dyskusyjnych:a...@n...v.pl
...
On Tue, 9 Feb 2016 00:53:13 +0100, "J.F."
<j...@p...onet.pl> wrote:
>> Podobnie w C nie mogles napisac funcji, ktora by dostala adres
>> portu
>> jako parametr. Musial byc staly i znany juz w czasie kompilacji.

>Bo nie można było użyć switch ew. zwykłego if ???

Mozna bylo, ale nadal adres musial byc znany z gory i tylko kilka
dostepnych do wyboru.
No chyba, ze chcesz switch na wszystkie mozliwe 256 adresow :-)

A tak prawde mowiac ... kto wie, czy nie efektywniej bylo skopiowac
tych kilka procedur niz dorabiac switcha w srodku ...

J.

do góry

W dniu 2016-02-06 00:08, Grzegorz Kurczyk pisze:
> W dniu 05.02.2016 o 21:22, Atlantis pisze:
>> W dniu 2016-02-05 o 18:47, Sebastian Biały pisze:
>>
>>> Przy czym zaznaczam że czasami harvardowatość jest ukryta przed kodem
>>> usera. Mówimy o procesorach gdzie jest to widoczne, jak na przykład AVR.
>>> Tam jezyk C z definicji bedzie musiał być wspierany w mało przenośny
>>> sposób aby wydajnie programować.
>>
>> Hmm... O jakich aspektach kodu pod AVR tutaj mówimy?
>>
>
> AVR ma oddzielną pamięć programu i danych co powoduje, że np do
> odczytania bajtu z pamięci programu (która ma szynę 16-bitową) służy
> inny rozkaz procesora niż do czytania bajtu z pamięci danych z szyną
> 8-bitową. Czyli jeśli z poziomu języka wyższego poziomu chcesz np.
> wyświetlić jakiś napis, to masz dwie różne definicje łańcucha
> określające w jakiej pamięci ma być umieszczony i dwie różne procedury
> do wyświetlania tego łańcucha w zależności gdzie był umieszczony. W
> AVRGCC jest specjalny typ wskaźnikowy do stałych umieszczonych w pamięci
> programu.

Wstępnie zaznaczę, że nie znam kompletnie AVRGCC...

Jeśli tak jest, że w AVRGCC *nie da się* zmienną wskaźnikową wskazać raz
na obiekt w pamięci programu, a potem na obiekt w pamięci zmiennych, to
jest to tylko ułomność owego AVRGCC. MCS-51 miał jeszcze bardziej
porypany model pamięci i do każdej z nich trzeba było się odwoływać
innymi instrukcjami maszynowymi. Niemniej kompilator Keila bez problemu
sobie z tym radził i standardowe wskaźniki C były implementowane w taki
sposób, że takim wskaźnikiem do woli można skakać pomiędzy różnymi
rodzajami pamięci MCS-51. Standard C nie wymusza, że wskaźnik musi być
li tylko adresem. Wskaźnik jak najbardziej może przechowywać dodatkowe
informacje pozwalające na dobranie się do wskazywanego obiektu bez
żadnych dwuznaczności.
W kompilatorze Keila na MCS-51 wskaźnik zajmował trzy bajty -- jedno
pole 8-bit typu pamięci + 16-bitowy adres. Oczywiście były też
niestandardowe wskaźniki służące do pokazywania tylko w wybranym typie
pamięci -- to dla tych co lubią/potrzebują optymalizować kod.

> Przy architekturze von Neumanna nie ma rozdzielenia pamięci danych od
> pamięci programu. O tym czy procesor widzi pamięć w danej chwili kostkę
> RAM, EPROM czy rejestr jakiegoś I/O decyduje dekoder adresów. Procek
> może wykonywać rozkazy umieszczone w dowolnym obszarze przestrzeni
> adresowej. Z punktu widzenia języka wysokiego poziomu w rodzaku C taki
> sam wskaźnik char* może wskazywać na jakiś fragment kodu programu, daną
> czy rejestr układu I/O.

Napomnę o Modified Harvard Architecture, współcześnie
najpopularniejszej, łączącej wspólną przestrzeń adresową i korzyści
posiadania dwóch (a może i jeszcze więcej) magistral.

pzdr
mk

do góry

W dniu 2016-02-09 o 00:53, J.F. pisze:
> Dnia Mon, 8 Feb 2016 21:28:14 +0100, janusz_k napisał(a):
>> W dniu 2016-02-07 o 22:15, J.F. pisze:
>>>>> Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś z tym
>>>>> żyjemy.
>>>> To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
>>>> danych i programu.
>>>
>>> Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
>>> namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
>>> huge .. 6 ich bylo :-(
>> Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
>> dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
>
> W modelu small byl jednak segment kodu, segment danych, a
> adres/wskaznik tylko 16 bitow liczyl.
Ale segment mogłes zmienić, oczywiście nie było to atomatyczne, trzeba
było załadować rejestr segmentu ale się dało.
>
>>>>> Intel x86 też ma oddzielne instrukcje mov i in.
>>>> Łaskawco rozrózniaj instrukcje dostępu do pamięci "mov" od instrukcji
>>>> we/wy "in", bo jak na razie to mieszasz pojęcia.
>>>
>>> Poniekad ten sam problem, tylko w jeszcze innym miejscu.
>>> taki 8080 nie mial np adresacji in/out posredniej czy przez rejestr,
>>> tylko wpisany w rozkaz, - co uniemozliwialo zadanie adresu parametrem
>>> - musial byc z gory okreslony.
>>
>> Jarku sprawdz zanim napiszesz, cytuję:
>> "Other Instructions
>>
>> IN Port Data from Port placed in A register.
>> OUT Port Data from A register placed in Port."
>>
>> http://fms.komkon.org/comp/CPUs/8080.txt
>
> No - dane byly w rejestrze A, a adres portu ?
> W drugim bajcie rozkazu.
A tak masz rację, pomyliło mi się z innym prockiem :)


--
Pozdr

Janusz_K

do góry

Użytkownik "janusz_k" napisał w wiadomości grup
dyskusyjnych:n9g5du$12te$...@g...aioe.org...
W dniu 2016-02-09 o 00:53, J.F. pisze:
>>>>>> Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I
>>>>>> jakoś z tym
>>>>>> żyjemy.
>>>>> To kompilator ma a nie procek, x86 od zawsze miały wspólną
>>>>> przestrzeń
>>>>> danych i programu.
>>>> Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
>>>> namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny,
>>>> small,
>>>> huge .. 6 ich bylo :-(
>>> Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
>>> dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
>> W modelu small byl jednak segment kodu, segment danych, a
>> adres/wskaznik tylko 16 bitow liczyl.
>Ale segment mogłes zmienić, oczywiście nie było to atomatyczne,
>trzeba było załadować rejestr segmentu ale się dało.

W assemblerze sie dalo, bo w C/model small to nie bardzo.
Owszem, wskaznik mogles zadeklarowac huge czy jakos tak, ale funkcje
biblioteczne przyjmowaly parametry small.

J.

do góry

W dniu 2016-02-10 o 21:25, J.F. pisze:
> Użytkownik "janusz_k" napisał w wiadomości grup
> dyskusyjnych:n9g5du$12te$...@g...aioe.org...
> W dniu 2016-02-09 o 00:53, J.F. pisze:
>>>>>>> Intel x86 też ma oddzielnie segmenty kodu i danych. I co? I jakoś
>>>>>>> z tym
>>>>>>> żyjemy.
>>>>>> To kompilator ma a nie procek, x86 od zawsze miały wspólną przestrzeń
>>>>>> danych i programu.
>>>>> Przestrzen wspolna, adresacja jedna, ale i tu moze segmentacja
>>>>> namieszac. Ktos jeszcze pamieta te modele pamieci w C - tiny, small,
>>>>> huge .. 6 ich bylo :-(
>>>> Pewnie, pisałem na nie. Co nie zmienia faktu że można było wpisać
>>>> dowolny adres i pobrać dane czy zapisać z całej pamięci RAM,
>>> W modelu small byl jednak segment kodu, segment danych, a
>>> adres/wskaznik tylko 16 bitow liczyl.
>> Ale segment mogłes zmienić, oczywiście nie było to atomatyczne, trzeba
>> było załadować rejestr segmentu ale się dało.
>
> W assemblerze sie dalo, bo w C/model small to nie bardzo.
> Owszem, wskaznik mogles zadeklarowac huge czy jakos tak, ale funkcje
> biblioteczne przyjmowaly parametry small.
Ja akurat pisałem w asemblerze więc nie był to problem :)

--
Pozdr

Janusz_K

do góry