I have done some changes in fasm ,and it works ok with .com files
but .exe files had errors in the relocations table,
could you explain please, how rellocations work ,and for what are used
the 24 byte struct that stores label info.

Some info was posted here: http://board.flatassembler.net/topic.php?t=639#4075

Thanks but i don´t know what fasm does with all this data.
i solved the problem forcing the assembler to do another pass.
the attached file is based on fasm 1.51 beta 1 i have modified
some lines of code related to label offset calculation ,now fasm assembles
itself in only 6 passes and generates the same code than fasm 1.51
i don´t know if this algo can have some bug ,check it.

This is a nice trick - after analysing it I think it should not do any harm, while it does a good prediction of moved label values, I even think that additional pass is not really necessary for it to work, i will try to implement a simplified version of this algorithm for a new fasm.

simplified? i just modified about 20 lines of code. (not optimiced)

But the additional pass is really not necessary.
Some other modifications are needed, though. So I guess it won't be really simplified. I should have used the word "modified".
The only problem the algorithm might cause is with mispredicting some forward-referenced symbols that are not directly related to the position - I'm not sure, but it could lead sometimes to infinite loop, I'll have to rethink it - it was the main reason why I never implemented such solution, but your simple implementation has made me think again.

I got rid of all the potential problems by using additional flag to mark whether symbol can be adjusted. Also, as it adjusts only the symbols that need it, it is even more efficient this way (got it to 4 passes and few more bytes optimized).

The official 1.54 now uses this algorithm, since I believe it's reliable in this variant.

Great thanks for pointing it out that this kind of improvement is possible. It's perhaps the most valuable submission to fasm made ever.

I can't belive my eyes... Compiling Fresh took 81 passes, now it's just... 16 Great work!

i don't know well, but it seems to be good thing.

Thanks!

--
PS: why don't you make subversion?
for example:
fasm-1.54.1.tar.gz
fasm-1.54.2.tar.gz ...

I agree that subversions are needed. If I have 1.54, and you update it, breaking compatibility somehow, how will I know why one copy works and another one doesn't?

Yes! Great work!!!

The "subversions" are marked with the number of seconds in the time of last modification of all files in the official packages. The most recent 1.54 has is set to 8.

Really impressive! FASM becomes faster and faster.
Thanks guys.

Regards.

It's an amazing achievement
Congratulations.

Fasm compiling itself...with a very outdated computer...

flat assembler version 1.54
4 passes, 0.7 seconds, 65536 bytes.

flat assembler version 1.53
45 passes, 2.1 seconds, 65536 bytes.

Just one more thought.
Privalov, maybe documenting FASM internals is something that you should give more attention? We know that you don't have enough time for everything, but this could bring more ideas about making FASM faster, and just better
Oh, and actually FASM should mean "Fast(est) Assembler"

And this monster: http://board.win32asmcommunity.net/showthread.php?s=&threadid=13854
now assembles in 6 passes only, and still generated code is smaller by 173 bytes than the one generated without this improvement.

BTW, I have changed the default limit for passes to the original 100 (this limit was used by fasm 1.0), with this new algorithms changes that something will need more passes are very small, but you can change this limit from command line with the "-p" setting (see updated documentation).

I agree that I should finish that internals documentation as soon as possible, but it's very hard to write it, when internals are constantly changing. I first have to arrive at the level of their development, where I will feel it's near to the final one.

I find that to be confusing, but I guess it works...

I decided to use this kind of "invisible" updates after I have noticed, that I get most of the bug reports etc. after the official releases - people tend to wait for the "stable" release before replacing the executable they're using, and only then the new release is tested enough.
But I do change version number if I add some new features (entries marked with plus in the whatsnew.txt).

[quote="Privalov"]I got rid of all the potential problems by using additional flag to mark whether symbol can be adjusted.
Yes this was my intention but i don´t know fasm source well enough,
only offsets betwen current position and next 'org constant ' should be adjusted and the org directive should set ajuste=0

It wouldn't make any noticeable difference, as after the "org" directive the adjustment is anyway most probably mispredicted, and will be fixed by the first (any) label definition, which will provide the new valid adjustment for the following code (the same goes for all other directives which affect the org origin value). And since it is the most likely that some kind of label will be defined right after "org" before any forward-reference, it won't do any difference at all. Note that if you forward-reference symbol defined after "org" in the code before the "org", the adjustment will be wrong anyway - there is no reliable method to determine to which addressing space the given symbol belongs, there is a possible solution of extending the symbol structure to hold the org origin address for each symbol, but that would be a much more complicated change which I'm not sure that would be worth the effort; though it still might improve things a bit for a sources with a lots of cross-linking between different code spaces. However - the beauty of current solution is its simplicity, while it gives really good improvement on assembling the "standard" sources. Some mispredictions in intermediate passes don't hurt much - they are resolved consecutively, as the area with zero adjustment enlarges, and they will be happening anyway, even within a single code space (for examples when some label is forward-referenced very far from where it's defined).