Re: GCC slouèení do správného typu

[Tomáš Hamouz]

V embedded programování se většinou člověk musí přizpůsobovat cílové platformě, obzvlášť 
když se zabývá různou komunikací a tudíž rozsekání dat na byty, případně na menší struktury 
(vašich 7 bitů) a jejich zpětnou rekonstrukci. Není to čisté high-level programování,
obzvlášť pokud se snažíte udržet kód efektivní.

Pokud trváte na zcela obecném řešení, pak bude asi nutné zvlášť poskládat hodnotu 
a podle bitu znaménka pak vytvořit výslednou hodnotu. 

uint32_t  value = ..... // poskladat bity D14 - D0, vysledek se do typu zarucene vejde
int16_t result
if (precteno[0] & 0x02) {
   // nastaveny znamenkovy bit, tedy zaporne cislo
   result = -(32768 - value);	
} else {
   // znamenkovy bit nulovy, nic se nedeje
   result = (int16_t)value;
}


Nebo to udělat podle GCC a kdyby to někdo chtěl překládat něčím jiným či pro jinou platformu,
tak si dát do zdrojáků vygenerování chyby překladu, pokud nesouhlasí platforma a překladač.
Alespoň to dotyčného trkne že si má zkontrolovat co to bude dělat.

#if !defined(__GNUC__) || !defined(PLATFORM_ESP)
  #error "Zkontroluj chovani konverze precteno[] -> int16 !!!"
#endif

Tomáš



> Takze je to jak jsem si myslel? V GCC to funguje OK, ale obecne nemusi?
> Cili asi lepsi kvuli prenositelnosti na to nespolehat.
> ESP urcite nema ARM, to je nejaka Cinska riscova silenost a u ESP32 at
> cumim do assembleru jak chci, nechapu tam nic. Ale z GCC prekladac asi
> vychazi.

> Dne 07.10.2021 v 11:32 Jan Waclawek napsal(a):
>> Z ciste pravnickeho hladiska...

>> To finalne pretypovanie na int16_t z nezapornej hodnoty 0..0xFFFF z
>> implicitneho int32_t (lebo ten ARM je 32-bitovy - u 16-bitoveho alebo
>> 8-bitoveho mcu tam zrejme treba robit saskovanie s explicitnym
>> pretypovavanim minimalne na uin16_t) je C99 6.3.1.3. (Conversions->Signed
>> and unsigned integers), kde sa pre pripad vysledku vacsieho ako 0x7FFF
>> (t.j. hodnoty ktora nie je reprezentovatelna v int16_t) hovori v #3:
>> [...] either the result is implementation-defined or an
>> implementation-defined signal is raised.

>> Implementation defined znamena, ze si treba pozriet v manuali k danemu
>> prekladacu, ako sa to presne sprava. Pre gcc je to
>> https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation
>> :
>> For conversion to a type of width N, the value is reduced modulo 2^N to be
>> within range of the type; no signal is raised.

>> co prelozene do ludskej reci znamena, ze sa to zasprava presne ako by sme
>> predpokladali.

>> Left shift znamienkoveho (tu zrejme implicitneho int32_t) je kupodivu v
>> tomto pripade v poriadku, 6.5.7#4:
>> The result of E1 << E2 [...] . If E1 has a signed
>> type and nonnegative value, and E1 × 2^E2 is representable in the result
>> type, then that is
>> the resulting value; otherwise, the behavior is undefined.

>> t.j. undefined by to bolo len ak by bol vysledok vacsi ako 0x7FFF'FFFF, co
>> tu urcite nebude.


>> Co sa tyka efektivity, napriklad v ARMv7M architekture je instrukcia BFI:
>> Bit Field Insert copies any number of low order bits from a register into
>> the same number of adjacent bits at any
>> position in the destination register.

>> Neviem co je v tom ESP, tipujem ze ARMv7A, a neviem ci tuto instrukciu ma,
>> ale ak ano, mozno to gcc vyuzije.
>> Prekladace C su dnes chytre ako opice, nechal by som to na ten prekladac
>> aby to vyoptimalizoval.

>> wek


>> ----- Original Message ---------------
>> Kdyz jsou vzdy v nejvyssich bitech ty 0, tak signed/unsigned je jedno,
>> ne, stejne se to z-paduje vlevo? Ostatne (cas pro Weka, at mne omlati o
>> hlavu C standard), left shift signed si neumim moc predstavit...
>> J.

>> On 07.10.2021 10:17, TomᚠHamouz wrote:
>>> Re: GCC slouèení do správného typu Znaménko není tøeba øešit. Pokud je
>>> v D15 znaménko a budete to skládat do int16_t, tak bude správnì nastavené.
>>> Jen bych dal pozor na to, dìlat bitové posuny jako unsigned a až na
>>> konci to pøetypoval na signed.

>>> Tomáš
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list


> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20211007/b918ab69/attachment.html>