Yes. I originally used
\GCstudio\FBASIC\x64\fbc.exe
to compile. Since I couldn't get it to work, I tried a fresh download from freebasic, thus the K:\FreeBASIC-1.07.1-win64\ folder shown above. I get the exact same results using either 64-bit freebasic exe.
I have checked the path statement, the environment, and scanned the registry, and can not find any trace of where this could be coming from. Does it work for you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will get Angel to update the release with this new ZIP.
@angel.... something was missing, I have not figured out which file(s). We need to get this update into the build. ( Let me know you have it in the Gold build and I will delete the ZIP).
So, I get the issue with STUDIO. That needs to be resolved.
I used the Help to figure this out. I do not remember this information once it is written down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the problem was the -arch 586
okay, probably my bad.
I got that from the gcbasic.fbp project file out of the trunk source code, not from gcstudio.
Kinda makes sense, the 586 wasn't a 64 bit chip. So just some adjustments to gcbasic.fbp, or I guess you aren't supporting fbedit any more, so just remove it from the trunk.
the only occurance of -arch 586 I found in gcstudio were these files which I have no idea what they are or what they are for-
as I see it, looking at the two compile commands, as you said:
fbc.exe $SF\gcbasic.bas -exx -arch 586 -x $SF\gcbasic32.exe
or
fbc.exe $SF\gcbasic.bas -x $SF\gcbasic64.exe -ex
the difference being the options, i.e.
32bit: -exx arch 586
64bit: -ex
the default for arch is 486, according to the help. I can see trying to give it a little boost by using pentium instructions.
as for the -exx vs. -ex, I think they could both be -exx
why would you want to saddle the 32 bit code with array bounds/null-pointer checking and not the 64 bit code?
In the real world, I can't complain if it takes 2.1 seconds using 32 bit gcbasic vs 1.9 seconds using 64 bit for the worst program I could find to compile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can share there is some checking re array bounds. I have added this over the last few years. Re null pointers there is always an inspection of pointer addresses prior to use.
1.9s is fast. Is that for the GLCD touch calculator? I get 1.921s which was 3.1s before the library changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I misspoke badly. My computer isn't that fast!
GLCD_Touch_Simple_Demonstration_ATmega2560_SSD1289.gcb which I think you are talking about takes 3.1 secs. If you can do it in 1.921s, I guess it's time for me to upgrade :)
The 1.9 is for one of the BitwiseControls.gcb I picked up accidentally at some point (no idea why), while testing my 22 yr old celeron laptop with a whopping 5MB of ram. If everything runs on that we should be good to go.
On my computer, the slowest demo to compile is "CAN-Link_18f4550.gcb" at about 4.8 secs for both the 32bit and 64bit compilers
The second slowest is the "GLCD_Simple_Demonstration_ILI9488.gcb" at about 4.1 secs.
The CAN-Link is slowest in the compiler section of the program, eg.
4.844 total 1.895 preprocessor 2.015 compiler
The GLCD is slowest in the preprocessor section, eg.
4.385 total 2.501 preprocessor 0.600 compiler
As for -exx, I think they should both be the same, whether that is -ex or -exx. Strangely, the celeron is faster with -exx than -ex, so I'd say the tests were inconclusive.
Testing the -arch option, the celeron ran
8.5s with 486 (default)
7.5s with 586
7.1s with 686 (surprising, not sure if we expect 1993 computers or 1995 computers as the minimum)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been trying to compile the 64 bit version of GCBasic for quite a while now with no luck.
I'm using a simple fbc command in a command window.
fbc -exx -arch 586 gcbasic.bas
I get the error:
gcbasic.bas() error 91: Executable not found: "K:\FreeBASIC-1.07.1-win64\bin\win32\as.exe"
the error being that fbc 64-bit is looking in the wrong folder, it should be
"K:\FreeBASIC-1.07.1-win64\bin\win64\as.exe"
I have searched and searched but can not find what is making 64 bit fbc create a folder with win32 in it's name.
I have tried also:
fbc -target win64 -exx -arch 586 jggcbasic.bas
but no change.
What is the correct call to fbc to get a 64-bit output program?
Do I have to make internal changes to gcbasic.bas to get it to work?
I have no interest in trying to navigate gccode to do this. I just want the simple fbc command to get it done!
Do you have GCSTUDIO installed?
This is not a question of using GCODE just to understand your environment and how the folder structure/management method.
Yes. I originally used
\GCstudio\FBASIC\x64\fbc.exe
to compile. Since I couldn't get it to work, I tried a fresh download from freebasic, thus the K:\FreeBASIC-1.07.1-win64\ folder shown above. I get the exact same results using either 64-bit freebasic exe.
I have checked the path statement, the environment, and scanned the registry, and can not find any trace of where this could be coming from. Does it work for you?
I just tried again to be sure, I tried-
H:\GCstudio\FBASIC\x64\fbc.exe -exx -arch 586 gcbasic.bas
and I get
gcbasic.bas() error 91: Executable not found: "H:\GCstudio\FBASIC\x64\bin\win32\as.exe"
It works for me me because I trust Angel to compile the toolchain for us.
That said. Which is the truth. You need to unzip the following to the FBASIC folder. This will resolve.
The correct command to complile for 64bit is.
..\FBASIC\x64\fbc.exe gcbasic.bas -x gcbasic.exe -exI will get Angel to update the release with this new ZIP.
@angel.... something was missing, I have not figured out which file(s). We need to get this update into the build. ( Let me know you have it in the Gold build and I will delete the ZIP).
https://1drv.ms/u/s!Ase-PX_n_4cvhNwmeetxyrU6-9eV6A?e=gFIgdV
The command line switches are in the Help and the correct download is in the Help.
See https://gcbasic.sourceforge.io/help/_development_guide_for_gcbasic_exe_compiler.html
This has the URL to the complete download, I just unzipped, change the unzipped directory, where $SF =
c:\gcstudio\gcbasicand it worked.So, I get the issue with STUDIO. That needs to be resolved.
I used the Help to figure this out. I do not remember this information once it is written down.
So the problem was the -arch 586
okay, probably my bad.
I got that from the gcbasic.fbp project file out of the trunk source code, not from gcstudio.
Kinda makes sense, the 586 wasn't a 64 bit chip. So just some adjustments to gcbasic.fbp, or I guess you aren't supporting fbedit any more, so just remove it from the trunk.
the only occurance of -arch 586 I found in gcstudio were these files which I have no idea what they are or what they are for-
"H:\GCstudio\vscode\data\user-data\user\globalStorage\state.vscdb"
"H:\GCstudio\vscode\data\user-data\user\globalStorage\state.vscdb.backup"
"H:\GCstudio\vscode\data\user-data\user\workspaceStorage\8ea64928a4b2460e64a246754bd91312\state.vscdb"
"H:\GCstudio\vscode\data\user-data\user\workspaceStorage\8ea64928a4b2460e64a246754bd91312\state.vscdb.backup"
as I see it, looking at the two compile commands, as you said:
fbc.exe $SF\gcbasic.bas -exx -arch 586 -x $SF\gcbasic32.exe
or
fbc.exe $SF\gcbasic.bas -x $SF\gcbasic64.exe -ex
the difference being the options, i.e.
32bit: -exx arch 586
64bit: -ex
the default for arch is 486, according to the help. I can see trying to give it a little boost by using pentium instructions.
as for the -exx vs. -ex, I think they could both be -exx
why would you want to saddle the 32 bit code with array bounds/null-pointer checking and not the 64 bit code?
In the real world, I can't complain if it takes 2.1 seconds using 32 bit gcbasic vs 1.9 seconds using 64 bit for the worst program I could find to compile.
Again, good insight.
We should use -exx on both version?
I can share there is some checking re array bounds. I have added this over the last few years. Re null pointers there is always an inspection of pointer addresses prior to use.
1.9s is fast. Is that for the GLCD touch calculator? I get 1.921s which was 3.1s before the library changes.
No, I misspoke badly. My computer isn't that fast!
GLCD_Touch_Simple_Demonstration_ATmega2560_SSD1289.gcb which I think you are talking about takes 3.1 secs. If you can do it in 1.921s, I guess it's time for me to upgrade :)
The 1.9 is for one of the BitwiseControls.gcb I picked up accidentally at some point (no idea why), while testing my 22 yr old celeron laptop with a whopping 5MB of ram. If everything runs on that we should be good to go.
On my computer, the slowest demo to compile is "CAN-Link_18f4550.gcb" at about 4.8 secs for both the 32bit and 64bit compilers
The second slowest is the "GLCD_Simple_Demonstration_ILI9488.gcb" at about 4.1 secs.
The CAN-Link is slowest in the compiler section of the program, eg.
4.844 total 1.895 preprocessor 2.015 compiler
The GLCD is slowest in the preprocessor section, eg.
4.385 total 2.501 preprocessor 0.600 compiler
As for -exx, I think they should both be the same, whether that is -ex or -exx. Strangely, the celeron is faster with -exx than -ex, so I'd say the tests were inconclusive.
Testing the -arch option, the celeron ran
8.5s with 486 (default)
7.5s with 586
7.1s with 686 (surprising, not sure if we expect 1993 computers or 1995 computers as the minimum)
Again, interesting stuff.
Re speed.... GLCD_Touch_Simple_Demonstration_ATmega2560_SSD1289.gcb used to take 37seconds.
CAN-Link_18f4550.gcb here... 3.68s one one machine and 5,7s on main dev machine.
We have improved performance - that we made the goal!
Next... want to help FLOATS? See https://sourceforge.net/p/gcbasic/discussion/596084/thread/b867317011/
We start with the simple issues and then build up from there.
wow. That's a lot. Let me look into it before I commit.
Of course.
We start with fixing the simple maths, learning as we go. Then, once the basics work, more to harder issues.