går det att skriva en c-kod-algoritm som enkelt växlar mellan att vara double/float?

Aha, det snappade jag ju inte. Jag tog fram de militära exemplena pga att de är typexemplet på tunga beräkningsalgoritmer som måste gå fort. Och feltoleransen är liten.
Tänkte att mina utvikningar om att flyttalsberäkningar inte är så självklart som man kan tro kanske intresserar den allmänt intresserade datornörden här
Nu har ju inbyggda system, sk embedded systems blivit ett så generellt flytande (floating ) begrepp att det även innefattar kompletta 64-bitars datorer i sk kluster. Ett inbyggt system brukar menas att det inte har någon direkt användarinteraktion, tex mus, pekplatta, skärm ja, IO-enheterna är ibland bara begränsade till typ nätverksinterface.
Så jag är inte hemma på vad du försöker sno ihop för programvara.
Ursäkta svamlet om kineser med kulramar men det är ett (gammalt) standardskämt i den tekniska världen.
Du refererar i trådstarten till den här artikeln:
https://www.geeksforgeeks.org/catch-...nversion-in-c/
Vilket inte säger mig ett dugg, tyvärr. Det är typ standard test av exception, inte något med skillnaden mellan 32-bits floats och 64-bits doubles för någon FPUs hastighet.
Är du säker på att 32-bits float räcker så är det bara att köra på det ju.
Tänk dock på att felpropageringen kan bli betydande redan efter ett (litet) antal float operationer.
Du sätter ju parametrarna i kompilatorn att den ska kompilera för en 32-bits CPU.
Men tycker att din FPU bör utan vidare klara av 64-bits doubles.
Och det med god hastighet.
Jag har ju ingen aning om hur fort det måste gå, det handlar ju om att du måste veta på ett ungefär om du kan tåla de extra mikrosekunder det kan handla om.
Inne i CPU/FPU/GPUn sker allting mycket fortare än det du kan se på skärmen.
Grafiken på en vanlig skärm är väl ungefär 1-10 miljoner gånger långsammare än vad som händer inne i en vanlig PC-CPU på 3 GHz.

Din CPU/FPU-modell ska ju ha specifikationer kring sådana flyttalsoperationer och hur snabb den är.

Det är ju klart att om du bygger ett robotpar som ska kunna spela bordtennis mot varandra så vill det till att de kan räkna fram bollbanan fort, förstås.
Ursäkta att jag skrivit ur ett generellt övergripande perspektiv, men du får själv prova dig fram, tills du har något som är körbart.
Om du nu pratar om ett styrsystem, tex en robot så är rörelserna så långsamma att om du räknar floats eller doubles det bör inte ha någon betydelse. Om det nu inte är en jäkligt långsam CPU/FPU du har, typ...

Här står det om tex Raspberry Pis (ett vanligt "inbyggt system") prestanda på flyttal:
https://stackoverflow.com/questions/...oint-operation
Raspberry Pi 3 står sig mycket bra och hinner klara av 1 miljon flyttalsoperationer på 0,013 millisekunder, vad man kan lära sig av diagrammet.
Här finns en utläggning om doubles jämfört floats och 32-bit float kan tvärtom gå långsammare eftersom chipet måste konvertera i varje steg, tyvärr:
https://stackoverflow.com/questions/...hich-is-faster

Eftersom jag inte vilken FPU som sitter i ditt inbyggda system så är frågan om floats eller doubles en fråga som jag inte kan svara på.
Du måste helt enkelt mäta själv, om du inte hittar någon spec kring din CPU/FPU som kan klargöra detta. Du måste också ta reda på vilka flaggor, switchar som ska sättas på kompilatorn för att programet ska bli körbart på just din CPU/FPU-modell.

Och x87- serien av FPUer använder 80 bitars sk extended doubles hela tiden (internt):
https://stackoverflow.com/questions/...ecision-number
Och förklarar att 32-bits floats kan gå långsammare pga konverteringssteget ifrån 80-bits till 32-bits.
Det är därför man har dissat 32-bits floats i de flesta vanliga sammanhang.

