On Sat, 14 Nov 2015 23:52:26 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> http://www.chip.pl/news/sprzet/procesory/2011/11/w-p
olsce-powstal-najwydajniejszy-na-swiecie-procesor

17000MHz robi wrażenie (cały artykuł trzyma ten poziom kompetencji).
Również wizja użycia go w urządzeniach mobilnych brzmi ciekawie.
Minęło 4 lata , jakieś smartfony na nim ktoś widział?
Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

--
Marek

do góry

On Sun, 15 Nov 2015 00:38:36 +0100, Marek <f...@f...com> wrote:
> Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

Dodam tylko, że świat musi na prawdę być pod wrażeniem jakimi
jesteśmy mistrzami w tworzeniu super procesorów, których twörcy robią
na nich biznes mimo, ze nie sprzedali ani jednej sztuki.
A idioci z Intela czy innego AMD wydają kasę na marketing, dział
sprzedaży, wsparcia.... Rotfl! Uczyć się od Polaków robić biznesy!

--
Marek

do góry

On 2015-11-15 00:38, Marek wrote:
>> http://www.chip.pl/news/sprzet/procesory/2011/11/w-p
olsce-powstal-najwydajniejszy-na-swiecie-procesor
> 17000MHz robi wrażenie (cały artykuł trzyma ten poziom kompetencji).

Tam jest masa dupereli ale nawet jak się trafią konkrety to brzmi jakoś
nienajszybciej. Np. 0.5DMIPS/MHz (żeby za chwile na stronie produktu
napisać 75.08 VAX MIPS w celu reklamy :). Bieda. Może w powiązaniu z
ilością bramek może imponować, ale bezwzględnie raczje nie.

> Również wizja użycia go w urządzeniach mobilnych brzmi ciekawie.

Pewno do *szybkiego* sterowania modemem gsm. Z tego co widzę to te
kawałki telefonów są sterowane tego typu antykami. Jakoś nie mogę się
powstrzymać przed wizją że 30 lat temu ktoś napisał soft i zginął kod
źrodłowy albo że architektura jest konsekrowana jakimś certyfikatem.

> Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

Gdyby nie było tego całego szumu w mediach pelnego kłamstw i półprawd to
może bym założył że trafili w niszę i tyle. A że szum zrobił się
przeogromny to mam wrażenie że ktoś tu kogoś robi ciula wykorzystując
tępych dziennikarzy i masę niezrozumiałych liczb.

do góry

On Sun, 15 Nov 2015 01:01:37 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Gdyby nie było tego całego szumu w mediach pelnego kłamstw i
półprawd to
> może bym założył że trafili w niszę i tyle. A że szum zrobił się
> przeogromny to mam wrażenie że ktoś tu kogoś robi ciula
wykorzystując
> tępych dziennikarzy i masę niezrozumiałych liczb.

Co konkretnie sugerujesz?

--
Marek

do góry

On 2015-11-15 09:33, Marek wrote:
>> może bym założył że trafili w niszę i tyle. A że szum zrobił się
>> przeogromny to mam wrażenie że ktoś tu kogoś robi ciula
> wykorzystując
>> tępych dziennikarzy i masę niezrozumiałych liczb.
> Co konkretnie sugerujesz?

Komuś zależy na sukcesie bo otwiera to drzwi? Dziennikarze złapali
clickbait i rozdmuchują ile wlezie? Społczeństwo wymaga nawet tak
absurdalnych sukcesów?

do góry

On 14.11.2015 22:45, Marek wrote:

> układy 18F
> (konkurencyjne z popularnymi Atmegami) mają już architekturę przyjazną C.

A co jest przyjaznego w stronicowaniu RAMu co 256B, stronicowaniu flasha
i sprzętowym stosie? I czemu użytkownik oryginalnego kompilatora
microchipa (picc18) musi ręcznie przydzielać zmienne do banków jeśli
chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne? Albo
czemu musi tablice przekraczające 256B adresować tylko z użyciem wskaźników?

do góry

To, że pic16 (18F) jest przyjazny dla C.nie oznacza że Microchipowa
implementacja C jest przyjazna dla użytkownika :-), ale po kolei:

On Sun, 15 Nov 2015 10:31:51 +0100, Zbych <z...@o...pl> wrote:
> A co jest przyjaznego w stronicowaniu RAMu co 256B, stronicowaniu
flasha

Stronicowanie flasha jest w corach pic14 (16F i mniejsze), core'y
pic16 (18F) tego nie mają.
Problem stronicowanie w pic14 nie dotyczy programowania C, np. SDCC
na pic14 obsługuje to przezroczyscie dla programisty. Oczywiście inną
kwestią jest wpływ na wydajność takiego stronicowania.


> i sprzętowym stosie?

W czym to przeszkadza, skoro on jest tylko używany do call/return a
kompilator i tak używa własny stos, którego wielkość można dowolnie
ustalać? Po za tym są "shadowed registers", które sprzętowo
wspomagają zachowywanie/odtwarzanie rejestrów przy obsłudze przerwań.

> I czemu użytkownik oryginalnego kompilatora
> microchipa (picc18) musi ręcznie przydzielać zmienne do banków
jeśli
> chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne?

Ależ to są głównie problemy C18 (kompilatora i linkera), użyj inny
kompilator. W SDCC np. nie ma problemu z rozróżnianiem wskaźników do
flash i ram. W XC8 też już tego nie ma.

