v1.5 128 bit (and beyond) math *** COMPILER ERROR ***

[NOVARSEG]

example:   multiply the ASC value of 2 letters   A  *   B

The answer is 4,290

Code: QB64: [Select]

1. DIM var1 AS _UNSIGNED _INTEGER64
2. DIM var2 AS _UNSIGNED _INTEGER64
3. DIM var3 AS _UNSIGNED _INTEGER64
4. DIM var4 AS _UNSIGNED _INTEGER64
5.  
6. DIM m1 AS STRING * 128 '1024 bits
7. DIM m2 AS STRING * 128 '1024 bits
8. DIM m3 AS STRING * 256 '2048 bits
9.  
10. m1 = "A" + STRING$(127, CHR$(0))
11. m2 = "B" + STRING$(127, CHR$(0))
12.  
13. DIM mm1 AS _MEM
14. mm1 = _MEM(m1)
15.  
16. DIM mm2 AS _MEM
17. mm2 = _MEM(m2)
18.  
19. DIM mm3 AS _MEM
20. mm3 = _MEM(m3)
21.  
22. var1 = _MEMGET(mm1, mm1.OFFSET, _UNSIGNED _INTEGER64)
23.  
24. var2 = _MEMGET(mm2, mm2.OFFSET, _UNSIGNED _INTEGER64)
25.  
26. var3 = var2 * var1
27.  
28. _MEMPUT mm3, mm3.OFFSET, var3
29.  
30. var4 = _MEMGET(mm3, mm3.OFFSET, _UNSIGNED _INTEGER64)
31.  
32. PRINT var4

Seems like a complicated way to multiply numbers.   With this method it should be possible to multiply two  64 bit numbers or multiply  2  strings of 8 letters each.

[Richard]

As many would know, bit flags are a powerful feature that allow for access to memory mapped operations.

In the application to say 128 bit (and beyond) math, bit patterns allow for specifically designed routines as an easy way for certain classes of operations in low-level programming. It would allow implementation of features for speed and memory optimization in addition to various programming interface protocols.

Referring to my reply #163 (this topic/thread), I was not able to use _UNSIGNED _BIT with MEM blocks.

Only one person ( @NOVARSEG ) replied that MEM does not support _UNSIGNED _BIT. I was hoping that some QB64 developers would comment on same.

