Reduce stack usage for AES calls

[th-otto]

We already implemented the udef_* functions for some VDI functions that otherwise use too much stack space, but for AES the situation is similar. Currently the four arrays are always declared with their maximum size (16 each), which amounts to a total of 192 bytes.

I'm therefore currently experimenting with the attached patch. It also has the benefit that you automatically get warnings when eg. specifying 2 intin parameters in the macro, but then writing 3 values to the array.

What do you think?

PS.: is there a reason why github rejects attaching *.patch files?

aesp.patch.txt

[mikrosk]

I wasn't aware of __builtin_constant_p, nice. Will this work also on older compilers, at least 4.6.4?

PS.: is there a reason why github rejects attaching *.patch files?

I guess they want to encourage you to use PRs. :)

[th-otto]

Yes, it works on 4.6.4.

The error message for the attachments reads:

 We don’t support that file type. with a GIF, JPEG, JPG, MOV, MP4, PNG, SVG, WEBM, CSV, DOCX, FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PATCH, PDF, PPTX, TGZ, TXT, XLS, XLSX or ZIP.

So that should alllow *.patch?

[xdelatour]

PS.: is there a reason why github rejects attaching *.patch files?

I don' known the reason but *.patch is not in this list (GitHub Docs)

What do you think?

I've never heard of it but it would be great if it helps reduce stack usage

[mikrosk]

Btw while we are discussing compiler-specific flags/optimisations, I have found an interesting answer about the keyword restrict: https://stackoverflow.com/a/30827311/21009 ... maybe it could be used on a few places in freemint/libs?

[th-otto]

Using restrict is sometimes dangerous i think. It might enable optimizations that our code is not prepared for. For example i've seen already quite some code where someone uses strcpy(p, p + 1) in order to remove the first character of a string. Such code will actually produce garbage when strcpy is heavily optimized.

[mikrosk]

Of course, it couldn't be used in the libc functions. But maybe it would be worth looking whether there aren't some loops worth adapting (especially in some time-sensitive parts like context switching, fork() etc where a lot of stuff is copied).