 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 : Constant Keyword Useage
Page 1 of 2   |
|||||
| Author | Message | ||||
jwettroth Regular Member  Joined: 02/08/2011 Location: United StatesPosts: 79 |
I'm trying to make some code more readable. It manipulates several port pins and I'd like to give these sensible names. In assembly or C, they have literals that just let you create aliases, the macro processor expands these before compiling. It seems that the closest thing in basic is CONST. Is the following a reasonable thing to do? For example CODE BEFORE spi open 10000000,0,8 'spi at 10M setpin(2)=out 'pin 2 is chip select for spi device- dac pin(2)=0 'cs low- talk to dac spi write 1,a% pin(2)=1 CODE USING CONST CONST DACCS% = 2 'DAC cs on pin 2- creat constant SPI OPEN 10000000,0,8 SETPIN(DACCS%)=OUT PIN(DACCS%)=0 SPI WRITE 1,A% PIN(DACCS%)=1 Is this the most sensible way to do this. I'm an old assembly/c language programmer and I hate having hard constants embedded in code. Edited 2022-07-09 05:38 by jwettroth John Wettroth |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I would say so, yes. The only problem with using CONST is that you have a tiny lookup delay every time you use the variable. In this instance there's no problem, but there might be if it was used in a loop. The delay can be minimised by keeping the variable name short and distinctive so that it's found quickly. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| jwettroth Regular Member Joined: 02/08/2011 Location: United StatesPosts: 79 |
Thanks for the response, Mick! I don't think there is a good alternative- if anyone can think of one let me know. I thought of just having a big comment block at the top and hardcoding them in place. Search for the name in the comment string... John Wettroth |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
As MMBasic is an interpreter there isn't a way to get round having to look up a variable during run time. It's very fast, but there is always some delay, which depends on how long and complex the variable name is as the search is multi-pass. That's why short, simple names are found the quickest. Hard-coded is the fastest but the most obscure. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Unless you're finding speed is an issue, don't hard-code! Graphics-intensive is when speed tends to matter e.g. a game. John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
CMM2, PicoMite, MMB4W, MMB4L, ArmmiteH7 all use a hashed lookup. Variable name length has only very a tiny impact. Similar variable names have NO impact |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
no worse than using any variable and a lot better that providing an absolute value which the expression evaluator has to ascertain what you mean (every time). consider this bit of silly code Const q=1,l=10000 dim integer c c=0 timer=0 do c=c+1 loop while c<10000 ? timer c=0 timer=0 do c=c+q loop while c<l ? timer > RUN 1083 1052 in this instance, 30ms isn't a great difference but then the code is tiny... so... You should use CONSTs (or variables) whenever practical for a speed boost and when you have to use an absolute, consider the radix - &h is faster than decimal and &o is fastest of all. I touch on this subject in my hints 'n' tips article. Edited 2022-07-09 16:59 by CaptainBoing |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1233 |
John, Mick something I learned so far, in my two month experiance with MM-Basic from the point of the speed of execution If reading a CONST is time critical, so the next Steps could be, develop your Project it as it is. When the Program is ready Look for Functions and Subs, that are only called from one place in the program, replace the call with the Code of the Functions or Sub. Backup your readable Source (as you might have to do some changes or fixes later) replace every CONST with its value(in notepad), because they do not change their value. Remove all Comment Lines, as they also cost some "Ticks" replace additions and subtractions with the inc command and use interes if possible t=Timer Const Va=10 n=1 For x=1 To 10000 something Next x Print Timer-t Sub something n=n+va End Sub 857.685 mS without Const: t=Timer 817.685 mSn=1 For x=1 To 10000 something Next x Print Timer-t Sub something n=n+10 End Sub without the sub t=Timer 375.426 mSn=1 For x=1 To 10000 n=n+10 Next x Print Timer-t last fine tune t=Timer 299.813 mSn%=1 For x%=1 To 10000 Inc n%,10 Next x% Print Timer-t So we managed to get the little Program which does the same thing to run in a 1/3 of its time. Have fun Chears Martin my two cents Edited 2022-07-09 17:18 by Martin H. 'no comment |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Sorry, Peter, I hadn't realised that the PicoMite had a hash table now. It was never something I gave much thought to anyway as I've never been a fan of complex variable names - I'm a poor typist so the shorter the better. :) You had me on that one at first, Cap'n. lol I don't like using lower case L as a variable name - it leads to some confusion when silly fonts make it look like 1. const l00=1000 ? l00 1000 const l00=1000 ? l00 1000 :) @Martin It's always a balance between speed, readability and ease of maintenance. It depends on what the code is. There's no problem with coding parts of the program for high speed and the rest for readability most of the time, but if you do that then it's not always a good idea to strip at least some of the comments out or you lose ease of maintenance. I'm not in favour of stripping out all comments to gain speed except in very tight circumstances - and you'd better keep a commented copy too. :) Edited 2022-07-09 17:25 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
The morale of this story is that you have to test and not make assumptions; especially ones based on experience with compiled languages. Additionally the results from one MMBasic platform do not necessarily apply to a different one. Case in point: CHOICE is documented as being faster than the equivalent IF THEN ELSE construct, but on the PicoMite it is slower ... unless Peter had "fixed" this since it was observed. I'm most surprised by The Captain's observation that using a CONST or variable is faster than an integer literal, all the more surprising since I think his testing was on one of the pre-hash lookup MMBasic implementations. It has been my observation that literals are faster! Perhaps he was accidentally testing on a Commodore 64, where using a variable was apocraphally faster?  Best wishes, Tom Edited 2022-07-09 18:31 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
On a non-hash version of MMbasic variable lookup (including constants) is sequential search. If you have very few variables then this is quicker than hashed lookup. Say we have just one variable "A" then the first search will find it. Moreover its value is already the required binary representation needed. Compare a literal. No lookup required but an ascii to binary conversion is needed. The balance between a variable and a literal will therefore depend on the time taken to do the search which can be very fast if the required variable is near the top of the list vs the time taken to do the binary conversion. If the variable is a float this will be significant. The hashed solution is much more deterministic. Variable lookup will take almost the same time irrespective of the number of variables UNTIL you start to see hash table collisions. |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
heh, yeah... it was an extraordinarily bad example... I don't know why it happened really - I never use L as a "go-to variable" like n or x etc... was probably equating it to "limit" or something. In the font I use in PuTTY+ and Notepad++, lower-case L is distinguishable but courier (between the CODE tags) duffs that up. 3/10 - must try harder I guess.  |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Some really good stuff in there  Craig |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
please feel free to add/critique it. I am thinking i need to start caveating my stuff because there are clear differences between the "traditional" MMBasics (like '170s platforms) and the newer "MMBasic2" for Pi, PC and ST |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Heck, apart from the "Z80/68000" bit, this could've come from me: I built a 5-axis articulated, non-contact (laser) measuring arm and decided to hire a programmer to write the bulk of the code. I never looked at his source but the contraption certainly worked. I couldn't help thinking that the touch-screen interaction was sluggish. One day, I walked into his office and I could see his screen as he was writing code and I picked up on something like: a% = 20 a% = 20 a% = 20 I asked him what that was all about and he replied "assigning a value to a variable but I just like to be sure that it sticks"  Turned out that ALL of his code was written like this. Even performed the same calculations multiple times  He was actually offended when I insisted that it was ridiculous: "who cares, we have faster computers coming next year"  Craig |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
saints preserve us! Could you imagine a world where you could never be sure the three assigns were enough to achieve a "stuck" value I try not to be too harsh on fellow programmers, god knows I have written some cr4p in my time but in this instance I think I will permit it... No.23. Point, Laugh. Edited 2022-07-11 19:57 by CaptainBoing |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3378 |
No problem. If he only expects 1/3rd of his code to be effective, just pay him 1/3rd of what he contracted for. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| jwettroth Regular Member Joined: 02/08/2011 Location: United StatesPosts: 79 |
Many moons ago probably early 90's, I was doing Car Alarms around the then new PIC16C54. They had a note in the data sheet- I'll have to see if I can find the reference- that recommended that in noisy environments that you "refresh" port pins values on a regular basis. This always seemed pretty sketchy to me. I dutifully obliged and "refreshed" the data direction and port registers each time I serviced the watchdog. I wonder if this how this guy got started. John Wettroth |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
No. He was just a dumba$$ programmer. |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
I came across something similar in the early 90's. A Motorola 68HC11 "programmer" put a lot of the chip configuration register initialization inside the main loop, "to ensure the chip was always configured properly." Good programming practice, he assured me.  Visit Vegipete's *Mite Library for cool programs. |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
