Author Topic: OxygenBasic  (Read 18521 times)

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
OxygenBasic
« on: July 07, 2011, 10:05:14 PM »


Introducing Oxygen Basic

Oxygen Basic (O2H) is a Just-In-Time compiler assembler, deployed in a single DLL that takes source code strings and returns executable binary. It is an extension of the O2 assembler. This implementation can be embedded in any application to provide high performance programmability. The compiler can also generate conventional executables and dynamic link libraries (DLL).

Oxygen supports Object Oriented Programming with multiple inheritance and also single inheritance modes, more suited to COM. In addition to this O2H supports User-defined operators and operator sets for use with complex numbers, matrices, vectors, sets and other specialised forms. It can also compile & execute strings of source code at run time with its built in compile() function, opening new possibilities for functional programming.

The built in function set is small. but contains the necessary tools to build class / function libraries to any scale.

In addition to understanding Basic in the QBasic genre, Oxygen can read sufficient C syntax to deal with most C headers directly, eliminating the need to translate them into Basic.

oxygenbasic.org

« Last Edit: July 07, 2011, 10:07:01 PM by JRS »

Mike Lobanovsky

  • Guest
Re: Peacock Butterfly
« Reply #1 on: December 20, 2013, 11:03:15 AM »
John,

What you should really ask Peter about is what the Step value in fact is in his "For i=v to 1" statement. In all "normal" BASIC's, Step defaults to 1 unless specified explicitly. It seems like it is not so in OxygenBasic. It also seems that Charles is overlooking this obvious peculiarity when adding his twopence to the discussion.

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
Re: Peacock Butterfly
« Reply #2 on: December 20, 2013, 11:15:09 AM »
Quote
A fair substitute:
For i=v to .999999


c is an RGB composite: 1..0x00FFFFFF

Time: 21 secs

I think Charles responded appropriately and corrected Peter's answer.

Any clues to the Draw_Line() mystery?

Resolved. (uninitialized variables)  :o
« Last Edit: December 20, 2013, 02:12:49 PM by John »

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #3 on: December 20, 2013, 12:01:28 PM »
John,

I'm telling you again, Gharles' answer has no relation to your problem. In any BASIC, evidently except OxygenBasic, "For i=v to .999999" will loop only once because the value of i step is not specified, and if so, then it will default to 1. Having looped once, For/Next will stop because the next value of iterator i will be 1 which is the upper limit for either <1, or =1, or =0.999999, whatever.

For any other BASIC, presumably including your SB, the statement should be something like "For i = v To 0.999999 Step 0.01" or whatever else similar to that, because i = v must be set only at loop start as per BASIC Standard. Later on, regardless of whether  v changes, i incrementation according to the Step value shouldn't change unless i is changed explicitly within the loop. Which it is not.

Try and change your outer For/Next as I suggest and I'm sure you'll see your script working.

Alternatively, not all BASIC's support fractional Steps. For example, FBSL doesn't. In this case, you should change your outer loop to
Code: [Select]
i = v
While i < 0.999999
    ...(do something)...
    i = i + 0.01 ' for example
WEnd

Hope this helps.
« Last Edit: December 20, 2013, 12:03:45 PM by Mike Lobanovsky »

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #4 on: December 20, 2013, 12:16:07 PM »
My code:
Code: [Select]
#Option Strict

Dim q = 1., q1 = .9997, v = .01, i = v, vv = .0004, xs = 750, ys = 730
Dim xm = 650, ym = 180, br = -.7393, bi = .117, c, ar, ai, tr, ti
Dim x, y, d

GetDC(ME)

FbslSetFormColor(ME, 0)
Resize(ME, 0, 0, 700, 500)
Center(ME)
Show(ME)

Dim gtc = GetTickCount()
While i < 1
For d = 1 To 15000
tr = ar * ar - ai * ai + br
ti = 2 * ar * ai + bi
x = tr * xs + xm
y = ti * ys + ym
v = v + vv
q = q * q1
c = d ^ 2.1
Line(GetDC, x, y, x + Cos(i) * 50 * q, y + Sin(i) * 50 * q, c)
ar = tr
ai = ti
Next
i = i + v
WEnd

