flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > new optimization algorithm

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
comrade



Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation
comrade 04 Aug 2004, 02:35
Privalov wrote:
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.


The seconds in PKZIP are reduced precision by 1-bit. 8 seconds means revision 4?

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 04 Aug 2004, 02:35
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Aug 2004, 09:14
Yes, 8 was revision 4, because there was no revision with 6 seconds, only 0,2,4,8 and now 10 (though sometimes I would use 16 instead).
Post 04 Aug 2004, 09:14
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Aug 2004, 12:01
And the current revision has 12 seconds - I considered the virtual blocks too, and this way got still a few passes less when assembling Fresh.
Post 04 Aug 2004, 12:01
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica 04 Aug 2004, 13:04
IMO the best way to denote versins+"subverions" is the *nix defacto stanard convension for versioning:
1) Major.Minor.Build-release
(sometimes Build is used as an "minor.minor" version or omitted, the relase tag is mostly used by rpm packets)
or why not the kernel way:
2) Major.Minor.Release-extraversion, where the minor denoted stable/development (odd=dev, even=stable, the Major nly changes when something "big happens")

IMO 1 siuts the ok for fasm, eg, we'd now be having release 1.53-3 (if I haven't lost my count).
IMO 2 is better(best, since this new algo can be tested in a controlled manner - eg:
release 1.54 (the current 1.53-3 or 1.53-2 (without the new algo))
make 1.55 is the current development version, 1.55.1 would be next development version - which contains fixups (bitwise;))or new features to test.
once the new features have gotten "tried and true"/"stable" you could release 1.56, or if the change is minor, release 1.53.4 - which is (then) the latest stable version.
This way people can use the "tried-and-true"-stable version without having nightmares over the newest feature Wink and we/those who like to live life "dangerous", or want to help test new versions simpl get the latest dev version.

and about the "-extraversion", eg, 1.53.3-sci (or 1.53.3-perm or 1.53.3-up ) could be the "unsafe permissions" patched branch Smile
Post 04 Aug 2004, 13:04
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Aug 2004, 13:16
I'm attached to tradition. Wink All my tries to use any other versioning system failed anyway.
Post 04 Aug 2004, 13:16
View user's profile Send private message Visit poster's website Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard 04 Aug 2004, 13:47
but keeping release number only as seconds is just unconfortable Confused
Post 04 Aug 2004, 13:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Aug 2004, 14:07
This is not really release number - it's a kind of mark just to indicate some version was compiled later, there never was any rule for it. I was always using it in case of small knick-knocks and cosmetic changes with sources and therefore my scripts handle it for me. But when the latest version is indicated to be older than a few days, you can be sure the "cosmetics" period has ended and you've got the really final one.
This is relict of past, but is comfortable for me - also, as I said above, the most of the useful reports I get after releasing "stable" versions, it always takes up to the week to finish with all those small updates then.
Post 04 Aug 2004, 14:07
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 04 Aug 2004, 14:40
Privalov wrote:
And the current revision has 12 seconds - I considered the virtual blocks too, and this way got still a few passes less when assembling Fresh.


As "few" as double - from 18 to 9. Very Happy Great work! Now the pass count is equal to that with optimization switched off, and the time is even shorter because of smaller load of the preprocessor.

But there are bad news too Wink now the bottle neck is at preprocessing again. It takes almost 50% of the compilation time.

Regards.
Post 04 Aug 2004, 14:40
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 04 Aug 2004, 16:07
JohnFound wrote:
But there are bad news too Wink now the bottle neck is at preprocessing again. It takes almost 50% of the compilation time.

These are actually good news, I see many places in preprocessor that still would get improved a bit, so this is again something I can work on.
Post 04 Aug 2004, 16:07
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation
comrade 05 Aug 2004, 05:08
This is great!
Not only fasm now compiles a project in less passes (11 -> 4), but it makes smaller code too! I have compared outputs from 1.52 to 1.54, and found a few short jumps (<127 range) that were encoded as long jumps:
Code:
1.52: 0F 84 7D 00 00 00
1.54: 74 7D    


So we can consider this not only an optimization, but also as a bug fix? I mean, 1.52 took 11 passes but still could not shorten the jump.

Does the time also decrease? For me 11 pass compilation 1.52 and 4 pass compilation by 1.54 both took 0.7 seconds. Perhaps the project was not large enough.

Thank you, Privalov!

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 05 Aug 2004, 05:08
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 Aug 2004, 05:25
Yes, I have already written about it in my fourth post here. But I wouldn't call it "a bug fix", since there is no algorithm that could guarantee generating smallest code - it all need to be based on heuristicts, and this one just gives better results (I'd say: unexpectedly good, if I had known that such simple heuristic would give such large improvement, I would have implemented it at least two versions ago).
Post 05 Aug 2004, 05:25
View user's profile Send private message Visit poster's website Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy 05 Aug 2004, 07:46
What can I say, outstanding... Cool
Post 05 Aug 2004, 07:46
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 Previous  1, 2

< 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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.