| |
|
|
|
| |
|
| |
|
|
| |
What's News in the PlayBasic world ? - Find out here.
|
PlayBasic V1.64P - WIP Round Up #1
|
|
By: Kevin Picone Added: January 29th, 2014
|
|
Category: All,Update
|
The following clips are taken from the development blog of PlayBasic V1.64P and read oldest to newest - You can find the complete blog (for this and every other update) on our forums
PlayBasic V1.64P Beta 17 - Operators and Precedence (November 28, 2013)
It shouldn't come as any great surprise that changes in this revision are to help with the PlayBasic To DLL translator and it's ability to produce cleaner and better code generally. Building the translator means taking a fine tooth comb to the generated byte code and making sure the compiler outputs the leanest set of instructions possible to perform each operation. While looking over the bit wise/logical operators recently noticed they'd not been set to force an integer result. So if you had an expression fragment that contained a float, it'd return a float in the legacy VM. Fortunately this is simple to rectify as the parser has a switch to force an integer return. This is a bit of a none issue in most programs since the operators are generally only ever see integers on either side of them, but it can and does actually occur in some code.
Having operators return a float isn't an earth shattering problem, it just makes a simple operation messy and slower than need be when such things occur. The existing translator already supports operations upon integers, but it didn't handle mixtures between integers and floats. Forcing the compiler to produce an integer only result, helps the VM keep everything integer and translator produce cleaner machine code from the byte code without making multiple path ways.
While looking at the operators again in the compiler and translator, noticed that NOT seems have a precedence issue. For some reason it's evaluated before the math/compare operators in an expression. It should be the same as the other operators and occur after them.
So code like print not a=b is being evaluated Not A then result_of_Not_A=b , where it should do A=b then do Not Result_Of_Compare_A_With_B.
Moreover Not is implemented as a mask and Xor of the bit zero value on the right hand side. After a rethink, it'd be better implemented as a equality test with zero then xor. So code like Not 45, would actually be evaluated as Not (44<>0), Not 1 = 0. Where it'd currently return 1 since bit zero is OFF, it'll flip that off bit to on.
The bad thing about the NOT operator is that your introducing complexity into your expression for no real benefit, as result = (Not A = B) and Result = (A <>B) are functionality the same, expect the former is two operations and the latter is single operation. No big deal in a loop of 1 to 100, but a very big deal when iteration count blows out in both VM and Machine Code.
Live Edit #1:
Found the problem, the operator trap in the parser was missing the operation level screen. Once added, the order solves as expected.
print not a=b
print not a<>b
print not a#=b#
print not a#<>b#
; thee lines would fail in older versions of PB, since it'd evaluate Not A$ first
print not a$=b$
print not a$<>b$
Live Edit #2: Optimizer
The expression solver now contains logic to optimize & rewrite code fragments like the following. The optimizer also supports literal Not statements as well so that be evaluated in constant expressions.
Print Not 1
Print Not 0
Print Not 1.0
Print Not 0.0
Print Not A=B
Print Not A<>B
Print Not A#=B#
Print Not A#<>B#
Print Not A$=B$
Print Not A$<>B$
Becomes,
Print 0
Print 1
Print 0
Print 1
Print A<>B
Print A=B
Print A#<>B#
Print A#=B#
Print A$<>B$
Print A$=B$
So since we're saving an opcode every time, the object code is smaller and of course faster in both the VM and machine code. No brainier really.
PlayBasic V1.64P Beta 18 - Shift Operators (December 02, 2013)
Just dropping in some more C styled operators with the << and >> which are equivalent of the existing LSR32 and LSL32 functions (which is what they are in assembly btw). Just makes dragging code between dialects that little bit simpler. There's no functionality difference between them.
print 1 << 2
print 256 >> 2
a=16
b=4
b#=b
print "variables & literals:"
print a << 4
print a >> 4
print 4 << a
print 4 >> a
print "integer only"
print a << b
print a >> b
print b << a
print b >> a
print "mixtures (floats recast as ints)"
print a << b#
print a >> b#
print b# << a
print b# >> a
Sync
waitkey
PlayBasic V1.64P Beta 18 - Updated Operator Codes For IDE ( December 02, 2013)
The compiler and IDE talk to each other when you first start PlayBasic up. The discussion is pretty one sided, but the IDE basically asks PB for it's current internal command, constant and operator list.
The forum board syntax highlighter currently doesn't support them all as you can currently see in this snippet. (This statement will be obsolette when i next update the board, so they'll appear as per the IDE..)
; Testing operators in standard PlayBasic IDE
a++
a--
a+=b
a-=b
a*=b
a/=b
print a< B
print a> B
print a<>B
print a><B
print a>=B
print a<=B
print a=>B
print a=<B
print 1 << 2
print 256 >> 2
a=16
b=4
b#=b
print "variables & literals:"
print a << 4
print a >> 4
print 4 << a
print 4 >> a
print "integer only"
print a << b
print a >> b
print b << a
print b >> a
print "mixtures (floats recast as ints)"
print a << b#
print a >> b#
print b# << a
print b# >> a
print hex$(255 and 15 << 8)
Sync
waitkey
Edit #1 - Not Equal Operator
It appears PB parser would only ID one version of the Not Equal operator, that being <> , where as the inverse also represents an inequality, but the parser didn't pick it up. With a quick tinker and it now supports >< also.
Live Edit #2 - C styled not Not Equal Operator
Dropped in the != this in for those who can't live without their c fix.. Same as <>and ><
PlayBasic V1.64P Beta 19/20 (January 16, 2014)
The V1.64P revision has only had a few changes late last year, none of them were really user related (just the odd tweak for how PB and PlayBasic 2 DLL communicate) , although tonight i've been looking over the GetArray and SetArray commands. These are a way a user can access arrays through a stub array. So if you create a stub (and array with no data of it's own) via MakeArray, you can copy the 'pointer/buffer' from any other array into the stub via getting that arrays index via GetArray and then setting it via SetArray. The array indexes are linear, so you can actually write code that runs through a block of similar arrays without having to pass them. The process is basically the same as how and array is passed into a function or psub anyway..
Dim Table(100)
Dim Table2(1000)
; make a stub array called Me()
MakeArray Me()
; Me() now contains a copy of buffer that Table() officially owns
SetArray Me(), GetArray(Table())
; see me is now 100 elements in size
Print GetArrayElements(Me())
; put some data in table are indexes 0,1,2
Table(0) = 111
Table(1) = 222
Table(2) = 333
; show what me()'s looking at
print Me(0)
print Me(1)
print Me(2)
Sync
waitkey
While working on PlayBasic to DLL noticed the GetARRAY function can be pre computed at compile time, currently there's actually a library function that preforms the rather trivial calculation at runtime. SetArray is little more difficult as it's scope aware, which is fine for the VM environment, but a little difficult in the translated version, without piping all the compile time data into the DLL, which i'm not too keen on. Originally the SetArray would let you set and get between any array regardless of scope. I forget why it was changed, but have a feeling that could well get reverted at some point in the near future 
PlayBasic V1.64P Beta 21 - Data updates (January 27, 2014)
While building the data support into PlayBasic to DLL, found a few issues with the VM data commands. The main one was the Restore command would allow a negative data pointer position. Which would pull data from off the table, since it's not clamped. Another change is the FindDATA function had some dead weight in it and was missing the ability to search from the current DataPointer position. This has been added as a switch in the position field, if you set the field to a -1 the command will use the existing data pointer to search from. The position field is optional now and defaults to -1
Data 10, 20,30,40,50,10,10,50
; find the first instant of the Integer value 50
; and set the data pointer to the cell after that value
Restore FindData(50)+1
; show us what where it is within the set
Print GetDataPointer()
; find the next instance of 50
Restore FindData(50)
; show us where it is
Print GetDataPointer()
sync
waitkey
Test Code.
Data "StartBaby"
Label1:
Data 10
Label2:
data 20,30,40,50
Label3:
Data 111.111,222.222,333.333 ,444.444, 555.555
Label4:
data "hello world1","hello world2","hello world3","hello world4","hello world5"
DLL_DATATEST()
sync
waitkey
Function DLL_DATATEST()
print GetDataPointer()
Label4=100
restore Label4
print "Reading data types on heap"
Count=GetDataQuantity()
print "Count:"+str$(count)
for lp=-10 to count
restore lp
DataType=getDataType()
s$= Str$(lp)+" ="+str$(getDataPointer())+" type="+str$(DataType)
Select DataType
case 0
s$+=" Data="+str$( ReadData())
case 1
s$+=" Data="+str$( ReadData#())
case 2
s$+=" Data="+ReadData$()
endselect
print s$
next
print "restore tests"
restore "hello world2"
print GetDataPointer()
restore "StartBaby"
print GetDataPointer()
print "find Data tests"
print FindData("hello world3",0)
print FindData(50,0)
print FindData(222.222,0)
; find the first instance of 50 from the current data pointer position
print FindData(50)
EndFunction
|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
