ciao
essendo

float       float_value;
sint32_t floor_part;

tralasciando per un attimo il fatto che il range coperto dai numeri float IEEE 754 binary floating point representation supera di gran lunga il range copriblile da sint32_t e che quindi dovrei anche valutare di volta in volta se la conversione e' possibile, oppure segnalare che non lo e'

ora vorrei evitare come la morte di dover fare questa porcheria:

floor_part = (sint32_t) float_value;

Dando una rapida occhiata all'assembler prodotto negli intorni di quella riga C noto che dietro a quel casting deve intervenire pesantemente il compilatore, cosa che non mi piace nemmeno un po', anche perche' non tutti i compilatori C che ho me lo fanno, alcuni non fanno raticamente nulla e mi copiano bit a bit quanto e' contenuto in termini di mantissa ed esponenziale nei 32bit della definizione float e io mi ritrovo in floor_part qualcosa di assolutamente sbagliato.

non posso (e non voglio) permettermi il casting di un float in un uint32_t (signed long 32bit), sicche' idee, alternative ?

Ho risolto in C, giocando con i bit del formato IEEE574
mi ha aiutato moltissimo questo piccolo tool che visualizza i bit segno, mantissa, esponente
http://www.h-schmidt.net/FloatApplet/IEEE754.html

Maw il mio problema e' che alcuni compilatori interpretano correttamente il significato di casting quando lo si richiede per convertire un float in un sint32_t, mentre altri compilatori piu' sciocchi non lo fanno e ti copiano bit a bit un formato numerico nell'altro infischiandosene del significato che hanno i bit.

Se dipendesse da me farei uso di fixedpoint e buona notte come e' raccontato nel link che hai segnalato, sono piu' che daccordo, sopratutto dopo aver fatto analisi numerica in universita', dove ti fanno vedere quanti problemi saltano fuori usando il float, pero' nel mio caso:

1) sono un mero esegutore, ho una serie di requisiti che chiedono ieee574, cosi' vuole il cliente
2) ho richieste sia per cpu/dsp che sanno fare in hw ieee574
3) sia richieste per cpu/dsp softcore che di base non saprebbero fare ieee574 perche' non hanno FPU, ma che nel loro progetto sono stati dopati di steroidi e sintetizzati in fpga dando loro non solo piu' Mhz di quello che e' la versione ASIC, ma anche questa nuova possibilita' di macinare dati in floating point

e quindi il problema nasce da alcune richieste particolari del BSP per il quale il committente vuole anche una conversione float_to_sint32_t (si ora sono interessati anche al segno, prima il requisito parlava di unsigned long, uint32_t).

Per accontentarle tutti, anche i compilatori C sciocchi, ho risolto con del codice C che molto sinteticamente interpreta i vari bit all'interno del formato float e con essi ricostruisce la parte intera nel formato sint32_t

Nello specifico, facendo uso di una union {float, uint32_t}, estraggo il bit di segno, che utilizzo solo alla fine, e di li in poi considero il numero flaot come se fosse positivo, quindi estraggo i bit dell'esponente e li uso per ottenere una potenza di due in sint32_t, con un banale shift, poi aggiungo a questa base il significato che hanno i bit della mantisa a partire dal bit22 muovendomi verso destra (verso il bit0) di tante posizioni quante quelle specificate dal esponente.

Il risultato finale e' quello che volevo: la parte intera del numero float, perfettamente rappresentata in sint32_t, e nota che questa procedura lavora soltanto in sint32_t, e non necessita di alcun casting: ho potuto giustificare l'attivita' portendo utilizzare l'idea anche in ADA, linguaggio talmente tipizzato da non ammettere affatto alcun uso di backdoor come il casting sul C.



p.s.
hai messo il dito nella piaga, alcuni target sono lo squalo tigre, anche se devo dire che e' quello che "morde" di meno.