PlayBASIC To DLL (Development Blog)

[kevin]

 Unfortunately, there's no order emails here for PB2DLL.  Although when i look in the shareit account there are new PB2DLL orders listed, but it hasn't sent out those to me.. No idea why.. Although it's happened before.  

 I'll try and manually process them in a minute, which is likely to take about 30 minutes..  



  Update: All orders have been dispatched.

[ATLUS]

Good.
Now i try to convert file water, first time it convert ok, i deleted dll and try to convert again and tool write: "This program source code does not contain any DLL exportable function, aborting "

[kevin]

Good.
Now i try to convert file water, first time it convert ok, i deleted dll and try to convert again and tool write: "This program source code does not contain any DLL exportable function, aborting "

  which file did you pick ?  If you select Example/water/Main.PBA you'll get that error, it's not an appropriate source (has no exportable functions) to convert.   Inside the Examples/Water project there's another folder called DLL, inside that is the Example/Water/DLL/Water.pba source file.     That's the actual DLL code.  

[ATLUS]

Now i understand, thank you!

[kevin]

  PlayBASIC To Dll -  In-lining More Math Functions

      The generation engine has been up and running for a while now, but it's still relatively young solution, it'll be a while till it matures.   One of the things on my to do list is inline pretty much every common place math function where it makes sense to do so.   It actually handles a bunch of then already, but the more the better.  

      This afternoon I've been looking at the getDistance2D function (still don't like that function name) as a possible candidate.  It's one of the situations where a lot of code is generated just to call the function (before it even does anything), in particular if the input parameters are of the wrong type.    Most math functions expect floats, so if you pass integers, the caller will cast them into temps for you.  Which is nice and all, but not ideal if you want lean and mean code produced.  

      Now since the the floating point unit in your CPU has a square root built in, the actual operation can be performed directly on the FPU.    Which not only turns out to be less code than calling the function, it performs a much much better also.   To bench mark the performance, all i'm doing is scanning through the screen of coordinates and calculating the distance to the fixed point.    I'm not plotting anything, just doing brute force square roots.    

     The code bellow originally ran on average at 149.5 milliseconds when built with previous editions of PB2DLL, but with today's build, it executes in 10 milliseconds on average.    For a 800*600 screen mode that's 480,000 square roots   (Test system 9 year old Althon FX64 3000)

     The result is an almost 15times performance boost.

PlayBASIC Code: [Select]

Function DLL_ComputeSquareRoots()

      Width=GetSurfaceWidth()
      Height=GetSurfaceHeight()

      midx=width/2
      midy=height/2

      for ylp=0 to height-1
         for xlp=0 to width-1
            Dist=GetDistance2D(xlp,ylp,midx,midy)         
         next
      next

EndFunction

  See ->  Sinus Rendering Example (Compares PB2DLL V099 to V099a)

[kevin]

  PlayBASIC To Dll V0.99a  Released and Available For Download


     Here's the first revision for the PB2DLL package.   The main changes are in the code generation routines for more common math functions being assembled in line so they can be executed without have to call functions.  This can give us some dramatic performance improvements over calling the internal function library inside PB.     


     These couple of translations improvements


  Download:

      To download use the link that was assigned to you from your registration email.   That link will always return the latest edition of PB2DLL to you. 



  History

 

Code Select Expand



V0.99a   May,2014  -6th,June, 2014 

Code Generation:

- RgbAlphaAnd(), RgbAlphaOr() & RgbAlphaXor() functions are now trapped and inlined
  on demand. 

- GetDistance2D(X1,y1,x2,y2) is trapped and placed in line for the FPU.
  The call is about 50% less code when passing floats to the function and probably
  75% less code when passing integers in.  Speed wise it bench marks up to 15 times  faster. 

- Cos/Sin functions are resolved now directly in line on the FPU for you.


Fixes:

- Sqrt() & ABS() decoders didn't move the PC correctly causing the parser to get
out of alignment... Throwing a bunch of bogus errors after those statements

                  - Tweaked the rego field screening to only accept characters between ASCII 32 to 128
                 

 

[kevin]

