Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 10:56 03 May 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Limits of variable names

     Page 2 of 2    
Author Message
karjo238
Regular Member

Joined: 12/10/2018
Location: New Zealand
Posts: 54
Posted: 04:25am 14 Jul 2019
Copy link to clipboard 
Print this post

Just a quick update to my story. I pressed on and managed to get the code running in MMBasic 5.

I now just have to think in the new paradigm of coding that it brings along

Many thanks for everybodys help.

Joseph.
 
Turbo46

Guru

Joined: 24/12/2017
Location: Australia
Posts: 1636
Posted: 05:12am 14 Jul 2019
Copy link to clipboard 
Print this post

That's good. Sorry about the sidetrack I caused with the integer thing but I learnt something from it anyway.

Don't suppose you'd like to share it?

Bill
Keep safe. Live long and prosper.
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 4245
Posted: 11:44am 28 Apr 2020
Copy link to clipboard 
Print this post

  matherp said  The variable table is just a sequential list in the order created and the parser searches from the top until it finds a match to the variable name.


I might be wrong to resurrect this thread and I hate to second guess other programmers, but is there a good reason for this, seems like there are more efficient schemes.

e.g.

1. Separate lists for variables beginning A, B, C, ...
2. Having the single character variables stored separately and in fixed locations so they can be looked up with a single indirection.
3. Combine 1 & 2 by having separate lists per leading character sorted alphabetically ... that way a single character variable can be looked up with one indirection and the longer names can be looked up with a binary chop.
4. Hash maps and other more complex data structures.

1 & 2 are what made BBC BASIC so fast compared to its peers.


Regards,

Tom
MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3267
Posted: 02:04pm 28 Apr 2020
Copy link to clipboard 
Print this post

Some time ago I did a lot of benchmarking of MMBasic to discover where it spent most of its time and then I optimised the parts which wasted most of the time.  This provided a useful performance boost.

I cannot remember where variable lookup sat in the list but it was not very high.  This is because typically most programs don't have that many variables and a linear search does a reasonably good job without the overhead and wasted flash space used by more complicated schemes.  

Recently Peter Mather discovered a small tweak for the search algorithm which does speed it up somewhat and I will include it in the next release.  But for a typical program the overall improvement will be small.

Geoff
Geoff Graham - http://geoffg.net
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 4245
Posted: 10:17am 29 Apr 2020
Copy link to clipboard 
Print this post

Thanks for taking the time to answer Geoff, I guess this has been asked before.

I asked because I've just found that the most effective optimisations I can make to my MMBasic (4.5) code are those that reduce variable lookups, of course they also reduce the amount of parsing, so it's not a simple equation. Maybe one of these days the kids will give me time to poke at the C myself so I can satisfy my curiosity

Are the optimisations you talk about in MMBasic 4.5 as on the Colour Maximite, or only in MMBasic 5.x on the Micromites?

Best wishes,

Tom
Edited 2020-04-29 20:22 by thwill
MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3267
Posted: 09:45am 30 Apr 2020
Copy link to clipboard 
Print this post

Yes, most of the optimisations were made back in V4.5 so they apply to the Maximite family.  A couple more have been made since then but they do not make a great difference.

My view has always been that interpreted BASIC has an inherent issue with speed and while you can tweak it you will never make it really fast.  If fast is what you need then writing in C or assembler is the only real answer.

Geoff
Geoff Graham - http://geoffg.net
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 4245
Posted: 10:44am 30 Apr 2020
Copy link to clipboard 
Print this post

  Geoffg said  Yes, most of the optimisations were made back in V4.5 so they apply to the Maximite family.  A couple more have been made since then but they do not make a great difference.


OK, thanks.

  Quote  My view has always been that interpreted BASIC has an inherent issue with speed and while you can tweak it you will never make it really fast.  If fast is what you need then writing in C or assembler is the only real answer.


In my professional capacity I agree with you, but with my hobbyist hat on I think on a modern processor / micro-controller an interpreted language can be fast enough for most purposes (see all the usage of Python, admittedly semi-compiled). Especially if you can fallback to native code for critical routines ... alas not possible on the Maximite

Thanks again,

Tom
MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
     Page 2 of 2    
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025