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

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).

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.

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 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

I'm attached to tradition. All my tries to use any other versioning system failed anyway.

but keeping release number only as seconds is just unconfortable

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.

As "few" as double - from 18 to 9. 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 now the bottle neck is at preprocessing again. It takes almost 50% of the compilation time.

Regards.

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.

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:


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!

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).

What can I say, outstanding...