Moony
Moony
this is probably due to color blending. Blending colors the way TPT does it generally tends towards white.
@TChapman500 Yes, but UTF-16 strings aren't processor specific. There is genuinely two UTF16 standards, the BE and LE versions.
The problem with existing formats is that they don't exactly support custom architectures. The final object linking to an existing format makes sense, but, for example, ELF only supports 32bit...
An assembler pretty much needs to go with the old linking method of doing things. As nice as a full project system is, it's not viable here.
For now, I don't think so(?), so the best way would just be to use `0b0000_0000`, and just remember which bit is which reg which isn't too hard.
I think it's more important for things like the #str directive, which kinda need to be simple, and having to reverse the string beforehand would be annoying.
And, in general @hlorenzi, it'd be more convenient.
That is a good point, UTF8 is endianness neutral. The real issue I have is that keeping track of endianness is annoying, and more importantly, doing something like #d32 label...
end of day, an endianness directive is a pretty important addition, especially now with the ability to work on more complex architectures with v0.11. Having to utilize a workaround is...
Yep. Macros are almost always a preprocessor step, so just do that here, too.