It would be nice if fasm could create temporary file for subsidiary use when it runs out of memory.
(Thus having two memory settings)

What for?

It already does.

Well not directly anyway, the OS will do it. In Windows it is called pagefile.sys. In other OSes it is probably called something else. But that is what virtual memory is -- a file on disk for times when RAM is insufficient.

Use the "-m" switch to reserve however much memory you want. But remember that it is a 32-bit application and is limited to ~2GB-4GB maximum (exact amount depends upon the OS you are using).

revolution,

External storage (in general case) allows to use much larger buffer for preprocessed source (which is the main problem, as I see it). Simple source with include "Win32AX.Inc" can grow quite fast with each macro used (EXAMPLES\HELLO.ASM is almost 3.5 MiB preprocessed, +1.7k for each extra invoke, +7k for each .if/.while/.repeat).

Am I the only one that thought about "compile something useful & readable using fasm -m 1024" contest? fasm compiles in 4 MiB, but is its source readable for anybody except Tomasz?

fool/shell.asm compiles with exactlly 2519 kilobytes, no more needed.

and is not usefull, then, it is out of the discution.

but using an external storage for fasm memory can be interrseting, but only for fasm debugging.

for applications, only the listing is usefull to detect the problems, and it is effectivelly a file generated via .fas file, internally generated by fasm.

I understand the memory problem. I really do. Since in the past I have regularly run out of memory. But now I have developed most of my macros to use a lot less memory.

But I have to ask this: Does anyone here actually have source code that needs more than 2GB of memory to compile? Or is this just an academic discussion? And I am not talking about some trivial source file of repeated nonsense made just to test the system.

Should we be expecting fasm to ever be able to compile this?

rev, go punch FASMARM developer for a new version, and don't bother.
This is no Heap and noone's asking for your "suggestions".

baldr, it is, though you're right Tomasz did intentionally not put comments in it.

And what about me?

I still can't understand for what reason you want such behavior.

guignol: You want Tomasz to include a new function, as shown by your topic here. But you offer no justification for including it. vid already gave you the hint in his first reply, but you ignored it. So I asked specifically for what code you need this functionality, which you also ignored (and merely attack in response). But in reality if you still want Tomasz to include something like this for you then you need to explain why it is needed. Else what incentive is there for Tomasz to put in all the work involved with doing it?

My 'suggestion' to you is to explain the reason for it. If you have a clear use for it then Tomasz might view it as important and start working on it. My 'suggestion' is here to help you to achieve what you want, not to work against you.

(She is a girl)


vid, don't take me too much wrong... but "so what?"
You see, from where I perceive it, you sound like that chatterbox mentioned above.


After all, isn't it enough that I will appreciate it?

More than 4 GB of memory? That would, of course, require upgrading all the pointers to larger sizes. Thus it may as well end as rewriting fasm for x86-64 architecture. Which is not a bad idea itself, but has nothing to do with writing own virtual memory handling, as that idea deserves exactly the vid's initial response.

What do you think? Would the fact that "guignol shall appreciate that" be enough to convince Tomasz to implement this feature?

Tomasz, define "virtual memory"?
I wasn't talking about virtual memory from OS perspective.

Let's say, for starters, that preprocessor tokens would be treated into that subsidiary file, thus freeing actual memory.


P.S. Do I really need to read all fasm source to tell where those two can be divided?

http://en.wikipedia.org/wiki/Virtual_memory

The pointers into preprocessed source would still be 32-bit offsets. So you would be still left with 4G limit for it.

This is not the point.
The point is that anything that can be treated out of actual physical memory be possible to be done with so.

If I write it to file, it is actually quite probable, that OS will keep it in cache, so it will stay in physical memory anyway - especially since the preprocessed source is "randomly" accessed by all of the later stages.

Tomasz
Cache?
So FreeMemory actually caches it?

guignol,

Without FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING every file access goes through cache manager.

FreeMemory — what is it? Turbo Pascal/Delphi procedure? Then it has nothing to do with Windows memory management.

baldr
No, I misread Tomasz:

(That's why I was so buggy about proper language usage )


Ok, so what's wrong with using file directly (without caching/mapping it into memory)?

There is no reason to do it.