Pardon my misreading of the code earlier, however I realize there is (I believe...) another issue I didn't think about at the time.

Char is not guaranteed to be signed. your strcmp function relies on char being signed (To implement the standard behavior)

Note that this reveals another bug relating to signed integer overflow, the actual subtraction must occur inside of unsigned char's

x86_64 uses two's complement so subtraction is semantically equivalent between signed and unsigned char, but due to language semantics and compiler UB, to get the correct behavior, you have to move the chars into unsigned variables, subtract, move back to signed variables, and return.

Even if you compile with -fwrapv (for defined signed integer overflow) you will still have to correct strcmp to use signed char explicitly instead of just char, as the standard does not specify whether or not char should be signed or not.

I had a lot of fun reading your code and I want to thank you for it. It was very enjoyable and educational.

1. Undefined behavior. Obsessive use of double underscore names is the least of it, implicit pointer integer conversions and mixed signed/unsigned... I shudder to think about it. Maybe you copy-pasted it from somewhere, or OSdevers told you it was a good idea?

2. Extremely bad symbol names. you export a variable called "initialized". Need I say any more?

3. Bugs. There are two at work here, one is obvious (test case: any negative number), the other is evil:

(I believe there's actually a third bug in the itoa function that I figured out while looking at your other code, but I'm not confident in it.)

Oh, the fun you'll have debugging this one if it ever shows itself. You probably won't. Please don't put this in production code, I almost missed it myself. (EDIT: This one is actually a multi-headed beast. The other heads are less fearsome but far cleverer)

4. Coding conventions that look like obfuscation techniques

I suspect you copy-pasted this from somewhere. Also, there's at least 2 bugs. They're very trivial and you'll find them immediately.

EDIT: there is a secret evil bug that isn't showing itself due to the set of compiletime constants you chose. I thought this one was trivial but no, it's got some evil.

I mentioned this function before. I'd call it exceptionally bad to have a pre-declaration outside of your headers. The function prototype being alone like this should help you figure out the other bug (No, not the negative number one).

I spent a while researching the issues you were having with debugging and optimization, "field optimized out"

You have to keep in mind, that "Field optimized out" is sort of what you want to happen. Variables being eliminated is part of the beauty of optimization.

If you really don't want your variables to disappear... I already told you about the volatile variable trick, that's the oldest trick in the book, however it will defeat a large part of the point of optimization. You want things to get eliminated.

1. Don't use GDB, use printf's (Or in your case, putul/putd/puts) as that guarantees that variables cannot be wholly eliminated at compile time. Failing that, write it out to a volatile global variable as that will do the same thing. I know that might sound stupid to you, but I speak from experience, using printfs will help you track down the location of UB and compilation bugs much faster than GDB. Debuggers are overrated.
2. Try to eliminate as much assembly as possible. I noticed you wrote memcpy and memset in assembly... as long as your memcpy and memset implementations don't compile such that they invoke memcpy or memset, then you don't need to worry. I Know that C compilers require memcpy to be implemented, but you can get around that really easily with a bootstrap (Use a memcpy and memset to compile a new memcpy and memset, which is then used in your project). This is important because you may be able to write a more optimized memcpy that operates based on aligned 16/8/4/2/1 byte movs, which you can of course write in assembly, but it'd be hell. You're requiring SSE2, so there's no reason not to. Yes, I believe using optimized loads and stores in a memcpy implementation is important.
3. Try -Os or -Oz (Clang only)... you might be surprised. They're equivalent to -O2 but with some things turned off and extra stuff turned on for more compact bytecode.
4. -mtune=native, it's like -march=native but without the low portability downsides.
5. https://llvm.org/docs/BranchWeightMetadata.html

Please pardon the fact that this isn't actually an issue.

void* skylight_memcpy(void* restrict __dest, const void* restrict __src, size_t __nbytes){
	size_t __i = 0;
	for(;__i<__nbytes;__i++) ((unsigned char*)__dest)[__i] = ((unsigned char*)__src)[__i];
	return __dest;
}

Tell me if you see any bugs. I tested it a little bit and I didn't see anything. This also functions as a memmove implementation... if you remove the restrict qualifiers from the pointers.

Note that this is not a particularly efficient implementation as this will do byte-by-byte copies, the most efficient copying would work in the largest power of two subset of the source which fits into a register. But this works for now

I donate this code to you under the CC0 license and permanently waive all my copyright attachments to this code so that it may be contributed to your codebase and not interfere with its licensing.

0. Thanks for fixing those bugs I told you about.

1. I've made some comments on your commits, I didn't spot any critical bugs, but I spotted several bits of... "unusual" practice.

2. You should be aware that pointers on most x86_64 machines have a special property... the 48th bit is repeated through the upper quarter of the integer. The pointers are actually only 48 bits (bits 48-63 are repeats of bit 47, if bit 0 is the first bit) When you discard the pointer type and use uint64_t, the type system can't preserve this intriguing fact.

I didn't spot anywhere in your code where this fact would give you a bug, but you're intentionally punning away pointer classification to uint64_t which I foresee down the line is gonna cause issues for this very reason. This is also just bad practice.

HUGE NOTE: this 48 bit property is NOT in the spec for x86_64 it is merely a fact for x86_64 arches we have today. the spec says those other 16 bits can be used in the future... so don't go storing your pointers in 6 bytes for efficiency either.

a pointer will be 8 bytes and you don't need to worry about the compiler ruining your packed structs. No, the compiler won't remove the unused 16 bits (... if it does, then please tell me, that would be a very interesting bug report...)

3. You should know that void pointer arithmetic is a gnu extension. I know you said you only ever compiled with clang, but believe me, you will most likely regret this decision later.

4. You can have a struct with a member pointer to itself (In the standard)

typedef struct myStruct{
    struct myStruct* next;
    struct myStruct* previous;
    unsigned char data;
} myStruct;

This is valid C syntax. I think it's even in the C89 standard as an example for implementers (iirc) so every compiler on earth will do the right thing.

Your puts implementation lacks newlines or carriage returns (\r\n) here's the fix

serial_terminal_t* puts(const char* s) {    
    serial_message(s); 
    putc(0xa);
    return putc(0xd);
}

Unknown if you intended this, though.