PlayBASIC To Dll -  New Product Hiccups

       The interest in the PB2DLL is slowly by surely building, it was never going to be 'explosive'  opening that's for the sure.   None the less, hopefully we'll see some locals trying to push the bounds of what was thought to be possible in PB as time ticks on, perhaps hammering out some libraries.  Perhaps tacking some of those crazier demo effects.   
             
        Things haven't entirely gone to plan though, there's been a few hiccups occurring in the ordering process (It took them 3 days to send  the initial orders to me.. yeah WTF)..  There's been a few activation issues and even some dialog problems.   Haven't resolve them all as yet, but are working on it ! 



Optimization - Sinus Render
     
        Improved the conversion quality some more with it being able to inline all the common sin/cos functions.  Stuff like SinRadius SinNewValue, which are uses to plot polar coordinates. 

        The functions bellow solve as one chunck of hand optimikzed assembly. 

PlayBASIC Code: [Select]

         for angle=0 to 360      
            x=cosradius(angle,100)
            y=sinradius(angle,100)
            fastdot 400+X,300+y,$00ff00
         next
      
         for angle=0 to 360      
            c#=a#+b#
            x=cosnewvalue(400,angle,20)
            y=sinnewvalue(300,angle,20)
            fastdot X,y,$FFff00
         next

      



         Just by writing directly to the destination buffer you can double the performance of the sinus render. 

PlayBASIC Code: [Select]

      lockbuffer
      ThisRGB=point(0,0)

   /*
      for ylp=0 to height-1
         for xlp=0 to width-1
            Dist#=BaseAngle#+GetDistance2D(xlp,ylp,midx,midy)         
            Dist=sin(Dist#)*100.0
            fastdot xlp,ylp,Rgb(Dist,Dist,dist)
         next
      next
   */
      Ptr   =GetIMagePtr(0)
      Pitch=GetIMagePitch(0)

      for ylp=0 to height-1
         RowPtr=Ptr+(ylp*Pitch)
         for xlp=0 to width-1
            Dist#=BaseAngle#+GetDistance2D(xlp,ylp,midx,midy)         
            Dist=sin(Dist#)*100.0
;            fastdot xlp,ylp,Rgb(Dist,Dist,dist)

            POkeint RowPtr,Rgb(Dist,Dist,dist)
            RowPtr+=4

         next
      next
         
      
      unlockbuffer

PlayBASIC To Dll - Next Update ?

        I'll be uploading a new build (with some crazy debug logs in it) later on tonight (my time)..  I'm just testing an alternative LoadDialog function now,  if it behaves ok then i'll try and exchange with the PBdialogs version.

[kevin]

  PlayBASIC To Dll V0.99d  Released and Available For Download

    Here's the second revision for the PB2DLL package.   The main changes are two fold, firstly it's  is built using the latest edition PlayBASIC V1.64P (Beta 41),  and it in includes more math function solvers to in line common PlayBASIC math functions.  



 Download:

     To download use the link that was assigned to you from your registration email.   That link will always return the latest edition of PB2DLL to you.  



 History

 

Code Select Expand





V0.99c   May,2014  -7th,June, 2014  

Code Generation:
- COSRADIUS & SINRADIUS resolved directly on FPU
- COSNewValue & SinNEwValue resolved directly on FPU

Fixes:

                 - Re-Tweaked the rego field screening :(
                 


V0.99a   May,2014  -6th,June, 2014  

Code Generation:

- RgbAlphaAnd(), RgbAlphaOr() & RgbAlphaXor() functions are now trapped and inlined
 on demand.  

- GetDistance2D(X1,y1,x2,y2) is trapped and placed in line for the FPU.
 The call is about 50% less code when passing floats to the function and probably
 75% less code when passing integers in.  Speed wise it bench marks up to 15 times  faster.  

- Cos/Sin functions are resolved now directly in line on the FPU for you.


Fixes:

- Sqrt() & ABS() decoders didn't move the PC correctly causing the parser to get
out of alignment... Throwing a bunch of bogus errors after those statements

                 - Tweaked the rego field screening to only accept characters between ASCII 32 to 128
                 

 

[kevin]

  PlayBASIC To Dll -  Register Optimization (Serialization)

       Work on PB2DLL has been two fold, a cross between those GUI & file system niggles and the conversion engine itself.   Yesterday work focused upon the conversion engine,  where  previously the core math operations had been solved to emulate the behavior of the runtimes.     The compiler does a fairly good job of removing redundant moves from the byte code version of your source code, but there are times where you end up with a serialized run of operations. An example of such an expression that would create this pattern would be  A=B+C+D+E.  So the resulting compiled code is effectively tallying the result in a register waiting to put the final answer in some other variable.   In previous versions of the translator the tallying would still hit memory.   But not in today's build.  

       Now today people seem to think that memory access is super fast and abundant due to the x86 clever designs,  when the reality is quite at odds with that belief.   Your CPU has a limited number of on chip registers (think of them as variables).  Register values are stored in the fasted memory in your entire computer.    When a chunk of code read  / writes from system memory the cpu manages this process through levels of cache.   Cache is smaller chunks of on CPU memory that's faster again than your system memory.   Moreover modern chips are also smart enough to cache successive memory / register accesses in what they 'virtual registers', which are registers that don't exist to the user, but are substituted at the micro code level before code is executed.   CPU have all this to avoid reading or writing from memory.  

      Ok.. so what we can take from all that, is that anytime we hit memory we're losing some performance.  Therefore it makes a lot of sense to hold temp values in chip registers where ever possible.  Since we're in x86 land here,  this is not always possible since we don't exactly have a wealth of on chip registers or the implementation of the instruction (like in the FPU) can at times require reading / writing to memory.      

      What today's addition does, is it implements a look ahead mechanic into the translator.  The routine scans for obvious situations where a result of some operator can be held on chip and solved in series.    So far, the solver only handles integer sequential expressions that use the +, -, / , *, AND, OR , XOR, <<, >>. (Yes.. I'm going to add more)

      It's worth mentioning that the order of operations has to be respected for the following code to translate on chip.   So an expression like    A=B+C+D+E  can be solved in order on chip (since they're all the same operation level), removing at least 4 temporary read / writes from memory.   So it'll execute much faster.  But if you're expression was something like this, with a mult in the middle of some adds  A=B+C*D+E, then this can't be fully solved on chip (as yet), mainly due to how the PB compiler deals with the order of operations in such expressions.  Meaning the translator would need to learn more about how the expression is unfolding (top to bottom), but for now it's an marked improvement.

     You can get  A=B+C*D+E to solve completely on chip though, just be rearranging the expression and moving the higher precedence operators to left of the expression. This gives the same result A=C*D+B+E and avoids any temporal memory usage.  

      When we get a serialized run, the code generator can reduce your code to one instruction per operation for the aforementioned supported core operators.  Mult & Divides need more instructions unfortunately which is just how x86 does things.  

   
     All of this was added yesterday, Tonight's little challenge is going to be build something that can handle serialized floating point math operations.  These a bit harder than integer registers given how the FPU instruction set work, but we should be able to remove fair amount of memory thrashing also.  


      Bellow is just some same code integer only i've been bench marking performance with.

