DUP

[shankle]

Is there a Maximum size for DUP.
I defined the following and had to redefine it to get my code to work.
EX: FileBuffer  10000 DUP (0)
File goodies stopped around 5000.

Redefined:
  FileBuffer 5000 DUP (0)
               5000 DUP (0)
This worked.
I can't find anything in the books about a max for DUP.

Thanks for any suggestions.
JPS

 

[MichaelW]

I don't know what the ultimate upper limit for DUP might be, but for COFF modules the practical upper limit is determined by how long you are willing to wait for MASM to finish. This, for example, works OK but MASM takes several minutes to generate the 1MB+ object module:

FileBuffer db 1000000 dup(0)

For stuff like this it would probably better to allocate memory at run time.

[raymond]

Or you can declare it instead in the uninitialzed .DATA? section. Since the assembler does not have to "code" values for such variable, it should not affect the assembly time.

Although "uninitialized", you can generally assume that such variables will initially all be 0 when the OS loads your program.

Raymond

[Tedd]

There is a limited, but I think there's an option you can pass to ml to increase it.
And unless you want your exe to be an extra few thousand bytes of nothing, you can put it in the .data? section for no added cost. It will be initialised to zero on startup -- many C programs rely on this behaviour, so it is done for safety.
There is still a limit on the size of the data? section, but there's an option for it too. In any case, if you're allocating more than 1MB then I'd suggest using HeapAlloc (or GlobalAlloc).

[hutch--]

I go for dynamic allocation every time unless its a very small amount or an array of pointers. Anything you initialise makes the EXE file larger and using large quantities of uninitialised memory give a larger memory footprint than you need. Dynamic allocation has the advantages of both being a smaller file and resizable so unless you need tables of initialised data or addresses or similar, it is the way to go.

[jj2007]

And unless you want your exe to be an extra few thousand bytes of nothing, you can put it in the .data? section for no added cost. It will be initialised to zero on startup -- many C programs rely on this behaviour, so it is done for safety.

I've stumbled over this question many times, and would love to get a clear answer. I have an app with 4926 bytes of .data? variables.
1. According to theory (but contrary to Tedd's statement above), I should expect garbage in the .data? section.
2. With the code below, I get, reproducibly, plenty of non-zeros for ecx==2214  - as if somebody had arbitrarily decided to zero-initialise only the first 4926 - 2214 = 2712 bytes.
3. When I check with Olly, strangely enough the whole .data? section is zero.

All that is pretty confusing for a poor hobby programmer... can anybody enlighten me?

Code Select Expand

mov ecx, offset LastVar ; clear all .data? variables
mov esi, ecx
sub ecx, offset FirstVar
add ecx, 4
pushad
invoke MessageBox, 0, str$(ecx), chr$("Bytes not initialised:"), MB_OK
popad
.while ecx
mov eax, [esi]
.if eax
pushad
invoke MessageBox, 0, str$(ecx), addr AppName, MB_OKCANCEL
.if eax==IDCANCEL
exit
.endif
popad
.endif
add esi, 4
sub ecx, 4
.endw


[jj2007]

I realise I had a bug in my snippet. With the code below, it seems that all .data? are indeed zero-initialised - which is still against the "expect garbage" theory. So does ML insert some code for zero-initialisation, or is it sheer chance that my .data? section is zero?

Code Select Expand

mov esi, offset FirstVar
mov ecx, offset LastVar ; clear all .data? variables
sub ecx, esi
add ecx, 4
pushad
invoke MessageBox, 0, str$(ecx), chr$("Bytes not initialised:"), MB_OK
popad
.while ecx<80000000h
mov eax, [esi]
.if eax
pushad
invoke MessageBox, 0, str$(ecx), addr AppName, MB_OKCANCEL
.if eax==IDCANCEL
exit
.endif
popad
.endif
add esi, 4
sub ecx, 4
.endw


[tenkey]

I assembled the following code:

Code Select Expand

.386
.model flat

.code

_start:

mov eax,100

.data

db 'abcdefghij'

.data?

dd 8192 dup(?)

end _start


MASM 6.14.8444
Linker 5.12.8078

Using the /coff option, the OBJ file is 428 bytes, and the EXE file is 1 536 bytes.

The declared size of the data? section is 32 768 bytes.

Unlike OMF, COFF does not have compression of repetitive data, so there is nothing in the OBJ or the EXE file holding zeroes for the data? section. (At least, not for the entire section.)

[Tedd]

I realise I had a bug in my snippet. With the code below, it seems that all .data? are indeed zero-initialised - which is still against the "expect garbage" theory. So does ML insert some code for zero-initialisation, or is it sheer chance that my .data? section is zero?

Whose 'expected garbage' theory are you referring to?
When the exe is loaded, its sections are unpacked and organised into memory - the .data? (aka .bss) section is allocated and zeroed; once all sections are prepared, the entry point ('start') is called.
There's no need for anything to be inserted by ML - it's specifically zeroed by windows (and similarly under linux) because programs expect it to be, so it would cause problems if it wasn't.
The only reason to 'expect' garbage is when looking from a high-level purist view, where variables that haven't been specifically initialised will contain garbage. This is true for local variables (since they're allocated from stack space), but not for the data? section.

[jj2007]

Whose 'expected garbage' theory are you referring to?
When the exe is loaded, its sections are unpacked and organised into memory - the .data? (aka .bss) section is allocated and zeroed; once all sections are prepared, the entry point ('start') is called.
There's no need for anything to be inserted by ML - it's specifically zeroed by windows (and similarly under linux) because programs expect it to be, so it would cause problems if it wasn't.
The only reason to 'expect' garbage is when looking from a high-level purist view, where variables that haven't been specifically initialised will contain garbage. This is true for local variables (since they're allocated from stack space), but not for the data? section.

Thanxalot for the clarification; Tedd. I remember (but don't find) an old thread about this, but most probably that was about LOCAL variables.