flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2 |
Author |
|
baldr
f0dder,
Features come at a cost, simplicity of fasm macro engine brings a heavy toll on memory consumption. ----8<---- Tomasz Gryzstar, This isn't a critique, I understand (probably) your considerations regarding design of so powerful preprocessor. Is there a whitepaper about second generation of fasm? |
|||
![]() |
|
vid
baldr: Have you seen FASMCON 2009 talk about FASM2?
|
|||
![]() |
|
bitRAKE
I thought the memory problem was solved with OBJ support? Getting familiar with FASM, I initially had the same concern/confusion about its operation. Not just the macros, but simple things like RB taking more memory seems bothersome.
Only one of my projects really have a problem with FASM's memory limit, and a work-around wasn't that difficult. It's common for me to use FASM for data processing - loading a huge data file directly into EXE - the lazy way. Combine that with a large hash table - the lazy way. Throw on some 256-aligned memory structures - the lazy way. Memory goes quick. (Someone say a x86-64 version of FASM? ![]() |
|||
![]() |
|
DOS386
vid wrote:
+1 to original suggestion: add optional temp file support to FASM. Why ? 1. This pagefile.sys is hacky and slow as hell (and there is none at all in UNREAL mode) 2. With temp file you have almost 4 GiB for source and another almost 4 GiB for preprocessed stuff. With pagefile.sys you have 4 GiB for both together and additionally all the other crap (AFAIK "only" cca 1 GiB in XP). > I thought the memory problem was solved with OBJ support? ![]() |
|||
![]() |
|
bitRAKE
DOS386 wrote: > I thought the memory problem was solved with OBJ support? If my project requires 4GB to build then I have limited audience and development choices myself. The downside being slower build times - which are hopefully mitigated by the use of NMAKE or similar. |
|||
![]() |
|
Tomasz Grysztar
DOS386 wrote: 1. This pagefile.sys is hacky and slow as hell DOS386 wrote: (and there is none at all in UNREAL mode) I agree, but making unREAL version use some swapping mechanism would in fact beat the point of using unREAL in the first place (which was that it should work directly on physical memory and be faster than the other variants). So to get more memory it is still simpler and better to use DPMI version with some decent virtual memory implementation. DOS386 wrote: 2. With temp file you have almost 4 GiB for source and another almost 4 GiB for preprocessed stuff. |
|||
![]() |
|
Tomasz Grysztar
bitRAKE wrote: Someone say a x86-64 version of FASM? ![]() |
|||
![]() |
|
revolution
I vote fasm 2. All this talk about 4GB sources is pie-in-the-sky stuff. No one really has sources that need so much memory.
|
|||
![]() |
|
baldr
revolution,
fasm 1 is, by design, memory-hungry. At least when some advanced macros are used. I really should see that FASMCON 2009 presentation. ![]() |
|||
![]() |
|
revolution
Well I still have a copy, M2U00510.avi, 119124kB, 12m24s.
Although I have no idea how to send to you. ![]() |
|||
![]() |
|
vid
try to use yousendit.com, or something similar, if you have decent enough upload.
|
|||
![]() |
|
f0dder
Tomasz Grysztar wrote:
_________________ ![]() |
|||
![]() |
|
vid
And write it in some portable language! ... Oh well...
|
|||
![]() |
|
Alphonso
Ummm.. FASMW with AWE
![]() |
|||
![]() |
|
bitRAKE
baldr wrote: I really should see that FASMCON 2009 presentation. |
|||
![]() |
|
Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.