I was browsing Fasm source code, to gain more understanding of its internals, and noticed the heavy use of string instructions. Non repeated string instructions are quite slow in modern processors, and are used in Fasm sometimes in inner loops. Maybe they should be replaced for faster code?

But then, Fasm is already very fast

well, it still needs to remain readable and easily editable. But maybe some optimizations could be achieved by macros.

I am still optimizing mainly as if I was optimizing for 80386 - well, this one needs the optimizations the most, isn't it?

[EDIT]

heh, it seems I'm out of the topic, you're talking about non repeated string instructions...

[/EDIT]

I, personally, use macros like repmovs, repecmps, repnecmps, repstos, repescas, repnescas (replods is unnecessary). They replace original instructions with loops. They have two optional parameters:

• ecxz - test if ecx zero (rarely needed)
  
• rev - simulate DF=1 (default is DF=0)
  

repmovs and repcmps have additionally one more optional parameter - temporary register for memory-to-memory operation.

Examples:

Actually, this is what I am currently doing with my version of Fasm, and yes, you guess it, doing such optimization is actually rather superfluous, cause it takes an outrages amount of dump coding time with only weak effects on the execution speed, and furthermore it just bloats the executable a lot, since usual MOVs, INCs, DECs, ADDs and SUBs take up more space than shorte string instructions.

Yep, to do real optimization you would need to profile the code and see where Fasm spends its time. Thats just to much work for small gains.
Anyway, I also found a few "leftover" instructions in the code, maybe I'll report them as bugs if I find enought of them.

Right - it's so fast as it is, it's hard to imagine huge gains. When my projects takes less than a second to compile, I don't really need it to go faster.

FASM is very fast already. But, if removing or changing the string instruction usage would make it any faster, then good.
Most short programs assemble quickly, but long programs (for example FASM itself) can take a lot of time to assemble. I doubt if anyone here even uses the 386 anymore- to be compatible with 386 is one thing, but to be optimized for 386 seems to miss the point. Am I wrong?

I know some people using 386 machines and even using fasm there. And since on 386 it really takes noticeable time to assemble larger project, I see no point in making it slower there just to make it faster on some modern processor, where you won't anyway see the difference.

Also on the newest processors even non repeated string instructions seem to perform quite well. Not saying that the encodings are much shorter. And what work for the fasm's speed are mainly chosen algorithms, not chosen instructions.

I have a lovely 386 still running at home. There are a lot of tasks that this computer can accomplish and given its power consumption, it is optimal for an always on system. It doesn't even need a fan.

What are you using it for? Only thing that come to my mind is testing some OS code like bootloader... or an internet gate for local network (if 386 is enough for that...).
I have a working P166 box that is used only by my mother and only for chatting

I also have a running 386 that I run FASM on. It's a nice workstation for testing hobby OSes!