MsgBox(, GetTickCount() - gtc, d - 1 & " lines drawn",)
ReleaseDC(ME, GetDC)

My results:


Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
Re: Peacock Butterfly
« Reply #5 on: December 20, 2013, 12:26:01 PM »
Actually the FOR i = v to .999999 worked fine. There were 2 variables that needed to be zero rather than undef and that solved the bad argument for Line_Draw().

I haven't run your code on my laptop but you look to be clocking in at 0.188 seconds. What do you get when  you compile your FBSL script?
« Last Edit: December 20, 2013, 04:37:10 PM by John »

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #6 on: December 20, 2013, 01:25:14 PM »
1. Actually, this is the worst reading of all. A typical one is 171 ticks = 0.171 seconds on my PC. Doesn't matter if the script is compiled or not as FBSL's BASIC isn't a compiler but rather an interpreter. The script comments and #defines are stripped off and constants are propagated where possible (strings concatenated and numeric results calculated). Then the script is passworded, obfuscated, uber-zipped and written into the .rdata section of an FBSL executable. Appropriate magics are added for decompression and finally the executable is UPX-ed in a --force --utra-brute mode. On launching the executable, FBSL does the opposite; it reads in the script from the memory stream and compiles it into bytecode where possible then launches for execution.

Yet a script remains a script at all times.

2. Low results are due to two nested loops which are slow in FBSL as loop frames are not bytecoded but rather interpreted token by token. That's a requirement of Variant nature of FBSL's variables.

Slow looping was one of the major reasons why DynAsm and DynC JIT's appeared in FBSL in the first place. If re-written in ether one of them, the code would run as fast as only the LineTo() WinAPI permits. Perhaps up to an order of magnitude faster.

3. Now let me ask you, what is the default Step value in your SB's floating-point statements of the type "For i = v To 0.999999"? How is i actually incremented on default and does it also change its value if v is changed within the loop as it is in this piece of code? Loop behavior seems to be similar in SB and O2B but I wouldn't call it the expected behavior of a BASIC iterator.

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
Peacock Plume
« Reply #7 on: December 20, 2013, 01:56:07 PM »
The most outer loop assigns i to .10 (same as v) and exits. (one iteration) The outer loop now seems like a silly error on Peter's part. I also changed the program to calculate the cos and sin once. I posted the resulting screen shot with the below code and I don't think it changed anything. The time remained about the same. (little faster)



Code: [Select]
' ScriptBasic Peacock Plume

DECLARE SUB Window ALIAS "SB_Window" LIB "sdl"
DECLARE SUB WaitKey ALIAS "SB_WaitKey" LIB "sdl"
DECLARE SUB Ticks ALIAS "SB_Ticks" LIB "sdl"
DECLARE SUB UpdateRect ALIAS "SB_UpdateRect" LIB "sdl"
DECLARE SUB Draw_Line ALIAS "SB_Draw_Line" LIB "sdl"

Window 700, 500, "Peacock Plume"
q = 1
q1 = 0.9997
v = 0.01
vv = 0.0004
xs = 750
ys = 730
xm = 650
ym = 180
br = -0.7393
bi = 0.117
ar = 0.0
ai = 0.0
_cos = cos(0.01)
_sin = sin(0.01)
t1 = Ticks()
FOR d = 1 TO 15000
  tr = ar * ar - ai * ai + br
  ti = 2 * ar * ai + bi
  x  = tr * xs + xm
  y  = ti * ys + ym
  v  = v + vv
  q  = q * q1
  c  = d ^ 2.1
  Draw_Line x, y, x + (_cos * 50 * q), y + (_sin * 50 * q), c
  ar = tr
  ai = ti
