Hi,   
      
   On Monday, May 1, 2017 at 10:55:02 PM UTC-5, Jim Leonard wrote:   
   > On Monday, April 10, 2017 at 8:36:08 AM UTC-5, Robert Prins wrote:   
   > >   
   > > All part of a process to convert a Pascal program into pure assembler,   
   which has   
   > > now reached the stage where all code is actually in-line assembler, making   
   the   
   > > program rather a lot smaller, and about three times as fast. ;)   
   >   
   > This feels an awful lot like a question you could answer yourself.  In fact,   
   I'll bet you already have...   
      
      
   Not feeling very helpful today, are we, Jim?   ;-)   
      
      
   Robert, I've not looked at your code. In fact, I somewhat doubt I   
   could help. (I don't really understand FPU/SSE.) But since you claim   
   you have a pure Pascal version, I would indeed be curious to run it   
   (preferably in pure DOS). Then again, I think you said it runs in   
   less than a second, which is hardly a worthwhile benchmark.   
      
   Just to explain, I've recently tested some compilers (GPC, FPC, TP55,   
   VP21) and various high-level tricks to optimize their output. Nothing   
   fancy, just mild curiosity.   
      
   For GPC, the obvious answer is attribute(inline) or let it do it   
   automatically with either -finline-functions or -O3.   
      
   FPC needs "inline" function directive (and -Si). I've seen you   
   complain about FPC before, but it matches (GCC 3.4.6 / 2005) GPC   
   in output speed nowadays. Seriously, I would reconsider and try   
   FPC again. It's very good.   
      
   TP55 (and similar) are too old but still work fine. There are   
   various speedups available there, but of course there are better   
   compilers nowadays, too.   
      
   I think you said Virtual Pascal is slow and generates lousy code.   
   Not quite true. Sure, it doesn't go past 586, but it's not really   
   slow. It also has the (Delphi-ish) inline function directive   
   (same as FPC) but in much more limited functionality, so it's not   
   nearly as useful. Still, it can help a lot.   
      
   The other problem I noticed is that VP does indeed claim to   
   use (186+) ENTER/LEAVE for nested procs. The docs said that   
   was for 586, but AFAIK that is for all targets (386, 486, 586).   
   The docs say it was faster on an actual 586. But I've seen this   
   problem before. On my Core i5 (admittedly somewhat old, Nehalem   
   Westmere), that kind of code, when heavily used, is actually   
   four times slower than the older 8086 equivalent. So try   
   "flattening" your source to avoid nested procedures (move   
   them to global scope) and re-benchmark it. It really helps!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)