(https://i.postimg.cc/Whs1yc2g/1.jpg) (https://postimages.org/)
on my machine, it looks like ml is dead.
anybody know? 1 min or 1 hour?
what's wrong, I click on pic, then opened https://postimages.org/ (https://postimages.org/)?
never mind, open image in new tab works
tip: For memory that large, allocate it. Just remember to free it when you no longer need it.
In your case, it takes as long as it takes. Different ml versions may be slower or faster.
Also different CPUs may make it take longer or less time.
I just tested that. Mine is still assembling....
edited to add:
couple minutes later
about 4 minutes here.... for 4 MB in data? section...
If you run Task Manager, you will see that ml is not quite dead, slow yes but not yet dead. so, hold your horses. (be patient, wait)
Quote from: dedndave on September 28, 2013, 03:10:13 AMyes - it is a known masm bug
there are ways to avoid it
a simple way is to break up the define
i think if you break the 1024000 byte buffers into 16 64000 byte buffers, it will build faster
DSNBUFFER1 BYTE 64000 DUP(00h)
BYTE 64000 DUP(00h)
BYTE 64000 DUP(00h)
;etc
the ORG macro that Jochen mentioned is also a good way
of course the SIZEOF and LENGTHOF operators won't work
but, you can put a label at the end and subtract addresses to get past that
This is useful info; I had no idea this could happen.
Seems to me this ought to be in one of the programming fora (Workshop?) as it's not just a rant but an actual problem people ought to know about.
Good tip, sinsi. I had known about that - but had forgotten. :smiley:
replace
a db 4*1024*1024 dup(?)
with
a db 64000 dup(?)
repeat 65
db 64000 dup(?)
endm
en... wtf... still looks like ml is dead
Here is the thread learn64bit, that sinsi obtained that quote from:
ML.exe super-slow with large BYTE values? (https://masm32.com/board/index.php?topic=2412.0)
Read that, maybe you will understand better.
It looks like he understood it fine, and that should've worked, shouldn't it?
That ORG ... then a single DB ? method looks pretty kewl. Maybe you should try that, learn64.
Quote from: sudoku on April 17, 2024, 12:14:09 PMtip: For memory that large, allocate it. Just remember to free it when you no longer need it.
Exactly. 4MB in the data section is fixed in size and address. That might be OK, depending on what you're doing, but there's no way of resizing it, or even freeing it. Use the heap functions instead.
Sure, what you wrote is true. But look at declaring that huge memory area in the
.data? (
not .data) section:
- It doesn't take up much space in the .exe file
- No allocation needed, just use it
- Freeing it? Windows takes care of that for you on program exit.
Just tested with Microsoft (R) Macro Assembler Version 14.39.33522.0 and it seems that MS have fixed the bug, building took <1s
a db 4*1024*1024 dup (?)
.asm:
;00936
include \masm32\include\masm32rt.inc
.data?
align 4
b label byte
a equ offset b
org $+4194304-1
db ?
.code
mainCRTStartup:
public mainCRTStartup
mov eax,offset a
mov ebx,4194304
aTest:
.if ebx
mov [eax],eax
add eax,4
sub ebx,4
jmp aTest
.endif
inkey "Press any key to exit..."
exit
end
.cmd:
@rem 00936
@echo off
\masm32\bin\ml.exe /nologo /c /coff /FoWin7m3.obj Win7m3.asm
rem Microsoft (R) Macro Assembler Version 6.14.8444
\masm32\bin\link.exe /nologo /subsystem:console /out:Win7m3.exe Win7m3.obj
rem Microsoft (R) Incremental Linker Version 5.12.8078
pause
okay, now it's fast, ml not looks like dead anymore
Quote from: sinsi on April 17, 2024, 02:30:49 PMJust tested with Microsoft (R) Macro Assembler Version 14.39.33522.0 and it seems that MS have fixed the bug, building took <1s
a db 4*1024*1024 dup (?)
I'm using 6.14.8444 (which I think is what's currently in the MASM32 package); any idea if this has the bug or not? Too lazy to write a test program at the moment ...
ML v6.14.8444 has the bug, both for .data and .data?
ML v14.39.33522 (from VS) is OK for both.
Hi learn64bit,
You can also use dynamic memory allocation functions like VirtualAlloc.