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

[Richard]

@SpriggsySpriggs

Thanks for code - you even gave me an extra 2 bytes for the file! :)    (a semi-colon on PRINT #1 line fixed that)

I modified slightly your code, as below, to investigate why I got millions of "SPACEs" in my file - I thought that it would EITHER be millions of "NULLs" (i.e. CHR(&H00)) or "RANDOM GARBAGE" (if things were not initialized properly).

I used a simple free HEX editor to quickly view the file - have not yet analyzed what is in the MEM block.

Anyone like to comment???

Code: QB64: [Select]

1. OPTION _EXPLICIT
2. CONST GIGABYTE = 1024 ^ 3
3. DECLARE DYNAMIC LIBRARY "Kernel32"
4.     SUB CopyMemory ALIAS RtlCopyMemory (BYVAL Destination AS _OFFSET, BYVAL Source AS _OFFSET, BYVAL length AS _INTEGER64)
5. END DECLARE
6. DIM m AS _MEM: DIM I AS INTEGER: DIM gig AS STRING * GIGABYTE
7. m = _MEMNEW(GIGABYTE)
8. gig = "Hello, Richard"
9. FOR i% = 1 TO 32
10.     IF MID$(gig$, i%, 1) = " " THEN MID$(gig$, i%, 1) = "_"
11.     IF MID$(gig$, i%, 1) = CHR$(&H00) THEN MID$(gig$, i%, 1) = "-"
12. NEXT
13. CopyMemory m.OFFSET, _OFFSET(gig), LEN(gig)
14.  
15. OPEN "A:\HelloRichardTest.txt" FOR OUTPUT AS #1
16. PRINT #1, _MEMGET(m, m.OFFSET, STRING * GIGABYTE);
17. CLOSE #1: END

[SpriggsySpriggs]

It's just space. I mean, I made a fixed string the size of 1 gigabyte (which, to my knowledge, would be 1 gigabyte of spaces, then a CHR$(0)) and then stored it in the mem block. That's what's in the mem block. Since I printed the mem block's contents to the file you would get a gigabyte's worth of spaces in the file since the mem block only contains my gigabyte string. I have no use for moving data like this and have never used mem blocks so I probably won't pursue this any further.

[NOVARSEG]

Richard

I had 3 different (non-interacting with each other) QB64 programs running and because of the the very slow performance I suspect that all 3 programs were running using the same physical (+logical) processor maybe???

If statements are not (or cannot be) available - would it help to have multiple QB64 x64 installations  eg on C:\ , A:\, D:\ etc and accordingly run each program from a different QB64 installation?

Similarly if I wish to force multiple programs to run on a particular physical/logical processor (where speed is not important) - is this possible to program?

Windows already allows multiple applications to run at the same time.

For a, say, 486 CPU with 4 GB ram, you can run 4095 simultaneous x86 programs at the same time. That is like 30 year old technology..

If you are worried about speed then try to incorporate all the features of those programs into a single one.

There are methods in which multiple CPUs can work on a single problem to increase speed. I imagine these systems to be  complex and expensive so you would need a good reason to do so.

[SMcNeill]

@SpriggsySpriggs

Thanks for code - you even gave me an extra 2 bytes for the file! :)    (a semi-colon on PRINT #1 line fixed that)

I modified slightly your code, as below, to investigate why I got millions of "SPACEs" in my file - I thought that it would EITHER be millions of "NULLs" (i.e. CHR(&H00)) or "RANDOM GARBAGE" (if things were not initialized properly).

I used a simple free HEX editor to quickly view the file - have not yet analyzed what is in the MEM block.

Anyone like to comment???

Code: QB64: [Select]

1. OPTION _EXPLICIT
2. CONST GIGABYTE = 1024 ^ 3
3. DECLARE DYNAMIC LIBRARY "Kernel32"
4.     SUB CopyMemory ALIAS RtlCopyMemory (BYVAL Destination AS _OFFSET, BYVAL Source AS _OFFSET, BYVAL length AS _INTEGER64)
5. END DECLARE
6. DIM m AS _MEM: DIM I AS INTEGER: DIM gig AS STRING * GIGABYTE
7. m = _MEMNEW(GIGABYTE)
8. gig = "Hello, Richard"
9. FOR i% = 1 TO 32
10.     IF MID$(gig$, i%, 1) = " " THEN MID$(gig$, i%, 1) = "_"
11.     IF MID$(gig$, i%, 1) = CHR$(&H00) THEN MID$(gig$, i%, 1) = "-"
12. NEXT
13. CopyMemory m.OFFSET, _OFFSET(gig), LEN(gig)
14.  
15. OPEN "A:\HelloRichardTest.txt" FOR OUTPUT AS #1
16. PRINT #1, _MEMGET(m, m.OFFSET, STRING * GIGABYTE);
17. CLOSE #1: END

_MEMNEW doesn’t initialize a memblock, so it can contain all sorts of random information.  If you need it to be blank, be certain to set it that way manually.

DIM M AS _MEM
M = _MEMNEW(10000000000) ‘10 GB
_MEMFILL M, M.OFFSET, M.SIZE, 0 AS _UNSIGNED _BYTE ‘fill with CHR$(0)
_MEMFILL M, M.OFFSET, M.SIZE, 32 AS _UNSIGNED _BYTE ‘fill with blank spaces

[Richard]

@ SMcNeill

Thanks Steve - ACTUALLY I was hoping that for a special project I am playing around with (highly experimental - may not work at all) - to ATTEMPT to copy a contiguous bock of memory (1 GByte) (ideally I would choose by trial and error various locations) where only a very small part is changed (eg to less bytes (or zero preferably) than "Hello, Richard"). That is to say I don't want the MEM block to be "initialized" in any way (so I would "see" what the RANDOM GARBAGE was).

It appears that DIM gig as STRING  * GIGABYTE does an initialization for the whole string to be spaces.

Anyway to do  DIM gig so that "NO INITIALIZATION OCCURS" (I know that this is a strange request)?

[SMcNeill]

If you just want to view an uninitialized GB of memory, try this:

DIM M AS _MEM
M = _MEMNEW(1000000000) ‘1 GB
temp$ = SPACE$(1000000000) ‘1 GB string
_MEMGET M, M.OFFSET, temp$ ‘get the mem block into the string

‘DO whatever

[Richard]

The preferred method for feature requests AND bugs etc is the link below

https://github.com/QB64Team/qb64/issues

Auto update for compiling when include file changed.


When editing an include file for use with the current QB64 program being edited in the IDE - the .exe file generated does not use the latest include file version (unless the programmer remembers to also "edit" the line (and immediately restores the line) where the include file is mentioned).

Feature request - option to auto update to latest versions of any include files referenced when compiling

[Richard]

The preferred method for feature requests AND bugs etc is the link below

https://github.com/QB64Team/qb64/issues

This may be only related to Windows 10 x64 high DPI displays (eg my computer QB64 v1.5)...


If already have an instance of QB64 v1.5 Windows 10 x64 running - when attempting to launch a second instance of QB64 v1.5, the opening IDE screen does not appear on the display (it appears as a tiny "pop-up" when "hovering" mouse cursor over TaskBar ICON) - if now AGAIN attempt to launch QB64 v1.5, the IDE opening screen is now visible on main display as NORMAL. So now need to remove the "second" instance and so proceed with the third instance (which now becomes the intended second instance of QB64).

[SpriggsySpriggs]

I feel like this should have been just a new topic

[FellippeHeitor]

As proper as the repository is, I’ve already replied to you there.

Since it’s been replicated here, I’ll replicate the reply too:

For some reason improper coordinates got stored for the second instance. Go to internal/config.ini and delete the section for the second ide window. Please let me know if that fixes it.

And yes, this thread seems to have lasted too long already.

[Richard]

Would be nice to have 128 bit (and beyond) math ability - for those who would use it.

Currently 8 byte (64 bit) is available and also with _FLOAT 10 byte used (80 bit).

Feature request initially is for the IDE to be able to handle the extra variable types - which would be a big task - and the number crunching parts (e.g. SQRT) would be via include files of various kinds (Basic, C++, etc) from users and outside sources.

So for instance, the IDE would recognize x&&& as a 16 byte (256 bit) variable type as a signed _INTEGER128 and be able to do the usual tasks such as PRINT x&&& etc.

It may  never eventuate that "everything" for larger bit work is provided, but at least if the IDE can recognize and handle the new variables - this would be a great start. Even if the functionality is limited only to HEX and BINARY formats (and the conversion to/from decimal is at user's responsibility) - this would also be quite useful.


I have read recently that apparently for more "serious" scientific work - calculations are done using "hundreds of decimal places" (and am not referring to those purely academic projects such as calculating Pi to 3.14 trillion decimal places and such.)

The manipulation of the larger math would be very suited for MEM and the user variables such as x&&& allow for easier code reading/writing.


Maybe I may be the only one to use this larger math - if so, then it may not be justified to invest into the required QB64 code development.. So much can be said relevant to this implementation.

[luke]

There will not be any new first-class variable types added to QB64.

Consider producing a library to achieve such calculations, or wrapping something like GMP.

[bplus]

Maybe I may be the only one to use this larger math - if so, then it may not be justified to invest into the required QB64 code development.. So much can be said relevant to this implementation.

Already doing arbitrary math with the oh interpreter, here is a pretty impressive example for the inverse of a giant number (23 - 9's an 8 and then 24 more 9's given by STx) to 4000 decimal places finding the first 115 terms of Fibonacci sequence in one number!
https://www.qb64.org/forum/index.php?topic=3723.msg131080#msg131080

[Richard]

@luke quickly replied that there will not be any new first-class variable types added to QB64, which is a pity (for me). On internet research it seems that even with C++ language that 64 bits is the limit. So from the discontinuation of MS PDS7.1 (upgrade to QB45) some thirty years ago - there seems to be no expansion of bits.  I think that IBM for a number (if not most or all) of mainframes, the OS was highly scalable and already had 128 bits and this predates 30 years ago. It seems that since the Intel architecture is only 64bits, no one wants to have say a C++ written library to handle 128bit multiplication.

I started looking at @bplus OHI and am a bit lost at this stage to "extract" the least code required to incorporate in my programs. (To be able to do many digits of resolution for the basics - add, subtract, multiply and divide). Has anyone previously done this?
.
Even if BPlus code is used, I will be limited - eg doing SQR, TAN, <>, arrays, input # etc would be a pain!

Luke mentioned wrapping something like GMP. I read into this a bit, it was interesting that only some success was reported when using windows. I gather that GMP (and other similar versions) are written in maybe C++ (or some other language that I have no training, knowledge or experience with). My past experience with trying to use "packages" (like GMP etc) is that I end up downloading maybe Gigabytes, cannot get it to work with my present version of Windows (10 x64), found that the forums were not helpful in "getting started", and often very old ( eg a number of years) which does not interact with versions
 updates from Windows.

[SpriggsySpriggs]

128 bit variable types do exist in C++