QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: NOVARSEG on February 13, 2021, 12:46:12 am

Title: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 12:46:12 am
Sidetracking a bit.
 I want to devise some test code to see if the order of data items in TYPE structures are important.



Quote
TYPE ABC
    Z AS INTEGER
    Y AS INTEGER
END TYPE

DIM b AS _OFFSET

DIM c AS ABC

c.Z = 100
c.Y = 1000

b = _OFFSET(c)

so the memory address of TYPE ABC is stored in b. Now how do you read the entire 4 bytes in that TYPE into an LONG ,  using b ?
Title: Re: NOVARSEG and the quest for _MEM
Post by: SpriggsySpriggs on February 13, 2021, 12:59:53 am
@NOVARSEG
Check the Wiki for MEM
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 01:06:09 am
OK yes MEM   . It looks like the order is important when referencing   TYPE data structures by address but want to make sure with some tests

I was reading on some site that an option to padding was rearranging the items in a data structure and  thought how is that?


Title: Re: NOVARSEG and the quest for _MEM
Post by: SpriggsySpriggs on February 13, 2021, 01:11:00 am
@NOVARSEG
That would only be an option when it is a type that you are making for your own functions. For anything like WinAPI, you can't reorder the variables unless you WANT the data to go to the wrong variables
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 01:30:01 am
@SpriggsySpriggs

Makes sense thanks

Quote
DIM L AS LONG

DIM m AS _MEM

_MEMGET m, m.OFFSET, B

_MEMPUT m, m.OFFSET, L

PRINT L

get a memory not initialized error.
Title: Re: NOVARSEG and the quest for _MEM
Post by: SMcNeill on February 13, 2021, 01:42:05 am
@SpriggsySpriggs

Makes sense thanks

get a memory not initialized error.

Makes sense, as you haven’t initialized your memory.  It points at nothing.

Here’s what you’d be doing with file access:

m = FREEFILE
GET m, 0, B

And, you’d get an error then too, as you’ve never actually opened any file on your drive to access.  Start with wiki examples, or my tutorials, and learn the basic syntax of the commands, before just shooting off blindly with them.

What you’re doing is almost as bad as trying to PRINT HELLO WORLD without using quotes, and then complaining when it doesn’t work as you imagine.
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 03:32:19 pm
Ok IM totally stupid when it comes to mem

Quote
DIM m AS _MEM 

DIM N AS STRING * 4

N = "abcd"

m = _MEM(N)

_MEMPUT m, m.OFFSET, N

N = ""
_MEMGET m, m.OFFSET, N

PRINT N

does not print abcd
Title: Re: NOVARSEG and the quest for _MEM
Post by: SMcNeill on February 13, 2021, 04:23:55 pm
Of course it's not going to print abcd.  You just reset N to "".

Start a topic on mem, and ask questions there about it.  I don't have a clue what you're trying to do, but it's definitely not related to the topic at hand.
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 05:33:06 pm
yes off topic did not want to start a new thread

Will get back on track but MEM to me is an abstraction on so many levels


 I thought N is now stored in m with
_MEMPUT m, m.OFFSET, N

N = ""

then do the reverse

_MEMGET m, m.OFFSET, N

see how I don't understand MEM?. At least I know what I don't understand

PRINT N


****

In C there is

Quote
The & is a unary operator in C which returns the memory address of the passed operand. This is also known as address of operator. The * is a unary operator which returns the value of object pointer by a pointer variable. It is known as value of operator.


Ok so  i got the address of TYPE ABC structure in B
Quote
TYPE ABC
    Z AS INTEGER
    Y AS INTEGER
END TYPE

DIM b AS _OFFSET

DIM c AS ABC

c.Z = 100
c.Y = 1000

b = _OFFSET(c)

In C there  is the "value of operator."

Do I really need MEM stuff to do a "value of operator" on  B"

Title: Re: NOVARSEG and the quest for _MEM
Post by: SpriggsySpriggs on February 13, 2021, 05:57:58 pm
@NOVARSEG
Like Steve said, you might want to go ahead and make a new thread and discuss MEM there. You might find more help there since the title will at least match the topic being discussed. People who understand MEM will see your question and respond.
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 06:01:33 pm
If I do that then more people will see how stupid I am when it comes to MEM
Title: Re: NOVARSEG and the quest for _MEM
Post by: RhoSigma on February 13, 2021, 07:17:56 pm
If I do that then more people will see how stupid I am when it comes to MEM

Not stupid, just blind seeing the obvious. you think your m is another variable, which you can exchange the value of N with and wise versa, but NO, m is not another variable, it's just ANOTHER WAY TO ACCESS your variable N.

Ie. m is a pseudonym for N, doesn't matter if you access N directly (N="") or via _MEMGET/PUT, you always change N and only N.

m is a pointer to the memory, where the value of N is stored, not more, not less.

EDIT:
If you're likely more familiar with C/C++, it's like taking the reference of a variable here:

