Je to legrace programovat DSP, už jen proto, že velikost char je 16 bitů, to rozbije spoustu existujícího kódu, nikdo s tím nepočítá, i když to standard C povoluje.
K úplné dokonalosti to dotáhly DSP řady 56F8300, char je tam taky 16 bitů, ale návrháři DSP si řekli, že je to přece škoda, když se často pracuje se stringy, nevyužít celých 16 bitů, takže existuje speciální "packed" adresovací mód, kdy se do jednoho 16-bitového charu ukládají dva 8-bitové znaky. Existuje tedy něco jako standardní pointer (na 16-bitový char) a byte pointer na polovinu 16-bitového charu. Konverze mezi standardním pointerem a byte pointerem znamená vynásobit hodnotu standardního pointeru 2x. void* je byte pointer, takže při volání memset/memcpy je opravdu nutné dávat si pozor, co se tam předává a obvykle to znamená vynásobit hodnotu pointeru 2x.
Jojo, prave zde na tyhle procesory bych nahnal vsechny ty 'patlaly' kodu (co znaji jenom little endian i386 a pouzivaji takove to oblibene 'pretypovani' (byte *)&int), at si na vlastni kuzi vyzkousi, ze norma ANSI C opravdu rika jenom to ze:
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
Na tomto jsme se poprve 'vysekal' na vetsim bratricku DSP320C32 na diplomce, kde sizeof() vseho je sice 1, ale to 1 je 32bitu !!!!
Takze pokud si do charu ulozite 16M, tak to z nej zase prectete :-) A little/big endianes tak nejak ztraci smysl ....
sizeof(type)
Returns size in bytes of the object representation of type.
IMHO stačí psát všude *sizeof(char)
. CHAR_BITS jsou bits, ne bytes.
Pokud by ten kompilátor měl sizeof(char) == 1
, ale char zabíral přesto několik bytes, tak to neodpovídá specifikaci a pak těžko na cokoliv spoléhat. Předpokládám, že ale i byte je pak definovaný jako 32 bitů (například).
To ctes z normy ANSI C nebo je to neco novejsiho (C89/C99)?
sizeof gives the size in units of chars. These "C bytes" need not be 8-bit bytes (though commonly they are); the number of bits is given by the CHAR_BIT macro in the limits.h header.
https://www.thecodingforums.com/threads/implementations-with-char_bit-32.440062/#post-2435265
To bylo z cppreference: http://en.cppreference.com/w/cpp/language/sizeof
Na druhé straně, 6.5.3.4 z C standardu (doufám! - http://c0x.coding-guidelines.com/6.5.3.4.html) říká, že sizeof(char) == 1.
Ono se s tim opravdu u TMS320x bojovalo (+druha odpoved Williama Forbese, ktera ale resi jen polovinu problemu):
https://www.misra.org.uk/forum/viewtopic.php?f=71&t=973&sid=c0d16f6804491874a3064a0fdb4b06b5
(na druhou stranu, ten kod stejne nebyl prenositelny kvuli uplne jinym vecem, tak se to nejak ohlo :/, urcite tam CHAR_BIT nefigurovalo)
Ješte bych asi zmínil klasiku největší: https://www.amazon.com/TMS32010-Digital-Processor-Revised-February/dp/B0019CRCJ0
(ale určitě se to bude u starších develů válet někde na stole mezi hrnky od kafe)
Už se těším. Docela bych rád věděl, jak se v C řeší užití paralelních jednotek - například CPU, CLA a FPU - tak, aby pracovaly paralelně, jestli to řeší kompilátor nebo ne. I když se obávám, že je to nad rámec tohoto seriálu. Je také zajímavé (nevím jak u původních verzí) je , že DMA nebo CLA periférie používají jen omezenou, nestejnou část RAM. S tímhle mikrem bude ještě sranda :-)
Co DSP, to je ještě celkem v pohodě, tam se to dá ještě nějak algoritmizovat (teď dělej to, potom tamto) a jenom si dávat majzla na to, jak se to vlastně provádí (např. nebyly možný některý sekvence instrukcí, protože operand ještě visel v násobičce. Když ty pasti člověk vychytá a potřebuje něco řídit, jsou k nezaplacení. Posledně ten QPSK demodulátor stál za to... :D Asi jako přechod od plaza k ptákovi.
Co je ale přechod od plaza ke stromu, to jsou PLD, ať už CPLD nebo FPGA. Tam se věci dějí tak nějak současně, následnost kroků se řídí víceméně jenom stavovým automatem nebo pipeline... O rychlosti běhu a využití čipu (a tím i ceně zařízení) rozhoduje například jeho zapojení (kam namapuju GPIO) atd. Tam bych to v biologii přerovnal jako přechod od plazů ke stromům... Však si to prubni, kit s MachXO se dá sehnat kolem 600-700 CZK.
Btw, právě proto, že DSP umí něco a CPU něco jinýho, dělají u TI brouky řadu OMAP. Tzn. DSP 1-2GHz + ARM 400+ MHz (nevím z hlavy aktuální nabídku, nějak bych to momentálně neměl jak využít)...
Tohle srovnávání nemám rád, protože se tu srovnává nesrovnatelné. HDL popis je de facto do slov převedené schema, tedy popis zapojení. Tak jako u schématu rádia by nikoho asi příliš nepřekvapilo, že ve všech těch drátech tam vyobrazených teče proud tak nějak současně najednou a ty tranzistory pracují každý sám za sebe, nezávisle na ostatních, jen na základě toho, co je jim přivedeno na B-C-E, nemělo by to překvapovat ani v HDL popisu.
Schema rádia nám neříká, jak rádio funguje. Popisuje nám, jak je zapojeno. Teprve až analýzou schematem vyobrazeného obvodu bychom přišli na to, jak to vlastně funguje.
U HDL je třeba míti vždy na paměti, že neprogramuji, ale navrhuji obvod. Jenom to nedělám pomocí tužky a čtverečkovaného papíru, ale verbálně. Nekreslím sčítačku, ale píšu plus. Nekreslím komparátor nebo multiplexor, ale píšu if, when apod. Nekreslím hradla, ale píšu and, or atd. Nemaluju čáry, ale píšu, co je s čím propojeno pomocí něčeho, co by v programování vypadalo jako přiřazení do proměnné. Ale tady to nemá s proměnnou nic společného! Nečtu "do Áčka přiřaď hodnotu Béčka a pak do Céčka hodnotu Déčka", ale "vývod A nechť je propojen s vývodem B, vývod C s D" atd., jako bych to postupně maloval do schematu. Ale až to postupně namaluju, tak to tam bude vyobrazené samozřejmě současně. Je buřt, nakreslím-li nejdřív spodní čáru a pak horní nebo naopak. Nekreslím klopné obvody, ale píšu, že se má něco s něčím propojit až s příchodem hrany hodinového signálu. A přestože by se programátorovi mohlo zdát, že to je skoro to samé jako to výše popsané "přiřazení", jenom je to uvnitř jakéhosi bloku, tak elektrotechnik ví, že je to něco diametrálně odlišného!
Návrh obvodu pomocí HDL není prací pro programátory, nýbrž pro elektrotechniky. Spoustu lidí mate, že to na první pohled vypadá jako program, ale není to program, je to popis obvodu! Pokud měl někdo problémy s elektrotechnikou, bude mít problémy i s HDL návrhem. Protože to je elektrotechnika a s programováním to ve skutečnosti nemá společného víc než kreslení elektrického schema.
Připadá-li někomu nezvyklé, že se v PLD dějí věci tak nějak současně, tak by mu mělo připadat nezvyklé, že mu může v bytě současně svítit lampa v obýváku i v koupelně a ještě při tom v kuchyni současně běžet lednička. Ani o ždibeček větší kouzla se v PLD nedějí.
(Samozřejmě jsem neměl na mysli behaviorální popis pro účely simulací. Jenže takovým popisem velmi často končí návrh, pokud ho dělá programátor, který si neuvědomuje, že toto opravdu není programování. Syntezátor se mu samozřejmě snaží vyhovět seč mu síly stačí, ale to co z něj vypadne, pokud se mu to podaří, je pak neuvěřitelné zvěrstvo.)
Já myslím, že ve starém dobrém světě se ví, že kilobajt, megabajt a podobné jsou odvozeny od mocnin dvojky. Tak to v technice platilo, platí a platit bude.
To, že obchodníci dělají bordel je věc jiná - a ti ho budou dělat vždycky. Budou si vymýšlet své definice MB a GB. Výrobci procesorů vám neudají spotřebu, ale raději budou uvádět TDP, které nikdo nemůže změřit ani zkontrolovat. Čínské reprobedýnky udávají výkon v PMPO wattech, takže maličký repráček dá stovky, někdy i tisíce wattů, apod.
Až do své smrti budu uvádět kilobajty a nikdy kibibajty, a pod. A vždy to budou mocniny dvojky.
Howgh.
Podívejte se, Američané nedokázali ani to, že by za 100 let přešli z ošklivých palců, stop, liber, galonů, Fahrenheitů a dalšího na logičtější a jednodušší metrický systém. V tom jsou za opicemi, i ti zaostalí Rusové se byli schopní vzdát svých verst a sáhů - a používají metry.
Až Američané přestanou používat středověké jednotky, budu já používat kibibajty.
Az mi prineses ukazat fyzickou podobu ram, o velikost 1000B (tedy podle tebe 1kB), tak ja zacnu pouzivat kiB. Do ty doby je odkajziva 1kB === 1024B.
Sranda je, jak se to tem podvodnikum (s diskama) ted pekne vraci v podobe SSD, protoze tam to presne takhle je. Takze 1TB SSD je o dost vetsi nez "1TB" HDD.
Ony totiz nasobky odpovidaji pouzite soustave, a schvalne sem napis tisic ve dvojkovy soustave ...
No, tohle zrovna není úplně nejvhodnější příklad, protože v počítačích se kilobajt značívá KB, tedy s velkým K. Narozdíl od fyziky, kde kilo je s malým k. A pokud si vzpomínám na své začátky s počítači v 80. letech, tak nám bylo tehdy vysvětleno, že tím velkým písmenem se kdysi právě zdůrazňovalo, že nejde o 1000, ale o 1024. Jenže tento pradávný úzus z dob, kdy megabajt byla kapacita čehokoli jen v říši fantazie, se časem nějak pozapomněl, nebo lidem začal připadat zbytečný, čert ví, takže mega, giga atd. už se psalo jako ve fyzice (přitom záměna mB s milibajtem by z pochopitelných důvodů nehrozila).
A pak musela uplynout spousta času, než jsme se dožili doby, kdy spousta lemplů a podvodníků se potřebuje tvářit, že dělá něco užitečného, místo užitečné práce jen vykazují činnost tváříce se strašně důležitě a tak znovu vymysleli už jednou vymyšlené a nepříliš osvědčené, i když chápu, že nějaké ty důvody spočívající v reakci na optimalizátory zisků výrobců, kteří místo inovací jen vymýšlejí, jak nejlépe oklamat a oškubat spotřebitele, tu taky sehrály důležitou roli.
Sám za sebe říkám, že to nepoužívám a používat nebudu. I za cenu toho, že bych musel do dokumentace výrazně připisovat, že předpony jsou myšleny jako mocniny dvou.
ja bych zavedl, ze byte=10 bitu, at se to BFUckam dobre pocita (na co jim to je, je uz dalsi vec, vsak dneska kazdej bere do pusy "megapixel" a vubec netusi, o cem mluvi). Slovo je dale 20 bitu, potom kilo, mega atd. krasne mocniny 10^3, zrusit divne * a / pro nasobeni a deleni, vsak mame unicode symboly × a ÷ Brave new world.