ReAl 0 27 апреля, 2012 Опубликовано 27 апреля, 2012 · Жалоба Кучу - нет. По стеку можно посмотреть его исходники, порядка 20-30 байтПолный вариант — немного больше сорока, добавляется буфер под максимально возможную длину для преобразования float. В очень старых версиях (~10-летней давности) полный вариант при наличии float-форматов выделял этот буфер через malloc. Это притянулось от какого-то распространённого варината форматтера, но быстро было исправлено. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 128 27 апреля, 2012 Опубликовано 27 апреля, 2012 · Жалоба добавляется буфер под максимально возможную длину для преобразования float.Что-то я не нашел его в исходниках. 11-байтовый плюс еще несколько локальных переменных видел, но они используются во всех вариантах. преобразование float скидывает 6 регистров на стек, плюс сами параметры printf на стек кладутся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 28 апреля, 2012 Опубликовано 28 апреля, 2012 · Жалоба Точно. Давненько я туда не заглядывал. Работает, да и ладно :-) Когда-то давно-давно, до avr-libc 1.6, как я сейчас выяснил, было #define FLTBUFLEN 40 ... #if PRINTF_LEVEL >= PRINTF_FLT int8_t decpt; char fb[FLTBUFLEN]; /* floating point buffer */ #endif остатки от форматтера, который и double умел. Сейчас они 1) жёстко урезали до float с максимум 7 значащими цифрами и написанная на ассемблере __ftoa_engine в тот 11-байтовый буфер складывает флаги результата преобразования (в т.ч. NAN) и преобраованную мантиссу, а порядок возвращает в vfprintf как число, которое там уже выводится отдельно. Итого к стеку в самом vfprintf добавляется адрес возврата при вызове __ftoa_engine и шесть байтов для сохраняемых в ней регистров. Очень хорошо (то-то я как пример 4-debug написал, так удивился, что отладочній процесс с printf-ом ест меньше стека, чем яожидал :-) ). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
