Author Topic: What to expect over the next 5 (or so) days...  (Read 4141 times)

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
What to expect over the next 5 (or so) days...
« on: April 17, 2012, 05:21:59 PM »
I'm still on break from work for the next 5 days and will be doing some QB64 development. I probably won't be doing much bug fixing and will be devoting my time to getting the new QB64 _MEM blocks system in place and applying a QB64 update. There is still a lot of work to do on _MEM blocks but the core concepts are solidly in place. Like the QB64 image system, I suspect it will take a while for QB64 coders to begin using it for anything except experimental examples but later down the track it will provide the backbone for a lot of powerful QB64 programs, particularly for libraries/modules written in pure QB64 code. The problem with the _MEM system is that there is no point releasing it piecemeal, all of it (including the speed optimization metacommand) needs to be available for it to be useful.
Something old... Something new... Something borrowed... Something blue...

DarthWho

  • Hero Member
  • *****
  • Posts: 3853
  • Timelord of the Sith
Re: What to expect over the next 5 (or so) days...
« Reply #1 on: April 17, 2012, 05:39:27 PM »
the mem blocks system is going to allow us to do things like memcopy bit based arrays right? because I still have a use for that and it wouldn't just be experimental...
Rassilon: My lord Doctor; My lord Master; My lord DarthWho
The Doctor and the master at the same time :WHAT!?!?!

FastMath 1.1.0 released: http://dl.dropbox.com/u/12359848/fastmath.h

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #2 on: April 17, 2012, 05:53:38 PM »
Quote
the mem blocks system is going to allow us to do things like memcopy bit based arrays right? because I still have a use for that and it wouldn't just be experimental...
That's a really good question. I'll see what I can do to allow for this. You won't be able to reference 'by bits' but it'd be nice to open up the bytes of bit arrays for access.
Something old... Something new... Something borrowed... Something blue...

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #3 on: April 17, 2012, 06:49:08 PM »
Does this mean you decided on some specific syntax's then? I'm curious to see what you decided on. In the end, whatever you decided on I'm sure I'll get used to.

Also, will _NEWMEM be faster then DIM for arrays? IE:

Code: [Select]
DIM m as _MEM
m = _MEMNEW(2000) 'forgot the syntax sorry, but you get the idea
DIM m2(2000) as _BYTE

Which one would be faster or better to use?

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

DarthWho

  • Hero Member
  • *****
  • Posts: 3853
  • Timelord of the Sith
Re: What to expect over the next 5 (or so) days...
« Reply #4 on: April 17, 2012, 07:03:46 PM »
just one other question: does
DIM m(3) AS _BIT * 2 fit into a single byte?
Rassilon: My lord Doctor; My lord Master; My lord DarthWho
The Doctor and the master at the same time :WHAT!?!?!

FastMath 1.1.0 released: http://dl.dropbox.com/u/12359848/fastmath.h

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #5 on: April 17, 2012, 08:11:50 PM »
Quote
Does this mean you decided on some specific syntax's then?
Not 100% but I settled on a GET/PUT style system which is more familiar to QBASIC programmers...
Code: [Select]
x = _MEMGET(block, offset, type)
_MEMGET block, offset, variable
_MEMPUT block, offset, variable
_MEMPUT block, offset, expression AS type 'note: all expresseions MUST use AS TYPE to avoid any confusion

'so this is ok:
_MEMPUT myb, myoff, _MEMGET(myb2, myoff2, INTEGER) AS INTEGER
'results in:
'*(int16*)myoff=*(int16*)myoff2;


Quote
DIM m as _MEM
m = _MEMNEW(2000) 'forgot the syntax sorry, but you get the idea (it's right!)
DIM m2(2000) as _BYTE

Which one would be faster or better to use?
[revised reply]In theory accessing the data above should be equally fast because we are dealing with bytes anyway. However you cannot (as yet) speed up access to an array by skipping bounds checking but you will be able to speed up access to _MEM blocks by skipping any checking. Furthermore, you can use offsets directly using _MEM blocks commands but you will always access array data through an array's descriptor. Ultimately it will depend on what you want to do and how many times you want to do it, but usually _MEM blocks (if used correctly with $CHECKING:OFF) will be faster. _MEM blocks also allow for moving memory around in new ways which conventional QB64 code simply cannot cater for. If what you want to do can be achieved with arrays or _MEM blocks and timing is not of utmost concern then using arrays will make your code more readable and that should also be considered. Also, in your example the m2 array contained 2001 bytes and the m block contained 2000 bytes ;)



I've just done some work on scoping of locks...
Code: [Select]
DIM SHARED m AS _MEM

mysubA
_MEMCOPY m, m.OFFSET, 1 TO m, m.OFFSET + 1 'this WON'T work (generates a critical error saying memory has been freed)

SUB mysubA
what& = 1
m = _MEM(what&)
PRINT what& 'prints 1 (as it should)
mysubB
PRINT what& 'prints 257 (as it should)
END SUB

SUB mysubB
_MEMCOPY m, m.OFFSET, 1 TO m, m.OFFSET + 1 'this WILL work
END SUB
« Last Edit: April 17, 2012, 11:35:15 PM by Galleon »
Something old... Something new... Something borrowed... Something blue...

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #6 on: April 18, 2012, 12:52:24 AM »
I'll post some scraps here as I work on this...

Code: [Select]
SCREEN 13
DIM b AS _MEM
b = _MEMIMAGE(0)
PSET (0, 0), 40
_MEMGET b, b.OFFSET, c~%
PRINT c~% 'prints 40

Some interesting benchmarks of a not very real situation...
Code: [Select]
'a benchmark of the _MEM system
'test: read the pixel color values of a 1024x768 image 100 times

DEFLNG A-Z
DIM m AS _MEM
DIM o AS _OFFSET, o2 AS _OFFSET

myscreen = _NEWIMAGE(1024, 768, 32)
SCREEN myscreen

'using POINT (POINT is not really optimized in QB64 so this is a bit unfair to POINT but...)
t1# = TIMER(0.001)
FOR n = 1 TO 100
    FOR y = 0 TO 767
        FOR x = 0 TO 1023
            col = POINT(x, y)
        NEXT
    NEXT
NEXT
PRINT TIMER(0.001) - t1# '2.79 seconds

'using _MEM block with checking (checking will catch any problems and give meaningful error feedback)
t1# = TIMER(0.001)
m = _MEMIMAGE(0)
o = m.OFFSET
FOR n = 1 TO 100
    FOR y = 0 TO 767
        FOR x = 0 TO 1023
            _MEMGET m, o + (y * 1024 + x) * 4, col
        NEXT
    NEXT
NEXT
PRINT TIMER(0.001) - t1# '1.45 seconds

'using _MEM block without checking
t1# = TIMER(0.001)
m = _MEMIMAGE(0)
o = m.OFFSET
FOR n = 1 TO 100
    FOR y = 0 TO 767
        FOR x = 0 TO 1023
            $CHECKING:OFF
            _MEMGET m, o + (y * 1024 + x) * 4, col
            $CHECKING:ON
        NEXT
    NEXT
NEXT
PRINT TIMER(0.001) - t1# '0.69 seconds

'using _MEM block without checking AS WELL AS a linear approach (not really a fair comparison but it does the same functionality)
t1# = TIMER(0.001)
m = _MEMIMAGE(0)
o2 = m.OFFSET + 1024 * 768 * 4 - 1
$CHECKING:OFF
FOR n = 1 TO 100
    o = m.OFFSET
    DO
        _MEMGET m, o, col
        o = o + 4
    LOOP UNTIL o > o2
NEXT
$CHECKING:ON
PRINT TIMER(0.001) - t1# '0.37 seconds

'using an array (not really a screen but it's still an equivalent buffer)
DIM pixels(1024 * 768)
t1# = TIMER(0.001)
m = _MEMIMAGE(0)
o = m.OFFSET
FOR n = 1 TO 100
    FOR y = 0 TO 767
        FOR x = 0 TO 1023
            col = pixels(y * 1024 + x)
        NEXT
    NEXT
NEXT
PRINT TIMER(0.001) - t1# '1.09 seconds

So let's have a look at the C++ generated for the core loop of the _MEM linear approach in C:
Code: [Select]
do{
*(int32*)__LONG_COL=*(int32*)(*__OFFSET_O);
*__OFFSET_O=*__OFFSET_O+ 4 ;
}while((!(-(*__OFFSET_O>*__OFFSET_O2)))&&(!new_error));
There's a lot of casts, but casts like these don't slow things down. There's the obvious O=O+4 not O+=4 but the C compiler optimizes this automatically. There's the 'new_error' bit which shouldn't really be there and won't be later this year (checking is supposed to be turned off... sigh). Still, for QB64 code output it's a pretty good result.


Code: [Select]
SCREEN 13
DIM m AS _MEM
m = _MEMIMAGE
CLS , 5
_MEMPUT m, m.OFFSET, _RGBA32(3, 2, 1, 4) AS LONG
c& = _RGBA32(3, 2, 1, 4)
_MEMPUT m, m.OFFSET + 4, c&
4 pixels in 256 color mode, 2 ways... a simple demo of _MEMPUT
« Last Edit: April 18, 2012, 04:52:21 AM by Galleon »
Something old... Something new... Something borrowed... Something blue...

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #7 on: April 18, 2012, 04:58:43 AM »
Quote
DIM m(3) AS _BIT * 2 fit into a single byte?
Yes.
Something old... Something new... Something borrowed... Something blue...

