Author Topic: What the heck happened to MEM.TYPEs??  (Read 3467 times)

0 Members and 1 Guest are viewing this topic.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
What the heck happened to MEM.TYPEs??
« on: January 27, 2021, 03:02:12 pm »
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 s1 AS STRING * 1
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12. m = _MEM(b): PRINT m.TYPE; "Byte"
  13. m = _MEM(i): PRINT m.TYPE; "Integer"
  14. m = _MEM(l): PRINT m.TYPE; "Long"
  15. m = _MEM(i64): PRINT m.TYPE; "Integer64"
  16. m = _MEM(ub): PRINT m.TYPE; "Unsigned Byte"
  17. m = _MEM(ui): PRINT m.TYPE; "Unsigned Integer"
  18. m = _MEM(ul): PRINT m.TYPE; "Unsigned Long"
  19. m = _MEM(ui64): PRINT m.TYPE; "Unsigned Integer64"
  20. m = _MEM(s): PRINT m.TYPE; "Single"
  21. m = _MEM(d): PRINT m.TYPE; "Double"
  22. m = _MEM(f): PRINT m.TYPE; "Float"
  23. m = _MEM(s1): PRINT m.TYPE; "String * 1"
  24. 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. 
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #1 on: January 27, 2021, 03:15:22 pm »
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.
« Last Edit: January 27, 2021, 03:22:18 pm by SMcNeill »
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #2 on: January 27, 2021, 03:29:25 pm »
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
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: What the heck happened to MEM.TYPEs??
« Reply #3 on: January 27, 2021, 03:49:03 pm »
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

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #4 on: January 27, 2021, 03:53:50 pm »
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.  :)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: What the heck happened to MEM.TYPEs??
« Reply #5 on: January 27, 2021, 03:57:27 pm »
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 s1 AS STRING * 1
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12. m = _MEM(b): PRINT m.TYPE; "Byte", m.ELEMENTSIZE
  13. m = _MEM(i): PRINT m.TYPE; "Integer", m.ELEMENTSIZE
  14. m = _MEM(l): PRINT m.TYPE; "Long", m.ELEMENTSIZE
  15. m = _MEM(i64): PRINT m.TYPE; "Integer64", m.ELEMENTSIZE
  16. m = _MEM(ub): PRINT m.TYPE; "Unsigned Byte", m.ELEMENTSIZE
  17. m = _MEM(ui): PRINT m.TYPE; "Unsigned Integer", m.ELEMENTSIZE
  18. m = _MEM(ul): PRINT m.TYPE; "Unsigned Long", m.ELEMENTSIZE
  19. m = _MEM(ui64): PRINT m.TYPE; "Unsigned Integer64", m.ELEMENTSIZE
  20. m = _MEM(s): PRINT m.TYPE; "Single", m.ELEMENTSIZE
  21. m = _MEM(d): PRINT m.TYPE; "Double", m.ELEMENTSIZE
  22. m = _MEM(f): PRINT m.TYPE; "Float", m.ELEMENTSIZE
  23. m = _MEM(s1): PRINT m.TYPE; "String * 1", m.ELEMENTSIZE
  24. m = _MEM(o): PRINT m.TYPE; "Offset", m.ELEMENTSIZE
  25.  
  26.  

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: What the heck happened to MEM.TYPEs??
« Reply #6 on: January 27, 2021, 04:00:50 pm »
Oh! I didn't quite understand the problem. So I'm silent and learning! :)

FellippeHeitor

  • Guest
Re: What the heck happened to MEM.TYPEs??
« Reply #7 on: January 27, 2021, 04:01:31 pm »
@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.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #8 on: January 27, 2021, 04:56:01 pm »
@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.  :(
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

FellippeHeitor

  • Guest
Re: What the heck happened to MEM.TYPEs??
« Reply #9 on: January 27, 2021, 05:28:34 pm »
Just sent you a private message here on the forum with a new user name and password.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #10 on: January 27, 2021, 05:59:44 pm »
Wiki updated to reflect the correct values for mem.TYPE.  :)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #11 on: January 27, 2021, 06:10:54 pm »
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
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: What the heck happened to MEM.TYPEs??
« Reply #12 on: January 28, 2021, 03:18:19 pm »
@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.
« Last Edit: January 28, 2021, 03:22:44 pm by Petr »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: What the heck happened to MEM.TYPEs??
« Reply #13 on: January 28, 2021, 03:40:44 pm »
@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.     PRINT 255; "IS GREATER THAN "; 1

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.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!