On Tue, 15 Aug 2023 at 18:31, Andrew Fish via groups.io <afish=apple....@groups.io> wrote: > > > > > On Aug 15, 2023, at 8:39 AM, Pedro Falcato <pedro.falc...@gmail.com> wrote: > > > > On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via groups.io > > <afish=apple....@groups.io> wrote: > >> > >> Chao, > >> > >> From a quick google it looks like CSR* is used to access banks of > >> registers that relate to things like performance counters and debug > >> infrastructure and the number of banks of these register sets is likely > >> implementation defined. Seems like we could introduce some Fixed At Build > >> PCD values that define the maximum number of elements in a given bank. > >> > >> If we are forced to use assembler it might be possible to write some > >> macros that used the fixed at build values to only generate functions for > >> banks that are needed for a given build. Then I think it becomes an > >> exercise in dead code stripping the assembler. Most compilers generate > >> assembler that contains functions that can be stripped as long as those > >> functions follow certain rules. > >> > >> As a side note it would be good for us to have an FAQ/Wiki entry for the > >> dead code stripping rules for the various flavors of assembler. I know the > >> Apple assembler has a unique take on this. > > > > FWIW, I'm almost positive there's no DCE in GNU as (or llvm-as as > > well). Unless you use something ffunction-sections > > -fdata-sections-like, but then you're relying on the linker + > > gc-sections to take care of it, just like GCC/clang would. > > > > I guess I usually think of DCE as a linker job, since the linker knows the > functions that are NOT called. At least from the Apple tools the DCE has the > same rules if you are using Link Time Optimization or not. It is basically a > flag in the object that tells the inker it is OK to follow the DCE rules > around labels and remove stuff. > > Worst case it seems like we could have macros that generate assembly files > based on build time constants so we have one function per file. This might > take a tweak to the build system, but I’d rather do that than have library > functions that magically turn on Self Modifying Code. > > Regardless of the answer I think documenting the rules is a useful exercises > since needing to save size in firmware images is not an uncommon task. >
There is already prior art in MdePkg where code targeting both GCC and VS uses inline asm, so I don't see why we would make our lives difficult and deviate from that for LoongArch. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107771): https://edk2.groups.io/g/devel/message/107771 Mute This Topic: https://groups.io/mt/100751724/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