PlayBASIC Code: [Select]

Function DLL_TestTally(Max)

      a=100
      b=200
      c=300
      d=400

      For lp=0 to max

         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   

         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   
         result=a+b+c+d+20+a+b+c+d   

      next


EndFUnction result

 

[kevin]

  PlayBASIC To Dll -  Dialogs Replacement

      The first releases of  PB2DLL use the PBDialogs library for an easy interface to windows common dialogs library, the main stuff it requires are the Load/Save file dialogs / Find Folder dialog and the text input dialog.   Now i've been looking at replacing that library with a simple library.  The load/save dialogs turns out to be easy, then we hit FolderDialog problem.    This particular dialog is one of the easier ones visually but it's implementation (in windows) seems rather under done.   All because you can't set the initial path of the dialog without sending it a message from a it's own callback.    Without this it always starts at the computer level.    Which is ok for the initial search I guess, but just creates extra clicks in a repetitious process. 

      To solve the Folderdialog problem has meant including some functionality in the VM just to manage the callback side of it, so todays build of the WindowsDialogs library will only work in V1.64P or above.    Moreover, another annoying thing about them is you can't easily control the position of the dialog.  The folder dialog window seems to ignore all positioning for some reason.    No idea why..

      Originally I'd assumed the InputDialog in PBDialogs was a common dialog,  like message box for example, but it's apparently a custom one.   So we can't just call the API directly to get a replacement.   After thinking about it, I've decided to go a different way with it.     That functionality is only used in the registration window.   Which requires the user to cut'n'paste their fields individually.  However a method i've been using more recently is clipboard monitoring.   This way the user opens the rego dialog and clicks the 'cut'n'paste' fields button (will prolly rename that).   This dialog waits for a minute, while the use opens their rego email and grabs all the fields together.  PB2DLL examines and reacts to any the text in the clip board.    If it find some suitable fields in the clipboard text, it parses the Name,Email + Key fields into the dialog for you.  Making it a two click process.     

      So that's where at this afternoon,  with any luck we'll get all the components hooked together tonight and uploaded soon after.    Can't say i'm 100% sure this will solve some of the dialog drama, but even it if doesn't, the dialogs are slightly newer in terms of controls and therefore that little bit more flexible. 

