### Author Topic: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***  (Read 11685 times)

0 Members and 1 Guest are viewing this topic.

#### NOVARSEG

• Forum Resident
• Posts: 510
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #165 on: June 13, 2021, 08:19:38 PM »
example:   multiply the ASC value of 2 letters   A  *   B

Code: QB64: [Select]
1.
2. DIM m1 AS STRING * 128 '1024 bits
3. DIM m2 AS STRING * 128 '1024 bits
4. DIM m3 AS STRING * 256 '2048 bits
5.
6. m1 = "A" + STRING\$(127, CHR\$(0))
7. m2 = "B" + STRING\$(127, CHR\$(0))
8.
9. DIM mm1 AS _MEM
10. mm1 = _MEM(m1)
11.
12. DIM mm2 AS _MEM
13. mm2 = _MEM(m2)
14.
15. DIM mm3 AS _MEM
16. mm3 = _MEM(m3)
17.
18. var1 = _MEMGET(mm1, mm1.OFFSET, _UNSIGNED _INTEGER64)
19.
20. var2 = _MEMGET(mm2, mm2.OFFSET, _UNSIGNED _INTEGER64)
21.
22. var3 = var2 * var1
23.
24. _MEMPUT mm3, mm3.OFFSET, var3
25.
26. var4 = _MEMGET(mm3, mm3.OFFSET, _UNSIGNED _INTEGER64)
27.
28. 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.
« Last Edit: June 13, 2021, 08:45:25 PM by NOVARSEG »

#### Richard

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #166 on: July 01, 2021, 04:00:26 AM »
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

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #167 on: July 01, 2021, 07:43:22 AM »
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

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #168 on: July 01, 2021, 01:16:11 PM »
@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

Quote

@TempodiBasic

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

Parent:
Code: QB64: [Select]
1.
2.
3. 2.
4.
5.
6. 3.DIM AS _MEM pShare 'You need to use a _MEM block
7.
8.
9. 4.DIM AS LONG longtoShare: longtoShare = 500 'declaring a long variable to store in the _MEM block
10.
11.
12. 5.pShare = _MEM(longtoShare) 'storing the long variable in the _MEM block
13.
14.
15. 6.
16.
17.
18. 7.PRINT CommonShared("MySharedMem", pShare) 'initializing the shared memory object
19.
20.
21. 8._MEMFREE pShare
22.
23.
24. 9.
25.
26.
27. 10.'\$INCLUDE:'Win32 SharedMem.bas'
28.

Child:
Code: QB64: [Select]
1.
2.
3. 2.
4.
5.
6. 3.DIM AS _MEM newMem: newMem = _MEMNEW(4) 'declaring the destination _MEM block
7.
8.
9. 4.
10.
11.
12. 5.PRINT ReadShared("MySharedMem", newMem) 'reading the shared memory object into the new _MEM block
13.
14.
15. 6.
16.
17.
18. 7.DIM AS LONG dest 'declaring a destination long variable
19.
20.
21. 8._MEMGET newMem, newMem.OFFSET, dest 'storing the contents of the _MEM block into a new long variable
22.
23.
24. 9.PRINT dest
25.
26.
27. 10._MEMFREE newMem
28.
29.
30. 11.
31.
32.
33. 12.'\$INCLUDE:'Win32 SharedMem.bas'
34.

