What the heck happened to MEM.TYPEs??

[SMcNeill]

The link to the wiki: http://www.qb64.org/wiki/MEM

And a quick copy of information for ease of reference:

Code: [Select]

0 = UDT (user defined type) or memory created by _MEMNEW
1 = 1 bit ELEMENT.SIZE=1 *Only used along with specific types (currently integers or floats)
2 = 2 bit. ELEMENT.SIZE=2 *
4 = 4 bit. ELEMENT.SIZE=4 *
8 = 8 bit. ELEMENT.SIZE=8 *
16 = 16 bit. ELEMENT.SIZE=16 *
32 = 32 bit. ELEMENT.SIZE=32 *
64 = 64 bit. ELEMENT.SIZE=64 *
128 = 128 bit. ELEMENT.SIZE=128 *
256 = 256 bit. ELEMENT.SIZE=256 *
512(+ bit*) = integer types only(ie. whole numbers)
1024(+ bit*) = floating point types only(ie. numbers that can have a decimal point)
2048 = STRING type only
4096(+ 512 + bit*) = _UNSIGNED integer type only
8192 = _MEM type only
16384(+ 512 + bit*)= _OFFSET type only
And a quick program to compare against:

Code: QB64: [Select]

1. DIM b AS _BYTE '129
2. DIM i AS INTEGER '130
3. DIM l AS LONG '132
4. DIM i64 AS _INTEGER64 '136
5. DIM ub AS _UNSIGNED _BYTE
6. DIM ui AS _UNSIGNED INTEGER
7. DIM ul AS _UNSIGNED LONG
8. DIM ui64 AS _UNSIGNED _INTEGER64
9. DIM s AS SINGLE
10. DIM d AS DOUBLE
11. DIM f AS _FLOAT
12. DIM s1 AS STRING * 1
13. DIM o AS _OFFSET
14.  
15.  
16.  
17. DIM m AS _MEM
18.  
19.  
20.  
21. m = _MEM(b): PRINT m.TYPE; "Byte"
22. m = _MEM(i): PRINT m.TYPE; "Integer"
23. m = _MEM(l): PRINT m.TYPE; "Long"
24. m = _MEM(i64): PRINT m.TYPE; "Integer64"
25. m = _MEM(ub): PRINT m.TYPE; "Unsigned Byte"
26. m = _MEM(ui): PRINT m.TYPE; "Unsigned Integer"
27. m = _MEM(ul): PRINT m.TYPE; "Unsigned Long"
28. m = _MEM(ui64): PRINT m.TYPE; "Unsigned Integer64"
29. m = _MEM(s): PRINT m.TYPE; "Single"
30. m = _MEM(d): PRINT m.TYPE; "Double"
31. m = _MEM(f): PRINT m.TYPE; "Float"
32. m = _MEM(s1): PRINT m.TYPE; "String * 1"
33. m = _MEM(o): PRINT m.TYPE; "Offset"

And a quick screen shot of the results this program is giving in 64-bit QB64.
  [ You are not allowed to view this attachment ]  

Did the mem.TYPE values change?  Just what the heck is going on here?  None of the values are matching up. 

[SMcNeill]

Testing various versions and the issue goes back all the way to v1.3, in 64-bit Windows.

I'll grab a 32-bit version and see if the problem is the same there, as well.


EDIT: 32-bit versions of QB64 are giving the same results.

Testing older code which I have (such as the mem sort routine), these values seem to hold true, as the program is written with them in mind.  It seems that somehow, the WIKI is wrong, and _MEM hasn't changed the TYPE values for some time now.

[SMcNeill]

The actual values should be this set:

