Hacker News Reader

Comment by tenebrisalietum | Hacker News Reader

CBM had 5 byte floats I think you meant--edit: maybe it was 6. 5 byte mantissa and 1 byte exponent??

CBM BASIC was a Microsoft product and I think more or less what all the Microsoft BASICs did was convert everything to floats internally--even when not really needed. For example the index in a FOR I=1 to 10 was dealt with internally (and slowly) as a float--including the operation to increment it by 1 or the STEP value.

If Atari BASIC didn't do that it would have made things faster in many situations. Apple's Integer BASIC was faster because it didn't support floats at all, if you could deal with the almost C-style strings IIRC.

View on HN

CBM had 5 byte floats, but when they were copied into the floating point "registers", they were expanded into a 6 or 7 byte representation for speed. It was 8 bits of exponent, 1 bit sign, and 31 bits of mantissa (with one extra implicit bit since the leading bit is always 1).

It's true there was very little performance gain to using BASIC integer variables, since they'd be converted to floats internally almost always. The one real advantage of integers is that a DIMed array of ints was more compact than an array of floats.

I always thought it would be cool if the line numbers were floating point. You could always insert a line between any existing ones then.

I'm pretty sure Netflix queues used to work this way. For the DVD-by-mail service, I think.

Basically, the web page had a text field next to each movie, and you could type in numbers, then submit a form, and it would reorder your queue.

The obvious thing to do was swap "1" and "2" to flip the order of the top two items. But you could just set the second one to "0.5" and leave the first at "1". When you submitted the form, it would renumber them all with integers.

That would be JOSS or FOCAL:

https://en.wikipedia.org/wiki/JOSS

https://en.wikipedia.org/wiki/FOCAL_(programming_language)

We could add an imaginary part to line numbers. If you do a GOTO 200 + 20i, you’ll jump to a line that’s above the program in the imaginary axis and continue running from there.

With FOCAL, though, they were more like modules rather than floating point values; you could address blocks of code ("groups") by, for lack of a better expression, the integer portion of the number, with the fractional portion being the line number within that group.

This is why everyone use 10, 20 etc.

I think I remember there was a Renumber command that would reset any inserted numbers too?

There were BASIC extensions you could get that added renumber. The C128 had renumber as a builtin.

Integer variables were written I%. I%=I%+1 was certainly faster than I=I+1, but I am not sure if that extended to FOR loops.

Oh, you'd be surprised. Run this:

10 TI$="000000":J=.:FORI=0TO900:J=J+1:NEXT:PRINTTI

20 TI$="000000":J%=.:FORI=0TO900:J%=J%+1:NEXT:PRINTTI

I get, on VICE in PAL mode, 212 jiffies and 256 jiffies respectively.

The reason for this nonsense is that Commodore BASIC does the math in floating point, and converts it to integer after the fact. You can speed this up with

20 TI$="000000":J%=.:K%=1:FORI=0TO900:J%=J%+K%:NEXT:PRINTTI

which gives me 244 jiffies, but still slower, because even though K% is now already an integer and it costs "less" since it is now in a variable instead of being converted from BASIC text, it still requires a roundtrip to the floating point accumulator.

Bottom line: always benchmark.

Cool! I did remember benchmarking it, but it's been... a few years :)

The implementation issue with integers in Commodore BASIC 2 was that they were still stored in a 5 byte format, while actually using just the first two bytes. Meaning, unlike with other implementations of MS BASIC, they occupied 7 bytes in memory (with two leading bytes for the identifier), just like floating point variables, and there was no improvement on memory usage with integers.

Atari BASIC used 48-bit BCD floats and the routines were not well optimized, making it one of the slowest at the time(later retrohobbyists have made various patches as well as faster BASIC implementations). It was also Microsoft-incompatible which made it an odd duck among the microcomputer BASICs.

Reply on news.ycombinator.com