According to this article: german C64 Wiki article about the POS() command POS(π) is 20 % faster.
Although in my experience it is circa 28 % faster.
Is there a specific reason for this immense speed boost?
2 Answers
That interpreter apparently parses the source text, or at least the numerical literal values, at every execution. π is a single-byte magic token, therefore, as soon as it is recognized, it is immediately substituted with the value of Pi, and nothing else needs to be done.
When a byte that might occur in a number is parsed, the number parsing routine begins. Its execution time will depend on the number of characters in the string representing the number. When parsing a number, each digit in the integer part requires multiplying the number parsed so far by 10 and adding the value of the digit. The fractional part is usually parsed as an integer, then divided by the appropriate power of 10. The division operation is expensive, and it makes sense to check if the dividend is 0 before dividing — that's why .0 is much faster than .1.
That's why, as the German Wiki article says, the next best execution time is for POS(.): the number parsing routine starts, but there are no digits to parse, and it devolves to skipping the period and adding the initial (zero) values of the integer and the fractional part, then for a variable with a single-character name (name lookup), and then for the number 0 (will cause the computation of 0 * 10 + 0). Longer numbers will take even longer.
-
2I'm pretty sure there was an HP BASIC that, after each
RUN, would tokenise each line the first time it is encountered, replacing the original in memory, then detokenise only when the program ended. It's a shame Microsoft et al didn't learn from that.– TommySep 27, 2017 at 18:23 -
3you definitely can, and some BASICs do. But they're the sort that tokenise as you type, never keeping a plain-text copy around.– TommySep 27, 2017 at 18:29
-
4@Tommy: Lines are tokenized in MS-BASIC, but sequences of digits are kept as written. In some BASIC dialects, if one writes
10 X=1.20and then typesLISTthe program would list back as10 X=1.2, but Commodore BASIC generally tries to list programs in such a way as to match what was typed.– supercatSep 27, 2017 at 18:29 -
4@Kaz Or an interpreter optimized to fit in the available memory, when the choice is between a slow ("crap") interpreter or no interpreter at all. I'll rephrase that statement.– Leo B.Sep 27, 2017 at 22:31
-
9Don't forget that Microsoft BASIC was designed to fit in a very small menory footprint because that's all there was. The original PET had 4 or 8K RAM and BASIC had to fit into 8K ROM. The Altair BASIC from which Commodore BASIC was derived had to fit in even less space. You can visualise the entire C64 memory map losslessly with a 256 x 256 GIF image. People today forget how constrained memory was back in the early 80's.– JeremyPSep 28, 2017 at 9:01
The C64 BASIC uses a floating point as basic format for everything. So even if a function requires an integer argument, the number is parsed into a floating point number first and then converted into an integer. When giving the constant π, a pre-stored floating point value of 3.14159265 is used, so the time for the conversion of the number to floating point is omitted. For POS(), the argument is a dummy argument, so its value does not matter to the result, which makes POS(π) easily possible. But even for other functions like POKE giving π as an argument (which will then be converted to 3) would be a bit faster than writing a 3.
-
I wonder how much extra code would have been required to say that whenever the exponent byte is zero, the next four bytes will be interpreted as a signed integer, and operations whose operands and results are both signed integers yield signed integer results? Operations that can't be handled that way would simply need to start with a call to a function that would convert operands to normalized format, but most operations would execute much faster because they could skip the normalization steps.– supercatJan 14, 2019 at 20:25
POS(0.0)?pos(π), butpos(.)should be faster thanpos(0).POSreturns the cursor column. It takes an argument but doesn't use it — it's a dummy.