char N;
char *m = &N;
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 13, 2021, 09:00:35 pm
I have no idea how/why this works.   Finally got it to print out.
Z is LSW,  Y is MSW. Could someone explain how it works

Code: QB64: [Select]
  1. TYPE ABC
  2.     Z AS INTEGER
  3.     Y AS INTEGER
  4.  
  5.  
  6. DIM c AS ABC
  7.  
  8. c.Z = 400
  9. c.Y = 0
  10.  
  11. m = _MEM(c)    
  12.  
  13. _MEMGET m, m.OFFSET, N&    

with
 c.Z = 400
c.Y = 0

print N& = 400

****

with
c.Z = 1
c.Y = 1

print N& = 65537
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 15, 2021, 01:51:24 am
_MEMPUT does the reverse of that


Code: QB64: [Select]
  1. TYPE ABC
  2.     Z AS INTEGER
  3.     Y AS INTEGER
  4.  
  5.  
  6. DIM C AS ABC
  7.  
  8.  
  9.  
  10. m = _MEM(C)
  11.  
  12. N = 2 ^ 32 - 1
  13.  
  14. C.Y = 0
  15. C.Z = 0
  16.  
  17. _MEMPUT m, m.OFFSET, N
  18.  
  19. PRINT C.Z
  20. PRINT C.Y

print C.Z = -1

print C.Y = -1

****
This proves that variables in a TYPE list, are contiguous in memory

Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 15, 2021, 02:14:58 am
What happens when a variable length string is added to the TYPE list

Code: QB64: [Select]
  1. TYPE ABC
  2.     S AS STRING
  3.     Z AS INTEGER
  4.     Y AS INTEGER
  5.  
  6.  
  7.  
  8. DIM C AS ABC
  9.  
  10. C.S = "abcdefghijk"
  11.  
  12.  
  13. m = _MEM(C)
  14.  
  15. N = 2 ^ 32 - 1
  16.  
  17. C.Y = 0
  18. C.Z = 0
  19.  
  20. _MEMPUT m, m.OFFSET + 4, N
  21.  
  22. PRINT C.Z
  23. PRINT C.Y

print C.Z = -1
print C.Y = -1

The "S AS STRING" takes 4 bytes in the TYPE list, but there are 11 bytes stored in S

Now when the variable length string is changed to a fixed length string like


Code: QB64: [Select]
  1. TYPE ABC
  2.     S AS STRING * 11
  3.     Z AS INTEGER
  4.     Y AS INTEGER
  5.  
  6.  
  7.  
  8. DIM C AS ABC
  9. 'print len(c)
  10. C.S = "abcdefghijk"
  11.  
  12.  
  13. m = _MEM(C)
  14.  
  15. N = 2 ^ 32 - 1
  16.  
  17. C.Y = 0
  18. C.Z = 0
  19.  
  20. _MEMPUT m, m.OFFSET + 11, N
  21.  
  22. PRINT C.Z
  23. PRINT C.Y
  24.  

print C.Z = -1
print C.Y = -1

Then  "S AS STRING * 11"  takes up 11 bytes in the TYPE  list. So we know that "abcdefghijk" is stored in memory just before Z and Y integers.   That is not the case with the variable length string.
Title: Re: NOVARSEG and the quest for _MEM
Post by: RhoSigma on February 15, 2021, 02:55:41 am
That is, because fixed length strings are directly incorporated into your type, hence 11 bytes, but for variable length strings only a pointer to the string descriptor is incorporated into the type, which should be 4 bytes when using the 32bit version of QB64, while it should be 8 bytes when using the 64bit version of QB64.

In different words, fixed length is incorporated as is, variable length strings are just incorporated AS _OFFSET.
Title: Re: NOVARSEG and the quest for _MEM
Post by: NOVARSEG on February 15, 2021, 03:22:50 am
As RhoSigma suggested , the first 4 bytes in the TYPE list is the memory address of variable length STRING S

Code: QB64: [Select]
  1. TYPE ABC
  2.     S AS STRING
  3.     Z AS INTEGER
  4.     Y AS INTEGER
  5.  
  6.  
  7. DIM C AS ABC
  8.  
  9. C.S = "abcdefghijk"
  10.  
  11.  
  12.  
  13. m = _MEM(C)
  14.  
  15. _MEMGET m, m.OFFSET, N
  16.  

PRINT N = memory address of variable length string.

Title: Re: NOVARSEG and the quest for _MEM
Post by: SMcNeill on February 15, 2021, 09:27:50 am
PRINT N = memory address of variable length string.

This may, or may not, be true.  Variable length strings can move around in memory at any time, depending on when your OS does clean up calls and memory packing/rearranging.  When you got the value of N, that's where your variable length string was at that moment, but it could be somewhere else by the time you get to, and complete, the PRINT statement.  It's this movement of variable length strings which is why they don't work with _MEM as it currently exists.