home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 116,739 of 117,927   
   Stephen Pelc to All   
   Re: Avoid treating the stack as an array   
   15 Sep 24 15:04:11   
   
   From: stephen@vfxforth.com   
      
   On 14 Sep 2024 at 08:19:52 CEST, "Anton Ertl"  wrote:   
      
   > locals    stack   
   > 401       336   gforth-fast (AMD64)   
   > 179       132   lxf 1.6-982-823 (IA-32)   
   > 182       119   VFX FX Forth for Linux IA32 Version: 4.72 (IA-32)   
   > 241       159   VFX Forth 64 5.43 (AMD64)   
   > 163       175   iforth-5.1 mini (AMD64)   
      
   There are design decisions within locals that can impact optimisation.   
   The design of locals in VFX was influenced by Don Colburn's Forth's   
   and by a desire to use locals to simplify source code when interfacing   
   to a host operating system. Many operating systems return data   
   to the caller by passing the address of a variable/buffer as an input   
   parameter. Locals that can have an accessible address make such   
   code much easier to read and write. The example below comes from   
   early system access code in VFX (see kernel/386Lin/syspatch.fth).   
   The locals design dates from long before ANS.   
      
   $541B equ FIONREAD   
      
   : (OS_key?)    { | nread[ cell ] -- flag }   
     ?PrepTerm  nread[ off   
     nread[ FIONREAD stdin @ dll_ioctl @ 3 nxcall -1 = if   
       0                    \ Error return from ioctl   
     else   
       nread[ @ 0<>   
     then   
      
      
   : (OS_Key)    \ -- key ; SFP003   
     { | iobuff[ cell ] -- char }   
     ?PrepTerm   
     1 iobuff[ stdin @ dll_ReadFile @ 3 nxcall drop   
     iobuff[ c@   
      
      
   Code such as this has been around for a very long time and the use   
   of addresses of locals, and of local buffers, has proven itself over   
   time. Yes, we could put in a great effort to improve the performance   
   of locals, but this is Forth and there are other optimisations that may   
   produce bigger changes to application performance. In the last   
   decade or so there has been very little customer demand for   
   faster code. However, higher level source code has been much   
   in demand. An example is Nick Nelson's value flavoured structures,   
   which are of particular merit when converting code from 32 bit to   
   64 bit host Forths.   
      
   Just because many of the Forth applications visible to the Forth   
   community now run on CPUs with 16 or 32 address registers   
   does not mean that all systems can implement the compiler   
   techniques required for high-performance locals.   
      
   I can buy a lot of CPU cycles for the cost of one day of programmer   
   time. I am reminded when looking at locals that a client's Forth   
   engine is currently at 4GHz on a 12nm process. The performance   
   was detuned to 4GHz becuase the machine was more than fast   
   enough.   
      
   Stephen   
   --   
   Stephen Pelc, stephen@vfxforth.com   
   MicroProcessor Engineering, Ltd. - More Real, Less Time   
   133 Hill Lane, Southampton SO15 5AF, England   
   tel: +44 (0)78 0390 3612,  +34 649 662 974   
   http://www.mpeforth.com   
      MPE website   
   http://www.vfxforth.com/downloads/VfxCommunity/   
      downloads   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca