Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
What would you think about an alignment option for Local variables (x64, FASTCALL)?
This would be very useful in context to SSEx instructions that requires aligned memory.
LOCAL myXmmWord::XMMWORD ; :: = align
Supplement: a new bit for the option win64 is maybe more practical than an syntax extension.
the syntax extension looks rather hackish to me. OPTION WIN64 would be no problem, but this feature isn't useful for Win64 only. Probably the best is a new OPTION STACKALIGN.
OPTION STACKALIGN sound good :-D
Would that option align according to the type's size? For arrays it can also be useful to have a grater alignment than the size of the elements (e.g. for copying the array).
Automatic 16-byte alignment of stack variables will be implemented in next release.
I choose OPTION WIN64:4 to activate this feature - despite the consideration that this feature might be also useful for non-win64 systems.
There's a Win32 test version of jwasm available that you can try: http://www.japheth.de/Download/JWasm/JWasm212bw.zip
Great, you've found a good solution by coupling the local's size with the alignment.
There is only one thing that makes me currently a bit worried and is probably subject for the documentation: under which conditions does the option applies. What I've found is that it works for automatic generated frames (option frame:auto) or if at least one of the other win64 options is used. But it seem to not work for 'plain' PROCs (no FRAME keyword, win64:4).
Also, in this context, I want to mention that it may be useful to have equates/symbols to read out the current option-settings.
EDIT: the test procedure that fails:
JWASM_STORE_REGISTER_ARGUMENTS EQU 1
JWASM_STACK_SPACE_RESERVATION EQU 2
JWASM_ALIGN16_STACK_VARIABLES EQU 4
option win64: JWASM_ALIGN16_STACK_VARIABLES
foo proc fo:DWORD
AFAICS it works for frame procs if frame:auto is set OR if option win64:2 is set. IOW, it works for those procedures where the registers in the USES clause are saved ABOVE the local variables.
Looks not very consistent at first glance, but the remaining cases are those that are also supported by ML64 - and thus jwasm can sustain Masm-compatibility.