Does that work well enough to also store the length at the end of each line to speed up the search for a lower line number?

You would need to structure it as:

<previous line text><CR><prev length><current length><current line text><CR>...

It's akin to linked-list vs. doubly linked-list data structures - the programming burden (code size, testing) vs. simplicity and smaller code. In traditional memory constrained 8-bit systems, I suspect going for smaller code and simplicity is a bigger win... (or maybe the writers of them back in the 70s and early 80s just didn't have the knowledge then?

My "big" BASIC (written in C) does a pre-run-time fix-up and scans the code for GOTO/GOSUB references and replaces them with a token containing the address of the line, so no searches during run-time. This also means no GOTO {expression}, but I can live with that as you can code mostly line-number free if desired.

I think there was an Atari Basic that did this sort of pre-run-time scan to speed it up too, but I may be wrong...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I got the idea from a certain Mr. Gates. I think that the only way for a human to notice the difference would be to run some rather large programs with a bunch of loops, like "Super Star Trek" or similar. I have a version that is stalled in the fixed-point navigation routines ... and has been for some time.

Some of these performance features that weren't in Frank's original 6800 implementation came after my realization that I wasn't going to fit VTL02 into 768 ROMable bytes at my coding skill level. I changed my goal to 1KB or less and used that extra breathing room to add a few features, like proper cold initialization of the user area, five additional binary operators, the VTL-2 equivalents of PEEK & POKE, and performance enhancements. I know a bit more now than I did then, and there's a non-zero chance that I or someone more skillful than I could revisit the 6800 source and try to fit the original features inside 768 bytes of 6502 (or 65c02) assembly, but that ship has probably sailed, at least for me in my current situation.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

The idea of a RUN command triggering some sort of pre-scan that checks for various mistakes before they can happen and/or speeds up later lookups is not a new one, though not one that 6502 Microsoft BASICs adopted.

This book https://www.wang2200.org/2200tech/Implementing%20BASICs.pdf touches on the concept.

Overall I think it's a horrible book, far too preachy in its "this is the way it's done" attitude and refusal to acknowledge that there are in fact alternative approaches. But it has one or two ideas I hadn't seen before.

Thanks for the link! (And the warning)

Indeed thanks. But it's a bit of a jar to my brain to see the first illustration has Top of Memory as smallest memory address, and Bottom of Memory as largest...

Neil

Except that storing the length of the line instead of the address of the adjacent line is that it does not need to be adjusted when lines are inserted or deleted.

I bought that book back in the day and totally forgot about it. I do not know where it is now...

Funny how that works...

We are accustomed to the lower left as the origin for charts.

Whereas we use the upper left of a display device as the origin with exceptions like OS/2 Presentation Manager.

And some people have real problems with stacks growing downward (toward lower address) on most processors meaning that the top of the stack is at a lower address than the bottom.

Don't get me started on electron vs conventional current flow...

Yeah, I never understood why Applesoft and friends used 16-bit absolute line links instead of 8-bit relative. It seems like a waste of a perfectly good byte for every line and adds an unnecessary burden to the line editor when inserting/deleting.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

8-bit relative has its price at run-time: an addition or subtraction involving the line's actual address.

The 6502 does it in such a way that the difference is negligible, and in fact slightly favors the relative technique:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Touché

How could forget that the 6502 is not like the 680x where I can simply do

ldx 0,X