Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Raw memory access

Author
Message
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 24th Nov 2009 04:45
Would anyone be interested in being able to have this ability. what i mean is being able to use pointers and read and write to them, and allocate/free memory? I am currently working on a dll to do this and was wondering if anyone would like it? Didn't want to post it up here if all it would to is take up space.

I currently have these commands(note: peek and poke mean read and write)

Allocation Functions:

Alloc(size) Allocates a 'size' bytes long block of memory and returns the pointer
Alloc_Zeroed(size) Just like above, it just sets the values to 0 before returning the pointer
Alloc_File(filePath$, size) allocates a block of memory. the size variable should be the file size+1(for the turminating null character) or more. if it is less the function will return -1
Alloc_SetValue(size, value) the same as alloc_zeroed but sets all values to the value parameter.
Alloc_String(string$) allocates a string of memory the size of the string and sets it's value to the string

Reading functions:

PeekByte(ptr) reads one byte from the location in memory the pointer points to
PeekWord(ptr) reads a word from the pointer
PeekLong(ptr) Reads a long(or DWORD) from the pointer
PeekString(ptr, string$, length) Reads a string and puts it in the string variable. If the length is set to 0 it will read until a null character is found.

Writing Functions:

PokeByte(ptr, byte) sets the BYTE value of the pointer to 'byte'
PokeWord(ptr, word) sets the WORD value of the pointer to 'word'
PokeLong(ptr, long) sets the LONG(or DWORD) value of the pointer to 'long'
PokeString(ptr, string$) sets each byte in the pointer to each character of the string. If the memory block pointed to by ptr isn't big enough then the function will fail and will terminate the program.
Save_Memory(filename$, ptr, size) saves the memory at location 'ptr' until location 'ptr+size' to a file.

Free(ptr, size) Will free the block of memory. if size is set to 0 then it will free the pointer as a array. you should just use the original pointer attained from one of the alloc functions. as using another(or adding to those) and free that with a size could have undesired results.

New Site! Check it out \/
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 24th Nov 2009 07:07
cool, i thought that's what memblocks were

"With games, we create these elaborate worlds in our minds, and the computer is there to do the bookkeeping." - Will Wright
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 24th Nov 2009 15:36
Kind of. But with this you are using pointers. so you can create some memory manipulate it and then send it on to a dll. or get a pointer from a dll and read it. Plus there is no liimit(exept how much memory your computer has) to how much of this you can create

New Site! Check it out \/
Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 24th Nov 2009 16:14
If it is faster then memblocks, I'm in

- Link102
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 24th Nov 2009 16:29 Edited at: 24th Nov 2009 16:45
I have not checked speed! wow. i forgot about that! i will check.

Edit:


I tested it. The dll is considerably faster! I made a 1kb(1000 byte) block of memory and a 1kb memblock and cycled through every byte and set it to a random number(0-255) and for the memblock it took 50 milliseconds and for the dll it returned 0! I have uploaded the dll and here's the example



New Site! Check it out \/

Attachments

Login to view attachments
Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 24th Nov 2009 18:08 Edited at: 24th Nov 2009 18:34
On my system memblocks took 18 milisecconds and your method 1 miliseccond.


edit:
something isn't right. It sais memblocks take 12 milisecconds and your dll takes 51 milisecconds


- Link102
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 24th Nov 2009 19:20 Edited at: 24th Nov 2009 19:41
Hmmm that's odd... Let me run some more tests. It might be slower. in that case, it's useless lol

Edit:

Your right. The first few times you run my test it returns 60 for memblock and 0 for dll but after that the memblock is faster.

This is weird though. because all the dll is doing is type casting a void* and setting the value. so that time should essentially be just the time ti takes to call the function. Hmmmm

New Site! Check it out \/
Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 24th Nov 2009 20:22 Edited at: 24th Nov 2009 20:28
well fix it

maybe it's dbc dll functions or the function call in the program or the addition on the pData handle?

Here, the dbc function is slowing you down 5 milisecconds, the addition of x another 3 milisecconds.


- Link102
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 24th Nov 2009 20:54 Edited at: 24th Nov 2009 20:56
Quote: "well fix it "


I can't. from the looks of these tests. the time is being taken by the call dll command, because look at my PokeByte() function:




how can you get any simpler? lol

New Site! Check it out \/
Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 24th Nov 2009 23:06
well, back to ye olde drawing board.
Unless someone else has a good idea.

- Link102
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 24th Nov 2009 23:27 Edited at: 24th Nov 2009 23:27
Not sure if you guys realize this but Functions in DBC are slower than otherwise.


These two codes does the same thing but the function version is about half the speed compared to non-function.



Link102
19
Years of Service
User Offline
Joined: 1st Dec 2004
Location: On your head, weeeeee!
Posted: 24th Nov 2009 23:48
see my post, 4 posts up.
I removed the function in that one.

- Link102
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Nov 2009 23:51
Yup. Functions are slower than straight code. The function address has to be pushed and pulled from the stack and the program counter has to keep track of the line that called the function and all the lines within the function - or at least something like that. The advantage is the parameter handling.

To compare the speed more evenly, put the memblock calls in functions as well. Call each and see if there is a difference. Then do both calls outside of functions.

Enjoy your day.
Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 25th Nov 2009 05:31
Well even outside of the function(link102 posted it up and i tested it) it only shaves off about 5-10 milliseconds off the 900 when the memblock one only took like 200. so i don't think it's possible to get it fast enough. I will test with the memblock in the function though.

New Site! Check it out \/
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Nov 2009 05:34 Edited at: 11th Aug 2010 22:21
The bottle neck is most likely in the Call DLL operation. Unfortunately, since this operation uses the name of the function (rather than it's pointer), this means that internally Call DLL has to first retrieve the pointer of this function, then built a call to it. Every time.

This constant overhead adds a lot of weight to the operation, which will only be magnified when put under stress of the bench mark.

Prior to the addition of MemBlocks in DBC (about 8/9 years ago), I wrote a library to simulate them in integer arrays. The generation process wasn't the quickest, but once the banks were created, you could handle banks of memory dynamically.

Today, you could no doubt take this type of approach further, via either with a combined MemBank + Array approach or setting up a allocation manager around a mem block. Which would allow you treat this chunk as many 'smaller' chunks, then resize the cache as required. Which would easily get around the memblock limit. Plus help with memory fragmentation.

Caleb1994
15
Years of Service
User Offline
Joined: 10th Oct 2008
Location: The Internet you idiot!
Posted: 25th Nov 2009 05:44
Quote: "The bottle neck is most likely in the Call DLL operation. Unfortunately, since this operation uses the name of the function (rather than it's pointer), this means that internally Call DLL has to first retrieve the pointer of this function, then built a call to it. Every time."


That's what i figured. Bummer really. Well it can atleast be used here and there to read from pointers if needed.

New Site! Check it out \/

Login to post a reply

Server time is: 2024-03-29 05:04:56
Your offset time is: 2024-03-29 05:04:56