Although a type such as _BIT is not mentioned for TYPE memory-type, I would think in my intended application for 128 bit (and beyond) math, if I worked with multiples of 64 bit fields - it would be possible to do MEM block <--> 64 bit array elements interactions (eg using DIM h~`(0 to 63)). Working with unsigned bit arrays would be a convenient mechanism for handling very large numbers, and has the advantage of easier program readability and debugging over packed bit methods such as byte, integer, long etc. QB64 appears to pack unsigned bits into bytes, so it is also memory efficient.

So suppose I had a bit array of size being a multiple of 64 bits - is there a programming mechanism to allow this to be a MEM block (which then can be accessed by the other variable types such as INTEGER64)? If not - then to have this special case of unsigned bit implementation as being compatible with the usual MEM block operations as a FEATURE REQUEST.  After all, if one sees that a MEM block is a contiguous set of bytes in memory, and a 64bit unsigned bit array is packed into 8 bytes in another contiguous set of 8 bytes of memory - then hopefully by virtue of handling contiguous sets of memory then MEM could work here.

To me, the fact that the very same MEM block can be "assigned" to many variable types including strings and vice versa (all of which effectively simultaneously) - makes it a very versatile feature of QB64 (together with potential speed gains and memory savings). Unsigned bit interaction capability would be a big plus especially in large number math (when compared to working with say integers, etc).

[SpriggsySpriggs]

Unsigned bit, or just bit, has many issues. It's not recommended for use at all, actually. It half works and isn't actually a bit anyways. You could use an integer64 and use ReadBit and SetBit. That works well.

[Richard]

@SpriggsySpriggs

Thanks for your reply. I do not understand (at the moment) when the BIT stuff only half works (suppose will find out for myself soon enough).

Lets assume for the moment that BIT arrays fully work, and the one super large array h~`(0 to 1023) packs into 128 contiguous bytes in memory (which I think it does). Referring to your post

https://www.qb64.org/forum/index.php?topic=4023.0   reply #6

@TempodiBasic

Don't forget; you can also use my new shared memory library in Windows!


Parent:

Code: QB64: [Select]

1. Option _Explicit
2.  
3.  
4. 2.
5.  
6.  
7. 3.Dim As _MEM pShare 'You need to use a _MEM block
8.  
9.  
10. 4.Dim As Long longtoShare: longtoShare = 500 'declaring a long variable to store in the _MEM block
11.  
12.  
13. 5.pShare = _Mem(longtoShare) 'storing the long variable in the _MEM block
14.  
15.  
16. 6.
17.  
18.  
19. 7.Print CommonShared("MySharedMem", pShare) 'initializing the shared memory object
20.  
21.  
22. 8._MemFree pShare
23.  
24.  
25. 9.
26.  
27.  
28. 10.'$INCLUDE:'Win32 SharedMem.bas'
29.  

Child:

Code: QB64: [Select]

1. Option _Explicit
2.  
3.  
4. 2.
5.  
6.  
7. 3.Dim As _MEM newMem: newMem = _MemNew(4) 'declaring the destination _MEM block
8.  
9.  
10. 4.
11.  
12.  
13. 5.Print ReadShared("MySharedMem", newMem) 'reading the shared memory object into the new _MEM block
14.  
15.  
16. 6.
17.  
18.  
19. 7.Dim As Long dest 'declaring a destination long variable
20.  
21.  
22. 8._MemGet newMem, newMem.OFFSET, dest 'storing the contents of the _MEM block into a new long variable
23.  
24.  
25. 9.Print dest
26.  
27.  
28. 10._MemFree newMem
29.  
30.  
31. 11.
32.  
33.  
34. 12.'$INCLUDE:'Win32 SharedMem.bas'
35.  

Full $INCLUDE, save as Win32 SharedMem.bas

Code: QB64: [Select]

1. Declare CustomType Library
2.  
3.  
4. 2.    Function CreateFileMapping%& Alias "CreateFileMappingA" (ByVal hFile As _Offset, Byval lpFileMappingAttributes As _Offset, Byval flProtect As Long, Byval dwMaximumSizeHigh As Long, Byval dwMaximumSizeLow As Long, lpName As String)
5.  
6.  
7. 3.    Function OpenFileMapping%& Alias "OpenFileMappingA" (ByVal dwDesiredAccess As Long, Byval bInheritHabndle As Long, lpName As String)
8.  
9.  
10. 4.    Function MapViewOfFile%& (ByVal hFileMappingObject As _Offset, Byval dwDesiredAccess As Long, Byval dwFileOffsetHigh As Long, Byval dwFileOffsetLow As Long, Byval dwNumberOfBytesToMap As _Offset)
11.  
12.  
13. 5.    Sub UnmapViewOfFile (ByVal lpBaseAddress As _Offset)
14.  
15.  
16. 6.    Function GetLastError& ()
17.  
18.  
19. 7.    Sub CloseHandle (ByVal hObject As _Offset)
20.  
21.  
22. 8.End Declare
23.  
24.  
25. 9.
26.  
27.  
28. 10.Function CommonShared%% (sharedName As String, pShared As _MEM)
29.  
30.  
31. 11.    Const INVALID_HANDLE_VALUE = -1
32.  
33.  
34. 12.    Const PAGE_READWRITE = &H04
35.  
36.  
37. 13.    Const FILE_MAP_ALL_ACCESS = &HF001F
38.  
39.  
40. 14.    Declare Dynamic Library "Kernel32"
41.  
42.  
43. 15.        Sub CopyMemory Alias "RtlCopyMemory" (ByVal Destination As _Offset, Byval Source As _Offset, Byval Length As _Offset)
44.  
45.  
46. 16.    End Declare
47.  
48.  
49. 17.    Dim As _Offset hMapFile, pBuf
50.  
51.  
52. 18.    Dim As Long sharedSize: sharedSize = Val(Str$(pShared.SIZE))
53.  
54.  
55. 19.    hMapFile = CreateFileMapping(INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, 0, sharedSize, sharedName)
56.  
57.  
58. 20.    If hMapFile = 0 Then
59.  
60.  
61. 21.        CommonShared = 0
62.  
63.  
64. 22.        Exit Function
65.  
66.  
67. 23.    End If
68.  
69.  
70. 24.    pBuf = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sharedSize)
71.  
72.  
73. 25.    If pBuf = 0 Then
74.  
75.  
76. 26.        CloseHandle hMapFile
77.  
78.  
79. 27.        CommonShared = 0
80.  
81.  
82. 28.        Exit Function
83.  
84.  
85. 29.    End If
86.  
87.  
88. 30.    CopyMemory pBuf, pShared.OFFSET, sharedSize
89.  
90.  
91. 31.    CommonShared = -1
92.  
93.  
94. 32.    EndShare hMapFile, pBuf
95.  
96.  
97. 33.End Function
98.  
99.  
100. 34.
101.  
102.  
103. 35.Function ReadShared%% (sharedName As String, destVar As _MEM)
104.  
105.  
106. 36.    Const FILE_MAP_ALL_ACCESS = &HF001F
107.  
108.  
109. 37.    Dim As _Offset hMapFile, pBuf
110.  
111.  
112. 38.    Dim As Long sharedSize: sharedSize = Val(Str$(destVar.SIZE))
113.  
114.  
115. 39.    hMapFile = OpenFileMapping(FILE_MAP_ALL_ACCESS, 0, sharedName)
116.  
117.  
118. 40.    If hMapFile = 0 Then
119.  
120.  
121. 41.        ReadShared = 0
122.  
123.  
124. 42.        Exit Function
125.  
126.  
127. 43.    End If
128.  
129.  
130. 44.    pBuf = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sharedSize)
131.  
132.  
133. 45.    If pBuf = 0 Then
134.  
135.  
136. 46.        ReadShared = 0
137.  
138.  
139. 47.        Exit Function
140.  
141.  
142. 48.    End If
143.  
144.  
145. 49.    destVar = _Mem(pBuf, sharedSize)
146.  
147.  
148. 50.    ReadShared = -1
149.  
150.  
151. 51.    EndShare hMapFile, pBuf
152.  
153.  
154. 52.End Function
155.  
156.  
157. 53.
158.  
159.  
160. 54.Sub EndShare (hMap As _Offset, pMapBuf As _Offset)
161.  
162.  
163. 55.    UnmapViewOfFile hMap
164.  
165.  
166. 56.    CloseHandle pMapBuf
167.  
168.  
169. 57.End Sub
170.  

