I found an interesting feature of MASM 6.15 (patched):
time to compile the code depends on array size , and in case its
an array of big structures it can be almost infinite. The code is below

SEND_BUF_SIZE EQU 1024
RECV_BUF_SIZE EQU 1024
MAX_CLIENTS EQU 1024

ClientInfo STRUCT
state dd ?
sendBuf db SEND_BUF_SIZE dup (?)
recvBuf db RECV_BUF_SIZE dup (?)
ClientInfo ENDS

.data?
clients ClientInfo MAX_CLIENTS dup (<>)

Once MAX_CLIENTS goes above 10 compile time grows unacceptably,
obj file size is the same. Looks like MASM tries to build this arrays in memory.

Does anybody knows the way to avoid this problem , or I'm doing something wrong?
Posted on 2002-12-22 18:37:17 by Sergo
Throw the array's in a .lib and link to it.
That's the only way around or just allocate this big chunk using HeapAlloc.
Posted on 2002-12-22 18:47:02 by JimmyClif
Allocate system memory for such things.. you may be saving a few seconds initially by not having to call upon API's, but in the long run its the way to go.. (as you are learning).

Some systems may have a hard time runing a program with such large data segments as well (seem to remember a converstion about this point with f0dder sometime ago ~ or perhaps im on drugs and it just sounds like good advice ;) )

Anywho, write a few macro's and use memory API's...
:alright:
NaN
Posted on 2002-12-22 22:08:27 by NaN
You can read this topic, but better use, in the case of large buffers/structures/etc..., some memory allocating API.

.obj files
Posted on 2002-12-23 04:38:03 by Four-F
and in case its an array of big structures it can be almost infinite

How big is almost infinite?
How close does a number have to be to be aproximated to infinite?

Mirno
Posted on 2002-12-23 05:25:19 by Mirno
I have noticed that .data? allocated arrays do take up much time, too.
.data?
stg dd 8096 dup (?)
took several seconds more while compiling. The library solution, provided by JimmyClif is very good, I've been using it for much time, and saves about twenty seconds of compiling a big project. And with libraries the code is better organized.

About the infinite: the longest time I have measured is 2 minutes, and I think more can be achieved ....
Posted on 2002-12-23 19:27:52 by Ultrano
Thanks, everybody

Now at least, I have to compile it only once, but it still long 100 struct - 2 min

Does converting obj file (with such array definition ) to lib give any benefits , linking speed , for example?

BTW, two other questions
1. Does somebody check how big is speed impact if allocate memory, catching exceptions?
( I guess, trapping and switch to kernel and back to user take some time )

2. I've seen once a WinHelp format doc for masm but can't find it now (it's not Programmer's Guide in .doc).
Can anybody share a link?

2. For those who use Visual Studio
Is there any way to make browsing (for symbols) work in non-C project?
(asm file included in C project are browsable)
I built sbr (there is a switch for it in ML) and bsc but VS (msdev) says my bsc has a wrong file format.
Posted on 2002-12-25 23:51:50 by Sergo
Sergo,

You really are better off going for dynamic memory allocation in this instance as you can work on far larger memory blocks this way than trying to shove it into the .DATA or .DATA? sections.

A friend of mine had the same problem as you did when he tried to put more than a megabyte of data into the .DATA? section in a MASM file, even though he could do it easily in NASM.

It is not good coding practice at best so MASM is actually doing you a favour in forcing you to do it another way. There is no point in building an assembler that covers up bad coding and it will pay off if you use dynamic code in terms of being able to work on far larger data routinely.

Regards,

hutch@movsd.com
Posted on 2002-12-26 04:25:39 by hutch--