Is there such a thing as a good low-level language?

At work, I occasionally have to do some low-level bit-fucking. I do it in C, and so does everyone - it's the de facto standard language for doing this sort of thing. and not to get into a mental midget-kun tier C hate but the more I do bit-fucking in C the more I notice its flaws when it comes to bit-fucking.

but this is not the thread about complaining about C's shortcomings. my question is: is there an actual programming language (other than some specific assemblers, but this isn't ideal because I'd need to write a lot of code to support different OSes and architectures) that is good for those kinds of things? I mean supporting things like:
- variables with programmer-specified number of bits; I don't mean just uint8, I mean 3-bit, 4-bit, 5-bit etc.
- direct access to specific bits in the variable's binary representation - bitmasks and shits may be how people achieve this but isn't it a bit of a hack? why not accessing bits the way you access bytes
- variable-length integers (like Exp-Golomb) as a native data type - would be useful in codecs because e.g. H264 uses them
- instructions like circular shifts (often used in crypto) being directly supported instead of compiler folding your logical shifts and ORs into them - 'some architectures don't have this instruction' is a bad argument against this; some architectures don't have mul and yet C has * for multiplication instead of folding looped additions into one
- explicit support for vector processing - see above for why 'compiler will fold your code into one' is stupid
- inlining being a command, not a suggestion
- standards-defined way to use inline assembly (I'm not sure that C doesn't have it, I don't remember if it's da standard or GNU shit)

>>1
Bitfiels, and...

instructions like circular shifts (often used in crypto) being directly supported instead of compiler folding your logical shifts and ORs into them - 'some architectures don't have this instruction' is a bad argument against this; some architectures don't have mul and yet C has * for multiplication instead of folding looped additions into one

Rolling your own, like >>13-san, will usually produce a rotate instruction for a somewhat optimizing compiler. Unfortunately no infix then...

explicit support for vector processing - see above for why 'compiler will fold your code into one' is stupid

<xmmintrin.h>?
for(int i = 0; i < 4; ++i)?

inlining being a command, not a suggestion

There's some extensions to force this but most compilers will do what you want with static inline. Or with a macro.

standards-defined way to use inline assembly (I'm not sure that C doesn't have it, I don't remember if it's da standard or GNU shit)

asm("implementation-specific"); is *almost* standard.



#include <stdint.h>
#include <limits.h>

static inline unsigned rotlu(unsigned x, unsigned n) {
const unsigned width = sizeof(unsigned) * CHAR_BIT;
return (x << n) | (x >> (width - n));
}

int main(int argc, char **argv) {
union {
unsigned u;
int i;
} x;
x.i = argc;
x.u = rotlu(x.u, 7);
return x.i;
}

will produce for x86 on gcc -O3:

main:
mov eax, edi
rol eax, 7
ret