News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

HJWasm 2.15 uploaded

Started by habran, September 05, 2016, 09:14:38 AM

Previous topic - Next topic

johnsa

I've uploaded this change, give it a try.

You can now use @ProcLine or @Line (just use it inside the IFDEF) and it should work out totally MASM compatible and HJWASM.

Cheers
John

jj2007

Quote from: johnsa on September 07, 2016, 07:29:00 AMso can you help me understand why you need the line number at time of prologue execution == the proc line ? (maybe it will help decide how best to change it)

Thanks for providing a ML compatible solution. The reason why I am using this is a bit complicated: The jinvoke macro can produce 64-bit code in two ways,
- by pushing 4 times args and dummy args
- by moving args into their stack locations

The switch is the cs in the prolog macro's userparms, i.e.
WndProc proc <cb cs> uses rsi rdi rbx hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
LOCAL ps:PAINTSTRUCT
  cmp uMsg, WM_CREATE
  jne not_create


cs stands for "compiler style". If the prolog macro sees cs, it allocates stack for all jinvokes that follow and sets a flag; if not, the jinvoke macro must create the 4*QWORD stack every time.

To achieve this, prolog contains jbCompStyle INSTR <userparms>, <cs>

Now, the only problem is that this variable, meant for jinvoke, is not yet set if, and only if, jinvoke is the first command after the LOCALs. Therefore I wanted to check, in jinvoke, if it is the first command, and force an error ("put a nop before jinvoke") if that is the case.

Now this is the reason behind the wish to have ML compatibility. What strikes me, though, is that this check regards the last Local line, not the proc line - which is closer to the Watcom behaviour than to ML ::)

I know this is a very exotic request, so don't take it too seriously :P