• Welcome to PlanetSquires Forums.
 

fumbling first questions

Started by dcouzin, December 18, 2018, 10:30:06 PM

Previous topic - Next topic

dcouzin

Hello Forum: I turned to FreeBASIC just two days ago, when my move to 64-bit Windows meant no more NTVDM to run my old QuickBASIC programs.  They're optical design programs written 25 years ago in QB version 3.00, and still useful. What a delight to find the programs could run 5 times faster using the FB compiler instead of QB's, and no more NTVDM and BRUN. 

My two goals:
1. to run the programs as fast as possible.
2. to not have to significantly rewrite the programs.
Do the goals conflict?
 
Paul Squires' latest suite with FreeBASIC-1.06.0 and WinFBE-1.8.7 worked straightaway.  The '-lang qb' option allowed most of my programs to compile after modest changes.  In QB I could name a variable 'X' and also name an array 'X()'.  I could express ≥ interchangeably with '>=' and '=>'.  Etc.  Etc. FreeBASIC-1.06.0 freaks out at these liberties and its error messages barely hint what's wrong.  Traces of guilt helped me to find them.

Without speaking for real programmers, I learned much of QuickBASIC v.3.00 syntax by trial and error.  Whatever the compiler allowed, I kept doing.  With time I should learn the new syntax allowed by the '-lang qb' option, but I fear that the new compiler will react to some deeper abuses/liberties in my programs that I won't fathom.

First question: do the earlier FreeBASIC compilers have a more tolerant '-lang qb' option than later FreeBASIC compilers?  Has the FreeBASIC principle of supporting QuickBASIC coding softened over time?

Second question: will the later FreeBASIC compilers provide a speed advantage for my programs?  The programs are just piles of arithmetic and trigonometry, running on a normal Lenovo T480s with Windows 10.

Besides those general questions, I'm mystified by specifics in the FreeBASIC-1.06.0 and WinFBE-1.8.7 combination.  One of my programs compiles and runs fine with build configuration 'Win32 GUI (Release)' and option '-lang qb', but with build configuration 'Win64 GUI (Release)' and option '-lang qb' it compiles only to crash after 2 seconds running.  How can this happen?

Will this forum suit someone who programs, but is not a programmer?

Dennis

Klaas Holland

Yes Dennis, this forum is a good place for you, because Paul and Jose are experts in helping you.

I'am not a programmer too and did switch from QuickBasic --> PowerBasic --> FireFly/PB --> FireFly/FB,
and I'am still using the same basics.

Paul Squires

Quote from: dcouzin on December 18, 2018, 10:30:06 PM
Hello Forum: I turned to FreeBASIC just two days ago, when my move to 64-bit Windows meant no more NTVDM to run my old QuickBASIC programs.  They're optical design programs written 25 years ago in QB version 3.00, and still useful. What a delight to find the programs could run 5 times faster using the FB compiler instead of QB's, and no more NTVDM and BRUN. 
Hi Dennis - welcome aboard! :)

Quote
My two goals:
1. to run the programs as fast as possible.
2. to not have to significantly rewrite the programs.
Do the goals conflict?
As you've noticed, you have had to do some tweaking of your programs. I NEVER use '-lang qb' ever and have dropped any of my old QuickBasic habits long ago (after I switched to PowerBasic). Personally, I would try compiling using '-lang fb' as that is the future of the compiler. Legacy QB compatibility should be frozen at FB 1.05 and stripped out of the compiler for versions after that(but that's my opinion and not widely shared by the greater FB community who have a lot of old QB code). If you ever decide to start using WinFBE's visual designer then it will only create code using -lang fb.
 
Quote
First question: do the earlier FreeBASIC compilers have a more tolerant '-lang qb' option than later FreeBASIC compilers?  Has the FreeBASIC principle of supporting QuickBASIC coding softened over time?
If anything, QB support got better with the compilers as time went on. Bugs fixed and quirks in the syntax fixed. My "feeling" is QB support will remain in the compiler but development in the FB syntax has taken over and always be the main area of future development.

Quote
Second question: will the later FreeBASIC compilers provide a speed advantage for my programs?  The programs are just piles of arithmetic and trigonometry, running on a normal Lenovo T480s with Windows 10.
Most likely they will especially the 64 bit versions that uses GCC for the compiling backend. Whenever GCC is updated we normally see speed improvements and optimizations. There is an experimental LLVM backend that one day may prove to be even a little faster.