Full \$INCLUDE, save as Win32 SharedMem.bas
Code: QB64: [Select]
1.
2.
3. 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)
4.
5.
6. 3.    FUNCTION OpenFileMapping%& ALIAS "OpenFileMappingA" (BYVAL dwDesiredAccess AS LONG, BYVAL bInheritHabndle AS LONG, lpName AS STRING)
7.
8.
9. 4.    FUNCTION MapViewOfFile%& (BYVAL hFileMappingObject AS _OFFSET, BYVAL dwDesiredAccess AS LONG, BYVAL dwFileOffsetHigh AS LONG, BYVAL dwFileOffsetLow AS LONG, BYVAL dwNumberOfBytesToMap AS _OFFSET)
10.
11.
12. 5.    SUB UnmapViewOfFile (BYVAL lpBaseAddress AS _OFFSET)
13.
14.
15. 6.    FUNCTION GetLastError& ()
16.
17.
18. 7.    SUB CloseHandle (BYVAL hObject AS _OFFSET)
19.
20.
21.
22.
23. 9.
24.
25.
26. 10.FUNCTION CommonShared%% (sharedName AS STRING, pShared AS _MEM)
27.
28.
29. 11.    CONST INVALID_HANDLE_VALUE = -1
30.
31.
32. 12.    CONST PAGE_READWRITE = &H04
33.
34.
35. 13.    CONST FILE_MAP_ALL_ACCESS = &HF001F
36.
37.
38. 14.    DECLARE DYNAMIC LIBRARY "Kernel32"
39.
40.
41. 15.        SUB CopyMemory ALIAS "RtlCopyMemory" (BYVAL Destination AS _OFFSET, BYVAL Source AS _OFFSET, BYVAL Length AS _OFFSET)
42.
43.
44. 16.    END DECLARE
45.
46.
47. 17.    DIM AS _OFFSET hMapFile, pBuf
48.
49.
50. 18.    DIM AS LONG sharedSize: sharedSize = VAL(STR\$(pShared.SIZE))
51.
52.
53. 19.    hMapFile = CreateFileMapping(INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, 0, sharedSize, sharedName)
54.
55.
56. 20.    IF hMapFile = 0 THEN
57.
58.
59. 21.        CommonShared = 0
60.
61.
62. 22.        EXIT FUNCTION
63.
64.
65. 23.    END IF
66.
67.
68. 24.    pBuf = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sharedSize)
69.
70.
71. 25.    IF pBuf = 0 THEN
72.
73.
74. 26.        CloseHandle hMapFile
75.
76.
77. 27.        CommonShared = 0
78.
79.
80. 28.        EXIT FUNCTION
81.
82.
83. 29.    END IF
84.
85.
86. 30.    CopyMemory pBuf, pShared.OFFSET, sharedSize
87.
88.
89. 31.    CommonShared = -1
90.
91.
92. 32.    EndShare hMapFile, pBuf
93.
94.
95.
96.
97. 34.
98.
99.
100. 35.FUNCTION ReadShared%% (sharedName AS STRING, destVar AS _MEM)
101.
102.
103. 36.    CONST FILE_MAP_ALL_ACCESS = &HF001F
104.
105.
106. 37.    DIM AS _OFFSET hMapFile, pBuf
107.
108.
109. 38.    DIM AS LONG sharedSize: sharedSize = VAL(STR\$(destVar.SIZE))
110.
111.
112. 39.    hMapFile = OpenFileMapping(FILE_MAP_ALL_ACCESS, 0, sharedName)
113.
114.
115. 40.    IF hMapFile = 0 THEN
116.
117.
119.
120.
121. 42.        EXIT FUNCTION
122.
123.
124. 43.    END IF
125.
126.
127. 44.    pBuf = MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sharedSize)
128.
129.
130. 45.    IF pBuf = 0 THEN
131.
132.
134.
135.
136. 47.        EXIT FUNCTION
137.
138.
139. 48.    END IF
140.
141.
142. 49.    destVar = _MEM(pBuf, sharedSize)
143.
144.
146.
147.
148. 51.    EndShare hMapFile, pBuf
149.
150.
151.
152.
153. 53.
154.
155.
156. 54.SUB EndShare (hMap AS _OFFSET, pMapBuf AS _OFFSET)
157.
158.
159. 55.    UnmapViewOfFile hMap
160.
161.
162. 56.    CloseHandle pMapBuf
163.
164.
165. 57.END SUB
166.

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

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #169 on: July 01, 2021, 01:42:31 PM »
@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

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #170 on: July 01, 2021, 02:19:48 PM »
@SpriggsySpriggs

Thanks.

Quote
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

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #171 on: July 01, 2021, 02:33:05 PM »
@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

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #172 on: July 01, 2021, 02:52:38 PM »
@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

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #173 on: July 19, 2021, 06:37:06 PM »
@SpriggsySpriggs

Quote
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" ...

Quote

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

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #174 on: July 19, 2021, 10:33:57 PM »
@Richard Do not use BIT

#### Richard

• Seasoned Forum Regular
• Posts: 330
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #175 on: August 09, 2021, 09:09:13 PM »
@SpriggsySpriggs

Quote
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).

« Last Edit: August 09, 2021, 09:17:15 PM by Richard »

#### SpriggsySpriggs

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #176 on: August 10, 2021, 08:50:44 AM »
So we're building security programs in QB64 now?

#### SMcNeill

• QB64 Developer
• Forum Resident
• Posts: 3688
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #177 on: August 10, 2021, 12:21:08 PM »
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…
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

#### SpriggsySpriggs

• QB64 Developer
• Forum Resident
• Posts: 1102
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #178 on: August 10, 2021, 12:22:42 PM »
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

• Forum Regular
• Posts: 123
##### Re: v1.5 128 bit (and beyond) math *** COMPILER ERROR ***
« Reply #179 on: August 10, 2021, 09:13:19 PM »
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"
________________________________________________________
George McGinn
Theoretical/Applied Computer Scientist
Member: IEEE, IEEE Computer Society
IEEE Sensors Council & IoT Technical Community
American Association for the Advancement of Science (AAAS)