Does the PB compiler unrole loops? Thats something you can blow your code and get a big performance plus.
I'd be careful with such optimisation tips on CPU-Level. And i would not really recommend Fred to use much time on this topic.
Because these sort of Optimization are heavily CPU dependen.
Unrolling Loops is just an example. If you unrol a loop, the whole loop may get out of the L1 Cache etc.
This sort of optimisations can also get obsolete or even worse contraproductive with each new CPU Generation.
The new CPU's have an advanced Loop-Buffer.
This makes the pipeline shorter. But Nehalem goes a step farther. Nehalem's loop stream detector is at the end of the pipeline. When it sees a loop, the microprocessor can shut down everything except the loop stream detector, which sends out the appropriate instructions to a buffer
Small loops do not get decoded mutiple times interanlly but stay inside the L1 cache.
TOM's Hardware
With the Nehalem architecture, Intel has improved the functionality of the Loop Stream Detector. First of all the buffer is larger—it can now store 28 instructions. But what’s more, its position in the pipeline has changed. In Conroe, it was located just after the instruction fetch phase. It’s now located after the decoders; this new position allows a larger part of the pipeline to be disabled. The Nehalem’s Loop Stream Detector no longer stores x86 instructions, but rather µops. In this sense, i
As you can read, small loop with 28 (around) Instructions run in "Turbo Mode", therefore by unroling over this amount you possibly would loose speed.
I think its on long term much better to take time and choose the best algo, then to try to squeeze the final cycle out of the CPU.
About the GOSUB. This is just a difference in Compiler-Design from Powerbasic to Purebasic. In Powerbasic I can use CALL (Label) inside a Procedure. In the same way I could write GOSUB and looking at the generated ASM Output, the Compiler would just make in both cases a simple CALL instruction. This is possible as the whole design of the generated Code seems to be different then the Purebasic code. Maybe because the Purebasic Compiler is based on a Multi-Platform Intermediate-Design.
Therefore in Purebasic other rules apply and there will be other Commands to use for such situations.
i wondered that there is a GOSUB in the Help-File and even a "FakeReturn" but it was said "only in the Main Procedure. Now knowing that this is by Design, the discussion is worthless as said.