Quote
Besides those general questions, I'm mystified by specifics in the FreeBASIC-1.06.0 and WinFBE-1.8.7 combination.  One of my programs compiles and runs fine with build configuration 'Win32 GUI (Release)' and option '-lang qb', but with build configuration 'Win64 GUI (Release)' and option '-lang qb' it compiles only to crash after 2 seconds running.  How can this happen?
32 bit code and 64 bit code can sometimes be a problematic. The most damning area would be if you use the INTEGER variable (I always use LONG just to avoid issues). An INTEGER is 32 bit on 32 bit systems, but is 64 bits on 64 bit operating systems.

Quote
Will this forum suit someone who programs, but is not a programmer?
Definitely. I venture to say that the vast majority of us here are not professional programmers. :-)
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen

#3
also, if you decide to convert your QB code to FB, be mindful of the integer type differences
QB Integer ( number% ) – Integer variables are 2 bytes long, FB32 Integer is 4 bytes long - FB64 Integer is 8 bytes long
QB Long Integer ( number& ) -Long Integer variables are 4 bytes long
in FB you can declare an integer like so
Dim as Integer n ' 4 or 8 bytes long
or
Dim as Integer<16> n '2 bytes long, valid sizes are 8, 16, 32 and 64 bits

raymw

Hi Dennis,

It depends if it is worth the effort for you, but I would consider trying to work out what your largest numbers are likely to be, and chose integers that will just about hold them. e.g, if your largest value is going to be in the hundreds range, then no point in doing calculations with 64 bit integers. If rounding errors are unacceptable, do not use floating point numbers, and so forth. Take this as an opportunity to rewrite your code in freebasic, as Paul suggested. If it is software you developed yourself, and you have the documentation ;-) it may be as easy to rewrite it anyway, from your original specification, instead of trying to convert your existing qb code line for line.

Best wishes,

Ray

dcouzin

Dear all:
Is the only reason for using the 64-bit compiler large integer calculation?  But why would the 64-bit compilation crash when the integers happen to be small?  My program declares some integer variables; none take values over 300.  Why should the FreeBASIC 64-bit compilation not execute when the FreeBASIC 32-bit compilation and the QuickBASIC 16-bit compilation do?  Shouldn't the crash concern the developers?  In the crash scenario, the fat DOS cursor blinks for about two seconds and then the window disappears.

After reading a 2008 discussion at freebasic.net/forum I appreciate how QuickBASIC needed reform, and FreeBASIC fulfilled that.  GOSUB leads to spaghetti code.  It's fun to write, but just a few months later it's hard to untangle.  Now, 25 years later and faced with a calculation core with 79 GOSUB's, 27 RETURN's, 72 GOTO's in 1400 lines, untangling is beyond my powers.

The code was originally written in the assembly-like language of the TI-95, and then transformed to QuickBASIC.  Besides those two encodes there's little documentation.  If the '-lang qb' option now allows compilation of my old code, why rewrite it in FB?  As an exercise for learning FB?  It's too difficult an exercise.  Better to learn a new language through writing small new programs.  The compiler signals a few errors, you correct those, and you're a step farther into the new language.   

I added FreeBASIC-1.05.0 to the WinFBE_Suite directory to compare with FreeBASIC-1.06.0.  (That a newbie can do this testifies to the clarity of WinFBE.)  For that 1400 line program, the 1.06.0 compiler made a 78,848 byte executable, compared to the 1.05.0 compiler's 76,288 byte executable.  What did the 2,560 bytes of extra lard in the first compilation provide?  Not faster execution.  The 1.05.0 version is actually 0.5% faster -- based on many runs, it's a real difference. 

In the film "Orphee" (1949) Cocteau gives his definition of "poet", (Englished): "One who writes, but is not a writer."  Can we find the nice X defined: "one who programs, but is not a programmer"?

Dennis

Johan Klassen

#6
@dcouzin
the reason I suggested to be mindful of the difference in integer size is that a lot of FreeBASIC programs that were written for the 32-bit version fail when compiled with the 64-bit version because of the assumption on the integer size being 32-bit
but since you are not inclined to learn to program in FreeBASIC but only want to compile and run your old Qbasic programs then I suggest you try QB64 http://www.qb64.org
QB64 prides itself in Qbasic compatibility, though the executables are bloated and usually run twice as slow as that produced by FreeBASIC
QB64 forum https://www.qb64.org/forum/index.php

dcouzin

@Johan Klassen
Maybe I now understand what went wrong with my integer variables.  It was the '-lang qb' option that forced the FB 64-bit compiler to make the integer variables 32-bit.  Then the execution failed.  Why didn't the 64-bit compiler "know" that execution had to fail with 32-bit integers?  Why, instead of reporting errors, did the compiler pass off a doomed executable?  Perhaps I rely too much on error reporting by the FB compiler.  If ever the FB 32-bit compiler produced an executable that just crashed, I wouldn't know what to do.

My first post stated my two goals:
1. to run the programs as fast as possible.
2. to not have to significantly rewrite the programs.

Since the FreeBASIC 32-bit compiler, with option '-lang qb', achieves the goals, why would I ever choose QB64, which you say is slow, over FreeBASIC?  Well, I just now tried QB64.  It accepted my QuickBASIC program as-is: pleasant.  But its executable ran 2.5× slower than FreeBASIC's: disqualifying for most of my work.  FreeBASIC's executable uses 24% of my CPU compared to 11% for QB64's.

I see no advantage, yet, to 64-bit compilation.  My programs don't need over 2 GB of memory.  If fact the tested FreeBASIC executable used just 7 MB of memory.  I certainly don't need integers larger than 2^32 -1.  What other advantages are claimed by 64-bit compilations?

Dennis


José Roca

The main advantage of a 64-bit compiler is to address more memory. If you have enough with 32-bit, then use it. As simple as that.

Johan Klassen

@dcouzin
I just downloaded the latest stable version of QB64 for Windows and run a simple speed test and it's slow, the test speed was 12+ second
I then downloaded the 64-bit version from http://qb64.freeforums.net/thread/100/qb64-x64-10-17-2018 and the test speed was about 0.5 seconds
hope this helps you :-)

Johan Klassen

@dcouzin
in my view, QB64 may be useful to you, if you get the 64-bit version linked in the post above
and there's a trick to get your program to run as fast as one compiled with FB
first place this meta-command in the top of your program

$CHECKING:OFF

do a test-run, it's so that QB64 will create the file recompile_win.bat in the directory qb64/internal/temp/
open that file and right after g++ add a space and -O3, save and run the file to recompile your program

dcouzin

@Johann Klassen
I tried what you suggested with qb64-x64.  With the first compilation my test program took 70 seconds to run.  After the recompilation it took 54 seconds.  FreeBASIC takes 30 seconds.
My sample code must be very different from yours, to benefit so much less from the recompilation.

Dennis

Johan Klassen

@dcouzin
perhaps g++ reuses the object files from the unoptimized compile if the source file has not changed, may I suggest one more try
open your program in the editor and enter a character somewhere and then delete that character and save the file, exit the editor
reopen recompile_win.bat and place -O3 as before and recompile, hope that will do the trick.

Johan Klassen

@dcouzin
since execution speed is important and FreeBASIC32 is compiling you program ok, I suggest you compile your program with compiler option -gen gcc -Wc -Ofast
sometimes gcc can make good optimazations

dcouzin

#14
@Johann Klassen
I couldn't make your qb64-x64 trick work.  The recompilation is always the same.  (It is smaller than the first compilation and gives 54 second execution instead of 70 second.) 

How could fiddling with pgm.bas effect the "object files" connected with pgm.exe anyhow?  I assume you mean the many files in the directory qb64/internal/temp/ that were created when pgm.exe was created.  I also tried deleting some of those files, but then recompile_win.bat wouldn't work.  Perhaps there are certain ones I can delete in order to get a different recompile.

On the other hand, your suggestion for the FreeBASIC compiler worked beautifully.
Making the compiler options: '-lang qb -gen gcc -Wc -Ofast' the compilation came out smaller (61,952 bytes vs. 78,848 bytes) and the execution time dropped from 30 seconds to 16 seconds.  Super!

The '-gen gcc' option worked with FreeBASIC-1.06.0\fbc32.exe, but not with FreeBASIC-1.05.0\fbc32.exe.  Is that to be expected?

Dennis