I get 5.533 seconds.

@doppler

I don't do Windows programming, but can you tell me where this special call to a Windows function occurs? It should be wrapped in a $IF compiler directive statement, thus preventing it from even being considered by the compiler. I can see if there is a work-a-round for it.

Thanks

...  I knew INFORM did not compile on the PI.  Because right off the bat, a special call to a windows function occurs.  Rendering PI compile very moot. ...

@doppler  - The problem with getting QB64 into the Raspberry Debian repositories is that not all the code compiled by QB64 on the PI works.

There is an issue with SIG BUS address errors in some programs. Also, QB64 only works in the 32bit OS. Does not work in the 64bit OS (On the PI4/PI400's).

I have posts elsewhere (see https://qb64forum.alephc.xyz/index.php?topic=4617.msg141500#msg141500) that partly explains all the issues in running QB64 on a PI.

If you want, I can send you code that fails due to misaligned addresses, if you'd like.

Unless the Raspberry PI Foundation applies the hardware fix that was done to the x86 chips (I don't know if Apple's M1 ARM was fixed), then QB64, unless someone goes into the C++ code and corrects all the misaligned fields (which is impractical), will not work all the time.

Right now, InForm doesn't compile due to this very error. It would be nice to have QB64 working on the PI, but until I get a M1 ARM processor to test it out, in 5 years when the ARM processor becomes standard with new computers, QB64 may have to be changed so it can run on these CPU's

So how do we get 150,000 new QB64 users.  With sales of 30 Million unit's in 2019, who knows where that number is today with covid locking people at home.  And any available unit being scalped at ridiculous prices.  Or any online listing announcing stock all gone within 15 minutes.  The little sought after PC is the Raspberry PI.  If we can get 0.5% of the user base to install it's 150K new users.

So what will it take to get QB64 listed in the Raspberry Debian Repository ?  There are many locations the where repositories are holding code.  I could be wrong but all we need is one developer to compile and post a image of QB64 and support files.  I now the install script exists to compile QB64 but it's not "ALL" new user friendly.  I think we need to "APP" QB64 into a repository package.

So can we make this happen ?  I would love to help but I am too newbie even after a couple of years using Linux to know how to do this.

Thanks
BTW, With all the competition QB64 has under windows.  Nobody has listed there basic in the repository.  We could be a first.
 

@MrGW454 @bplus

I haven't been around in a while as I have been researching a possible project in crypto.

Anyway, I have solved the issue on ARM involving DATA statements - I am going to assume I am looking at posts before MrGW454 contacted me, as from our discussion on Discord, it works.

@bplus - if you want the fix for this, I will be happy to give it to you. I actually ran into a number of issues that I guess others gave up on, until I ran into an issue involving misaligned addresses on the PI's ARM that was fixed in the x86 chip (hardware fix) that may have been done in the Apple M1 ARM processor, which until July I will not have one to test my changes with.

Also an issue is that QB64 does not work on a PI running a 64bit OS. I am looking into that, but I suspect from all the technical documents I've read (and contacts with some in the IEEE) that the PI ARM may not be a fully compliant chip, where I was told the M1 should be,

If you support SUBS, all a GOSUB is is a SUB with a label. I would think you should be able to process a GOSUB the same way as a SUB.

Hey @bplus nice example!  Yes, Subs and Functions are supported and at present all variables must be declared. 

Goto and gosub are not supported at present. There will be some complexity to do that as there is not a parallel in javascript.

I tried to run your code on the PI with a 32bit OS using GDB, as I cannot repeat your error (I've run it 10 times on my system, which is an x86_64 64Bit QB64) and on the PI it gets a "SIGBUS - Bus error" which I'm assuming has to do with how freeglut works on the PI (probably related to the issue I am having with my other post on installing qb64 on the PI - same error).

Which makes me wonder if this is also a sometimes problem on an x86 architecture?

You should recompile your program with the -g compiler option and run it in GDB to see if you can trap the specific error you are getting.

To do this, go into "makeline_lnx.txt" in the "internal/c" subfolder of qb64, and add the -g after "gcc". Recompile then in the terminal, run "gdb RougeLike_1_1" to load it.

Since I am unable to reproduce it on my system, that is the best I can do.  (While typing this in I ran your code 5 more times and it worked every time).

I've have updates ready to QB64 that will automatically install it on a Raspberry PI and works properly, including DATA statements.

With Apple's new computers running the M1 ARM processor, and Intel (announced in June of 2021), along with AMD and Microsoft working together (announced in October of 2021) to develop ARM processors, QB64 needs to be able to run on these chips as well.

I have tested my changes, but I would like some others to check it out as well before I push the change on Gitub.

In my tests, I have even run compiled QB64 programs that use MariaDB and Zenity on the PI without issues. Pipecom runs without issues as well as $DEBUG. However, my testing has only been done on the 32bit Raspian OS. I do plan to test it with other Linux systems that run on the PI.

There were a number of changes needed, which most are automated in the setup_lnx.sh script. The other change was made directly to common.h.

The two files that changed are below, but here is what I needed to change.

common.h
Two of the issues I ran into had to do with mis-aligned addresses (int32 and int16 for example). To correct this, I either needed to add "-fsanitize=address" to the gcc statement, or add code to the common.h file for ARM processors. I was given the code by a C++ programmer who explained that, while not an issue with x86_64 or i386 processors, it is an issue with ARM processors. The code (see below) corrects this issue. She also gave me the corresponding code for the x86_64/i386, just in case. I've regression tested this on my x86_64 system, but others should also run it as well.

setup_lnx.sh
The setup script has a number of issues on ARM processors. The first is it doesn't download the libraries needed, and the other it created invalid link modules. To correct the first issue, the setup script now checks whether or not the processor is an ARM. If so, it sets DISTRO to "raspbian". The issue about the link/binary executables has to do with how the ARM processes bits. ARM processors are little endian (See note below). So the script replaces both the makedat_lnx32.txt and makedat_lnx64.txt files with the correct parameters for the OBJCOPY. ("-Oelf32-littlearm -Barm" replaced the original "-Oelf32-i386 -Bi386" in the 32bit file and the "-Oelf64-littlearm -Barm" replaced the "-Oelf64-x86-64 -Bi386:x86-64" in the 64bit file)

NOTE: Yes, Intel, AMD and the PI ARM chips are all little endian. However, from what I've read, the Intel and AMD chips convert the little endian to big endian. It has something to do with floating point. However, this does not seem to be the case with ARM processors, at least for the PI. From what I read, the Apple M1 is designed the same as that the PI's ARM. This change to the OBJCOPY allows DATA statements, among other things, to work. the -Barm tells OBJCOPY how to format the binary executable file. This is my understanding, which is of course, subject to interpretation, but the changes makes QB64 run and compile, and compiled programs also run on the PI.

To implement these changes, after extracting the QB64 compiler, you need to replace the common.h file in the qb64/internal/c directory, and the setup_lnx.sh file in the main qb64 directory. Then all you have to do is run the setup_lnx.sh file to install library dependencies and compile qb64.bas.

These changes should also work on the Apple M1 ARM processor, but I do not have one to test this on. If someone has a M1 ARM processor, I can provide the changes to the setup_osx.command script. You'll have to do the testing as I will not have a M1 processor until July.

Also, besides the M1 processor, I haven't been able to test is a 64bit OS on the Raspberry PI. Raspberry no longer offers the 64bit version of their Raspbian OS. So while I am looking for non-raspbian OS's to test on, if someone here is running, say Kali on a PI or an earlier version of the 64bit Raspbian OS, please test this. I will do so as well, but the more who tests this, the better. (This was suggested by Fellippe).

Some Issues:
When testing this on my PI, I was unable to get InForm to run. It compiles, but I get a series of errors from "Bus signal errors" to misaligned addresses. I am still looking into this, but I may need to defer to Fellippe or Luke on this, as I am not a C++ programmer, and in my C coding, I've never encountered these errors. I have run tests in gdb and ddd utilites to try and isolate the issue, but I am at a loss. If someone wants to tackle this on their PI, I'd appreciate it.

Here is the common.h file:

Here is the setup_lnx.sh file:



Thanks,

Other "modern" languages, like C/C++, FORTRAN, and even COBOL processes order of operations the way it's supposed to work (See https://en.cppreference.com/w/c/language/operator_precedence for how C/C++ does it).

I bet this is an old feature of the original BASIC.

I think that for QB64 to work the way many other languages work, maybe it needs to change, or provide a compiler directive to tell it to perform order of operations the way most other languages do it. It would improve QB64.

I know I can break up a formula so that it does the math properly, but why? I should be able to process a formula in a straight-line form properly.