Trzeba też brać pod uwagę, że mówimy o 8 bitiwcach. Rejestry są 8
bitowe więc dostęp do pamięci większej niż 256 bajtów będzie zawsze
się odbywał przez paradygmat stronicowania, bez względu jak
technicznie będzie to zrealizowane (segment:offset, przełączanie
banków, łączenie rejestrów itp). Oczywiście kompilator/linker może to
"ukryć", ale to już kwestia implementacji, ale ona może mieć wpływ na
wydajność.
Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?


>Albo
> czemu musi tablice przekraczające 256B adresować tylko z użyciem
wskaźników?

? w C18 nigdy nie miałem problemu z adresowaniem dużych tablic,
poproszę o szczegóły/przykład. W SDCC jest/był problem z dużymi
tablicami ale to dotyczy core'ow pic14.

--
Marek

do góry

Dnia Sun, 15 Nov 2015 00:55:53 +0100, Marek napisał(a):
> On Sun, 15 Nov 2015 00:38:36 +0100, Marek <f...@f...com> wrote:
>> Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.
>
> Dodam tylko, że świat musi na prawdę być pod wrażeniem jakimi
> jesteśmy mistrzami w tworzeniu super procesorów, których twörcy robią
> na nich biznes mimo, ze nie sprzedali ani jednej sztuki.
> A idioci z Intela czy innego AMD wydają kasę na marketing, dział
> sprzedaży, wsparcia.... Rotfl! Uczyć się od Polaków robić biznesy!

Chodzi mi po glowie ze jest w Polsce kilka firm, ktore "projektuja
procesory". Moze i nie sprzedali ani jednej szkuki, ale opis w VHDL
jakiegos ARM czy 8051 to rzecz (a wlasciwie nie rzecz), ktora mozna
drogo sprzedac.


J.

do góry

On Sun, 15 Nov 2015 11:30:15 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Chodzi mi po glowie ze jest w Polsce kilka firm, ktore "projektuja
> procesory". Moze i nie sprzedali ani jednej szkuki, ale opis w VHDL
> jakiegos ARM czy 8051 to rzecz (a wlasciwie nie rzecz), ktora mozna
> drogo sprzedac.

Ależ ja to nawet jestem w stanie zrozumieć, ale pod pewnym warunkiem:
oczekuję, że będę mógł go kupić (nie ważne kto kupi licencję i będzie
fizycznie go produkował), zaimplementować i *też* zrobić na nim
biznes.
Ja nie chcę czytać takich nagłówków ("pierwszy Polski procesor!"
albo "Najszybszy na świecie Polski procesor!"), ja chcę aby na
elektrodzie obok PIC, ARM czy AVR była zakładka np. PLPROC i
dotyczyła rodzimej konstrukcji. Mrzonka?

--
Marek

do góry

On 15.11.2015 11:14, Marek wrote:
>> i sprzętowym stosie?
>
> W czym to przeszkadza, skoro on jest tylko używany do call/return a
> kompilator i tak używa własny stos, którego wielkość można dowolnie
> ustalać? Po za tym są "shadowed registers", które sprzętowo wspomagają
> zachowywanie/odtwarzanie rejestrów przy obsłudze przerwań.

Sprzętowy stos przeszkadza w przełączaniu wątków.
Ile jest zestawów "shadow registers"? Po jednym dla każdego wektora
przerwania? Bo dokumentacja microchipa jest jakoś skąpa w tym zakresie.

>> I czemu użytkownik oryginalnego kompilatora microchipa (picc18) musi
>> ręcznie przydzielać zmienne do banków
> jeślihttp://www.xargs.com/pic/picc18-vs-c18.html
>> chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne?
>
> Ależ to są głównie problemy C18 (kompilatora i linkera), użyj inny
> kompilator. W SDCC np. nie ma problemu z rozróżnianiem wskaźników do
> flash i ram. W XC8 też już tego nie ma.

Własny procek microchipa i jego własny (płatny!) kompilator nie był w
stanie ukryć upierdliwości (czy może przyjaznej dla kompilatorów)
architektury.

XC8 nie testowałem, bo parę lat wstecz gdy wybierałem kompilator na PIC,
to XC8 generował większy kod na PIC18 i sypał dużą ilością warningów na
stosie TCP/IP microchipa. Stwierdziłem, że nie chcę być królikiem
doświadczalnym. Opłacanie prawa do aktualizacji też nie nastawiało
optymistycznie:

If your HPA has expired, you are entitled to download all compiler
versions that have been released up to the time of the expiration.

> Trzeba też brać pod uwagę, że mówimy o 8 bitiwcach. Rejestry są 8 bitowe
> więc dostęp do pamięci większej niż 256 bajtów będzie zawsze się odbywał
> przez paradygmat stronicowania, bez względu jak technicznie będzie to
> zrealizowane (segment:offset, przełączanie banków, łączenie rejestrów
> itp). Oczywiście kompilator/linker może to "ukryć", ale to już kwestia
> implementacji, ale ona może mieć wpływ na wydajność.

8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd ten
pomysł?

> Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?

Normalnie, adres jest 16-bitowy (albo dłuższy).

>> Albo czemu musi tablice przekraczające 256B adresować tylko z użyciem
> wskaźników?
>
> ? w C18 nigdy nie miałem problemu z adresowaniem dużych tablic, poproszę
> o szczegóły/przykład.

Cytat ze strony: http://www.xargs.com/pic/picc18-vs-c18.html
Zwróć uwagę na ostatnie zdanie.

PICC-18 allows RAM objects of any size to be declared, though some
limitations exist that require balancing objects between C source files
in certain cases. C18 does not support RAM objects larger than 256 bytes
by default; creating such objects requires editing linker control files
and adding pragmas to the C source which include hard-coded variable
addresses. These objects can only be accessed through pointers, not
directly.

do góry