locals...endl macro

Index > Macroinstructions > locals...endl macro

Author

Thread

Byte

Joined: 21 Mar 2026
Posts: 24

Byte 27 Apr 2026, 18:53

fasm for DOS
Code:

Code:

org 100h

use16

include '..\inc\proc32.inc'


stdcall test1, 16

enter_loop:
  mov  AH, 10h             ;
  int  16h                 ;
  cmp  AL, 0Dh             ; read key code and compare with 'enter'
  jne  enter_loop


proc test1, r:WORD
  locals
    pi   DW  314
  endl

  push ax dx bx cx
  
  mov  ax, [r]
  imul [r]
  mov  dx, [pi]
  mul  dx
  mov  bx, 100
  div  bx

  pop  cx bx dx ax
  ret
endp

During execution I get:

Code:

Debug:  mov  ax, [r] -> 0h
        mov  dx, [pi] -> 1252h

I can't understand why?

27 Apr 2026, 18:53

AsmGuru62

Joined: 28 Jan 2004
Posts: 1796
Location: Toronto, Canada

AsmGuru62 27 Apr 2026, 19:26

I believe that proc/endp/stdcall are for 32-bit code, so I wonder why FASM for DOS compiles it.
Should be an error, stating that registers like EBP cannot be used with 'use16' directive.
Maybe PROC32.INC can be modified to support stdcall procedures for DOS?
Any macro masters out there?

27 Apr 2026, 19:26

Byte

Joined: 21 Mar 2026
Posts: 24

Byte 27 Apr 2026, 20:12

AsmGuru62 wrote:

I believe that proc/endp/stdcall are for 32-bit code, so I wonder why FASM for DOS compiles it.

The fact is that when I compile 32-bit "pure" code, this macro also works incorrectly.
But for this I use fasm for DOS.

27 Apr 2026, 20:12

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20960
Location: In your JS exploiting you and your system

revolution 27 Apr 2026, 22:18

1. One problem with the code is that call (inside stdcall) pushes a 16-bit address so the computation of the offset for r is off by 2. The proc macro assumes a call will push a 32-bit address.

2. Second: pi is uninitialised, locals (defined in proc32) only defines lowercase versions of data definitions so DW is not special, only dw will initialise the constant. Using all-caps DW is why the code also fails in 32-bit settings.

I would suggest to make a dedicated proc16 macro set to handle 16-bit code correctly.

AsmGuru62 wrote:

Should be an error, stating that registers like EBP cannot be used with 'use16' directive.

CPUs in 16-bit mode are perfectly capable of running 32-bit instructions and using 32-bit registers.

27 Apr 2026, 22:18

Byte

Joined: 21 Mar 2026
Posts: 24

Byte 28 Apr 2026, 20:14

revolution wrote:

2. Second: pi is uninitialised, locals (defined in proc32) only defines lowercase versions of data definitions so DW is not special, only dw will initialise the constant. Using all-caps DW is why the code also fails in 32-bit settings.

Thanks, replacing 'DD' with 'dd' fixed the situation with 32-bit code.
Macros are cool, of course. But if the compiler core supported stdcall (cdecl etc) and local variables, it would be much cooler.

28 Apr 2026, 20:14

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20960
Location: In your JS exploiting you and your system

revolution 29 Apr 2026, 00:20

Byte wrote:

Macros are cool, of course. But if the compiler core supported stdcall (cdecl etc) and local variables, it would be much cooler.

stdcall/proc/locals/etc are OS specific and can generate multiple instructions. Those are not suited towards making a generic assembler.that works for all OSes. Linux and MacOS would need a different proc, so including only a Windows version of proc would make programming for other OSes awful.

29 Apr 2026, 00:20

Byte

Joined: 21 Mar 2026
Posts: 24

Byte 29 Apr 2026, 17:13

I disagree a little. Calling a routine depends not so much on the OS as on the calling convention. This or that OS only adheres to a certain convention. And that only applies to system calls. In addition, each OS requires its own compiler assembly. There is no universal code. But the compiler can support all known calling conventions.

29 Apr 2026, 17:13

macomics

Joined: 26 Jan 2021
Posts: 1215
Location: Russia

macomics 29 Apr 2026, 20:34

Byte wrote:

But the compiler can support all known calling conventions.

Then this compiler is no longer low-level. The assembler assumes working directly with the CPU, and not with the systems and their ABIs.

To solve such routine tasks, a preprocessor/macro language has been added to the assembler. This way you can create the macro instructions you need and work in any system and with any ABI.

29 Apr 2026, 20:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20960
Location: In your JS exploiting you and your system

revolution 30 Apr 2026, 00:35

Byte wrote:

Calling a routine depends not so much on the OS as on the calling convention.

Fair comment. And there are so many ABIs that supporting all of them is a task that goes beyond an assembler IMO.

Plus: ABIs get updated, renewed, re-invented, extended, etc. Some ABIs are extremely complex, especially when dealing with mixed integer and floating point values (e.g. SYSV, FASTCALL) The source code would need to signal the type of each value to correctly format all the call inputs. It gets untidy very quickly. The assembler code to handle all the different calling conventions becomes larger than the base assembler itself.

30 Apr 2026, 00:35

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum