Maury Markowitz Posted April 24, 2018 Share Posted April 24, 2018 The Advan Basic Compiler has support for PGMs, and DLIs and it's quite fast if you use the optimizing compiler and use the optional floating point package. It's fast already on integer based programs, but the need to ID integers with a "%" following both variables and in-line numeric expressions drives me nuts! That IS the standard for integers, however. It stated in the DEC basics on the PDP line, moved to MS when they basically copied DEC, and then became pretty common on other platforms. Unfortunately, MS didn't add it until the 1.6 version or so. Even then, the only place it was treated as a 16-bit int was when you were in an array index or for loop. In every case where you ran a math function, like A% = B% + 1, it converted them to the 9-byte FP/BCD format and then called the original FP math functions. I always found this odd. I emailed the original author of the 6502 version of MS BASIC, but the feature was added after he left microsoft (or that project anyway) so he didn't know. I think they did it because their primary concern was memory, and these took 2 bytes instead of 9, so that's a pretty big savings.But why not add an int library while you're at it? When I think about it, it seems there is a "half way" solution that was not attempted. Since these variables are really intended for loops and arrays, something like 99% of the functions called on them would be plus, minus and compare. It would seem one could have a very small addition to the original code with just these three functions in it, and still gain a significant performance increase. 2 Quote Link to comment Share on other sites More sharing options...
dmsc Posted April 24, 2018 Share Posted April 24, 2018 Hi! That IS the standard for integers, however. It stated in the DEC basics on the PDP line, moved to MS when they basically copied DEC, and then became pretty common on other platforms. Unfortunately, MS didn't add it until the 1.6 version or so. Even then, the only place it was treated as a 16-bit int was when you were in an array index or for loop. In every case where you ran a math function, like A% = B% + 1, it converted them to the 9-byte FP/BCD format and then called the original FP math functions. I always found this odd. I emailed the original author of the 6502 version of MS BASIC, but the feature was added after he left microsoft (or that project anyway) so he didn't know. I think they did it because their primary concern was memory, and these took 2 bytes instead of 9, so that's a pretty big savings.But why not add an int library while you're at it? When I think about it, it seems there is a "half way" solution that was not attempted. Since these variables are really intended for loops and arrays, something like 99% of the functions called on them would be plus, minus and compare. It would seem one could have a very small addition to the original code with just these three functions in it, and still gain a significant performance increase. This is not as easy as you think. The problem is that the language allows automatic conversion from integer to floating point and vice versa, this means that you don't know the type of an expression before parsing, then you also don't know if you need to call "add int" or "add float" when you see the "+" sign. Remember that the interpreter parses and executes in one go. One solutions to this problem is the used in FastBasic: expressions are parsed twice, first the parser tries to compile as INTEGER, if this fails, the parser retries from the start using floating points. This is slow at parsing, but very fast at execution. The other solution is to write integer constants different than floating-point constants, this is the approach used in Advan Basic, but I dislike having to add a "%" after each integer number. 1 Quote Link to comment Share on other sites More sharing options...
Maury Markowitz Posted April 25, 2018 Share Posted April 25, 2018 I only sort of jest -- I write primarily in PHP for my day job, so it's the language my brain thinks in these days. You poor, poor man. Well, periodically I have to do some APL, so there's that... Quote Link to comment Share on other sites More sharing options...
Maury Markowitz Posted April 25, 2018 Share Posted April 25, 2018 One solutions to this problem is the used in FastBasic: expressions are parsed twice, first the parser tries to compile as INTEGER, if this fails, the parser retries from the start using floating points. This is slow at parsing, but very fast at execution. The other solution is to write integer constants different than floating-point constants, this is the approach used in Advan Basic, but I dislike having to add a "%" after each integer number. So... 1) I saw there are different versions for integer and FB, but looking in the source on github I could not find a separate non-FP library. Is there someone I should look to understand what FB is doing here? 2) So does Advan require things like "A% = 10%"? Or is it "A% = 10". If the later, that is the "standard" all the way from BASIC-PLUS on the PDP-11 (ahhh, the PDP). If it is the former, I agree it's less than ideal, but I'm not sure why it is needed - wouldn't the parser normally work left-to-right? Quote Link to comment Share on other sites More sharing options...
dmsc Posted April 25, 2018 Share Posted April 25, 2018 Hi! So... 1) I saw there are different versions for integer and FB, but looking in the source on github I could not find a separate non-FP library. Is there someone I should look to understand what FB is doing here? Yes, both versions compile from the same source. For the parser, the main difference is in the basic.syn file, there are parts inside "#@if FASTBASIC_FP" / "#@endif FASTBASIC_FP", those are only compiled for the FP version. Note that currently the only place that accepts both integer or floating-point values is in the "PRINT" statement, look at he "PRINT_ONE" parsing table. And for the library, see in the Makefile, the "FP_AS_SRC" files are only included in the FP version. 2) So does Advan require things like "A% = 10%"? Or is it "A% = 10". If the later, that is the "standard" all the way from BASIC-PLUS on the PDP-11 (ahhh, the PDP). If it is the former, I agree it's less than ideal, but I'm not sure why it is needed - wouldn't the parser normally work left-to-right? Yes, Advan Basic requires "A% = 10%", it probably simplifies the parser a little, specially on expressions like "A% = X + 10%" versus "A% = X + 10", as the first is twice faster than the second. 1 Quote Link to comment Share on other sites More sharing options...
Geister Posted April 26, 2018 Author Share Posted April 26, 2018 Most of my programming in 10-15 of the last 30 years has been in Visual Basic classic (3.0 to 6.0). When .NET became a thing I switched to C# mostly because someone in IT decided we should be programming in a JAVA-Alike and being an MS house, C# was the closest we could get. In all those years I got used to Visual Basics Option Explicit and dimensioning ALL variables AS TYPE. I haven't had to put a dollar sign after a string or a % after an Integer in a long time. If you don't use option explicit and just assigned data to a variable you get the same problems you get in other basics where you can accidentally create variables you didn't mean to via typos. I initially hated having to declare everything but now I prefer to. I know a lot of Atari fans enjoy programming in Atari Basic, quirks and all, but I'd like to use a bit more modern a language. I could be happy with Turbo Basic and/or Basic XE, but Advan Basic despite it's features and speed irritates me with certain changes to the language that are unnecessary, like using SAVES and APPEND instead of LIST D: or ENTER D: Oh well, it's not like I'll be using it to make a living or anything. Quote Link to comment Share on other sites More sharing options...
dmsc Posted April 27, 2018 Share Posted April 27, 2018 Hi Geister! Most of my programming in 10-15 of the last 30 years has been in Visual Basic classic (3.0 to 6.0). When .NET became a thing I switched to C# mostly because someone in IT decided we should be programming in a JAVA-Alike and being an MS house, C# was the closest we could get. In all those years I got used to Visual Basics Option Explicit and dimensioning ALL variables AS TYPE. I haven't had to put a dollar sign after a string or a % after an Integer in a long time. If you don't use option explicit and just assigned data to a variable you get the same problems you get in other basics where you can accidentally create variables you didn't mean to via typos. I initially hated having to declare everything but now I prefer to. I know a lot of Atari fans enjoy programming in Atari Basic, quirks and all, but I'd like to use a bit more modern a language. I could be happy with Turbo Basic and/or Basic XE, but Advan Basic despite it's features and speed irritates me with certain changes to the language that are unnecessary, like using SAVES and APPEND instead of LIST D: or ENTER D: Oh well, it's not like I'll be using it to make a living or anything. Adding strict DIMensioning of variables to FastBasic is easy, in fact removing the automatic variable creation would simplify the parser a little (no need to parse the "$" or "%" symbols after each variable use), but I think that in a dynamic language like BASIC variables should be dynamic. Note that FastBasic needs a DIM for arrays *before* array use in the program source, this is because arrays have type (WORD or BYTE) and the parser needs to know the type to compile the proper assignment. Also, I implemented the parser with creating the variable on assignment only, an expression like " A = 2 " defines variable "A" as WORD, but " A = B " as the first line of a program gives error as "B" is not already defined. This allows catching some typos, as "VAR1 = 3 : ? VAB1 " shows a parsing error. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.