I spent the whole day trying to assemble a 22Mb source file (generated with a C program).
It contains 1,213,016 lines, the resulting code occupies 4Mb.

I first tested with NASM, but it gave me branch-out-of-range errors after line 500,000.
I then tried with FASM, but I get the error: "code cannot be generated", after 2 minutes.
(I spent a lot of time trying to get the ALIGN macro working, and found the solution on this forum)
Finally, I tried with MASM, and it assembles in less than 10 seconds !!!

I'm quite surprised by this result, and very disappointed by the time I spent on this problem.
If somebody is interested, I can post my EXE generator.

JC
Posted on 2003-06-14 16:23:09 by MCoder
Please do. I also recall Randall Hyde conducted some tests, and it turned out MASM assembled everything, and with fastest speed. FASM crashed at 40.000 line file if I recall correctly.
Posted on 2003-06-14 21:16:05 by comrade
That's just because of current 256-pass limit for optimizations; and fasm doesn't have currently non-optimized aasembly mode. But the current architecture allows this limit to be quite easily extended to 65536 if anyone needs it.
Posted on 2003-06-14 21:57:41 by Tomasz Grysztar
I've just uploaded the new experimental version (1.46.9.6) with the higher passes limit - please test it.
Posted on 2003-06-14 23:45:40 by Tomasz Grysztar
MCoder, was it not possible to generate code in memory rather than have big object?
Posted on 2003-06-14 23:55:18 by bitRAKE
Well, check by yourself.
I attached the generator (in FASM format) and its C source code (you can generate code for MASM/NASM/FASM by modifying the first defines).

It builds a 22Mb source file, and this source file has a LOT of branches, and also ALIGN.
Since my problem is now solved (and it took me one full day), I don't feel enough courage to test it again.

Also, I tried to assemble in COFF format with MASM, and it's incredibly slow !
MASM is fast only in OMF format (???).

Oh, last note: the generated program is a distributed project about magic knight tours. The EXE takes 4Mb, and is optimized only for P4.
I'm sorry, but it's really unreadable due to the use of optimizations...

JC
Posted on 2003-06-15 04:53:13 by MCoder
Wow, this monster took 1849 passes to resolve!
Well, the another solution would be to enable some non-optimizing two-pass compilation mode for FASM, if anyone thinks he needs it - please post here; if there's enough interest I'll think about implementing such mode.
Also it would be done just by putting the appropriate size operator for every jump etc.
Posted on 2003-06-15 05:46:54 by Tomasz Grysztar
If you implent an unoptimized compile mode, would then be best to let the sources decide wether to optimize or not?
lets say you implent it and you add a directive such as Optimisations On/Off, that is put in the beginning of the sources like the format directive, default is Optimizations On.
Or Could it be possible to have the developer select pices of code that should be optimized and which shouldn't, would that involve too much work?
or ecx,ecx

jae @F
Optimisations On
.be:
mov eax, 5
add ecx, edi
mov ebx, [ebp+ecx*2-1]
test ebx, esi
jnz .be
jmp @F
foo db "Odd"
Optimisations Off
@@: nop


You say "Also it would be done just by putting the appropriate size operator for every jump etc.", does this mean, if I say "jmp dword @F" and so I can shave of a few passes?
Posted on 2003-06-15 06:41:54 by scientica

You say "Also it would be done just by putting the appropriate size operator for every jump etc.", does this mean, if I say "jmp dword @F" and so I can shave of a few passes?

Yes, that's exactly what I mean.
I've tried it - with all jumps provided with "dword" operator it took only to 2 passes to compile, but the size of object grew from 4 281 856 to 4_745_216 bytes. Also the parsing stage is very slow in this case, because the hash tables are not very effective with such huge amount of similar labels. I guess hash tree would do it much better, but it's quite hard to implement it with current fasm architecture (static memory blocks - that's because of portability reasons).
Posted on 2003-06-15 08:21:44 by Tomasz Grysztar
I think it is a good idea to implement such a feature (turn optimizing on and off in the sources by a directive, and then specify the size of the operand by for instance type "jmp byte @F")... Keep up the good work!
Posted on 2003-06-15 11:59:17 by Tommy

I think it is a good idea to implement such a feature (turn optimizing on and off in the sources by a directive, and then specify the size of the operand by for instance type "jmp byte @F")... Keep up the good work!

That would be too much - if you turned optimizing off, you wouldn't need to use size operators, and whe you use size operators, it doesn't matter whether optimizations are used or not.
Posted on 2003-06-15 15:48:24 by Tomasz Grysztar
Oh...sorry...:stupid: I see...
Thanks for correcting me!
Posted on 2003-06-16 01:02:48 by Tommy