Här finns en mycket fyllig artikel om flyttal och dess fallgropar, och sett ur ett vetenskapligt perspektiv. Den tar även upp sådana udda frågor om flyttal i andra talsystem än de binära eller decimala:
https://docs.oracle.com/cd/E19957-01..._goldberg.html
Artikeln är mycket teoretiskt lagd. Och är väl överkurs för de som inte vill dyka ner i det numeriska träsket. Men som ändå har mycket stor betydelse för vetenskapliga framgångar.
Anledning till att använda binär representation av flyttal är att det är den allra snabbaste metoden att genomföra sådana operationer.
Men i tex handhållna miniräknare så används istället i allmänhet en variant av decimalrepresentation. Den vanligaste är tex BCD, Binary Coded Decimal, dvs fyra bitar representerar siffrorna 0-9. Och som mest används i ekonomiska system. Där kronor och ören måste gå jämnt ut.

BTW: Ursäkta för OT, återkom gärna med vad för CPU/FPU du utvecklar på. Är inte säker på att jag ids och har tid att svara på fler frågeställningar dock. Och regel nr 1 mät först och optimera sedan. Går ditt program för långsamt för en PC, ja då är det nog inte så mycket bevänt att kompilera om det för ett inbyggt system med ännu sämre prestanda. Du måste ha plats i minnet för dels ditt program, eventuellt OS, plus allt minne du behöver allokera.
Vad som dessutom gäller för inbyggda system är att de är svåra att debugga. Särskilt realtidssystem, där svarstider är kritiska osv. Och om det finns tex asynkrona enheter mm.
Debugging måste ske med andra tekniker än de som vanligen lärs ut.
Istället så skriver man gärna en emulator (simulator) på en PC som efterliknar ditt inbyggda system. En emulator, dvs en programvara som speglar det inbyggda systemet på ett realistiskt sätt, kan debuggas som vanligt.

Se C11 och _Generic: https://en.wikipedia.org/wiki/C11_(C_standard_revision)

På Wikipedia ges ett exempel.

För tydlighets skull så rättade jag länken i ditt citat. När du klistrar in en url i Flashbacks så får man se till att ifall länken avslutas med ett parentestecken så kan det bli fel. Url taggen kommer då att ibland expanderas till [ /url ] ) Parentestecknet hamnar efter avslutningen på url taggen.

https://en.wikipedia.org/wiki/C11_(C_standard_revision)

Testa att klistra in länken och tryck på Förhandsgranska inlägg, så ser du sedan i din inläggstext att slutparentesen hamnar utanför url taggen

Vet ju inte vad TS vill göra för slags program. Men en version av programmet ska köras på PC jag förstått. Den andra ska köras på ett inbyggt system, som vi inte vet så mycket om. Det blir alltså två olika target OS och/elr CPU-modell som koden ska kompileras för.
Det blir alltså två olika versioner ändå.
Så jag gissar att TS får skapa två (nästan likadana) källkodsfiler ändå.
Som sagt vet vi inte vilken miljö programmet ska köras i så är det svårt att ge tips om det behövs double eller float.
Om det rör sig om ett styrsystem så bör ju skillnaden i tidsåtgången mellan float resp double operationer vara helt försumbar. Eftersom ställtiden för styrenheterna brukar ju handla om sekunder typ.
Den text vlkmslf hänvisar till är ju ett macro som expanderas olika beroende på om typen som macrot anropas med är long double eller float.

Det är ju riktigt att annars generellt sett så kan man skapa snabbare kod om det rör sig om egna varianter av 32-bits float numeriskt format. Tex speciellt grafik osv, men sådan kod skrivs ju vanligen i assembler, där man måste skriva den specifikt för just den CPU/FPU-typen.

Som de länkade artiklarna i föregående inlägg jag lagt upp så är x87-serien av FPUer som ingår i alla Intels CPUer från och med 486-serien så har de utmärkt float-prestanda.
Och när jag då skriver float i den meningen så är de alltså 80-bitars extended double (precision). När man pratar om float (flyttal) rent allmänt så kan man avse vilket flyttalsformat som helst, enligt de länkade artiklarna.

Men om TS anser att 32-bits float duger för sitt ändamål så är det ju bara att köra på det.

Men redan ett uttryck som X = x1 * x2 * x3 * x4 * x5 * x6 * x7 ger ett förhållandevis stort fel med bara 7 signifikanta siffror (32-bits floats) i varje steg. Det är därför man har dissat 32-bits float sedan ganska lång tid tillbaka i de flesta sammanhang.

tanken är att programmet ska kunna användas allmänt mot olika inbyggda system, men särskilt intressant är fordonsindustrin.

Här är ett exempel på vad jag stöter på när jag läser om double/float i denna industri:


http://support.openecu.com/Floating%20point

Liknande info från andra aktörer.