Hi ,guys I have a problem, I started workin gon my 68K CPU emulator by writing a generator code in C, that generates a skeleton ASM file, so obviously its not bug free lol. But anyway, there seems to be a problem, MASM takes like 10 seconds to assemble these two files (I'm on WinXP Pro, AMD Duron 1.3Ghz and 512MB DDR). I know my comp ain't the fastest guy on the block, but it shouldnt take this long, just imagine how long it will take to compile when the code is finished :'(, please tell me whats going on so I can correct it! Its taking wayy too long already!!
Posted on 2004-06-05 22:12:31 by x86asm
Here is the second generated file:

Why does it take 10 seconds to compile!! I'm using some skeleton code


.686


.XMM
.model flat, stdcall
option casemap:none
include C:\v68kgen\v68kohl.asm ;Two included files
include C:\v68kgen\v68k.asm

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\masm32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib

.DATA

maincpu S68K<>


.CODE

start:
mov eax,5
lea eax,maincpu.data
lea esi,maincpu
mov DWORd PTr [eax+(0*4)],26h
mov DWORd PTr [eax+(1*4)],49h
jmp abcd01d







END start
Posted on 2004-06-05 22:14:27 by x86asm
It is a known MASM feature that it takes a long time for:
.DATA

ophlist dd 65536 dup(0)
You and I know this can be done simply, but obviously the guys that wrote MASM didn't know that. Or maybe, they are trying to encourage writing small programs. :D
Posted on 2004-06-05 22:47:21 by bitRAKE
Ya, its better to allocate this from memory anyways...

Regards,
:NaN:
Posted on 2004-06-06 00:12:35 by NaN
> bitRAKE:
> "Or maybe, they are trying to encourage writing small programs."

OK, small program :-)


.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
.data?
buffer db 80000h dup(?)
.code
start: invoke ExitProcess,0
end start
Posted on 2004-06-06 00:49:09 by kero
kero, small is a relitive subject and in this instance I mean memory footprint - not size on disk, or length of source code. I usually mean memory footprint because if the program is small in memory then it is small on disk (usually), and I don't care about the length of source code as ASM should be long winded and say very little - like my words here. ;)
Posted on 2004-06-06 01:18:14 by bitRAKE
bitRAKE, it was just joke, i didn't try "reductio ad absurdum" :-)

BTW you wrote:
"if the program is small in memory then it is small on disk (usually)"

What about UNusual case ? It's very interesting.
Posted on 2004-06-06 02:21:26 by kero

What about UNusual case ? It's very interesting.
From decompression to code generation...(I took your statement in a joking manner and then make fun of myself. ;))

The windows loader will initialize BSS section to zero and your post takes advantage of this important fact. IIRC, this doesn't effect MASM assembly time, though.
Posted on 2004-06-06 02:45:48 by bitRAKE
:-)
Posted on 2004-06-06 03:24:14 by kero
x86asm,

If I remember well, Randall Hyde recommended to assemble source files containing large static arrays with the /omf switch.


ml /c /omf srcfile.asm


This technique should reduce the time of assembling.
Posted on 2004-06-06 05:09:38 by Vortex
smarter to stay COFF and not use huge static arrays like that anyway ;) - or you could put the static array in another module that you don't re-assemble every time you hit 'build', and link that module in.
Posted on 2004-06-06 08:36:28 by f0dder