HASM 2.32 Release

[johnsa]

I've  uploaded a pre-release of 2.34 which now has full BND/MPX support.

OPTION BND:ON/OFF has been added to generate bnd call for invoke.
BND prefix is support for call/jmp/ret/retn/Jcc

link: www.terraspace.co.uk/uasm64.zip

test piece:

Code Select Expand


; Intel MPX Test-Piece

option casemap:none
option stackbase:rbp
option win64:7

option bnd:on ; Enable automatic generation of BND on invokes.

testProc PROTO aPointer:PTR

.data

bndStore0 dq 0,0

.code

testProc PROC aPointer:PTR

bnd ret
testProc ENDP

main PROC
LOCAL myBuffer[100]:BYTE

; Create two bounds.
; lower bound is stored as is in the BND0 register, the upper value RCX is size-1 and stored in 1s complement.
lea rax,myBuffer
mov rcx,99
bndmk bnd0,[rax+rcx]

lea rax,myBuffer
bndmk bnd1,[rax+99]

; Verify the bound move operations between registers and oword sized memory.
bndmov bnd2,bnd0
bndmov bndStore0,bnd1
bndmov bnd1,bndStore0

; Verify the bounds of the pointer in RAX pre-write for a dword sized write.
; CL (check lower bound uses the pointer value itself).
; CU (check upper uses the pointer + size - 1).
lea rax,myBuffer
bndcl bnd0,[rax]
bndcu bnd0,[rax+3]
mov dword ptr [rax],ecx

; Test OPTION BND via invoke
invoke testProc, rax

; Test BND call.
mov rcx, rax
bnd call testProc

; Test BND jmp/jcc
mov rcx,10
;bnd jmp firstLabel

firstLabel:
dec rcx
bnd jnz short firstLabel

; Test invalid prefix on opcodes that don't allow BND
;bnd mov rax,[rax]
;bnd iretq
;bnd cmp rax,rbx

ret
main ENDP

end main


[aw27]

I've  uploaded a pre-release of 2.34 which now has full BND/MPX support.

I have tested in the 32-bit chkstk and it assembles and runs fine. I will test later this test piece.

[aw27]

There is a "somewhat unexpected" problem:

This code:
bnd jb short cs20
mov eax, ecx
xchg esp, eax
mov eax, dword ptr [eax]
mov dword ptr [esp], eax
mov eax, esp
add eax, 4   
bnd ret
cs20:

Assembles with UASM to:
004FC857 F27210           repnz jb $004fc86a
  004FC85A 8BC1             mov eax,ecx
  004FC85C 94               xchg eax,esp
  004FC85D 8B00             mov eax,[eax]
  004FC85F 890424           mov [esp],eax
  004FC862 8BC4             mov eax,esp
  004FC864 83C004           add eax,$04
  004FC867 F2C3             repnz ret

and with MASM to:
004FC857 F2720E           repnz jb $004fc868
  004FC85A 8BC1             mov eax,ecx
  004FC85C 94               xchg eax,esp
  004FC85D 8B00             mov eax,[eax]
  004FC85F 890424           mov [esp],eax
  004FC862 8BC4             mov eax,esp
  004FC864 83C004           add eax,$04
004FC867 C3               ret   

MASM does not convert the bnd ret.
But when I run the UASM assembled code, it hangs occasionally, the MASM assembled does not hang.

The obvious reason is the "ret", because everything else is equal. Well, not exactly, there is a difference in the bnd jb short cs20 encoding as well.
May be you can find an explanation.

[johnsa]

That is really odd, I can think of NO reason why the bnd ret should not be encoded as F2 C3, According to MPX spec all near returns should a) support bnd and b) if used as bnd ret should be encoded as F2 C3, or F2 C2 (imm16)!

And given that MPX promises that any use of BND would result in effectively NOP on non-supporting processors whether present or not it shouldn't ever make it hang... I assume you're testing on a non-mpx processor?

[aw27]

That is really odd, I can think of NO reason why the bnd ret should not be encoded as F2 C3, According to MPX spec all near returns should a) support bnd and b) if used as bnd ret should be encoded as F2 C3, or F2 C2 (imm16)!

And given that MPX promises that any use of BND would result in effectively NOP on non-supporting processors whether present or not it shouldn't ever make it hang... I assume you're testing on a non-mpx processor?

Even more weird is that Visual Studio (2015 is the latest version I have here) does not compile programs with the same chkstk whose source code they supply, it compiles with a version of chkstk that does not contain the MPX instructions.
No, I don't have any computer with a mpx processor.

[johnsa]

