W dniu 2016-02-07 o 20:39, Sebastian Biały pisze:
> On 2016-02-07 20:06, Zbych wrote:
>> GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:
>> https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spa
ces.html
>
> To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca wskaźnik
> musiala by się generować osobno dla każdej kombinacji typów
> wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć __flash
> przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że bez
> rękodzieła ani rusz.

To jest raczej oczywiste, tyle że nie trzeba ręcznie wstawiać
pgm_read_cośtam.

do góry

On Sun, 7 Feb 2016 20:39:36 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> To nie wystarczy. Np. w przypadku AVR każda funkcja przyjmująca
wskaźnik
> musiala by się generować osobno dla każdej kombinacji typów
> wskaźnikowych jakie w programie wystąpią. Dlatego nalezy użyć
__flash
> przy wskaźnikowym argumencie funkcji, czyli znowu wychodzi na to że
bez
> rękodzieła ani rusz.

A sdcc testowałeś? O ile pamiętam ają port avr. Port pic16 (układy
18F) daje radę z mieszaniem wskaźników ram/flash (nie odróżnia os
strony programisty), więc może i port avr podobnie.

--
Marek

do góry

On 2016-02-07 21:25, Marek wrote:
> A sdcc testowałeś?

A obsługuje C++? Bo jak nie to jest *bezużyteczny*.

do góry

Dnia Sun, 7 Feb 2016 12:22:29 +0100, Sebastian Biały napisał(a):
> On 2016-02-07 11:30, J.F. wrote:
>>>> Dlaczego? Wystarczy zrobić
>>>> #define PROGMEM
>>> A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?
>> #define na najprostsza konstrukcje "zwyklego C" ?
>
> Pytanie co zrobisz gdy portujesz harvard->harvard i obie implementacje
> radośnie wymysliły własny lepszy sposób na grzebanie w rom.

Nadal #define moze problem rozwiazac.

A jesli nie ... no coz, za cos ci programsci musza brac pieniadze :-)

J.

do góry

Dnia Sun, 7 Feb 2016 13:03:39 +0100, janusz_k napisał(a):
> W dniu 2016-02-07 o 08:28, slawek pisze:
>> On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
>>> AVR ma oddzielną pamięć programu i danych co powoduje, że np do
>>
>> 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 :-(

od x386 sie troche zmienilo

> Te segmenty są na siłę robione i to dopiero ostatnimi
> czasy jak się pojawiły wirusy korzystające z przepełnienia
> stosu.

No, nawet w pelnej adresacji 32 bit te segmenty maja pewien sens -
pozwalaja rozszerzyc przestrzen wirtualna, dynamicznie zarzadzac
rozmiarem ... i oszczedniej to robic niz w 64 bit :-)

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

J.

do góry

On Sun, 7 Feb 2016 21:29:41 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> A obsługuje C++? Bo jak nie to jest *bezużyteczny*.

Broń Boże :)

--
Marek

do góry

W dniu 2016-02-07 o 22:15, J.F. pisze:
> Dnia Sun, 7 Feb 2016 13:03:39 +0100, janusz_k napisał(a):
>> W dniu 2016-02-07 o 08:28, slawek pisze:
>>> On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
>>>> AVR ma oddzielną pamięć programu i danych co powoduje, że np do
>>>
>>> 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, dopiero
w nowych teraz prockach jest blokada na poziomie jądra procka, tylko
procesy systemowe w ringu 0 mają całkowity dostęp.


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



--
Pozdr

Janusz_K

do góry

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.

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

Jesli miales w systemie np dwa porty szeregowe (UART), to nie mogles w
systemie napisac jednej procedury ich obslugi, do ktorej bys przekazal
adres bazowy sterownika portu. Adres byl staly.

Podobnie w C nie mogles napisac funcji, ktora by dostala adres portu
jako parametr. Musial byc staly i znany juz w czasie kompilacji.

Tzn mogles - jesli program byl w RAM a nie ROM, to program mogl sobie
zmienic bajt pamieci odpowiedniego rozkazu.

Cos mi chodzi po glowie, ze podobna zmiana kodu musiala byc stosowana
takze w x86, ale to jeszcze jakis inny rozkaz musial byc, bo IN/OUT
mialy mozliwosc adresowania DX.
A jak uwzglednic kolejki i cache, to sprawa przestaje byc prosta :-)

J.

do góry

On Sun, 7 Feb 2016 13:03:39 +0100, janusz_k <J...@o...pl> wrote:
> To kompilator ma a nie procek, x86 od zawsze miały wspólną
przestrzeń
> danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
> czasy jak się pojawiły wirusy korzystające z przepełnienia

Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...

do góry

Użytkownik "slawek" napisał w wiadomości grup
dyskusyjnych:a...@n...v.pl.
..
On Sun, 7 Feb 2016 13:03:39 +0100, janusz_k <J...@o...pl> wrote:
>> To kompilator ma a nie procek, x86 od zawsze miały wspólną
przestrzeń
>> danych i programu. Te segmenty są na siłę robione i to dopiero
ostatnimi
>> czasy jak się pojawiły wirusy korzystające z przepełnienia

>Ciekawe. Rejestry DS i CS to w x86 pojawiły się jakieś 30 lat temu...

Ale pamiec i przestrzen byla jedna.
Jak sie do DS i CS wpisalo to samo, to mozna bylo kod traktowac jak
dane.

Zreszta wskaznik zawieral i segment, wiec mozna bylo jednolicie
adresowac, chyba, ze ktos sie uparl przy modelu small ...

J.

do góry