[kevin]

  PlayBASIC To Dll V0.99f  Released and Available For Download (18th,June,2014)

     Here's revision F of PB2DLL V0.99 package.    This revision sees changes made to the both the GUI and code generation engine.   For the GUI side of the application we're change out the dialog libraries in favor of smaller replacement.   This gives us some generally better behaved dialogs with better features, but it has meant needing to the change the Registration Dialog

   
  Registration Dialog Changes:

       This dialog changed on 18th,June,2014.   The Original version of the dialog had three separate buttons.  The user would cut'n'paste each field separately, then hit the activate button.     This has been replaced to in favor of a single button called Set User Details. 

      When you click this button the software goes into a clipboard listening  state, where it's waiting for some text to be copied from another application.    So PB2DLL now expects the user will open their registration email and collectively select and copy the three important lines of the text from it.   The lines it wants, are the UserName, UserEmail & Serial lines all together as one chunk of text.    When PB2DLL notices new text on the clipboard, it parses it for looking for those important fields.   If it understand the lines of you copied, you'll get a successful message, other wise it'll continue waiting.   

       Once you've clipped your text and it's parsed it, hit the activate button as normal.



  Code Generation:

      This build include the most recent version of the code generator,  one of the newest features would be the ability to identify serialized runs of the math operators, be them Integer or floating point.  What this does it means the sequence of instructions can be solved without read/writing temp values back to memory.   So they're solved using on chip register.   Given that edition used the very  first edition of the generator, it's not a magic bullet, but can give a very healthy boost to long expressions of operators.

      The integer solver can handle ADD,SUB,MULT,DIV, AND,OR,XOR and the shift left <<  and shift >>  right operators.    So an some expression like  result=A+B+C+D+E+F only ever writes to memory when dropping the result into the result variable. 

     The floating point solver only handles ADD,SUB,MULT,DIV operators at this time. 




  Download:

      To download use the link that was assigned to you from your registration email.   That link will always return the latest edition of PB2DLL to you. 



  History

 

Code Select Expand



V0.99e   16th,June, 2014 - 18th,June, 2014

GUI:
- Replaced PBDialogs library with a custom solution.
- Changed the Rego dialog to use clipboard monitoring


V0.99e   13th,June, 2014  -14th,June, 2014

Code Generation:

- Added serialized solver for runs of INTEGER opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV
  / AND/OR/XOR/ shifts << and shift >> operators

                    eg.
                          result = 10*A +B - C <<2 >> 8   
                         
- Added serialized solver for runs of FLOAT opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV

                    eg.
                          result = 10*A# +B# - C#



V0.99c/d   May,2014  -7th,June, 2014 

Code Generation:
- COSRADIUS & SINRADIUS resolved directly on FPU
- COSNewValue & SinNEwValue resolved directly on FPU