name.TYPE is the type (represented as bits combined to form a value) AS LONG:
Supported from QB64 version .975 onward (Version .954 returns different values!)
[bit 0] 1* byte types (_BYTE)
[bit 1] 2* byte types (INTEGER)
[bit 2] 4* byte types (LONG or SINGLE)
[bit 3] 8* byte types (DOUBLE or _INTEGER64)
[bit 4] 16* byte types (reserved for future use)
[bit 5] 32* byte types (_FLOAT)
[bit 6] 64* byte types (reserved for future use)
[bit 7] 128 = integer types (_BYTE, INTEGER, LONG, _INTEGER64) (added to *)
[bit 8] 256 = floating point types (SINGLE, DOUBLE, _FLOAT) (added to *)
[bit 9] 512 = STRING types (fixed length or variable length)
[bit 10] 1024 = _UNSIGNED types (added to *+128)
[bit 11] 2048 = pixel data (added to 1+128+1024 or 4+128+1024)
[bit 12] 4096 = _MEM TYPE structure (NOT added to 32768)
[bit 13] 8192 = _OFFSET type (added to 4+128+[1024] or 8+128+[1024] or future_size+128+[1024])
[bit 14] 16384 = data created/defined by _MEMNEW(size) or _MEMNEW(offset,size)
[bit 15] 32768 = a custom, user defined type (ie. created with TYPE name ... END TYPE)
[bit 16] 65536 = an array of data (added to other type values defining the array's data type)

If I had to guess, I'd guess that the version on the wiki is from the SDL mem.TYPE values, and not the current version.  Could someone with WIKI access kindly update to the correct values.  It's mind blowing to be working with the command, go to look up the values, and find none of them make any dang sense to you.  :D

[Petr]

Hi Steve. Copy from IDE help for MEM statement:


IMPORTANT NOTE: As of Build 20170802/57 onward, mem.TYPE has been changed to be an _OFFSET, just as mem.SIZE and mem.ELEMENTSIZE.|red

[SMcNeill]

Hi Steve. Copy from IDE help for MEM statement:


IMPORTANT NOTE: As of Build 20170802/57 onward, mem.TYPE has been changed to be an _OFFSET, just as mem.SIZE and mem.ELEMENTSIZE.|red

Aye, but the values of the types aren't correct on the wiki.   A string has a value of 512, while the wiki has the value listed as 2048.  :)

[Petr]

This works fine:

Code: QB64: [Select]

1. DIM b AS _BYTE '129
2. DIM i AS INTEGER '130
3. DIM l AS LONG '132
4. DIM i64 AS _INTEGER64 '136
5. DIM ub AS _UNSIGNED _BYTE
6. DIM ui AS _UNSIGNED INTEGER
7. DIM ul AS _UNSIGNED LONG
8. DIM ui64 AS _UNSIGNED _INTEGER64
9. DIM s AS SINGLE
10. DIM d AS DOUBLE
11. DIM f AS _FLOAT
12. DIM s1 AS STRING * 1
13. DIM o AS _OFFSET
14.  
15.  
16.  
17. DIM m AS _MEM
18.  
19.  
20.  
21. m = _MEM(b): PRINT m.TYPE; "Byte", m.ELEMENTSIZE
22. m = _MEM(i): PRINT m.TYPE; "Integer", m.ELEMENTSIZE
23. m = _MEM(l): PRINT m.TYPE; "Long", m.ELEMENTSIZE
24. m = _MEM(i64): PRINT m.TYPE; "Integer64", m.ELEMENTSIZE
25. m = _MEM(ub): PRINT m.TYPE; "Unsigned Byte", m.ELEMENTSIZE
26. m = _MEM(ui): PRINT m.TYPE; "Unsigned Integer", m.ELEMENTSIZE
27. m = _MEM(ul): PRINT m.TYPE; "Unsigned Long", m.ELEMENTSIZE
28. m = _MEM(ui64): PRINT m.TYPE; "Unsigned Integer64", m.ELEMENTSIZE
29. m = _MEM(s): PRINT m.TYPE; "Single", m.ELEMENTSIZE
30. m = _MEM(d): PRINT m.TYPE; "Double", m.ELEMENTSIZE
31. m = _MEM(f): PRINT m.TYPE; "Float", m.ELEMENTSIZE
32. m = _MEM(s1): PRINT m.TYPE; "String * 1", m.ELEMENTSIZE
33. m = _MEM(o): PRINT m.TYPE; "Offset", m.ELEMENTSIZE
34.  
35.  

[Petr]

Oh! I didn't quite understand the problem. So I'm silent and learning! :)

