Date: Sun, 26 Dec 2021 21:42:38 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: ASM-to-C conversion for i386 Hi all, merry Christmas, everyone. I hope you survived the various family visitations in good health and are slowly coming out of the food coma, or whatever your anual rituals are. Anyway, I found myself with a bit of time on my hands and chose to be productive for once. Rich made some noise however long ago that he wanted to move from assembly source code files to C source code files with inline assembly. So I looked at what I could contribute to that cause. This is hindered somewhat by the fact that my knowledge of assembler is restricted to x86, PowerPC, and Microblaze. And for Microblaze, it has been a while since I've used it.. For ARM and most of the others, I can get the gist, but there may be subtleties I am not grasping, and that is precisely what we cannot use for such a conversion. So I decided to start with the architecture I am most familiar with: i386. And now I am finished with the largest part of it, the maths code. That is, finished with the first pass. You can follow the progress here: https://github.com/nullplan/musl/tree/asm2c So I've converted __set_thread_area(). That was pretty straightforward once I found SYSCALL_NO_TLS. The generated assembly generated by clang 6.0.0 hits the same notes as the handwritten code, so I'm willing to count that as a win. For the maths code, I've added the likely() and unlikely() macros to libm.h. Not sure if they belong there, but they do make the generated assembly more similar to the handwritten code. Most of that code was straightforward, but some of the more complex functions I am not sure about. What is up with __exp2l()? I can see that expl() is calling it, but I'm not sure why. But its existence forced me to employ a technique not used elsewhere in the code (that I could find): A hidden alias. I vaguely recall that such hackery was rejected before (on grounds of old binutils reacting badly to such magic), but I don't really know what else I could have done. Or was the correct way to make __exp2l() a hidden function with the actual implementation and exp2l() (without the underscores) a weak alias? Anyway, the maths code suffers from massive code duplication on both assembler and C levels. Not sure what to do about it, though. In many cases, each of the three versions of a function only differ in the fine details, but clang being as inline happy as it is means that many techniques to reduce code duplication in C cause bloated object files in assembler. For example, all functions of the floor, ceil, and trunc families have been implemented in floor.c, in terms of a new static function I called "rndint()", containing the heart of what used to be at label 1 in floor.s. Unfortunately, after compiling, clang has inlined rndint() every time, so that floor.o contains all nine functions, and all functions are substantially copies of rndint(). The only solution I would see to that would have been to rename "rndint()" to something with a double underscore at the start, make it hidden and extern, and move all the functions into their own files, thus preventing inlining and making the object files more modular. Not sure how you'd like it. Also, the generated assembly tends to use more memory. It appears that clang is hesitant to overwrite memory allocated to a variable, even if that variable is currently parked in a register. Or maybe my clang version is just weird. That also explains why it sometimes emits "fld" instructions in the wrong order and then fixes the mistake with "fxch". Not a huge deal, just weird. Nothing forces the wrong order. And the order is often correct in the smaller precision versions of the same function. Many of the maths functions are testing if their argument is subnormal, and return an underflow exception if so and the argument is not zero. For the single-precision case, the idiom used was to square the input, which I have recreated with FORCE_EVAL(). For the double-precision case, however, it was to store the variable as single precision. Finally, I have also converted fenv.s today. I was hesitant to do that at first, since a general C framework for fenv is under development, but it has been quite a while since I've heard a peep from that project. In any case, since their code should overwrite all of the existing fenv code, a merge would now just lead to trivial path conflicts that are easily resolved. I believe in doing the conversion, I found a bug in feclearexcept(). The original code said in the non-SSE version (context: EAX contains the status word, ECX contains the function argument, and "1b" is a function return) | test %eax,%ecx | jz 1b | not %ecx | and %ecx,%eax | test $0x3f,%eax | jz 1f | fnclex | jmp 1b |1: sub $32,%esp | fnstenv (%esp) | mov %al,4(%esp) | fldenv (%esp) | add $32,%esp | xor %eax,%eax | ret That second "jz" confuses me. The intent seems to be to test if any exceptions remain, and use "fnclex" if not. That would make sense, since "fnclex" clears all exceptions. But since the second "jz" is a "jz" and not a "jnz", the "fnclex" path is used only if exceptions remain, and the slower "fldenv" path is used if none remain. Or am I reading this wrong? Anyway, I implemented the logic that made sense to me in the C version. What remains to be done? Well, looking at the list of assembler files, the only targets for a C conversion that remain (in i386) are the string functions. After that, it is time to clean up and submit patches. Speaking of, how would you like those? One patch for everything, one patch per directory (i.e. one for thread, one for math, one for fenv, one for string), or one per functions group (the three precisions of each function), or one per function? I don't want to overwhelm you. Ciao, Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.