ReAl 0 April 27, 2012 Posted April 27, 2012 · Report post Кучу - нет. По стеку можно посмотреть его исходники, порядка 20-30 байтПолный вариант — немного больше сорока, добавляется буфер под максимально возможную длину для преобразования float. В очень старых версиях (~10-летней давности) полный вариант при наличии float-форматов выделял этот буфер через malloc. Это притянулось от какого-то распространённого варината форматтера, но быстро было исправлено. Quote Share this post Link to post Share on other sites More sharing options...
Сергей Борщ 186 April 27, 2012 Posted April 27, 2012 · Report post добавляется буфер под максимально возможную длину для преобразования float.Что-то я не нашел его в исходниках. 11-байтовый плюс еще несколько локальных переменных видел, но они используются во всех вариантах. преобразование float скидывает 6 регистров на стек, плюс сами параметры printf на стек кладутся. Quote Share this post Link to post Share on other sites More sharing options...
ReAl 0 April 28, 2012 Posted April 28, 2012 · Report post Точно. Давненько я туда не заглядывал. Работает, да и ладно :-) Когда-то давно-давно, до 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-ом ест меньше стека, чем яожидал :-) ). Quote Share this post Link to post Share on other sites More sharing options...