I've been trying to test the opcodes under SDE (which should emulate them perfectly, but their behaviour is very odd, sometimes the bnd jmp crashes, sometimes not..)
Maybe this is too cutting edge! 

[aw27]

At least in 32-bit (not tested yet in 64-bit)
.data
align 32

Does not produce an error as it does in MASM, and 50% of the time will work due to pure coincidence.
I was believing it worked but it was only my good star.

Currently, the only guaranteed way to align data to 32-bit is, as mentioned in another thread, is through the old way:
_DATA1 SEGMENT ALIGN(32) FLAT 'DATA'

_DATA1 ends

I suggest that you either fix it or produce an error.
Since ".data" aligns to paragraph by default may be you can use ".data 32", ".data 64" to align to 32, 64 etc bytes.

[Raistlin]

On the subject of memory alignment - are there any good articles out there
describing the effects & mitigation (besides what can be pragmatically detected
through trial and error / experience) ? 

[aw27]

On the subject of memory alignment - are there any good articles out there
describing the effects & mitigation (besides what can be pragmatically detected
through trial and error / experience) ?

Nothing that I am aware of.

[jj2007]

At least in 32-bit (not tested yet in 64-bit)
.data
align 32

Does not produce an error as it does in MASM, and 50% of the time will work due to pure coincidence.
I was believing it worked but it was only my good star.

Currently, the only guaranteed way to align data to 32-bit is, as mentioned in another thread, is through the old way:
_DATA1 SEGMENT ALIGN(32) FLAT 'DATA'

_DATA1 ends

Thanks, José - you found it :t (where, btw?)

Short version, tested with ML 8.0 onwards (6.14 and 6.15 don't like it):

Code Select Expand

include \masm32\include\masm32rt.inc ; plain Masm32
MbData SEGMENT ALIGN(32)
myvarA dd ?
align 32
myvarB dd ?
MbData ENDS

MbData SEGMENT
align 32
myvarC dd ?
MbData ENDS

.code
start:
  mov eax, offset myvarB
  sub eax, offset myvarA
  print hex$(eax), "h bytes difference B-A", 13, 10
  mov eax, offset myvarC
  sub eax, offset myvarA
  inkey hex$(eax), "h bytes difference C-A", 13, 10
  exit
end start

OPT_Assembler mlv10
OPT_Linker linkv614

Replace 'MbData' with your own name. Note the combination of a recent ML version and a very old linker. This works for almost everything except the very old assembler versions.

[johnsa]

I've never test align 32 under 32bit to be honest, it's always worked flawlessly for me on 64bit. I would think, that each section would be loaded into memory by the OS loader on page boundaries (4096).
This will need some investigation.. I suspect emitting an error using align 32 under 32bit mode is probably the easiest solution unless there is a better fix to force 32 alignment on the .data and .data? simplified directives.

[aw27]

Thanks, José - you found it :t (where, btw?)

I just remembered that .data is a "simplified directive".

[johnsa]

According to the documentation on LINK, the default section alignment is page (4096), but can be set with /ALIGN .. that might be something to check?
I'd be curious to see what your section alignments are by default (depending on the version of linker you use etc), perhaps try PEDUMP and have a look ?

It really should be 4096, in which case align 32 should be fine.

[TWell]

With:

Code Select Expand

MbData SEGMENT ALIGN(32) ALIAS('.data')
myvarA dd ?
align 32
myvarB dd ?
MbData ENDS
we can also test linkers how those combine sections.

EDIT: ml v10 accept this:

Code Select Expand

Data_ SEGMENT ALIGN(32) 'BSS' ALIAS('.bss')
foo1 dd ?
align 32
foo2 dd ?
Data_ ENDS


EDIT: since ml v8 seems to be possible to make a linker friendly static lib from one file for polink.exe:

Code Select Expand

.386
_TEXT1 segment flat align(32) 'CODE' ALIAS('.text')
foo1 proc
ret
foo1 endp
_TEXT1 ends
_TEXT2 segment flat align(32) 'CODE' ALIAS('.text')
foo2 proc
ret
foo2 endp
_TEXT2 ends
end


[aw27]

According to the documentation on LINK, the default section alignment is page (4096), but can be set with /ALIGN .. that might be something to check?
I'd be curious to see what your section alignments are by default (depending on the version of linker you use etc), perhaps try PEDUMP and have a look ?
It really should be 4096, in which case align 32 should be fine.

We are concerned with the default data alignment within a section not the whole section itself. The default is paragraph (16 bytes). To change that behaviour we can not use the simplified directive, or it appears so. I am talking about 32-bit. I have not checked 64-bit, I can just believe what you say.