1

Well the question is straightforward. I want to know if declaring variables inside procedures is a okay thing to do. like this for example:

SAMPLE PROC NEAR
    ; PROC BODY
RET
VARIABLE DW 0000H
SAMPLE ENDP

I don't think this should be an error. As RET is available at the end. What I want really to do is have an array of constants that is required for the PROC. Some sort of look up table.

If it is not legal, I would like to know why.

ponir
  • 447
  • 7
  • 20
  • 1
    Mixing data with code is a disadvantage on most architectures, including x86. Having the same line in L1I cache and L1D cache at the same time is a waste. (All modern CPUs have split L1 caches, [for several reasons](http://stackoverflow.com/a/38549736/224132)) – Peter Cordes Aug 17 '16 at 08:16

1 Answers1

3

Procedure boundaries are almost meaningless in assembly. It doesn't matter if the variable is before or after ENDP. So yeah, syntax-wise it's OK, as long as you're not trying to execute the variable contents as code. But there's a deeper issue here.

Protected mode systems (Windows, Linux) often make the code section read only; trying to write into such a variable would crash the program. You have to use the data section or the stack.

Under DOS, it's okay.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
  • Even when possible, keeping read/data next to code (in the same cache line) is still a performance disaster: the CPU will flush the pipeline after every store to a cache line that also contains code that's fetched or executing. Or even within the aligned 1k region on older CPUs. (`machine_clears.smc` performance event): [Observing stale instruction fetching on x86 with self-modifying code](https://stackoverflow.com/q/17395557). The OP's proposed read-only lookup table doesn't have this problem, merely [a waste of L1i/d and i/dTLB footprint.](https://stackoverflow.com/a/55609077/224132) – Peter Cordes Oct 02 '20 at 06:27