Собс-но сабж.
Есть число выдаваемое прибором формата DOUBLE.
При этом в компиляторе нет этого формата , а есть float и long int;
Как пересчисчитать с потерей точности и размерности?

А как же long float ?

2ТС: что за компилятор?

Это однозначно что-то нестандартное.

Как-то так можно:

Только поаккуратней с этим кодом - я его быстро набрасал, толком не тестировал.

Спасибо за подсказки.
Сделал просто пересчётом по формулt из IEEE 754

unsigned long int r1, r2;
float r3;
r1=((((unsigned int)dob[0]&0x7F)<<4)|doub[1]>>4);
r2=(unsigned long int)doub[1]<<28|((unsigned long int)doub[2]<<20)|((unsigned long int)doub[3]<<12)|((unsigned long int)doub[4]<<4)|(doub[5]>>4);
r3=pow(-1,doup[0]>>7)*pow(2,(r1-1023))*(1+r2/4294967296.0);

PS Компилятр CVAVR - long long там тоже не реализован. Но до этого момента и не нужно было.

Он и в этом моменте не нужен. Чтобы достать старшие байты double-числа, нет необходимости прибегать к типу long long. Более того, добычка этих байт через long long сопряжена с организацией огромных сдвигов (29 и 52 разрядов), что никак не назовешь эффективным программированием.

Было бы куда проще накладывать число double не на long long, а на unsigned char v[8] или unsigned short v[4], а затем сложить float из этих байт или слов. А еще симпатичнее вместо массива объявить структуру с битовыми полями под стать double-формату. Например:

Компилятор - не дурак, он не будет сдвигать по-битно 52 раза
Поэтому никакой разницы в скорости вы не увидите, сравнивая с реализацией, использующей структуры.
Да читаемость исходников улучшиться, тут я не спорю. Но на некоторых архитектурах могут появятся проблемы с выравниваем и упаковкой...

Если у компилятора нет формата double, то скорее всего, формата long long у него тоже нет. А "приживление" к нему формата long long ничем не проще, чем приживление формата double. Отсюда и вывод, что формат long long, как инструмент, здесь не годится.

Тогда как "мудрость" компилятора в отношении сдвига обычно сводится к вызову соответствующей библиотечной функции, писаной на ассемблере, которой число сдвигов задается в параметре.

Такс. Чото туплю.
От мантисы надо взять старшие 23 бита. Соответственно от экспоненты - младшие 8?
ЗЫ Таки да - формата long long тоже нет.

Так я поэтому и поделила double-мантиссу на LO и HI, не аки как, а чтобы отделить от нее именно 23 старших бита (изначально в ней 52 бита, что в long не лезет).

Это понятно! А что с экспонентой то делать.
В дабле 11 бит, а во флоате - 8.

То что раньше делал - не влезает в long int результат умножения .
Пошёл по такому пути.

typedef struct
{
unsigned long int mantissa_lo : 29;
unsigned long int mantissa_hi : 23;
unsigned char exponent_lo : 4;
unsigned char exponent_hi : 7;
unsigned char sign : 1;
} double_format;

typedef struct {
unsigned long int mantissa : 23;
unsigned char exponent : 8;
unsigned char sign : 1;
}float_format;


union double_union
{
double_format dbl;
unsigned char b[8];
}dbl_union;

union float_union
{
float_format flt;
float F;
unsigned char b[4];
}flt_union;

Не факт. В avr-gcc появился таки long-long, а double так и нет.

2ТС: чем скорее вы переползёте с CV на avr-gcc или IAR тем раньше сможете по-настоящему расправить свои крылья.
CV - это студенческая игрушка, пригодная лишь для ознакомления с миром ембеда и не более того.

Проект запущен на CVAVR -надо допиливать. Рефакторить под IAR надо очень много.
С STM32 уже давно сижу на IAR

Таки реализовал.
Как в изначальном виде, только пришлось переделывать функцию возведения в степень.
--
Изза потери точности заинтересовался...А реально ли из дабла сделать просто текст в ASCII? Тем более временем выполнения я не лимитирован. Только размерностью переменных в 4 байта.