 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 : MM+ E100 with "Not enough memory"
  Page 2 of 5   |
|||||
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6213 |
A match needs all bytes tested but a 'failed match' will move onto the next one as soon as a mismatch is found. Having the mismatch early in the data means it gets found sooner. You can test this in your own code. Jim VK7JH MMedit |
||||
| Bowden_P Senior Member  Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Thanks for the tacit explanation TassyJim - I thought I would be showing my ignorance!! Best to know what you don't know, rather than to think you know, and don't. With regards, Paul. Nothing so constant as change. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7474 |
There are no "silly" or "pointless" questions providing someone learns something from the answers. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10010 |
The latest Micromite versions (and the ArmmiteF4) match variable names 4 bytes at a time by sequential search. A non match can therefore be found with a single compare if the difference is in the first four characters. Of course to confirm an actual match all bytes need to be compared which takes the variable-name-length/4 compares. The CMM2 and now the ArmmiteH7 use a hashing mechanism on the variable name to allow much faster matching but other MMBasic variants don't have enough memory to do this. In addition the CMM2 also uses hashing on functions, subroutines and labels |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 384 |
LENGTH works in MM for DOS: DIM A AS STRING LENGTH 50 makes string A length 50. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10010 |
Still allocates 256 bytes No, without a major re-write. MMBasic manages its own heap and allocation of memory in the heap is in chucks of 256 bytes. This is core to the way the firmware works Edited 2021-04-28 18:11 by matherp |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 384 |
Oops! You're right, of course. Not giving a syntax error is not the same as working. |
||||
MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Very interesting indeed... I have been using things like 'DIM a$ LENGTH 5' for some while, thinking I was saving memory, and never considered it used the same amount of memory as a full length string! But like has been pointed out - try to assign 'a$="123456789"' and you get an error. It raises another question about memory: does the MEMORY command only calculate usage roughly, or does it compute the exact amount and just round it off to 'K' for display purposes? It would be great if it could display to the byte (or word)! Cheers, |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi Peter, Thanks for the detail about strings - looks like I'm not the only one to benefit from your clarification !! I intend to use the #REPLACE technique suggested by "disco4now" to reduce memory usage. I use the "OPTION EXPLICIT" for variable names, using the type suffix " % ", " ! ", or " $ " characters. Will this be included in a variable name's character count of 4, when searching is done 4-at-a-time on the "shortname" replacement name? e.g. For best efficiency, should the "shortname" be ABC$ or is ABCD$ equally fast ? With regards, Paul. p.s. I - like Mustardman - would like to see the MEMORY detail enhanced too if possible. Edited 2021-04-28 21:28 by Bowden_P Nothing so constant as change. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10010 |
The memory command is accurate. There is no point going to the byte level as the MMbasic interpreter also uses memory when it is evaluating expressions etc. so the amount free is constantly changing. You shouldn't get hung up on the difference between 4 characters or 5, we are talking a trivial difference in performance that you would never be able to measure. The thing that makes a difference is being discrete in the first four characters although even that is a small effect |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi disco4now, I'm having trouble with getting #REPLACE to work, and have PM'd you so as to not side-track this post. I would be most grateful for any help. With regards, Paul. Nothing so constant as change. |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
In opposition: could you reply to this post as I too have had trouble and might be able to pick up some pointers? Cheers, |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 966 |
I have updated the MMReplace thread to include a 32bit version. MMReplace Latest F4 Latest H7 FotS |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi disco4now and MustardMan, Thanks for the updated files. I have just run the Test1 code and it has worked fine. Performance figures on my MM+ E100 at 100MHz are :- 3557 un-#REPLACE'd 2090 #REPLACE'd. Apologies to MustardMan - I did not mean to cause any offense by my P.M. to disco4now, I just wanted to avoid my embarrassment at being an idiot in most things PC. I can use the machine for applications, but rapidly run out of knowledge when it comes to delving any deeper! I assumed it's erroring was something I had messed up somehow. Many thanks, Paul. Nothing so constant as change. |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
In an experiment with #REPLACE I tried to get it to "replace" the single character "_" with nothing - and promptly crashed MMEdit. That'll teach me !! The reason for this trial was to see if I could use it to remove the underscore character from my code - of which there are thousands I imagine. No such luck. With regards, Paul. Nothing so constant as change. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6213 |
If all you want to do is remove all underscores, I would use Notepad++ to do a global replace. I have deliberately not put global replace in MMEdit despite many requests. I consider it too powerful and risky in the wrong hands. Jim VK7JH MMedit |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi TassyJim, Thanks for the Notepad++ info on global replace. I know how dangerous it can be, and have only used it very carefully, especially when Windows doesn't keep previous versions of files to revert to if something obscure or unintentional goes wrong! With regards, Paul. Nothing so constant as change. |
||||
| Bowden_P Senior Member Joined: 20/03/2019 Location: United KingdomPosts: 162 |
Hi everyone, I have been editing my program to use both Captain Boing's flag manipulation techniques, and also disco4now's #REPLACE external program for MMEdit. Both have resulted in significant savings of memory. My 67 flags are now kept in 2 integers, each having 4 very short subs to manipulate them. The #REPLACE replaces the meaningful flag names with a specified bit number, before Crunching for Load. I have also used #REPLACE for storing 4 often used strings into a string array, limited by the LENGTH option to use 52 bytes for character storage, rather than the original 1024. What I have found however, is that #REPLACE gets a bit too enthusiastic in its action of replacing the specified strings, into unintended places !! So :- dim G$(4) length 13 #replace Fn$ G$(1) #replace Md$ G$(2) #replace Stg$ G$(3) #replace Prt$ G$(4) works well for :- "SELECT CASE Fn$+Md$" which becomes "SELECT CASE G$(1)+G$(2)" or "SELECT CASE Prt$" which becomes "SELECT CASE G$(4)" but not for :- "Tx_Str$=Tx_Msg_Type$+Tx_Msg_Prt$" which becomes "Tx_Str$=Tx_Msg_Type$+Tx_Msg_G$(4)" Not quite the wished-for result! I'm wondering if #REPLACE could be made more selective to avoid changing strings it shouldn't ? With regards, Paul. Nothing so constant as change. |
||||
| disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 966 |
Hi Paul, Its just a simple string replacement with no special rules or intelligence so will do what you are seeing. You can make use of the fact that the replacements are done sequentially in the order they are listed to help. Rename the one you want to preserve before the other replaces and then put it back after.e.g. #replace Tx_Msg_Prt$ Tx_Msg_KEEPME #replace Fn$ G$(1) #replace Md$ G$(2) #replace Stg$ G$(3) #replace Prt$ G$(4) #replace Tx_Msg_KEEPME Tx_Msg_Prt$ Regards Gerry Latest F4 Latest H7 FotS |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6213 |
This is the main reason why I prefer not to go down that rabbit hole. Gerry has allowed for strings being substrings at the start and middle, but not at the end. This is done by making sure that the character following the searched for string is a 'separator' It will need a complete rethink to check the preceding character as well to cater for both possibilities. As it's main purpose is to replace long strings with short ones, this is not usually an issue. Jim VK7JH MMedit |
||||
| Page 2 of 5 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
