bug regarding spurious address size override prefix being emitted

[zaydlang]

i ran into a weird issue where the following code:
mov(dwordPtr(rdi, 0x10), esi)

erroneously produces the following assembly:
mov DWORD PTR [edi+0x10],esi

I assume it's related to this line of code (and similar lines of code to it) that you have around the codebase:

if ((X64 && dst.size != 64) || dst.size != 32)
                        buffer = 0x67~buffer;

this if statement will trivially fire if dst.size == 64, which is probably not what you want

anyway... i know ive kinda waltzed in here and started putting up issues. lmk if i should continue, and if so, ill post any other bugs i find while integrating this library in my project

[cetio]

I was not anticipating this project to be used just about anywhere really, the fact you intend on using this code is both disconcerting and greatly startling to me. Alas, for thine prospects merry, I shall pay heed in hesitance and forthwith changes hence be made.

You're welcome to make issues or contributions, I don't mind, but this project isn't particularly maintained; not that I mind the idea of maintaining it.

My library Tern is far better maintained and I highly recommend it if you find yourself needing better standard library stuff, issues on there would be appreciated since it's more maintained.

[zaydlang]

yup ill take a look at Tern, some of the memory utilities youve got going on there look pretty appealing :D

i think ill upstream some work on this later when i've finished integrating it into my existing project. i used to use another emitter, xbyak4d, which is a rewrite of the C++ library xbyak in D. however, xbyak makes heavy heavy use of classes + inheritance, and in D, these are allocated on the heap. so when I tried to use xbyak4d, literally 85% of my program runtime was in malloc, and 15% in the rest of the codebase. i dont think 85% of a jit's runtime should be spent mallocing stuff, lol

sure, you could use scope to force a class to be allocated on the stack, but that didn't cleanly work for a lot of areas of the xbyak4d codebase. so i decided to ditch it and find another emitter. yours seems to have a very fast compilation speed, so yeah, that's why i chose to go with yours :)