flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > new optimization algorithm

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Privalov wrote:
I have updated the guide to cover the interface changes made in the latest releases, so it may be useful info for people wanting to port fasm to some new OS. Other chapters still have not been written yet.


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.
Post 02 Aug 2004, 09:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
Post 02 Aug 2004, 11:13
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Privalov wrote:
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.
Post 02 Aug 2004, 22:26
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Aug 2004, 07:50
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Privalov wrote:
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,
not necessary for .com of binary files ,but aditional modifications are needed for executables. I don´t know very much about executable formats so i just added another pass.


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)
Post 03 Aug 2004, 08:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Aug 2004, 08:35
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Aug 2004, 09:21
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
I can't belive my eyes... Compiling Fresh took 81 passes, now it's just... 16 Shocked Great work!
Post 03 Aug 2004, 12:27
View user's profile Send private message Visit poster's website Reply with quote
fasm9



Joined: 19 Jun 2003
Posts: 439
fasm9
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 ...
Post 03 Aug 2004, 12:52
View user's profile Send private message Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
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?
Post 03 Aug 2004, 12:58
View user's profile Send private message Visit poster's website Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy
Quote:
I can't belive my eyes... Compiling Fresh took 81 passes, now it's just... 16 Great work!
Yes! Great work!!! Very Happy
Post 03 Aug 2004, 13:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Aug 2004, 13:52
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Really impressive! FASM becomes faster and faster. Smile
Thanks guys.

Regards.
Post 03 Aug 2004, 14:00
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
It's an amazing achievement Very Happy
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.
Post 03 Aug 2004, 14:14
View user's profile Send private message Yahoo Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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 Wink
Oh, and actually FASM should mean "Fast(est) Assembler" Smile
Post 03 Aug 2004, 14:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 03 Aug 2004, 15:35
View user's profile Send private message Visit poster's website Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Quote:
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.


I find that to be confusing, but I guess it works...
Post 03 Aug 2004, 15:36
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 03 Aug 2004, 15:39
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
[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
Post 03 Aug 2004, 22:32
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 04 Aug 2004, 00:00
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.