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 [email protected] http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B