[FellippeHeitor]

@SMcNeill I've just reset your wiki credentials in case you'd lost them. Please check the email you have associated with your forum account.

[SMcNeill]

@SMcNeill I've just reset your wiki credentials in case you'd lost them. Please check the email you have associated with your forum account.

For whatever reason, I’m not getting that email.  Other folks send stuff to me successfully via the forums mail/messages, but the wiki reset is getting lost somewhere along the way.  :(

[FellippeHeitor]

Just sent you a private message here on the forum with a new user name and password.

[SMcNeill]

Wiki updated to reflect the correct values for mem.TYPE.  :)

[SMcNeill]

Oh! I didn't quite understand the problem. So I'm silent and learning! :)

A quick lesson in mem.TYPE:

SUB Foo (m as _MEM)

Now, when we pass our memblock to Foo, what is it?  Is it a memblock of an integer, a screen, or what?

IF m.TYPE AND 2048 then it's a memblock pointing to a screen image.
    IF m.TYPE AND 1 then it's a 256 color screen image.
    IF m.TYPE AND 2 then it's a text screen.
    IF m.TYPE AND 4 then it's a 32-bit screen.
END IF

IF m.TYPE AND 512 then it's a string which we're pointing to.  (set length string as variable length doesn't work with mem)

IF m.TYPE AND 1024 then it's an _UNSIGNED TYPE (we can get the type by using AND 1, 2, 4, or 8 for byte size)

And so on and so on....  With those proper values, we can use m.TYPE to determine exactly what variable type we're pointing at, and then process it accordingly.

But to use those values, the documentation has to be correct on them...  and it wasn't, but it is now.  :D

[Petr]

@SMcNeill Thank you for the detailed explanation. I also looked at _MEMSOUND and found that you was dealing with it as well. I don't have the latest version, but the _MEM field with _MEMSOUND for the .TYPE function returns zero. It's another area I have to learn, I haven't really worked with .TYPE  yet.

[SMcNeill]

@SMcNeill Thank you for the detailed explanation. I also looked at _MEMSOUND and found that you was dealing with it as well. I don't have the latest version, but the _MEM field with _MEMSOUND for the .TYPE function returns zero. It's another area I have to learn, I haven't really worked with .TYPE  yet.

One time when it's really important to know your mem.TYPE is if you're ever going to compare values.

Let's say we have a memblock that contains the hex values "FF", and a memblock that contains the hex values "01"...  Can you tell me, which value is smaller than the other??

One is the ASCII value of 255, the other is the ASCII value of 01... It's got to be obvious which is smaller!  Right??

The 255 is, of course!!

Code: QB64: [Select]

1. DIM ub AS _BYTE, ub1 AS _BYTE
2. DIM m AS _MEM, m1 AS _MEM
3. m = _MEM(ub)
4. m1 = _MEM(ub1)
5.  
6. _MEMPUT m, m.OFFSET, CHR$(255)
7. _MEMPUT m1, m1.OFFSET, CHR$(1)
8.  
9. PRINT "In Hex, with signed bytes:"
10. IF ub < ub1 THEN
11.     PRINT 255; "IS LESS THAN "; 1
12. ELSEIF ub = ub1 THEN
13.     PRINT 255; "IS EQUAL TO "; 1
14. ELSE
15.     PRINT 255; "IS GREATER THAN "; 1
16. END IF

At least, if we're talking about signed bytes, then &HFF is less than &H01...

So, if we're going to be doing any sort of comparisons with mem, we have to know what TYPE we're dealing with.

In hex: 
FF can be either 255 or -1, if dealing with signed vs unsigned bytes...
FFFF can either be 65535 or -1, when dealing with signed vs unsigned integers...

Just knowing the element size alone doesn't tell us how to deal with the memblock, or how to process them.  We need to know what those values represent to know to interpret them -- and that's what mem.TYPE stores for us and lets us access when we need it in our programs.