On 2016-02-07 02:20, Marek wrote:
> Ale to ja wiem, odpowiedz nie na temat.
> Pytam po co te pgm_costam?

Ponieważ o ile pamietam dla gcc pointer jest tylko "wartością" i nie
zawiera innych znaczeń. To ogranieczenie pochodzi z faktu że developing
gcc odbywał się na w miarę normalnych architekturach gdzie nie był to
kłopot i tak zostało.

Problem tak naprawde nie jest w gcc tylko w C/C++ (np wskaźnik na
funkcje nie jest kompatybilny z void* [1] co jest zrobione m.in. z
powodu jakiś dziwacznych architektur).

> Wewnetrznie kompilator wie

Nie wie. Byly próby aby się dowiedział w postaci propozycji zmiany.
Zdaje się że nie udało się wpuscić tego do mainstream, spodziewam się że
takie ficzery trafią wcześniej do clang. Nie mogę teraz znaleźć pdfa
który tą zmianę prezentował, jak znajdę to go tu wrzucę.

[1]
http://stackoverflow.com/questions/12358843/why-are-
function-pointers-and-data-pointers-incompatible-in-
c-c

do góry

Dnia Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk napisał(a):
> 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.

Przy czym zauwaz, ze to jest luzno zwiazane z "harvardowoscia".

Osobna pamiec programu ... program w C w zasadzie programu nie rusza,
a tam gdzie rusza (adres funkcji), tam kontekst jest z gory ustalony.

Problemem sa dane przechowywane w pamieci programu.
Cos w zasadzie sprzeczne z harwardowoscia :-)

C sie z tym boryka od dawna - byl chocby segment danych
niezainicjowanych i zainicjowanych czy nawet stalych.

Oczywiscie w uC przez dlugi czas bylo malo pamieci, co zachecalo do
uzycia ROM, z drugiej strony ROM jest wolny, a RAM szybki, co zacheca
do przepisania programu do RAM. Nawet jesli to specjalny RAM,
wydzielony tylko na program :-)

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

Harvard Harvardem, ale w co bardziej uniwersalnych systemach jest
potrzeba aby program tworzyl program do wykonania w RAM, czy nawet
zaczytywal go z dysku. I dostep do pamieci programu musi byc, nawet
jesli to pamiec specjalna.

J.

do góry

Dnia Sat, 6 Feb 2016 11:18:29 +0100, Sebastian Biały napisał(a):
> On 2016-02-06 10:48, Marek wrote:
>> Dlaczego? Wystarczy zrobić
>> #define PROGMEM
>
> A co zrobisz z pgm_read_float, pgm_read_byte i okolicą?

#define na najprostsza konstrukcje "zwyklego C" ?

J.

do góry

Dnia Sun, 07 Feb 2016 02:20:45 +0100, Marek napisał(a):
> On Sat, 6 Feb 2016 20:48:17 +0100, Sebastian
> Biały<h...@p...onet.pl> wrote:
>> Obsluga pamięci ROM i RAM wymaga dwóch różnych instrukcji
> maszynowych.
>
> Ale to ja wiem, odpowiedz nie na temat.
> Pytam po co te pgm_costam?

No przeciez wiesz - zeby program w C wiedzial, gdzie czytac

> Jak user chce tabklice we flash to ustawia, jej specjalny atrybut
> przy definicji/deklaracji i to wszystko. A dalejj czyta ją przez
> tab[ndex] lub przez wskaźnik.

No w zasadzie tak. Moze to poklosie wczesniejszych czasow, gdy
kompilator byl glupszy ?
A moze jednak ma zalety, takie bezposrednie podkreslenie, ze tu jest
cos inaczej, a nie - zdefiniowane trzy strony wczesniej.

J.

do góry

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.

do góry

W dniu 2016-02-07 o 02:20, Marek pisze:
> On Sat, 6 Feb 2016 20:48:17 +0100, Sebastian Biały<h...@p...onet.pl>
> wrote:
>> Obsluga pamięci ROM i RAM wymaga dwóch różnych instrukcji
> maszynowych.
>
> Ale to ja wiem, odpowiedz nie na temat.
> Pytam po co te pgm_costam?
> Jak user chce tabklice we flash to ustawia, jej specjalny atrybut przy
> definicji/deklaracji i to wszystko. A dalejj czyta ją przez tab[ndex]
> lub przez wskaźnik.
No ale Ci tłumaczą wszyscy że w avr-ach nie czyta, musi czytać przez
pgr_read_xxx(tab[index]), to jest konsekwencja innego dostępu do pam
programu która pokrywa się adresami z pamięcią ram.

> Wewnetrznie kompilator wie z jakim rodzajem pamięci ma do czynienia i
> stosuje odpowiednie instrukcje.
Nie, nie wie, to ty mu okreslasz skąd ma czytać.



--
Pozdr

Janusz_K

do góry

W dniu 2016-02-07 o 08:28, slawek pisze:
> On Sat, 6 Feb 2016 00:08:06 +0100, Grzegorz Kurczyk
> <g...@c...usun.slupsk.pl> wrote:
>> 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. Te segmenty są na siłę robione i to dopiero ostatnimi
czasy jak się pojawiły wirusy korzystające z przepełnienia
stosu.

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

--
Pozdr

Janusz_K

do góry

On Sun, 7 Feb 2016 12:57:03 +0100, janusz_k <J...@o...pl> wrote:
> Nie, nie wie, to ty mu okreslasz skąd ma czytać.

Pisałem ogólnie o kompilatorach, np. sdcc umie, stąd nie widziałem,
że gcc-avr ma z tym problem, ale już Sebastian wyłuszczył dlaczego.

--
Marek

do góry

W dniu 2016-02-07 o 10:43, Sebastian Biały pisze:
> On 2016-02-07 02:20, Marek wrote:
>> Ale to ja wiem, odpowiedz nie na temat.
>> Pytam po co te pgm_costam?
>
> Ponieważ o ile pamietam dla gcc pointer jest tylko "wartością" i nie
> zawiera innych znaczeń. To ogranieczenie pochodzi z faktu że developing
> gcc odbywał się na w miarę normalnych architekturach gdzie nie był to
> kłopot i tak zostało.

GCC jakiś czas temu nauczyło się rozróżniać przestrzenie adresowe:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spa
ces.html

do góry

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.

do góry