Maximum memory

[gofab]

Hi to everybody,

I tried to declare very big arrays with the DUP directive, but if I exceeed 1 Mega receive the message "Exceeded GoAsm safety limit for duplicate data".
If insted I declare "small" arrays of 1 Mbyte I can't declare more than four, otherwise there is the error message "Insufficient memory for the task".

I just would want to know if there is an option for declaring bigger arrays or not.
(I know I can theoretically address 4Gbyte, so I assume I can use them like I want....)

Thank you in advance,
Fabrizio

[jorgon]

Hi Fabrizio

The 1MB limit for DUP in GoAsm is there because GoAsm assumes that you must have made a mistake if you are trying to declare more than that as data.  The reasoning is that normally large blocks of memory like that in a Windows program would be established using the Windows memory APIs.

This may actually be a little restrictive.

Could users let me know if they would like the limit raised or switchable.

Meanwhile it is possible to create larger blocks of data by declaring more than one block, each block being under the 1MB limit.

[gofab]

Jorgon,

thank you for the reply and for creating GoAsm, that is for me much easier to use than other assemblers.
I will go to MSDN to find the appropriate function, and of course I would like the 1MB limit lifted  :8)

Best regards, Fabrizio

[pro3carp3]

Could this be a compiler setting with 1MB or some limit as a default and adjustible in the source file?

Code Select Expand



#DUPLIMIT 2MB



[1rDirEctoALgran0]

or a keyword like :

DS Space

With DS stands for Define Space. (Like old style assembler...)
Space is an unsigned integer in byte.
This declaration must be situated in a ".bss" section.

Patrick

EDIT: or DUM (for Define Uninitialised Memory) to avoid risk of confusion with the DS register.

[gofab]

Thank you for these further suggestions,

I will test and inform you about the results  :clap:

[1rDirEctoALgran0]

Note:
In my previous post I talk about DS or DUM keywords that are not implemented...
So now, you must use a memory allocation like this :

//////////////////
// MEMORY ALLOC //
//////////////////

GMEM_FIXED = 0000H
GMEM_ZEROINIT = 0040H
MEMORY_SIZE = 8388608 ;if I need 8 MB

   CODE
Start:
   INVOKE KERNEL32:GlobalAlloc,GMEM_FIXED+GMEM_ZEROINIT,MEMORY_SIZE
   MOV [pMem],EAX

   MOV ECX,MEMORY_SIZE/4
DummyFill:
   MOV [EAX],"DUM!"
   LEA EAX,EAX+4
   LOOPNZ <DummyFill

   INVOKE KERNEL32:GlobalFree,[pMem]
   RET

   DATA
pMem   DD ?


[attachment deleted by admin]

[Chip]

May I add my name to the list of those who would like to
see an increase on the Dup and memory size parameters.

Given the increasing amounts of cheap memory available,
it now seems reasonable to process extremely large
arrays in memory.  One benefit is that arrays read from disk
can be read into one very large buffer to reduce the amount of
windows "overhead" associated with each read.  With
disk drives now incorporating ram caches  exceeding
8MB, an (unfragmented)  large read could be super fast.

With the imminent arrival of 64bit processing, I believe the
overhead of processing very large arrays will also be reduced.
(That is, if programs are coded to take advantage of
the additional capabilities provided.)

I too have run into difficulties testing with extremely large
arrays due to GoAsm's memory restriction.  While I would
have agreed 5 years ago that 1MB was a reasonable limit,
this no longer seems the case.  I also have a particular interest
in not having to implement memory allocation workarounds.
I rather like the simplicity of just declaring  large arrays using
the existing GoAsm syntax.

In closing, I wonder what other things will become desirable
with 64bit processing.  The type of things that are never
considered, because most of our experience is with more
expensive and limited hardware.  While the memory limitation
has come to my attention, what else will be perceived as a
limitation in the future.  (I don't know enough to answer,
only to pose the question.)

Chip                       

[donkey]

Hi Jeremy,

I think that this can easily be solved by making the DUP error a warning instead of a fatal error (if possible). That way it will still provide a reminder but will not break a program if you need something bigger. For myself 1 MB is more than enough, I would certainly be using VirtualAlloc for anything approaching that size anyway, certainly I would be looking at anything rather than statically allocating it with no chance of expansion.

[jorgon]

I think that this can easily be solved by making the DUP error a warning instead of a fatal error

Brilliant idea!

This is now in GoAsm 0.55.10 available from here.

[bushpilot]

Thanks Jeremy.

Greg

[Chip]

Thank you Jeremy, for taking the time to address this change.
I like the overall simplicity of your solution.

Chip

[1rDirEctoALgran0]

Hi Jeremy,

there is a problem for space above 4 MB. (Insufficient memory for the task)
and I found a real bug (see attached file).

If you can fix them, it will be great !

Patrick


[attachment deleted by admin]

[jorgon]

Nice one Patrick, I'm on the case!

[jorgon]

there is a problem for space above 4 MB. (Insufficient memory for the task)
and I found a real bug (see attached file).

These bugs are now fixed in GoAsm 0.55.11 available from here.