<html><head><title>Re: GCC slouèení do správného typu</title>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 10pt;">V embedded programování se většinou člověk musí přizpůsobovat cílové platformě, obzvlášť <br>
když se zabývá různou komunikací a tudíž rozsekání dat na byty, případně na menší struktury <br>
(vašich 7 bitů) a jejich zpětnou rekonstrukci. Není to čisté high-level programování,<br>
obzvlášť pokud se snažíte udržet kód efektivní.<br>
<br>
Pokud trváte na zcela obecném řešení, pak bude asi nutné zvlášť poskládat hodnotu <br>
a podle bitu znaménka pak vytvořit výslednou hodnotu. <br>
<br>
uint32_t value = ..... // poskladat bity D14 - D0, vysledek se do typu zarucene vejde<br>
int16_t result<br>
if (precteno[0] & 0x02) {<br>
// nastaveny znamenkovy bit, tedy zaporne cislo<br>
result = -(32768 - value); <br>
} else {<br>
// znamenkovy bit nulovy, nic se nedeje<br>
result = (int16_t)value;<br>
}<br>
<br>
<br>
Nebo to udělat podle GCC a kdyby to někdo chtěl překládat něčím jiným či pro jinou platformu,<br>
tak si dát do zdrojáků vygenerování chyby překladu, pokud nesouhlasí platforma a překladač.<br>
Alespoň to dotyčného trkne že si má zkontrolovat co to bude dělat.<br>
<br>
#if !defined(__GNUC__) || !defined(PLATFORM_ESP)<br>
#error "Zkontroluj chovani konverze precteno[] -> int16 !!!"<br>
#endif<br>
<br>
Tomáš<br>
<br>
<br>
<br>
<span style=" color: #800000;"><b>> Takze je to jak jsem si myslel? V GCC to funguje OK, ale obecne nemusi?<br>
> Cili asi lepsi kvuli prenositelnosti na to nespolehat.<br>
> ESP urcite nema ARM, to je nejaka Cinska riscova silenost a u ESP32 at<br>
> cumim do assembleru jak chci, nechapu tam nic. Ale z GCC prekladac asi<br>
> vychazi.<br>
<br>
> Dne 07.10.2021 v 11:32 Jan Waclawek napsal(a):<br>
>> Z ciste pravnickeho hladiska...<br>
<br>
>> To finalne pretypovanie na int16_t z nezapornej hodnoty 0..0xFFFF z<br>
>> implicitneho int32_t (lebo ten ARM je 32-bitovy - u 16-bitoveho alebo<br>
>> 8-bitoveho mcu tam zrejme treba robit saskovanie s explicitnym<br>
>> pretypovavanim minimalne na uin16_t) je C99 6.3.1.3. (Conversions->Signed<br>
>> and unsigned integers), kde sa pre pripad vysledku vacsieho ako 0x7FFF<br>
>> (t.j. hodnoty ktora nie je reprezentovatelna v int16_t) hovori v #3:<br>
>> [...] either the result is implementation-defined or an<br>
>> implementation-defined signal is raised.<br>
<br>
>> Implementation defined znamena, ze si treba pozriet v manuali k danemu<br>
>> prekladacu, ako sa to presne sprava. Pre gcc je to<br>
</b></span></span><a style=" font-family:'courier new'; font-size: 10pt;" href="https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation">>> https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation</a><br>
<span style=" font-family:'courier new'; font-size: 10pt; color: #800000;"><b>>> :<br>
>> For conversion to a type of width N, the value is reduced modulo 2^N to be<br>
>> within range of the type; no signal is raised.<br>
<br>
>> co prelozene do ludskej reci znamena, ze sa to zasprava presne ako by sme<br>
>> predpokladali.<br>
<br>
>> Left shift znamienkoveho (tu zrejme implicitneho int32_t) je kupodivu v<br>
>> tomto pripade v poriadku, 6.5.7#4:<br>
>> The result of E1 << E2 [...] . If E1 has a signed<br>
>> type and nonnegative value, and E1 × 2^E2 is representable in the result<br>
>> type, then that is<br>
>> the resulting value; otherwise, the behavior is undefined.<br>
<br>
>> t.j. undefined by to bolo len ak by bol vysledok vacsi ako 0x7FFF'FFFF, co<br>
>> tu urcite nebude.<br>
<br>
<br>
>> Co sa tyka efektivity, napriklad v ARMv7M architekture je instrukcia BFI:<br>
>> Bit Field Insert copies any number of low order bits from a register into<br>
>> the same number of adjacent bits at any<br>
>> position in the destination register.<br>
<br>
>> Neviem co je v tom ESP, tipujem ze ARMv7A, a neviem ci tuto instrukciu ma,<br>
>> ale ak ano, mozno to gcc vyuzije.<br>
>> Prekladace C su dnes chytre ako opice, nechal by som to na ten prekladac<br>
>> aby to vyoptimalizoval.<br>
<br>
>> wek<br>
<br>
<br>
>> ----- Original Message ---------------<br>
>> Kdyz jsou vzdy v nejvyssich bitech ty 0, tak signed/unsigned je jedno,<br>
>> ne, stejne se to z-paduje vlevo? Ostatne (cas pro Weka, at mne omlati o<br>
>> hlavu C standard), left shift signed si neumim moc predstavit...<br>
>> J.<br>
<br>
>> On 07.10.2021 10:17, Tomá Hamouz wrote:<br>
>>> Re: GCC slouèení do správného typu Znaménko není tøeba øeit. Pokud je<br>
>>> v D15 znaménko a budete to skládat do int16_t, tak bude správnì nastavené.<br>
>>> Jen bych dal pozor na to, dìlat bitové posuny jako unsigned a a na<br>
>>> konci to pøetypoval na signed.<br>
<br>
>>> Tomá<br>
>> _______________________________________________<br>
>> HW-list mailing list - sponsored by </b></span><a style=" font-family:'courier new'; font-size: 10pt;" href="http://www.HW.cz">www.HW.cz</a><br>
<a style=" font-family:'courier new'; font-size: 10pt;" href="mailto:Hw-list@list.hw.cz">>> Hw-list@list.hw.cz</a><br>
<a style=" font-family:'courier new'; font-size: 10pt;" href="http://list.hw.cz/mailman/listinfo/hw-list">>> http://list.hw.cz/mailman/listinfo/hw-list</a><br>
<br>
<br>
<span style=" font-family:'courier new'; font-size: 10pt; color: #800000;"><b>> _______________________________________________<br>
> HW-list mailing list - sponsored by </b></span><a style=" font-family:'courier new'; font-size: 10pt;" href="http://www.HW.cz">www.HW.cz</a><br>
<a style=" font-family:'courier new'; font-size: 10pt;" href="mailto:Hw-list@list.hw.cz">> Hw-list@list.hw.cz</a><br>
<a style=" font-family:'courier new'; font-size: 10pt;" href="http://list.hw.cz/mailman/listinfo/hw-list">> http://list.hw.cz/mailman/listinfo/hw-list</a></body></html>