Would it be possible to somehow reduce stack requirements?

[FreddieChopin]

Compiling the code with -fstack-usage shows that some of the functions use a lot of stack - for example ufat_dir_find_path() is the most stack-hungry one, using 848 B (note - values for x86_64, but for an embedded MCU they are more-or-less similar) and ufat_dir_read() requests 672 B. But here's the problem - ufat_dir_find_path() calls ufat_dir_read(), so any call to ufat_dir_find_path() requires almost 1.5 kB of stack.

I noticed that the majority of this usage comes from ufat_dir_find_path() having a char name[UFAT_LFN_MAX_UTF8]; buffer (768 B) and then ufat_dir_read() having struct ufat_lfn_parser lfn; which internally has uint16_t buf[UFAT_LFN_MAX_CHARS]; (510 B).

This made me wonder, whether there's an option to somehow reduce this amount? I don't know much about FAT internals and LFN, so I'm asking what options are possible and what things have to stay that way and cannot be changed.

• Maybe a configuration option (#define) would be possible, which would disable USC2 / UTF-8 conversions, leaving only ASCII values valid - this would maybe allow UFAT_LFN_MAX_UTF8 to be 255 instead of 3 * 255? Or maybe I could just redefine UFAT_LFN_MAX_UTF8 to 255 and this would give the same (or similar) effect?
• Would it be possible to parse LFN "in-place"? Basically - would it be possible to parse USC2 to UTF-8 in ufat_ucs2_to_utf8() in-place (possibly in reverse or in two passes?) instead of from one buffer to another?
• Any other ideas? (;

I'm asking this because uFAT code in my project (wrapped in some layers) does NOT work with 4 kB of stacks, which I personally consider "a lot", so I wondering whether this can be somehow reduced.

[dlbeer]

On Thu, Sep 12, 2019 at 11:30:46PM -0700, Freddie Chopin wrote: Compiling the code with `-fstack-usage` shows that some of the functions use a lot of stack - for example `ufat_dir_find_path()` is the most stack-hungry one, using 848 B (note - values for x86_64, but for an embedded MCU they are more-or-less similar) and `ufat_dir_read()` requests 672 B. But here's the problem - `ufat_dir_find_path()` calls `ufat_dir_read()`, so any call to `ufat_dir_find_path()` requires almost 1.5 kB of stack. I noticed that the majority of this usage comes from `ufat_dir_find_path()` having a `char name[UFAT_LFN_MAX_UTF8];` buffer (768 B) and then `ufat_dir_read()` having `struct ufat_lfn_parser lfn;` which internally has `uint16_t buf[UFAT_LFN_MAX_CHARS];` (510 B). This made me wonder, whether there's an option to somehow reduce this amount? I don't know much about FAT internals and LFN, so I'm asking what options are possible and what things have to stay that way and cannot be changed. - Maybe a configuration option (`#define`) would be possible, which would disable USC2 / UTF-8 conversions, leaving only ASCII values valid - this would maybe allow `UFAT_LFN_MAX_UTF8` to be 255 instead of 3 * 255? Or maybe I could just redefine `UFAT_LFN_MAX_UTF8` to 255 and this would give the same (or similar) effect? - Would it be possible to parse LFN "in-place"? Basically - would it be possible to parse USC2 to UTF-8 in `ufat_ucs2_to_utf8()` in-place (possibly in reverse or in two passes?) instead of from one buffer to another? - Any other ideas? (; I'm asking this because uFAT code in my project (wrapped in some layers) does NOT work with 4 kB of stacks, which I personally consider "a lot", so I wondering whether this can be somehow reduced.

Hi Freddie, It's been a while since I worked on the LFN stuff, but I think the in-place parsing idea is something worth exploring. I'd say you could probably eliminate those buffers without losing any functionality. If you had some functions that could be given a pointer to a UTF-8 string and were able to sequentially pull out chunks of 8.3 packed data, and tell you in advance how many chunks would be produced, then I think you could use that for both matching and allocation of user-specified strings, without needing to assemble the whole filename in a big stack-allocated buffer. The original application for this was a bootloader in an OMAP3530 with plenty of RAM, so I didn't worry too much about stack at the time! Cheers, Daniel

…

-- Daniel Beer <dlbeer@gmail.com> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B