Fixes:

                  - Re-Tweaked the rego field screening :(




V0.99a   May,2014  -6th,June, 2014 

Code Generation:

- RgbAlphaAnd(), RgbAlphaOr() & RgbAlphaXor() functions are now trapped and inlined
  on demand. 

- GetDistance2D(X1,y1,x2,y2) is trapped and placed in line for the FPU.
  The call is about 50% less code when passing floats to the function and probably
  75% less code when passing integers in.  Speed wise it bench marks up to 15 times  faster. 

- Cos/Sin functions are resolved now directly in line on the FPU for you.


Fixes:

- Sqrt() & ABS() decoders didn't move the PC correctly causing the parser to get
out of alignment... Throwing a bunch of bogus errors after those statements

                  - Tweaked the rego field screening to only accept characters between ASCII 32 to 128
                 

 

[kevin]

  PlayBASIC To Dll -  Bug tweaking &  Even Better Code Generation

      While working on the G2D library I've discovered a few well hidden faults in PB2DLL, ranging from the some entry point trapping through to a few instruction combinations that it didn't support, but didn't pop errors from.    It's trickier than you might to  catch every permutation of VM opcode as many of those opcodes aren't single purpose !    So given the size of the instruction set, it's obvious such issues will happen.   Generally it's those lessor known or lesser used features that tend to break a translation now, but there will still more of them hidden away ! 

      One of the strange things that I've seen happen in various DLL's now is they cause strange crashes on exit from PB, when bound and executed from memory.  This turned out to be due to strange behavior of windows ( yet another one ) where it called the entry point (the dll's start up function) when the DLL was being closed. Why ?  I've no idea.. but it must have seemed like a good idea to them at the time.  Sorted it was easy enough, just meant tweaking the templates.

      Beyond just bug fixes,  I've been using the odd dev session to continue improving the translators Code generation, in particular when it sees serialized statements.  When such things occur, the solver can avoid hitting memory with temps.    The previous version of the solver was generally left handed.  Meaning that depending on the operation,  calculations that solved naturally left to right, would serialize easier than expressions that solved in a mixed order.   Which is a little more cumbersome to solve efficiently.     

      So to improve the code generation, i've dropped in some temp mapping to the expression solver.   The mapping tracks where the cumulative result is stored, which allows it to create better code from those unnatural expressions.    The integer solver has been further expanded to handle more common operations, namely the comparison operators and branching operations.   Which allows the translator to create better assembly from an expression like   (a=true) and (B=True) 

     Examples Misc,

   

PlayBASIC Code: [Select]

      if (a+a)=b
            print "Yeah do this"
      endif

      if b=(a+a)
            print "Yeah do this"
      endif

      if a
            print "Yeah do this"
      endif


      if a=b
            print "Yeah do this"
      endif
      
      if a=b and c=d
            print "Yeah do this"
      endif

  
    

    Simple expressions like  if a=b are really  two operations in the legacy runtime.    There's an equality  test  between A and B,  where the result is stored in a temp VM register.    Next there's compare with branch opcode on the value in that temp register.    So in the VM that's really two VM opcodes being created.   

    In the first versions of the PB2DLL, those opcodes would be translated separately.  This gives us cookie cutter code, that's obviously neglecting the data's path way (Ie. the comparison is being used in a decision).   But  now the solver can now look ahead, it'll see the CMP /BRANCH statement after the equality test and dump more  stream lined assembly code, avoiding temp data being written and read back from memory.   The solver could actually shorten this further, but  I'm trying to avoid over complicating it for a time being.   

    Most of the other expressions above will solve without hitting memory, except the last one if a=b and c=d, where the initial compare result isn't used immediately in the next opcode, thus breaking it's chain.   The other statements within that expression will though, so there's still a gain.


   To give you a clear idea of just how effective this technique really is.   If we have some cumulative expression like this   Result=A+B+D+E for example again.   PlayBASIC2DLL code generator gives us a virtually one to one mapping with assembly output, it doesn't get any quicker than that !

[kevin]

  PlayBASIC To Dll -  Breaking the one second mark for fractal render

       After tweaking the floating point code generator just a little, we get an even more staggering result from the previous fractal test, which now is rendering inside a second for a 640*480 screen on my test machine AMD FX64 (3000+).    The result gives us about 150 millisecond improvement over the initial test, so even the first versions of PB2DLL are surprisingly optimal, in particular when you compare those results to the primary competitors.   PB2DLL is consistently 3.5 times  faster than one and 5.2 times faster than another..    

       In this particular example the routine has a lot of dependency, by that i mean, calculations need to be done in a set order.  I suspect if the generator could interleave some of the FPU instructions around integer instructions, we could go even further though.   This is possible as the integer and float (FPU) sides of your CPU can actually run in unison.    Instruction operations on either side can generally overlap other instructions also, providing the following instructions don't rely upon the result of a previous instruction.      So we could interleave instructions that take a long time to execute around other instructions as long as they don't rely upon the result.


      Note: The original code/demo is attached to an earlier post in the PB2DLL WIP thread, it's exactly the same code.

[kevin]

  PlayBASIC To Dll V0.99g  Released and Available For Download (30th,June,2014)

     Here's revision G of PB2DLL V0.99 package.    This revision is focuses on bugs and the more improvements to code generation engine.  The main bug that this update fixes is the possible freeze when attempting to load a PBA that's has no exportable functions in it.   It was a strange issue, caused by the Replace$() function in PB, but that's been solved now.    So if you select a source that has no exports, you should get an error message, rather than it hanging. 


   
  Code Generation:

      Just like the previous build i've been working on improving it's detection and abilities to solve sequences of byte code operations in order and with in CPU registers.  The solver can support integer and float data types mainly. SO it's looking for sequences of integer or float operations that stack up in sequence.  When it finds one, it short cuts this series of instructions.   

      The Integer solver has three main additions, it support equality tests (= and <>) ,  Compare/Branches as well as better support for Left/Right hand operators.   The latter allows it to better track where which side of the temp data came from, then remap the operator accordingly. 

       On the float side, the changes are a little different,  the float solver can handle recasting results and some limited single parameter functions like Sqrt(), ABS() as well as the normal addition/subtraction/Divide/Multiplies. 


  Download:

      To download use the link that was assigned to you from your registration email.   That link will always return the latest edition of PB2DLL to you. 


  History

 

Code Select Expand




V0.99g  23rd,June, 2014  - 30th,June,2014

Fixes:
- The import library list would break when there's more than one
  library that needed to be imported/exported

- Reading from typed fields was exporting UTD pointer.

- DLL entry code now screens for caller actions.  Which seems to fix
  the crash on exit stuff that's been happening. 
 
- Seemed to be passing the wrong 'temp variable' in the integer serialer     

Code Generation:

- Parser better detects when an  AND/ON/XOR opcode is at the start
  possible run of serialized opcodes

- Integer serializer can handle equal and not equal compare
  operations. 
 
- Integer serializer can handle comparewith branch opcodes.

- Testing some single param float functions (Sqrt/ABS) to the float
  solver.  Seems to work well !
 
 
V0.99e/f  13th,June, 2014  -14th,June, 2014

Code Generation:

- Added serialized solver for runs of INTEGER opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV
  / AND / OR / XOR / shift << and shift >> operators

                    eg.
                          result = 10*A +B - C <<2 >> 8   
                         
- Added serialized solver for runs of FLOAT opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV

                    eg.
                          result = 10*A# +B# - C#
                         


V0.99e   13th,June, 2014  -14th,June, 2014

Code Generation:

- Added serialized solver for runs of INTEGER opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV
  / AND/OR/XOR/ shifts << and shift >> operators

                    eg.
                          result = 10*A +B - C <<2 >> 8   
                         
- Added serialized solver for runs of FLOAT opcodes. 
  The solver currently supports  ADD, SUB, MULT, DIV

                    eg.
                          result = 10*A# +B# - C#



V0.99c/d   May,2014  -7th,June, 2014 

Code Generation:
- COSRADIUS & SINRADIUS resolved directly on FPU
- COSNewValue & SinNEwValue resolved directly on FPU

Fixes:

                  - Re-Tweaked the rego field screening :(




V0.99a   May,2014  -6th,June, 2014 

Code Generation:

- RgbAlphaAnd(), RgbAlphaOr() & RgbAlphaXor() functions are now trapped and inlined
  on demand. 

- GetDistance2D(X1,y1,x2,y2) is trapped and placed in line for the FPU.
  The call is about 50% less code when passing floats to the function and probably
  75% less code when passing integers in.  Speed wise it bench marks up to 15 times  faster. 

- Cos/Sin functions are resolved now directly in line on the FPU for you.


Fixes:

- Sqrt() & ABS() decoders didn't move the PC correctly causing the parser to get
out of alignment... Throwing a bunch of bogus errors after those statements

                  - Tweaked the rego field screening to only accept characters between ASCII 32 to 128
                 

 

[kevin]

  PlayBASIC To Dll V099h  -  Breaking 800 Milliseconds for fractal render

        The last round of tweaks got the fractal demo running inside the one second mark, which as about a 250 millisecond improvement over the original base translation version.  Breaking the second barrier was enormous and I was very very happy with those results, but knew there was a little more room to move.     So yesterday I set my sights on increasing PB2DLL's serialization support to help avoid some unnecessary memory access.   With these fairly simple changes  we've smashed another 200 milliseconds from the V0.99g  results..   Bringing rendering down to around the 780-790 millisecond range.   

    When compared to our competitors the results demostrate PB2DLL accelerated version is 4.1 times faster than one and 6.6 times faster an another.    So in terms of high iteration  pure math operations they're no competition at all.. 

   8 year old Test machine AMD FX64 (3000+).  Screen resolution: 640*480 screen