NEXT
UpdateRect
t2 = Ticks()
t3 = (t2 - t1) / 1000
PRINT "Time:  ", FORMAT("%.4f", t3), " seconds.\n"
PRINT d-1, " Lines Drawn\n"
WaitKey

jrs@laptop:~/sb/sb22/sdl$ scriba peacock.sb
Time:  0.0880 seconds.
15000 Lines Drawn
jrs@laptop:~/sb/sb22/sdl$
« Last Edit: December 20, 2013, 11:11:34 PM by John »

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #8 on: December 20, 2013, 02:07:39 PM »
The most outer loop assigns i to .10 (same as v) and exits. (one iteration) ...

Exactly! :)

Just one step, is all. i = v yields i = 0.01, then the loop code launches the inner loop which runs 15,000 times, then i goes i + 1 = 1.01 at the end of the outer loop and the i < 0.999999 condition fails at the second iteration of the outer loop, and then finally the program exits happily.

The outer loop is a nuisance. I'm getting the exact same picture with the outer loop commented out completely.

[EDIT] But I like the picture anyway. :)
« Last Edit: December 20, 2013, 02:14:00 PM by Mike Lobanovsky »

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
Re: Peacock Butterfly
« Reply #9 on: December 20, 2013, 02:16:28 PM »
I think the SB example looks more like a peacock plume to me. I have seen this example somewhere before so it may not be a Peter original.
« Last Edit: December 20, 2013, 04:40:49 PM by John »

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #10 on: December 20, 2013, 02:19:34 PM »
I can forgive him for that. It's nice anyway: :)

Mike Lobanovsky

  • Guest
Re: OxygenBasic
« Reply #11 on: December 20, 2013, 02:25:49 PM »
BTW can you make your SB c an explicit integer? If yes then wouldn't your colors be like Peter's and mine?

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
Re: Peacock Butterfly
« Reply #12 on: December 20, 2013, 02:47:22 PM »
BTW can you make your SB c an explicit integer? If yes then wouldn't your colors be like Peter's and mine?

Nope. I did a INT(c) and there was no change. Maybe it's a 64 bit thing.  :P

SB FOR/NEXT Documentation
« Last Edit: December 20, 2013, 03:50:52 PM by John »

Mike Lobanovsky

  • Guest
Re: Peacock Butterfly
« Reply #13 on: December 20, 2013, 05:04:32 PM »
Nope. I did a INT(c) and there was no change. Maybe it's a 64 bit thing.  :P
Probably a 64-bit RGB() wouldn't be either:
-- just a simple "( b << 16 ) Or ( g << 8 ) Or r" byte arrangement, which is unlikely; or
-- Linux has a reversed order of RGB components as compared to Windows' actual BGR order despite the function name.

SB FOR/NEXT Documentation
Oh. So Step is changeable in SB. Quite unexpected but perhaps useful for some tasks. And yet another thing: the specs don't state explicitly if Step can be fractional or not. Not all BASIC's support fractional iterators, and that's normal.
« Last Edit: December 20, 2013, 05:08:12 PM by Mike Lobanovsky »

Offline John

  • Forum Support / SB Dev
  • Posts: 3512
    • ScriptBasic Open Source Project
SB STEP
« Reply #14 on: December 20, 2013, 05:24:02 PM »
Quote
Oh. So Step is changeable in SB. Quite unexpected but perhaps useful for some tasks. And yet another thing: the specs don't state explicitly if Step can be fractional or not. Not all BASIC's support fractional iterators, and that's normal.

Right off the bat I can see this being useful with a zoom routine where step rate may be change by the user.

Code: [Select]
stepvar = .5
FOR x = -1 TO 2 STEP stepvar
  IF x = 1 THEN stepvar = .25
  PRINT FORMAT("%g\n",x)
NEXT

jrs@laptop:~/sb/sb22/sdl$ scriba teststep.sb
-1
-0.5
0
0.5
1
1.25
1.5
1.75
2
jrs@laptop:~/sb/sb22/sdl$
« Last Edit: December 21, 2013, 10:34:27 AM by John »