All BASIC

Message Boards => Compilers => Topic started by: John on July 07, 2011, 10:05:14 PM

Title: OxygenBasic
Post by: John on July 07, 2011, 10:05:14 PM
(http://www.oxygenbasic.org/o2pics/gen/ii1fkio7g.jpg)

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 (http://www.oxygenbasic.org)

Title: Re: Peacock Butterfly
Post by: Mike Lobanovsky 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.
Title: Re: Peacock Butterfly
Post by: John 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
Title: Re: OxygenBasic
Post by: Mike Lobanovsky 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.
Title: Re: OxygenBasic
Post by: Mike Lobanovsky 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:

Title: Re: Peacock Butterfly
Post by: John 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?
Title: Re: OxygenBasic
Post by: Mike Lobanovsky 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.
Title: Peacock Plume
Post by: John 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)

(http://files.allbasic.info/ScriptBasic/peacock.png)

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$
Title: Re: OxygenBasic
Post by: Mike Lobanovsky 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. :)
Title: Re: Peacock Butterfly
Post by: John 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.
Title: Re: OxygenBasic
Post by: Mike Lobanovsky on December 20, 2013, 02:19:34 PM
I can forgive him for that. It's nice anyway: :)
Title: Re: OxygenBasic
Post by: Mike Lobanovsky 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?
Title: Re: Peacock Butterfly
Post by: John 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 (http://www.scriptbasic.org/docs/ug/ug_25.62.html)
Title: Re: Peacock Butterfly
Post by: Mike Lobanovsky 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 (http://www.scriptbasic.org/docs/ug/ug_25.62.html)
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.
Title: SB STEP
Post by: John 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$
Title: Re: OxygenBasic
Post by: Mike Lobanovsky on December 20, 2013, 05:35:12 PM
Thanks for the heads up, John, and I guess that's it for tonight. :)
Title: Peacock Plume
Post by: John on December 20, 2013, 06:23:42 PM
Quote
-- just a simple "( b << 16 ) Or ( g << 8 ) Or r" byte arrangement, which is unlikely; or

The SB SDL_Draw extension module is using 32 bit color by default. I might add another optional argument to the Window() function (title is currently optional) for 8/16/24/32 bit color. I'm not sure why anyone would want to use anything other than 32 bit color. I have never been a fan of backwards compatibility. If you have moved beyond it, forget about it.
Title: Re: OxygenBasic
Post by: Mike Lobanovsky on December 20, 2013, 07:02:53 PM
In fact, both 24- and 32-bit color is actually the same as far as color goes. Both use an &HFFFFFF value for color gradients proper. But 24 bits just ignore the &HFF000000 component while 32 bits use it for coding alpha-transparency of pixels. Since most everyday pictures don't have transparent areas, coding only 3-byte color pixels instead of 4 bytes yields a huge saving in size especially in lossy formats like e.g. JPEG. OTOH low-end colors produce yet far smaller files and draw much, much faster than 24 or 32 bits but yield lower color quality (variety).

You'd be surprised how many more color formats are there in Gdi+, OpenGL and DirectX libraries. Dozens of them and each one has its merits and drawbacks.

I was talking about another aspect. Windows stores the B component at &HFF0000, G at &HFF00, and R at &HFF. The corresponding Linux palette might be R at &HFF0000, G at &HFF00, and B at &HFF. That's why we seem to be getting inverse colors in our respective renders. This is because the line color is given not by an RGB() function call which would correct the endianness on the respective platform, but rather by numeric literals "c  = d ^ 2.1" which aren't endian-compensated in any way.

I'm not implying that Linux or Windows are good or bad. I'm saying they may be simply different in this regard. But the good thing is that the both would store alpha-transparency at &HFF000000. :)
Title: Windows may be color blind
Post by: John on December 20, 2013, 07:07:07 PM
Did I forget to say that I think the SB example looks more like a Peacock Plume?  ;D

Thanks for the extra effort to try to unravel what is going on. Maybe Charles or Armando might have some ideas.

Title: Re: OxygenBasic
Post by: Mike Lobanovsky on December 20, 2013, 07:35:44 PM
No, you didn't. The implication was wa-a-a-ay too obvious! :))

But I still admire my 5-pixel wide render too. It looks so pleasantly, er, cacophonic... (had to look it up in the dictionary :) ).

Have a nice night!