 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 : Oddity with FOR/TO loops
| Author | Message | ||||
| Goksteroo Senior Member  Joined: 15/03/2021 Location: AustraliaPosts: 114 |
I was messing around with some old Spectrum Benchmark programmes - stripping line #s, removing goto's, etc and then testing the results on CMM2, newest MM Basic for Windows, and an Amstrad emulator. Why? Because I was curious. The programme tests loops, maths, etc over a 10 second period and counts number the of loops performed as a score. Curiously for/to loops performed slower in MM basic once line #'s were removed and it came down to how the NEXT statements were written: MMB - Win MMB - CMM2 NEXT i:NEXT j - 239,133 - 14,092 loops NEXT i,j - 154,177 - 10,713 loops NEXT:NEXT - 371,976 - 26,316 loops Lesson there for anyone who uses lots of nested for/to loops in their programs.... but otherwise just a quirk in MM Basic. BTW - the Amstrad CPC managed 20 loops in the same 10 second period! Geoff aka Goksteroo |
||||
hitsware2 Guru  Joined: 03/08/2019 Location: United StatesPosts: 735 |
( Perhaps ( probably ) ) from abject ignorance , I have always thought line numbers an elegance . my site |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 483 |
They were necessary in the days of teletypes and dumb terminals in order to be able to get meaningful error messages and allow easy editing such as inserting new lines between other lines. In fact they're still required by the ANSI/ISO standard for Full BASIC. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
whatever floats your boat. They have their place I think, certinly as "tell-tales" for debug and error handling. I wrote VB (as a job) for years and I used line numbers scattered through the code to break up the program into logical chunks (not every line, key points and I called them steps though) so when errors were logged in the wild I had a really good idea what was going on at the time. Like this: ... 3100: Set TRS = DBCONN.Execute(SQL) G = TRS.GetRows 3110: For n = 0 To UBound(G, 2) ' each ci in buffer for this sysident InitCI (n) ' here we have a sanitized CI so check if it exists ... ... so any error reported in "step" is 3100 will be associated with that DB access. I went on to provide a similar debugging method (because TRON is unfathomable) in MMBasic which makes life a lot easier when debugging http://www.fruitoftheshed.com/MMBasic.Program-Step-A-Fast-Flexible-Debugging-Aid.ashx Edited 2022-02-01 18:30 by CaptainBoing |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8298 |
Strangely enough, an almost identical concept is described in my ancient "Basic - Faster And Better & other mysteries" book for the TRS-80. He says that line numbers should be used as subject and paragraph headings and that the Renumber command is probably the worst thing you can use. He has a very good point. Interchangeable blocks of code (taken from your "stock"), doing similar things, share the same block of line numbers as you'll only use one of these blocks in a program. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
