WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V3.1.0 June 4, 2023)
-
- Posts: 4310
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.6 May 17, 2020)
I had a look at SHA512 on 512MB of data. Listed are three runs followed by the binary size.
32-bit
gcc 5.2, -arch 686 -Wc -O3 5.289s 5.283s 5.303s 55296
gcc 8.3, -arch 686 -Wc -O3 5.300s 5.280s 5.276s 49664
gcc 8.4, -arch 686 -Wc -O3 5.222s 5.237s 5.252s 54784
gas 5.312s 5.321s 5.280s 52736
64-bit
gcc 5.2, -Wc -O3 5.302s 5.286s 5.281s 58880
gcc 8.3, -Wc -O3 5.314s 5.263s 5.296s 54784
gcc 8.4, -Wc -O3 5.199s 5.200s 5.203s 58368
gas64 5.200s 5.209s 5.210s 60416
The first thing to note is that there is no significant difference in performance anywhere.
gcc 8.4 has a slight edge on 8.3 for both 32-bit and 64-bit.
8.3 & 8.4 have a slight edge on gas for 32-bit.
gas64 has a slight edge on 8.3 for 64-bit but pretty much the same for 8.4.
For 32-bit 5.2 has the largest binaries.
For 64-bit gas64 has the largest binary followed by 5.2.
This is just one of many examples where 8.3 & 8.4 are better than 5.2.
gas64 is some way from being robust and can be much slower than gcc but with this example it is giving gcc a run for its money.
With FreeBASIC-1.07.1-gcc-8.4.rar you have 8.4 and gas64.
What are you waiting for?
32-bit
gcc 5.2, -arch 686 -Wc -O3 5.289s 5.283s 5.303s 55296
gcc 8.3, -arch 686 -Wc -O3 5.300s 5.280s 5.276s 49664
gcc 8.4, -arch 686 -Wc -O3 5.222s 5.237s 5.252s 54784
gas 5.312s 5.321s 5.280s 52736
64-bit
gcc 5.2, -Wc -O3 5.302s 5.286s 5.281s 58880
gcc 8.3, -Wc -O3 5.314s 5.263s 5.296s 54784
gcc 8.4, -Wc -O3 5.199s 5.200s 5.203s 58368
gas64 5.200s 5.209s 5.210s 60416
The first thing to note is that there is no significant difference in performance anywhere.
gcc 8.4 has a slight edge on 8.3 for both 32-bit and 64-bit.
8.3 & 8.4 have a slight edge on gas for 32-bit.
gas64 has a slight edge on 8.3 for 64-bit but pretty much the same for 8.4.
For 32-bit 5.2 has the largest binaries.
For 64-bit gas64 has the largest binary followed by 5.2.
This is just one of many examples where 8.3 & 8.4 are better than 5.2.
gas64 is some way from being robust and can be much slower than gcc but with this example it is giving gcc a run for its money.
With FreeBASIC-1.07.1-gcc-8.4.rar you have 8.4 and gas64.
What are you waiting for?
-
- Posts: 4310
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.6 May 17, 2020)
We have a small problem when introducing gas64 to SetCompilerPathsII.ini. SetCompilerPathsII.exe assumes that fbc32.exe and fbc64.exe are in the same path so compares the FBWINCompiler32 entry in the [Compiler] section of WinFBE.ini with the first path in the SetCompilerPathsII.ini list.
Paul's suggested entry, for the 8.4 download, is
"8.4 (1.07.1) (gas64)", "..\FreeBASIC-1.07.1-gcc-8.4\fbc32.exe", "..\FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe" ...... [1]
If WinFBE was closed after a gas64 compilation the next time SetCompilerPathsII opened it would have the 8.4 radio button selected. It should, of course, have the '8.4 (1.07.1) (gas64)' radio button selected.
SetCompilerPathsII does not know, a priori, what mode the next compilation is going to be so it cannot decide to check FBWINCompiler64.
To make sure that the '8.4 (1.07.1) (gas64)' radio button is selected on opening SetCompilerPathsII if the last compilation was gas64 is to change [1] to
"8.4 (1.07.1) (gas64)", "..\"FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe, "..\FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe"
I have tried this and there are no problems.
If you choose a 32-bit build then it will be overruled by a 64-bit build.
If you use SetCompilerSwitchesII and choose an -arch with a black box within it, that is '-arch 686', then we will get "error 83: Selected -gen gas ASM backend for non-x86 CPU, 686". This is not a problem, we should expect that. In this case we should use either an -arch as an empty box or a selected box; with a selected box for personal use only. As a 'by the way' I have seen some publish timings using '-arch native'. They should not do that because their 'native' may not be the same for me, or anybody else for that matter.
Added:
For the record the first three entries of my SetCompilerSwitches.ini are
In the first case '-gen gas' is redundant but looks better than an empty string.
In the second case '-gen gas64' is also redundant but looks better than just '-strip'.
With SetCompilerPathsII.ini instead of '8.4 (1.07.1) (gas64)' I simply use 'gas64'.
Paul's suggested entry, for the 8.4 download, is
"8.4 (1.07.1) (gas64)", "..\FreeBASIC-1.07.1-gcc-8.4\fbc32.exe", "..\FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe" ...... [1]
If WinFBE was closed after a gas64 compilation the next time SetCompilerPathsII opened it would have the 8.4 radio button selected. It should, of course, have the '8.4 (1.07.1) (gas64)' radio button selected.
SetCompilerPathsII does not know, a priori, what mode the next compilation is going to be so it cannot decide to check FBWINCompiler64.
To make sure that the '8.4 (1.07.1) (gas64)' radio button is selected on opening SetCompilerPathsII if the last compilation was gas64 is to change [1] to
"8.4 (1.07.1) (gas64)", "..\"FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe, "..\FreeBASIC-1.07.1-gcc-8.4\fbc64_gas64.exe"
I have tried this and there are no problems.
If you choose a 32-bit build then it will be overruled by a 64-bit build.
If you use SetCompilerSwitchesII and choose an -arch with a black box within it, that is '-arch 686', then we will get "error 83: Selected -gen gas ASM backend for non-x86 CPU, 686". This is not a problem, we should expect that. In this case we should use either an -arch as an empty box or a selected box; with a selected box for personal use only. As a 'by the way' I have seen some publish timings using '-arch native'. They should not do that because their 'native' may not be the same for me, or anybody else for that matter.
Added:
For the record the first three entries of my SetCompilerSwitches.ini are
Code: Select all
-gen gas
-strip -gen gas64
-gen gcc
In the second case '-gen gas64' is also redundant but looks better than just '-strip'.
With SetCompilerPathsII.ini instead of '8.4 (1.07.1) (gas64)' I simply use 'gas64'.
-
- Posts: 1002
- Joined: Jul 14, 2005 23:41
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Version 2.1.7 (May 31, 2020)
Editor:
- Added: Occurrences Highlighting. Editor will highlight words under the current cursor position (Visual Studio has this type of feature as well).
- Changed: Changed the default toolchain to: FreeBASIC-1.07.1-gcc-8.4
- Fixed: Performance issue with parsing document when about to show a popup Autocomplete list.
Visual Designer:
- Fixed: Listbox control not consistently updating display visually during add or remove.
Download from: https://github.com/PaulSquires/WinFBE/releases
Editor:
- Added: Occurrences Highlighting. Editor will highlight words under the current cursor position (Visual Studio has this type of feature as well).
- Changed: Changed the default toolchain to: FreeBASIC-1.07.1-gcc-8.4
- Fixed: Performance issue with parsing document when about to show a popup Autocomplete list.
Visual Designer:
- Fixed: Listbox control not consistently updating display visually during add or remove.
Download from: https://github.com/PaulSquires/WinFBE/releases
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Added also a compile error message if the installation path contains directory name with space character.
(is this limitation definitively ratified?)
(is this limitation definitively ratified?)
-
- Posts: 1002
- Joined: Jul 14, 2005 23:41
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
fxm, I tried my best to resolve the space in path issue. I tried a lot of different approaches but each one failed for differing reasons. The most promising approach was to change to the compiler folder itself making it the default folder and then initiate the compile from there so that the paths became relative paths to that directory. Sadly, the gorc resource compiler would then fail in situations where the resource contained paths to images, etc (because those paths were relative to the WinFBE project).
In the majority of cases, it was always the linker that failed during the compiling process.
Here is what the mingw starting guide has to say:
MinGW may have problems with paths containing spaces, and if not, usually other programs used with MinGW will experience problems with such paths. Thus, we strongly recommend that you do not install MinGW in any location with spaces in the path name reference. You should avoid installing into any directory or subdirectory having names like "Program Files" or "My Documents", etc.
http://www.mingw.org/wiki/getting_started
In the majority of cases, it was always the linker that failed during the compiling process.
Here is what the mingw starting guide has to say:
MinGW may have problems with paths containing spaces, and if not, usually other programs used with MinGW will experience problems with such paths. Thus, we strongly recommend that you do not install MinGW in any location with spaces in the path name reference. You should avoid installing into any directory or subdirectory having names like "Program Files" or "My Documents", etc.
http://www.mingw.org/wiki/getting_started
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Thanks for the update. "Occurrences Highlighting" works properly - nice. :-)PaulSquires wrote:Version 2.1.7 (May 31, 2020)
Editor:
- Added: Occurrences Highlighting. Editor will highlight words under the current cursor position (Visual Studio has this type of feature as well).
- Changed: Changed the default toolchain to: FreeBASIC-1.07.1-gcc-8.4
- Fixed: Performance issue with parsing document when about to show a popup Autocomplete list.
Visual Designer:
- Fixed: Listbox control not consistently updating display visually during add or remove.
Download from: https://github.com/PaulSquires/WinFBE/releases
To minimize the length of the combobox: can you add a button with 32/64 similar to poseidonFB? This will half the size and handling will be easier as the compiler settings are usually the same for both architectures.
I have an issue when the source code file will be modified outsite WinFBE. When WinFBE detects the modification and ask to reload the file than it crashes when I press yes to reload the file.
Faulting application name: WinFBE64.exe, version: 0.0.0.0, time stamp: 0x5ed40828
Faulting module name: ntdll.dll, version: 10.0.19041.207, time stamp: 0xcad89ab4
Exception code: 0xc0000374
Fault offset: 0x00000000000fdec9
Faulting process id: 0x16c4
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
This is also the case if you give the linker full dos short names?PaulSquires wrote: In the majority of cases, it was always the linker that failed during the compiling process.
such as C:\PROGRA~1
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Has anyone tried using an "fbgfx" opengl context while using visual designer elements? I'm just curious if there are any examples. I have very limited experience with managing OpenGL using the windows api. For instance, is there a way to easily render opengl gfx to a picture box I created with the visual designer? Is this even feasible? BadMrBox and I are making a game using some old code I wrote for the glCaster demo. The gui I made for that is absolutely horrid. If we could use this visual designer to create and manage the gui, it would be an absolute blessing. Thanks for any tips, tricks, advice, etc... ;)
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Thank you for this very nice addition to FB. I had been using fbEdit for many years. I gave up recently, it seems that fbEdit has some kind of problem when the number of files exceeds 255. I did not have enough interest to try and trace it down. So I tried yours. I will be sending you a couple of quirks with documentation on them as soon as I determine that is is not a misunderstanding on my part with some aspects of your program.
I am developing a large program using GTK 3.24. I have all the pieces I need including GLADE which is the GNOME GTK GUI designer. GladeToBac from TFJ converts GLADE output to FB. Great program. However, one design feature is that any event handler in the GLADE design generates a separate file with the proper skeleton and declarations needed to write the FB version of the event handler. It makes my job so much easier. Currently, I have over 300 event handlers (hence the problem with fbEdit). Your program works fine with it.
I would like to know if you have any plans in the future to allow additional headers in the Explorer window beside the standard 5. Having almost 400 routines on that list makes it a little difficult to use. If I could add several user-defined headers then I could put all the files for specific subprojects in separate areas and only have to work with a hand full of files in the explorer window that are relevant to what I am working on at the current time.
Thank you for any consideration.
One additional question. I assumed (probably a bad idea to make assumptions) that View Fold All would work on all routines in the current file that were open. I have found that it only seems to work on routines from the beginning of file to around where the current edit cursor is. After several applications of View Fold All without moving the cursor, it does seem to go a little farther each time and then eventually all the way. Could you explain the definition of All in this case so that I can understand better? I have taken to going to the end of the file, put the cursor there then doing a View Fold All, and that works fine.
Thank you again for your very nice product.
Wally
I am developing a large program using GTK 3.24. I have all the pieces I need including GLADE which is the GNOME GTK GUI designer. GladeToBac from TFJ converts GLADE output to FB. Great program. However, one design feature is that any event handler in the GLADE design generates a separate file with the proper skeleton and declarations needed to write the FB version of the event handler. It makes my job so much easier. Currently, I have over 300 event handlers (hence the problem with fbEdit). Your program works fine with it.
I would like to know if you have any plans in the future to allow additional headers in the Explorer window beside the standard 5. Having almost 400 routines on that list makes it a little difficult to use. If I could add several user-defined headers then I could put all the files for specific subprojects in separate areas and only have to work with a hand full of files in the explorer window that are relevant to what I am working on at the current time.
Thank you for any consideration.
One additional question. I assumed (probably a bad idea to make assumptions) that View Fold All would work on all routines in the current file that were open. I have found that it only seems to work on routines from the beginning of file to around where the current edit cursor is. After several applications of View Fold All without moving the cursor, it does seem to go a little farther each time and then eventually all the way. Could you explain the definition of All in this case so that I can understand better? I have taken to going to the end of the file, put the cursor there then doing a View Fold All, and that works fine.
Thank you again for your very nice product.
Wally
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
I have occasionally observed the following behavior but have not been able to get a short example.
When I am typing in a new set of code, I use 4 blank indents and place the else/elseif at the correct location. I then press ENTER to go to the next line and the editor reposition the else/elseif to someplace later in the line and that is the wrong location.
What I typed
The cursor was positioned following the last else command and I then pressed ENTER. This is what the system did to my code
I have Treat Tab as Spaces selected
I have Enable Autocomplete selected
I have not selected Enable Character Autocompletion
I have selected Enable Auto Indention and Enable loop variable..
I have selected Enable Brace Highlighting
I would appreciate it if you could look into this behavior. This does not happen often but 2-3 times a day.
Thank you
Wally
When I am typing in a new set of code, I use 4 blank indents and place the else/elseif at the correct location. I then press ENTER to go to the next line and the editor reposition the else/elseif to someplace later in the line and that is the wrong location.
What I typed
Code: Select all
SUB DialogFileNameDelete_clicked_cb CDECL ALIAS "DialogFileNameDelete_clicked_cb" ( _
BYVAL button AS GtkButton PTR, _
BYVAL user_data AS gpointer) EXPORT
if DialogFileNameTemplateFile <> NULL Then
dim as String s = getBOname(DialogFileNameTemplateFile)
dim as gtkwidget ptr dialog = gtk_message_dialog_new_with_markup(GTK_WINDOW(DialogFileName), _
GTK_DIALOG_MODAL or GTK_DIALOG_DESTROY_WITH_PARENT, _
GTK_MESSAGE_QUESTION, _
GTK_BUTTONS_YES_NO, _
"Are you sure you want to delete Sprite Sheet <b>" & s & "</b>?")
if gtk_dialog_run(GTK_DIALOG(dialog)) = GTK_RESPONSE_YES then
end if
gtk_widget_destroy(dialog)
else
END SUB
Code: Select all
SUB DialogFileNameDelete_clicked_cb CDECL ALIAS "DialogFileNameDelete_clicked_cb" ( _
BYVAL button AS GtkButton PTR, _
BYVAL user_data AS gpointer) EXPORT
if DialogFileNameTemplateFile <> NULL Then
dim as String s = getBOname(DialogFileNameTemplateFile)
dim as gtkwidget ptr dialog = gtk_message_dialog_new_with_markup(GTK_WINDOW(DialogFileName), _
GTK_DIALOG_MODAL or GTK_DIALOG_DESTROY_WITH_PARENT, _
GTK_MESSAGE_QUESTION, _
GTK_BUTTONS_YES_NO, _
"Are you sure you want to delete Sprite Sheet <b>" & s & "</b>?")
if gtk_dialog_run(GTK_DIALOG(dialog)) = GTK_RESPONSE_YES then
end if
gtk_widget_destroy(dialog)
else
END SUB
I have Enable Autocomplete selected
I have not selected Enable Character Autocompletion
I have selected Enable Auto Indention and Enable loop variable..
I have selected Enable Brace Highlighting
I would appreciate it if you could look into this behavior. This does not happen often but 2-3 times a day.
Thank you
Wally
-
- Posts: 1002
- Joined: Jul 14, 2005 23:41
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Hi Wally, thanks for your posts and observations. I have recorded them and will look at them for the next update(s). With regards to the misalignments of the If/Else statements, it is most likely due to the nesting of multiple If/Then structures and the editor not being smart enough to know which indent level to use based on the current depth of the nesting.
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Thank you for your consideration.
As far as the misaligned else, is there anything I can look at and report back to you when I see this happen again. It is not unusual to see it happen several times a day.
Wally
As far as the misaligned else, is there anything I can look at and report back to you when I see this happen again. It is not unusual to see it happen several times a day.
Wally
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
I have enabled AutoIndention and enabled append loop variable to For/Next statement
I type in the following 2 lines
and then enter an Enter key. I get the following
No variable on next statement
I then add a third line and press Enter and I then get
This time not only do I not get the variable on the nested next statement, I do not even get the next statement
This is FYI only, obviously, it does not slow my work down.
Thank you,
Wally
I type in the following 2 lines
Code: Select all
Sub alpha
for row as long = 0 to Rows-1
Code: Select all
Sub alpha
for row as long = 0 to Rows-1
next
I then add a third line and press Enter and I then get
Code: Select all
sub alpha
for row as long = 0 to Rows-1
for col as long = 0 to Cols-1
next
This is FYI only, obviously, it does not slow my work down.
Thank you,
Wally
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
> No variable on next statement
FreeBasic does not use a variable in the next statement. That is an obsolete syntax. It won't complain if you put one, but it is ignored.
FreeBasic does not use a variable in the next statement. That is an obsolete syntax. It won't complain if you put one, but it is ignored.
Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)
Not exactly.
NEXT can be used without identifier
NEXT can be used without identifier
- , and in this case, FreeBASIC closes the most one recent FOR statement block.
But if the identifier- of NEXT is specified, FreeBASIC checks if the identifier
- matches with the previous NEXT(s).
Example of detected errors:Compiler output:Code: Select all
Dim As Integer I, J For I = 1 To 2 For J = 3 To 4 Next I Next J For I = 1 To 2 For J = 3 To 4 Next I, J
C:\...\FBIde0.4.6r4_fbc1.08.0\FBIDETEMP.bas(5) error 283: FOR/NEXT variable name mismatch in 'Next I'
C:\...\FBIde0.4.6r4_fbc1.08.0\FBIDETEMP.bas(6) error 283: FOR/NEXT variable name mismatch in 'Next J'
C:\...\FBIde0.4.6r4_fbc1.08.0\FBIDETEMP.bas(10) error 283: FOR/NEXT variable name mismatch, found ',' in 'Next I, J'
C:\...\FBIde0.4.6r4_fbc1.08.0\FBIDETEMP.bas(10) error 283: FOR/NEXT variable name mismatch in 'Next I, J'
- matches with the previous NEXT(s).
- of NEXT is specified, FreeBASIC checks if the identifier