Using your shared memory routine of above - can I share the same contiguous memory used by h~`(0 to 1023) with a MEM block of size 128 bytes - in the one program (ideal case)? - over two programs (one program has h~`(0 to 1023) and the other a MEM block of size 128 bytes)?

If the above can be done, then maybe I would have BIT functionality (sort of) with MEM in my intended implementation of BIT in 128 bit (and beyond) math.

As it is critical for speed optimization in my case - I wish to persue using BIT with MEM (assuming it can be made to work in my case). Of course I will be doing numerous speed comparisons with other variables (not BIT) and MEM to determine which works best for me (there are many combinations of things to try out and compare in QB64 code alone, not to mention following up on the other suggestions by forum members such as C libraries etc).

Hope you understand my intentions of using your shared memory program to the case of BIT with MEM.

[SpriggsySpriggs]

@Richard To my knowledge, my Shared Memory Library should allow you to share a memory buffer up to the upper limit of a 64 bit integer. As long as your data matches on both sides then you can share whatever you want. Strings, numbers, arrays, etc.

[Richard]

@SpriggsySpriggs

Thanks.

To my knowledge, my Shared Memory Library should allow you to share a memory buffer up to the upper limit of a 64 bit integer. As long as your data matches on both sides then you can share whatever you want. Strings, numbers, arrays, etc.

If I understand you correctly - does that mean that I could have on one side a MEM block of size 18,446,744,073,709,551,615 unsigned integer64 elements (maximum limit size of unsigned integer64) (subject to available RAM memory of my computer)?

And also, in principle on the other side being of the same memory size, have a bit array of size h~`(0 to 18,446,744,073,709,551,615 * 64 -1) which I think is bigger than 128 bits span?

:)

Oops - h`() would have to be reduced down to only h`( 0 to 18,446,744,073,709,551,615 -1) because of indexing issues and correspondingly MEM block reduced to 18,446,744,073,709,551,615/64 unsigned integer64 elements to match in size to h~`().

 

[SpriggsySpriggs]

@Richard Not an unsigned integer64, just a regular integer64. From the documentation I see, the value for the buffer limit is created by two DWORDs, which are longs and not unsigned.

[Richard]

@SpriggsySpriggs

OK so signed integer64.

Now in theory I can ONLY work with 9,223,372,036,854,775,807 bits using h~`() array !

:)

Not that I will be using 128 bit (and beyond) math for this ...

Pi has been computed to 3.14 trillion digits (refer Google etc search) - I get bored reading Pi after 10 digits (so anything beyond that could be random numbers for all I care (who bothers to check the accuracy at say one millionth decimal place anyway)?

To calculate Pi to say 9,223,372,036,854,775,807/4 digits (rough estimate) may take longer than the known estimated existence of the universe on my computer!

[Richard]

@SpriggsySpriggs

To my knowledge, my Shared Memory Library should allow you to share a memory buffer up to the upper limit of a 64 bit integer. As long as your data matches on both sides then you can share whatever you want. Strings, numbers, arrays, etc.

For the "Parent" ...

3.Dim As _MEM pShare 'You need to use a _MEM block
 
 
4.Dim As Long longtoShare: longtoShare = 500 'declaring a long variable to store in the _MEM block
 
 
5.pShare = _Mem(longtoShare) 'storing the long variable in the _MEM block
 

Your program set is potentially very useful for me, and as per your example it worked. I was unsuccessful to apply it with variable types _BIT array and as  previously discovered _BIT types are not supported with _MEM blocks.


Is there any "programming trick" you know or heard of that I could try to "trick" the "child" program to link via a _BIT array h~`() in the child to a regular _MEM block in the "parent" program? In my case I would ensure that the _BIT array (which apparently is packed as contiguous bytes) is exactly the same number of bytes as the _MEM block in the parent program.

