![]() |
Forum Index : Microcontroller and PC projects : MMBasic for DOS. Ver 5.04 Beta
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
CaptainBoing![]() Guru ![]() Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
and I wouldn't be afraid to use long names ![]() major re-write I am guessing ... but ... if it happens, maybe consider 16 bit string lengths too? Possibly these are beyond scope for the smaller uMs |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
That is a brilliant idea and would result in a huge speed improvement. I will investigate. Geoff Geoff Graham - http://geoffg.net |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
would be something for geoff to comment upon, but in principal converting to 16-bit tokens might not be as hard as it first seems. it would require that the tokenizer identify and turn all variable names into tokens when saving from the editor, and maintain a table in flash to enable converting from tokens back to names when editing a program. this would require extra code. but then the interpreter would no longer need to be able to handle variable names, which would reduce the required code, perhaps by about the same amount as the tokenizer grew. there would also be a bit of complexity about where to stash the name/token table. the obvious place would be at the top of free flash, where the library currently resides. there may also be the opportunity to make all variables 'static' in RAM, as in the memory address for each variable being defined before the basic program even starts running. this would remove the need for any heap manager. and one could add a LIST VAR command that would list all the variables used in a program (and possibly their address in RAM), allowing easy identification of mis-spelled variable names - a long standing bugbear of basic. note: this is a very pie-in-the-sky idea. there may be very good reasons why it would not work at all! cheers, rob :-) |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
snap! i was (slowly) writing my post while you posted yours ![]() cheers, rob :-) |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
The main issue will be in accurately recognising variable names while the tokeniser is doing its job - a lot of things could confuse it. If that can be done the rest would be easy. The other issue is that whenever I make a change it creates bugs - so expect plenty of bugs. Geoff Graham - http://geoffg.net |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
we love bugs ![]() cheers, rob :-) |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
I have just thought of one issue... what happens when you CLEAR or ERASE variables - damn! Geoff Graham - http://geoffg.net |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10180 |
[CONSULTANCY-HAT-ON] What would be the objective of such a big change? Does a small (probably less than 20%) performance improvement justify a period of instability? To me the total reliability of the core MMBasic engine is one of the key aspects of all the various ports and I would be loathe to see this affected adversely. There is already a range of chips that progressively give greater performance increments than this change could yield so FWIW my instinct would be to leave things as-is. A true functional enhancement such as strings>255 chars would yield much better USP [/CONSULTANCY-HAT-ON] |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
One could also ask what the advantage of using CLEAR and ERASE has in an embedded system. Backward compatibility is not that important as going forward. I think there are two priorities for small embedded systems. Speed and available memory. Both of these would be addressed by replacing variables with tokens. I feel it is a good way forward,and the sooner it is tackled the better as going forward it will only get more difficult to implement. If using 16 bits for tokens is done then maybe also use 16 bits for string length, this would then get rid of the 255 maximum length problem. Variable string lengths with its inherent overhead is not really a good match with embedded systems but would be of great value in all purpose versions of the micromite like the ones who have lots of cpu power and memory. In todays world with so many solutions using internet i really think it is time to implement a hash/dictionary. Parsing will be so much easier to implement with that. And it is not that hard to do in C. Microblocks. Build with logic. |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
because variables would be pre-allocated, CLEAR would need to just set all floats and integers to zero, and all strings to "" (their initial states). ERASE would do the same to a subset of variables. the only complexity would arise with something like this: 10 DIM A(10) 20 ERASE A 30 DIM A(20) it would be necessary to somehow raise an error for line 30 when saving the program, doing so at runtime would make little sense. the error message might be something like "Duplicate variable name at line...". local variables could be handled by recording their name as subname.varname, however enforcing local variables being inaccessible from outside the subroutine in which they were declared may be difficult. thinking more on the matter, i could see this being - for the moment - an experimental branch in the language. a bit like python 2 and 3. if the changes proved worthwhile and the incompatibilities overcome, then later on the branch could be moved back into the main line. cheers, rob :-) |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
further thought has produced a solution that would seem to keep everyone happy and allow 100% compatibility with CLEAR and ERASE. see the below diagram: ![]() "plan A" is what i had originally envisioned, where the entire variable table is contained in flash and constructed upon exiting the editor (or completing 'autosave'). the (static) variable table would contain entries of variable length, but because the length of each entry would be known it could still be searched relatively quickly for a given token. since all variables would be 'static' there would be no need for complex heap management. the downside is that mmbasic would handle variables in a substantially different fashion, amongst other things no longer allowing re-dimensioning of arrays. "plan B" involves splitting the variable table into TWO tables, one static (in flash) the other created at runtime in RAM just as the existing variable table currently is. the static variable table (SVT) would just contain 16-bit token numbers (in sequence starting at, say, 64000) and variable-length variable names. it would exist solely for the purposes of 1. reconstructing the original source code when detokenizing before invoking the editor, and 2. converting tokens back into names for printing out error messages. one key piece of information derived from the SVT would be used at runtime: the total number of tokens. upon starting a BASIC program, a runtime variable table (RVT) would be created. the RVT would differ from a conventional BASIC variable table in a couple of key ways: each entry would be of a fixed length, and, the number of entries would be known beforehand (so the RVT would not need to be able to grow/shrink). there would be no need to search the RVT, instead the base token number (64000) + fixed entry size could be used to index into it - strictly speaking the RVT would not even need to hold the actual token numbers. prior to being first accessed or declared, the RAM address associated with a given token/variable would be nil, and after being CLEARed or ERASEd would be set back to nil. while the RVT would be of fixed size, heap management would still be required to allocate and recover the RAM used to hold each variable's content. geoff, peter: does this sound more workable? cheers, rob :-) |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10180 |
My strong view is still that this is a solution looking for a problem. The key to the future success of the Micromite is not tinkering inside the guts of the interpreter for no obvious FUNCTIONAL OR PRODUCTIVITY advantage. IMHO what is needed are many more magazine articles (or Instructables etc.) using the Micromite in real world applications. Where is a single example of using the excellent Explore-28 for DOING something? If we look at the Arduino, it has categorically the worst IDE of any platform and the primitives for using its I/O are clunky to say the least (compare I2C vs Micromite) but its strength is lots and lots of application code out there, easy to access, and easy to use. I appreciate I'm a serial offender in not contributing to the various "library" initiatives that have taken place over the years but to me that is the most important way forward. Want to use a BMP180 - here are library routines for using it. If this could be incorporated into something like MMEdit this could be hugely powerful - imagine a drop down list of library routines that you select from and that automatically then get loaded using the Micromite LIBARY command and where the calling sequence is documented and available in a panel on the IDE. The step up in real user productivity would be enormous, far greater than a modest speed improvement achieved by internal tinkering which in any event can always be solved by the next faster chip. |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6266 |
![]() It comes close... Just needs people add routines and keep them updated. Jim VK7JH MMedit |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Rob, great minds think alike! For my own benefit I sketched a method for getting tokenised variables to work and it is almost identical to yours. Peter, I agree with you. MMBasic is quite stable and we should be using it to build things rather than tinkering with it. It does make an interesting academic exercise though. Geoff Geoff Graham - http://geoffg.net |
||||
GoodToGo!![]() Senior Member ![]() Joined: 23/04/2017 Location: AustraliaPosts: 188 |
I've just about finished a project that is utilising one. I'll take some snappies and post them when I get a chance..... Cheers, GTG! ![]() ...... Don't worry mate, it'll be GoodToGo! |
||||
BrianP Senior Member ![]() Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Will be working on one as soon as my E28 arrives... ![]() B |
||||
flip Senior Member ![]() Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi Geoff, Am really enjoying this DOS version - it's great to test some GP routines. ![]() There may be a problem with SYSTEM command though, it seems to not like variables or expressions - it only takes string literals (either quoted or unquoted), i.e. > a$="DIR" doesn't work(seems to be sending 'a$' to DOS), whereas> SYSTEM a$ 'a$' is not recognized as an internal or external command, operable program or batch file. Error: Command could not be run SYSTEM DIR Volume in drive C is.... (Tested with 5.04.05 Beta 3) Following is a little play around with screen and menu and problem can be seen 2017-07-11_074034_DosScreenTests.bas.zip Regards, Phil |
||||
Paul_L Guru ![]() Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Flip, that stuff is pretty cool. Do Line Input Chr$(175)+ " ", a$ System "" + a$ Loop While Len(a$) Hmmmmm .... I don't see "loop while" in the bible, only "loop until". Also, the bible wants a semicolon ";" not a comma "," after the prompt string like this ... INPUT ["prompt string$";] list of variables but that might just change the spacing of the data entry point after the prompt.However, maybe this might work. do line input chr$(175)+" ", a$ if len(a$)<1 then EXIT DO system a$ loop while len(a$) Hmmmmm again .... I see that the "LINE INPUT" command somehow escaped from the bible, leaving the "LINE INPUT #fnbd" all by its lonesome. Paul in NY |
||||
flip Senior Member ![]() Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Thanks Paul! I slip into some old lazy habits from VB/QB when writing code...i.e. using an integer result as a True/False condition..which might work sometimes but is not good, thanks for that prompt, I've tidied up a bit... Do But it still seems we can't run SYSTEM command with a variable...(which would be a very useful feature)Line Input Chr$(175)+" ", a$ If Len(a$)<1 then Exit Do Else System a$ EndIf Loop Hi Geoff, I'm also finding an odd bug when calling a function of a function where the intermediate returned value starts with a null character: Function IntToChr(iVal As Integer,nChrs As Integer) As String This one is only as a consequence of testing my own program, but may be a subtle bug that causes grief.' Converts an unsigned integer to a character string of length nChrs ' little-endian Local As Integer iTmp=iVal Local As Integer iRmndr Local i As Integer For i=1 to nChrs iRmndr = iTmp MOD 256 iTmp = iTmp \ 256 IntToChr = Chr$(iRmndr) + IntToChr Next i End Function Function ChrToInt(sVal As String) As Integer ' Inverse function of IntToChr (little-endian) Local i As Integer For i=1 To Len(sVal) ChrToInt = 256*ChrToInt + Asc(Mid$(sVal,i,1)) Next i End Function Sub Tst Local a$ ? ChrToInt(IntToChr(23000,2));" - OK is 23000 as expected" ? ChrToInt(IntToChr(23000000,4));" - OK is 23 million as expected" ? ChrToInt(IntToChr(23,4));" - Bad is 0 - should be 23" a$=IntToChr(23,4) ? ChrToInt(a$); " - but is OK when putting intermediate value in a variable" End Sub Tst Regards, Phil |
||||
Geoffg![]() Guru ![]() Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Thanks Phil, I will look into them and report back. BTW many years ago when I was a kid I had a friend called Philip but his younger brother could not pronounce that and it came out as "flip". After a while that became Philip's nickname amongst all his friends. Did something like that happen to you? Geoff Geoff Graham - http://geoffg.net |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |