Not all that useful and the code quality is mediocre. gas has macros to reduce boilerplate to nearly nothing. String primitives have already been written in portable C with one liners (see Klee on github). Assembly should only be for things primitive bootstrapping, really weird alignment issues (such as to avoid F00F) or crazy but necessary tricks like stackless operation. Higher level is your friend, low level is "I have a hammer" job security. (I know the area around p. 1800-2200 of the Intel IA-32 manual too well, I'll probably never forget PDE and PDT layouts, GDTR-null self-hosting.)
A more interesting trick of exokernel frameworks would be to provide a consistent interface across platforms such as video, input, storage and threads made easily accessible like QNX and others have done.
I'd be happy to hear your suggestions for improving the code. I've done lots of assembly programming and firmware development over the years, but rarely on x86, and this project was the first time I've used the GNU assembler. It was a learning experience, and that's part of the reason I decided to share it.
I actually wrote parts of this library in C at first, but ported them down to assembler once I got them working, because it felt more elegant to divide my project cleanly into a 'runtime' library written in assembler and a 'kernel' program written in C. A matter of taste, I suppose. The use of assembly doesn't really create a maintenance burden as the target architecture isn't changing and the library already does everything it needs to.
A more interesting trick of exokernel frameworks would be to provide a consistent interface across platforms such as video, input, storage and threads made easily accessible like QNX and others have done.