LeChuck

  • Hero Member
  • *****
  • Posts: 895
  • 18 * 37
Re: What to expect over the next 5 (or so) days...
« Reply #8 on: April 18, 2012, 07:49:36 AM »
@Galleon

To be honest, I don't have a clue about these _MEM blocks other that it is supposed to resemble something like arrays but then in a c++ style which I don't know anything about. Is this something which will be more for the "advanced" QB64 programmer to use?
Two or more, use a FOR!

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: What to expect over the next 5 (or so) days...
« Reply #9 on: April 18, 2012, 12:50:22 PM »
What, no _FN or $FN in the works yet?

LeChuck, the mem blocks will make QB64 faster and allow more libraries to be added. Memory management is a big part of C designed programming, from my limited exposure to it.

Pete  ;D
It's only rocket science; it's not Linux!

SkyCharger001

  • Hero Member
  • *****
  • Posts: 1594
Re: What to expect over the next 5 (or so) days...
« Reply #10 on: April 18, 2012, 01:12:47 PM »
Quote from: LeChuck on April 18, 2012, 07:49:36 AM
@Galleon

To be honest, I don't have a clue about these _MEM blocks other that it is supposed to resemble something like arrays but then in a c++ style which I don't know anything about. Is this something which will be more for the "advanced" QB64 programmer to use?
I'm not certain but I think _MEM's purpose is to provide a controlled form of RAW memory access.
I see BLOCK as a pointer to the segment used.

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #11 on: April 18, 2012, 05:22:18 PM »
Quote
To be honest, I don't have a clue about these _MEM blocks other that it is supposed to resemble something like arrays but then in a c++ style which I don't know anything about. Is this something which will be more for the "advanced" QB64 programmer to use?
Firstly they have nothing to do with C++, in fact they are far removed from C++ style programming. They allow for raw memory access, much like PEEK/POKE/VARPTR/VARSEG/etc did in QBASIC but at a processor native level. _MEM blocks are so easy to use that you don't need to be an 'advanced' QB64 programmer to use them, that said, there are many more things an advanced QB64 user might use them for.

In a nutshell, the whole point of _MEM blocks is that you can move bytes (or groups of bytes) of memory around.
What is special about _MEM blocks, in comparison to other languages, is that if you make a mistake instead of your program crashing you get a useful error report about where and how the mistake was made. That's why I call _MEM blocks "messing with memory, safely."

Quote
LeChuck, the mem blocks will make QB64 faster and allow more libraries to be added. Memory management is a big part of C designed programming, from my limited exposure to it.
Again, nothing to do with C. _MEM blocks allows you to create a new block of memory which will not be destroyed when your SUB/FUNCTION returns, it is only removed when you use _MEMFREE. This lends itself to the creation of interfaces for various purposes using pure QB64 code. Before you would have has to use a multidimensional SHARED array or a giant STRING to keep the data in, and neither method is efficient.

Quote
I'm not certain but I think _MEM's purpose is to provide a controlled form of RAW memory access.
I see BLOCK as a pointer to the segment used.
That's right. A _MEM type holds some basic information about where and how big a region of memory is, as well as some hidden variables which allow QB64 to detect if the region of memory is still available.






Something old... Something new... Something borrowed... Something blue...

Clippy

  • Hero Member
  • *****
  • Posts: 16431
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #12 on: April 18, 2012, 05:37:36 PM »
This stuff sounds like trying to move your brain cells around rather than just thinking...  ;D
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: What to expect over the next 5 (or so) days...
« Reply #13 on: April 18, 2012, 09:31:54 PM »
For pure QB64 libraries to be useful to me, I would need my programs to compile when a call was made to a library. In QuickBasic, I simply wrote the call statement and compiled the program with the library included in the LINK statement. If I could call pure QB64 libraries that way again, that would be nice. Right now, that requires the library be placed in an include file. Honestly, I wonder if creating dlls wouldn't be a better approach?

Pete
It's only rocket science; it's not Linux!

Clippy

  • Hero Member
  • *****
  • Posts: 16431
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: What to expect over the next 5 (or so) days...
« Reply #14 on: April 18, 2012, 09:56:07 PM »
That would be cool if QB64 had a way to make DLLs. It would also be cool to have a way to use those old QLB libraries or their OBJ files again.
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip