Large buffers

[clamicun]

I am a FASM user playing around with MASM since a couple of days.

Just one question...

I need for some reason a very large buffer to load a file from disk and process it.
No problem, but ...

It takes an awful time to compile the asmfile and the created exefile is actually to large for what it does.

Is there a possibility with MASM to simply reserve the needed bytes like I can do with FASM using e.g.

the_buffer rb 5000000

Thank you in advance !

[jj2007]

Hi clamicun,

First things first: Welcome to the forum :icon14:

Your problem is a well-known Masm bug with dup, below a simple example. It will take over 2 seconds on an i5.

Workarounds:
a) use heap buffers instead, see halloc and hfree in \Masm32\help\hlhelp.chm, Macro categories/Memory Allocation
b) use JWasm, it's a perfect Masm clone and does not have this bug, and is much better and faster anyway:
  - direct download link
  - the only file that you need is JWasm.exe; extract to \Masm32\bin, then either
    1. rename ML.exe to ML_old.exe, then JWasm.exe to ML.exe or
    2. instruct your IDE to use JWasm.exe instead of ML.exe *)

include \masm32\include\masm32rt.inc

.data?
somebuffer   db 500000 dup(?)

.code
start:   print "ok"
   exit

end start

*) For example, the MasmBasic IDE will simply tell you "You need \Masm32\bin\JWasm.exe", i.e. no need to rename ml.exe etc

[dedndave]

i seem to recall a couple other work-arounds

one is to use ORG

Code Select Expand

buffer  db ?       ;create a 100004 byte buffer
        ORG     buffer+100000
        db 4 dup(?)

another is to use several smaller defines
i forget what the size is that MASM starts to screw up, but let's say it's 64 KB

Code Select Expand

buffer  db 65536 dup(?)
        db 65536 dup(?)
        db 65536 dup(?)

another would be to acquire MASM version 8.x
as i recall, the bug is fixed   

[clamicun]

Thank you guys !

jj2007 - yes ok. I installed JWASM. Compiles the file in 3 seconds. MASM needs 35 !

The exefilesize does not change of course. 900 KB.  FASM creates a 30 KB file.

PS.
This verification routine is absolutely boring.

[sinsi]

With FASM you usually put your RB stuff at the end so it doesn't add to the EXE size.
With MASM you put it into a special section - .data? (uninitialized data). This section doesn't actually exist in the EXE image.

[jj2007]

jj2007 - yes ok. I installed JWASM. Compiles the file in 3 seconds. MASM needs 35 !

3 seconds?? Must be a fairly big file. How many lines? FASM source, and compiles neatly with JWasm? Sounds like a miracle ;-)
My biggest source, with 16,000+ lines, takes exactly one second to build on an i5.

The exefilesize does not change of course. 900 KB.  FASM creates a 30 KB file.

As Sinsi rightly wrote, just add a "?":
.data?
mybuffer db 800000 dup(?)

This verification routine is absolutely boring.

The anti-troll thing? You need to pass it only once

Here are two very useful links for you: old and new forum search.

[Gunther]

Hi clamicun,

welcome to the forum.

Gunther

[clamicun]

Thank you guys a lot !

sinsi - I could have come to that conclusion myself. Now the exefile is compiled in mseconds and the size is 24 KB !!
Your dog is marvelous - I had a couple of dachshounds in my life.

jj2007 - This jWasm compiler is lightyears ahead of ml.exe

Gunter hi - you from Germany like myself ?
-------------------------------------

One more question please...

Can someone please give me an explanation on this construction - I do not get it.
What sort of handle is it ?

mov     edi, lparam 
mov     eax, [edi.NMHDR].hwndFrom  ??

Thank you guys.

PS:
The verification routine is getting disgusting - no way to jump it ?

[dedndave]

WM_NOTIFY is typically sent from a child (usually a control, like a button or edit box, etc)

http://msdn.microsoft.com/en-us/library/windows/desktop/bb775583%28v=vs.85%29.aspx

if you notice on that page, the NMHDR structure is a link...

http://msdn.microsoft.com/en-us/library/windows/desktop/bb775514%28v=vs.85%29.aspx

to understand better how it works, it might be best to look up the specific control type
you haven't told us what type of control it is

[Gunther]

Clamicum,

Gunter hi - you from Germany like myself ?

yes indeed, I stay in Berlin.

Gunther

[redskull]

I need for some reason a very large buffer to load a file from disk and process it.

While this has nothing to do with your original question, using a memory-mapped file would probably be both easier and faster (depending on your needs) than allocating a static buffer and reading the whole thing in at once.  Or, failing that, reading it in as 4K chunks into two separate buffers and swapping between which one you are processing.

-r

[sinsi]

Your dog is marvelous - I had a couple of dachshounds in my life.

My doberman takes offence (well she would if she was still alive )

[hutch--]

> well she would if she was still alive

Is that why she was so good looking ? 

[clamicun]

sinsi
I apologize to your late doberman.
But very good that you did not cut her ears.
Dachshounds and dobermans (dobermen ??) are in fact quite similar - except for the size.
----------

dedndave
Yes I see - hwndFrom is defined in NMHDR structure

redskull
In deed - Chunking makes it a bit faster - mseconds ?

Nice day to you all

PS.
Noone will answer to this verification routine ?

[jj2007]

Chunking makes it a bit faster - mseconds ?

Depends on many factors. For example, reading 960kB of \Masm32\include\Windows.inc completely into a heapalloc'ed buffer takes about one millisecond on my 500 Euro notebook. Surely that can be made much faster with memory-mapped files ;-)

In short: check if it's worth to invest your time. But learning never hurts, and memory-mapped files are an interesting exercise anyway.

Noone will answer to this verification routine ?

Zu Weihnachten bekommst Du freien Zugang geschenkt. Vielleicht macht Hutch sogar den Nikolaus