| |
|
|
|
| |
|
| |
|
|
| |
What's News in the PlayBasic world ? - Find out here.
|
PlayBasic To Dll V0.99l (Free Edition) Released
|
|
By: Kevin Picone Added: May 23rd, 2019
|
|
Category: All,Tools,PlayBasic2DLL,Machine Code
|
PlayBasic To Dll V0.99l (Free Edition) Released
Here's revision l of PlayBasic2DLL V0.99 package. This update removes the need for the retail key making the software FREE.
This tool is intended for use with PlayBasic V1.64P4 retail updates !
Read the PB2DLL development blog for the latest download !
|
|
|
|
PlayBasic To Dll V0.99k Released
|
|
By: Kevin Picone Added: November 23rd, 2015
|
|
Category: All,PlayBasic2DLL,Tools,Machine Code
|
PlayBasic To Dll V0.99k Released
Here's revision K of PlayBasic2DLL V0.99 package. This update address a few minor issues with the machine code generation and includes a few new command sets that were overlooked in previous builds.
This tool is intended for use with PlayBasic V1.64P3 retail updates !
Read the PB2DLL development blog for the latest inclusions !
|
|
|
|
|
PlayBasic2DLL V0.99i released
|
|
By: Kevin Picone Added: January 13th, 2015
|
|
Category: All,Tools,Upgrade,PlayBasic2DLL,Machine Code
|
PlayBasic To Dll V0.99i Released
Here's revision I of PlayBasic2DLL V0.99 package. This revision features even more improvements to the machine code generation as well as continuing to iron any hidden instructions that weren't supported by the translation engine.
In terms of code generation this update focuses mainly on pointer operations, in particular when reading / writing from a user defined typed pointer is used within an expression, as well as arithmetic and assignment operations on between pointers or between a pointer and integer.
Example:
type TestType
x#,y#,z#
EndTYpe
Dim Src as testtype pointer
Dim Dest as testtype pointer
Src = new testtype
Dest = new testtype
; write some integer values into these float fields..
; this type of type mismatch is now auto recast at compile time
Src.x = 1111
Src.y = 2222
Src.z = 3333
; copy a field to another within the same type
; The op
Src.x=Src.Y
; copy fieldds between different types
Dest.x=Src.x
; copy a field and add 100 to it
Dest.y=Src.y+100
; copy a field and mult it by 2
Dest.z=Src.z*2
print Dest.x
print Dest.y
print Dest.z
Sync
waitkey
The new changes allow the code builder to produce faster leaner machine code from such operations as well as when they appear in expressions, which generally can be solved on the cpu without having to hit memory with temp values like previous editions.
This tool is intended to be used with PlayBasic V1.64P2 retail updates. !
Read the PB2DLL development blog for the latest inclusions !
|
|
|
|
|
PlayBasic2DLL V099g Released - Fractal Performance !
|
|
By: Kevin Picone Added: June 30th, 2014
|
|
Category: All,Update,Tools,Machine Code
|
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.
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.
|
|
|
|
|
PlayBasic2DLL V0.99 Released
|
|
By: Kevin Picone Added: June 3rd, 2014
|
|
Category: All,Update,Tools,Machine Code
|
PlayBasic2DLL V0.99 Commercial Edition released!
Yes it's here... Finally...after more than few marathon nights the first fully fledged version of PlayBasic2DLL is available to the community. PlayBasic2DLL brings the power of native code to the PlayBasic developer, all we can say is welcome back to the machine code age.
This initial release has been discounted for the community down to $27.50 (US) from it's regular $49.99 US
What's PlayBasic2DLL ?
It's a companion tool to the PlayBasic programming language. The tool converts PlayBasic Source code into machine code DLL's. Allowing the programmer to fully harness the process of their computers cpu.
The tool has been in development for the best part 8 months now so rather than me crudely attempt to paraphrase the blogs, I recommend you read the PlayBasic2DLL blogs and check out some of the examples. ( 1,000,000 Vertex cube - Water Demo )
Order
You can order the product through shareit who provide all major payment processing methods from bank card, paypal, cheque, money order and more.
See->See Community Annoucement To Purchase PlayBasic2DLL
|
|
|
|
|
PlayBasic V1.64P and PlayBasic To DLL Latest News
|
|
By: Kevin Picone Added: May 1st, 2014
|
|
Category: All,Update,Tools,Machine Code
|
The following is a selection of blog posts from the development of PlayBasic to DLL (Machine code translator) and the parallel upgrade PlayBasic V1.64P
PlayBasic V1.64P Beta 38 - Loopy Loops (April 17, 2014)
After much head scratching it was decided that the VM's instruction set needed a few alterations with it's looping instructions. These changes are two fold, the parser now does a better job at producing cleaner input parameter data and the instructions produced are now more stream lined. Producing better code, is better for everything down the line from running the code through the VM and thus any translations. The translation stuff is really why these changes need to be made now, since the original parser would use generic instructions where some data was pre-computed. From the translators perspective, this made it very difficult to accurately detect those loops in a single pass.
Today's changes introduce some new high level instructions to the VM. These changes make it trivial to accurately pin point the set up code in a FOR/NEXT looping blocks. I've already added a decoder to PB2DLL which locates the new opcodes and builds a export string in the dissassembly. The detection and output are working fine, but it's here that I noticed there's a few extra moves creating into the output code than need be. Which mostly happens when a loop is using literals. In previous editions the parser would drop an extra move prior to the loop entry point. The same can happen in the destination value expressions also. These things are easily tweaked out, just hadn't noticed them before.
PlayBasic V1.64P Beta 38 - For / Next Loop updates (April 22, 2014)
If you didn't already know, it's been Easter holidays here which has just come to a close, so only started firing up the compilers today. Last time I was working on the tuning the compiler and VM to use the new looping setup codes for FOR/NEXT loops. These changes have were translated across to PB2DLL when I was happy with the new structures. The changes are much easier for PB2LL parser to accurately detect what's going on in the program in regards to loops. But not only that, the new format allows us to make more optimizations to the assembly.
Tonight I've been back working on the parser in the PlayBasic compiler, as when converting the code to assembly, there's often these extra move operations that would end up in the byte code first and thus translated assembly. Surprisingly it generally happened what a for loop's (start / end) were both literal. For some reason it'd drop them into temps and then pull them into the loop structures internal registers. Which appears to be some left over instruction set behaviors that are no longer necessary. Older versions of the VM worked differently than today, in particular when dealing with literals. Now they can be treated just like variables, so don't they need to be treated special ways.
Something you might not be aware of is that when a for/loop is started, there's a comparison between the Start and End of loop. If Start is bigger than the end, the execution jumps to the beyond the matching next.
For example,
For lp =0 to 100
print lp
next
So there's an indivisible screening wrapped around loop entry, which might look at like this in PB style code.
if 0<=100
For lp =0 to 100
print lp
next
endif
One of the new benefits of the FOR/NEXT replacement opcodes, is the export parser can detect constant behaviors and produce code accordingly. So the comparison behind the Start /End loop counters can actually be made at compile time when they're both literal. Removing those lead in comparisons from the output code. The same goes for the storing them in internal VM registers, saving more set up code.
Being able to trap literals helps with STEP loops also. When a variable is used in for/next/step loop, the looping structure has constantly query what sign the STEP, then clip the loop counter based upon it. If the sign of step is known at compile time, then the loop can be created with this knowledge ahead of time. Removing more redundancy from the final translated assembly (in PB2DLL)
PB is pretty flexible with FOR/NEXTS allowing integer and floating point counters with variable step directions in both. People rarely use floating point loops, but since the VM supports it, the exported assembly through PB2DLL should also. Dropped in the standard by one loop structure earlier today and have just started adding the variable STEP stuff with floats. It's painful purely because of the horrible fpu instruction set in x86 chips...
PlayBasic To Dll - Tweaking Looping Constructs ( April 24, 2014)
The past day or so I've been wrestling with FOR/NEXT/STEP implementation in the translator of all things. Those reading the PB1.64P upgrade blog lately would no doubt be aware that the compiler/VM side has recently changed, the changes were explicitly made to facilitate an easier more accurate translation to machine code from the byte code origin. When porting the changes across to PB2DLL I noticed that it only supported Integer FOR/NEXT looping structures, where as the VM supports integer and floating point look structures
Floating point loops present a bit of a problem due to the FPU's rather awful implementation, but really that's everything floating point in these things. Writing the translator code isn't difficult, it's just that it needs extra steps when dealing with floats which feels rather awkward. Knowing this, invested some time into the PB compiler to make sure the compiler side cleans out any unnecessary steps when setting up the loop and gives enough information to easily work out how to set the loop and what kind of set up is needed. The decoder is able to pick up short cut situations where you used literals in your For Next Statement and cut down amount of screen code needed, in some cases on screening is need. Since the loops duration can be validated at compile time. It's those little things that help fine tune the performance of the final machine code.
The big question is when do we release ? - Well since both sides need to be in alignment for the resulting DLL's work, the original plan was to release them both together, but I think we might release PB2DLL first.. This will help further test the translation in real world situations. Of course that'll most likely mean that there will be a few updates made prior to the release, but there's not that can be done about it. It now just needs people other than me testing it.
PlayBasic To Dll - Exporting LinkDLL binding code ( April 28, 2014)
Had a few short programming (testing mainly) sessions over the weekend. Up until now, I've been testing the translator from the PB IDE. So in order to run it, i've got to compile and run as normal (F5), but as release time nears, we need to be able to build it into a final EXE, but it's here we ran into a new problem, where the exported internal structures could stop the exe from running. I though this might happen, given how much of the PB VM internals have changed over the last 6 months. Tracking down the issue took a while, but was fairly easy to solve which is a good thing. So now I can build & run PB2DLL in exe form and it works as normal.
Once the build problem was sorted, i've been getting back to the GUI and internal exporter functions. For the first version(s) I'm not going to bother with adding switching over the assembly code generation/optimization, it'll just do it silently. There are times when that wouldn't be wanted, but can't foresee anybody running into such problems. Which means for the time being some of the GUI toggles have been ripped. The only option that is useful is the Export LINKDLL code option. This option gets the translator to build a chunk of the PlayBasic source code that handles the function binding to the newly created DLL.
Linking to DLL's is something of a mystery for most people, basically all that happens is the PB compiler/VM create interfaces to external machine code that look and act like normal PB functions in your program. There's some limitations in current versions of PB as to what data type/structures you can pass into and out of them, but those will be tweaked out in time. In order to use our newly converted DLL's in our PlayBasic programs, it stands to reason that we'd need to know how to write the LinkDLL binding code for the functions we wish to use. Which was true yesterday, but now the translator can build a template of the exported functions for you in PlayBasic code. Obviously there's some limits in terms of data types that it currently supports, which stem from the PB compiler side not supporting passing PB internal structures through to external code. Why? - because nothing other than PB understands PB internal structures, making supporting that originally point less.
To test the LinkDLL exporting, added a few bogus functions to the common point rotation demo and here's what we get.
; ---------------------------------------------------------------------
; ---------------------------------------------------------------------
; ---- [cube.dll ]---------------------------------------
; ---- [ Created:28 Apr 2014 ]---------------------------------------
; ---------------------------------------------------------------------
; ---------------------------------------------------------------------
linkDll "cube.dll"
dll_addintegers(a,b) alias "dll_addintegers" as Integer
dll_addfloats(a#,b#) alias "dll_addfloats" as Float
dll_addstrings(a$,b$) alias "dll_addstrings" as String
DrawCube(sections,spacing,scale#) alias "dll_rotate_vertex_cube_9mult_common_point"
DrawCube_opt1(sections,spacing,scale#) alias "dll_rotate_vertex_cube_9mult_common_point_opt1"
DrawCube_opt2(sections,spacing,scale#) alias "dll_rotate_vertex_cube_9mult_common_point_opt2"
EndlinkDll
This code can either get cut'n'pasted in your project or #included. Either way once it's in and assuming PB can find your DLL (it's in the project folder) then your away in the machine code era!
What might be a good is to get PB2DLL to mangle the export names in the DLL. So if you have a function called "AddIntegers", the external name can be mangled into some random hash, such as 'ABHDGSNFSSF' - This would mean that exported linkDLL codes must match the build of dll exactly, as if the alias names don't match, windows can't local the machine code function and it won't run ! It'd only be helpful to prevent snoops from look at your function names and potentially working out the parameters.
PlayBasic V1.64P BETA #39 (Retail Beta) (30th,Apr,2014)
Beta #39 introduces a bunch of subtle but equally important changes, starting with the newly replaced FOR/NEXT/STEP parser and VM instruction set, there's also a few changes to the VM close down behavior. The close down changes are due to a strange issue i've been having with PB2DLL where the PB2DLL EXE would crash on exit when the program wasn't registered (worked fine once you entered your serial).
So I've been chasing the close down issue most of the day, it appears that some typed arrays can somehow contained data that wasn't a typed array container. How that's the possible is a mystery at the moment, but I've included some more screening in the clean up code to make sure it's releasing the array an not some of random bank of that data that something else was/is using. Getting this right is more important now than ever, thus is because of the way type deletion works in the runtime, so we have to make sure it's releasing data that makes sense, as if it doesn't it'll die.
The real question is how is the bad array data was/is getting into the arrays in the first place, which i'm not 100% on at this point. So i've added some debug messages to the debugger console (F7 to run, then click on the console tab) to help the community track where else these quirks put up.. Does it happen at runtime ? or only closing down the VM..
So get testing !!!!!!
Download
Download PlayBasic V1.64P Beta 39
More Information
For the full picture/ screen shots etc see the PlayBasic 2 DLL development blog
|
|
|
|
|
PlayBasic To Dll - Tweaking Looping Constructs
|
|
By: Kevin Picone Added: April 25th, 2014
|
|
Category: All,Update,Tools,Machine Code
|
PlayBasic To Dll - Tweaking Looping Constructs
The past day or so I've been wrestling with FOR/NEXT/STEP implementation in the translator of all things. Those reading the PB1.64P upgrade blog lately would no doubt be aware that the compiler/VM side has recently changed, the changes were explicitly made to facilitate an easier more accurate translation to machine code from the byte code origin. When porting the changes across to PB2DLL I noticed that it only supported Integer FOR/NEXT looping structures, where as the VM supports integer and floating point look structures
Floating point loops present a bit of a problem due to the FPU's rather awful implementation, but really that's everything floating point in these things. Writing the translator code isn't difficult, it's just that it needs extra steps when dealing with floats which feels rather awkward. Knowing this, invested some time into the PB compiler to make sure the compiler side cleans out any unnecessary steps when setting up the loop and gives enough information to easily work out how to set the loop and what kind of set up is needed. The decoder is able to pick up short cut situations where you used literals in your For Next Statement and cut down amount of screen code needed, in some cases on screening is need. Since the loops duration can be validated at compile time. It's those little things that help fine tune the performance of the final machine code.
The big question is when do we release ? - Well since both sides need to be in alignment for the resulting DLL's work, the original plan was to release them both together, but I think we might release PB2DLL first.. This will help further test the translation in real world situations. Of course that'll most likely mean that there will be a few updates made prior to the release, but there's not that can be done about it. It now just needs people other than me testing it.
|
|
|
|
|
PlayBasic To DLL In Final Testing
|
|
By: Kevin Picone Added: April 12th, 2014
|
|
Category: All,Update,Tools,Machine Code
|
The following is from a selection of blog posts from the development of PlayBasic to DLL (Machine code translator) over the past months.
PlayBasic To Dll - Joining The Dots ( April 08, 2014)
The GUI side of the app is looking fairly complete now (apart from some tweaks), wrote (largely cut'n'pasted) a history dialog the other day from one of the other apps. Turned it up a bit, one of my pet peeves is programs that only remember the last couple of files you worked on. The current solution has no max size, but really it's unlikely you'll ever have more than a page or so loaded. There's a clean up button to remove files that no longer exist on disk. So when stuff get moved or delete or whatever.
The other remaining GUI tidbit that was left over, was the batch / folder scanning stuff, which was just transplanted across from the Amos2BASIC converter. The batch processing stuff just scans the folder you provide looking for PBA files. A PBA file for those who don't know, is the PlayBasic source code file. Each source it finds it'll attempt to build into a DLL. The translator expects the sources to be stand alone at this point, so they currently can't have #INCLUDE statements in them. Which is limitation, but It should be able to be overcome.
In order to get the best out of the tool, it's highly advisable programmers adopt a parent->child structure to their machine code accelerated projects. So your main project folder contains the game / tool source + media as normal, in here you'd also have any secondary library sources stored inside that main folder. Your libraries folder would include your PlayBasic DLL projects sources. So if you have a couple of lib's you can use the build folder option in PB2DLL to run through and build everything for you in one go. The build process will write the created DLL's to those folders and ideally generate linkDLL wrapper code for them. So in your main source you just #Include those wrappers and your away. .
So if we had an imagery a game called "PONG" , we'd make a project folder called PONG and hopefully give it a meaningful project name such as PONG.PBP (PlayBasic Project file), rather than the default 'Project.pbp' which the IDE will assign those lazy people. Inside that folder we'd create a MEDIA folder for all the games graphics and sound assets. This simple structure immediately helps keep everything more organized from just file management through our actual source code. If for some reason we wanted to add build a DLL library to help our pong game, we're create another folder inside the PONG folder. It could be called anything, but giving it a name such a DLL's or Libs, or Libraries or something, something that should be obvious to what the folder contains
Now let's say in your pong game you're loading media files that for of a different format, you can load them in your main source code, but there's some VM overhead in doing that. This would be an ideal situation for converting the loader/conversion code to a DLL. To do so, you start a new project in PB, then we save this project (with a meaningful name) into our games / dlls folder. So if our library was to be a packing library we might call it "Packer", where it's path might be PONG/DLL/PACKER/. Once we have a project, we'd cut'n'paste all the required code for the DLL functions to operate separately. So any structures arrays etc your packer functions need, need to be inside that project. The project should compile without any external requirements. Once you have that, directly PB2DLL to that folder/and source and translate it.
Once the functions we want are externally built into machine code, we need to convert our parent project to use the DLL version of the functions, rather than the original versions that might be in our code. In this case, we'd pull all the Packer functions of our game. We don't need them in the main source anymore since all that code is now hidden away in our machine code dll. However, if you're passing types between the sides you would still need those Types to be declared within your main source. PB can't get this information back from the DLL. Moreover the DLL is like a black box, so the only functions you can see inside the dll are those that you exposed in your code. To expose a function we rename it with the "DLL_" prefix. Only these will be exported. Any function not containing the prefix, will be included inside the final code but not visible from the outside, so we can't access it.
PlayBasic To Dll - The last 10% is really more like 90% (April 09, 2014)
One of the many frustrating things about programming is the almost there sensation, where the last 10 or so percent of the project, feels like it takes more like 90% of the development time. Testing is notoriously difficult and not to mention time consuming, one of the challenges with a project like this, is the near infinite amount of input situations the program has to deal with. One little issue I've been having is getting PB2DLL to control and understand the responses from both the PB compiler and FASM. It's fairly easy trapping a compiler errors (Shown bellow ) from the PB and returning this information back to the user, but from assembler is still a bit iffy trying to sense of what it returns, which soon goes beyond the scope of the product. Obviously it makes more sense to trap errors during generation, rather than after assembly. Since it's entirely possible a broken translation source could assemble.
Another problem that's been appearing is with batched conversions, where on some sets of sources, it's happy to compile and convert them, but there's the odd program that doesn't like being compiled in a batch, they'll compile fine alone, but not in a group. So there's something wrong with the loader state not being refreshed, but just can't find the actual smoking gun.
PlayBasic To Dll - Eureka, It's Finally Working (April 11, 2014)
There's a funny thing that happens when your chasing down bugs, where you'll follow a hunch down a rabbit hole almost infinitely, regardless of if there's real basis in it or not. You know it seems like this, so it must be this! Now the past week or so, I've tracking strange faults in the translator where compiling the same program twice in a row would work, then it'd fail when changing sources in a batch. Initially it seem GUI related, since the test code worked fine in the stand alone translator, but generally failed when you batched a folder out (translated a group of sources). There's a few obvious things come to mind, like the translators not initializing it's internal structures properly, or there's some unforeseen collision somewhere.
Initially focused on tuning up the initialization code, but the problem persisted.. So off I go looking for any collisions or potential issues between the two slabs of code, such as clash of variable scopes. Even found a couple of such issues, which looked potentially lethal, but turned out to be a bust.. Next logically conclusion, oh there's must some bug in PB that's at fault.. But right before diving into the runtimes, it seemed it might be nice to get a clearer picture of what the translator is looking at to begin with. If that code isn't valid, or has some bogus data in it, then there's possible smoking gun and wouldn't ya know it  when comparing the byte code state being compiles, there's an odd similarity in where the errors occur in them, in particular in the map that flags byte code as data and to be skipped.
So off I go looking at the byte code loader function and hey presto, the function REDIM's the ignore table. This creates a problem as Redim preserves the contents of that array, the array is used in parallel to the main byte code to screen stuff out, so compiling the same program would work but if you compile program A then program B.. Program B has Programs A's ignore list applied to it, the more programs to built in sequences the of lists get merged creating all sorts of strange artifacts. But right on 5PM that's bee been fixed now and it's working nicely !
Haven't just been searching for bugs in the translator, I've also added more error trapping abilities. Earlier this week, added support to trap error codes form PlayBasic compile process. This returned a line number / error number and error message, but it couldn't get the source line, until now. So when a compile error occurs, it'll dump that to the console also. Which should give you some idea as that's wrong with the source. Beyond that, there was no error trapping in the translator side of the tool as all. In fact if an error occurred, it'd still call the assembler and try build your DLL. PB2DLL has limit on the amount of errors it'll accept, unlike PB. This is because it's possible the error message you're getting is just a warning, so the code may assemble, but it may not also.. If there's too many errors though, it just considers this fatal case and aborts the process completely.
Anyway, prior to this week I was hoping to have the first commercial releases up and running by the this weekend, the delays this week make that very doubtful now, but it is just around the corner !
PlayBasic To Dll - Testing - 1,000,000 Point Rotation Example (real time) (April 11, 2014)
Here's something for those die hard skeptics out there, is rotating / clipping and drawing a 1,000,000 points to the screen possible in PlayBasic ? - Well, it's not running through the VM's, but it is if you translate your code to machine code via PB2DLL then it's easily within your grasp.
I remember back in the mid 90's counting clock cycles to try and get a few hundred, let alone a 1000 points rotated in a couple of frames from hand optimized assembly. You can do that easily in PB today (even running on the slowest VM), but it's mind boggling how far this has all scaled up.
Common Point Rotation / Dot Cube (PB2DLL Example)
The best news about this, is the current PB2DLL's translator has only a few redundancy tweaks in it, as yet I haven't added any arithmetic optimizations.
More Information
For the full picture / screen shots etc see the PlayBasic 2 DLL development blog
|
|
|
|
Viewing Page [1] of [2]
|
|
| |
|
|
|
|
| |
|
|
|
|