[SpriggsySpriggs]

@Richard Do not use BIT

[Richard]

@SpriggsySpriggs


Quote from @SpriggsySpriggs   (reply 113)

What is the reason for needing such a large number right now?

I omitted mentioning the following in my reply (118) ...



At about the same time of the "Pentium Bug", there was an interesting article. The article, as far as I could tell, did not mention specific names, companies, products and so - although "sketchy" here, the article relates to an investigation (in the USA) about that a certain (fairly complex) IC package (i.e. the silicon chip inside) was found in an "un-authorized" product on the commercial market. So apparently the silicon die chip was illegally copied and sold in a competitor's product. (Although the question maybe "Was this intelectural theft?" - or was this "A shenanigan (or something)" - the development that follows was that (at the time) an un-named US government agency was investigating the incident.)

Apparently, it turned out that the original manufacturer of the chip "on purpose" arranged by design a "deliberate error in the silicon die", an error (or design fault) so by its nature not to be noticed etc. and in the mainstream usage would not have typically any bearing on any outcomes. The shear probability of a competitor coming up with such a "extremely remote" design fault of this kind, and going further, that the whole silicon die itself was exactly identical including the physical location of the design fault on the silicon die itself - would suggest to readers of the article that corporate theft was involved. Further, due to lack of disclosure of specific names etc. and lack of follow-up press releases - the article left open to the readers that "Was there a National Security Risk (for USA) because of "corporate spying (or something)?". To sum this story up - I think the whole event was an investigative "STING" (I think the word is).


NOW, more recently (a few years ago, and I think maybe still continuing today) is the "Talent 1000" program - being run by the Chinese Government. Here the Chinese Government was actively encouraging its manufacturing infrastructure to improve its products to be competitive  with the rest of the world. Coincidently, there have been government investigations of "connections of various specialists" with the "Talent 1000" program - and especially of same (outside of China) not declaring such interests....(and I leave it to your imagination of all sorts of things that can be resulting because of this).


As far as this reply goes  ...


The Pentium Bug may not have been a "design mistake" (rather a test of security and integrity processes). As to the many thousands of computers which have had the particular "batch" of Pentium processors installed (apparently only a particular model/product number of the Pentium chip is affected) - and of which INTEL probably did not sell to computer makers - what happens to the owners of these affected computers today (and consider, following up on what was said above, on further INTEL products of the current "x86...x64" series)? At the time of the Pentium Bug, apparently software patches "popped up" but I seem to find same hard to find. For my INTEL processor I did run an INTEL program which did output a lot of information on my particular chip (like how much first, second and third level memory was present, etc.).



As far as QB64 goes, for the many potential "compromised" computers out there - maybe @SpriggsySpriggs (or someone) can come up with firstly a diagnostic program (Windows API or something) to exactly classify the processor installed. Secondly, based on this classification (and reference to any submitted list of "suspect processors") perform very specific program result tests (say along the line of advertised Pentium Bug tests). Finally to confirm if the bugs are present - and for say divides may need calculations beyond 64/80 bit using completely independent means (not intel divide/multiply operations).


Of course all of the above is an "isolated case" (Pentium Bug) and has not touched on a potentially more serious aspect of precision (which may be a matter of opinion depending on users expectations).
 

[SpriggsySpriggs]

So we're building security programs in QB64 now?

[SMcNeill]

So we're building security programs in QB64 now?

You and Richard might be, but I’m not.  ;D

I’m happy to just build “Wello Horld” programs when I can, without messing them up…

[SpriggsySpriggs]

I sure as heck ain't building anything for security. Security doesn't even cross my mind when writing a QB64 program. Only thing I think is, "huh, neat. It worked. It's a miracle"

[George McGinn]

I guess I should say some prayers on my next QB64 compile --- I could use a miracle!

I sure as heck ain't building anything for security. Security doesn't even cross my mind when writing a QB64 program. Only thing I think is, "huh, neat. It worked. It's a miracle"