 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 : Idle thought about MMbasic
Page 1 of 2   |
|||||
| Author | Message | ||||
| BrianP Senior Member  Joined: 30/03/2017 Location: AustraliaPosts: 292 |
If this has been dealt with in the past I do apologise... How feasible would it be / is it to create a compiler to convert an MMbasic program to machine code. Something like what could be done with a dBase program - convert it to a compiled executable which ran really fast. I guess it would need to be PIC specific, but would make a really neat addition to the MM world. Just thinking... B |
||||
Turbo46 Guru  Joined: 24/12/2017 Location: AustraliaPosts: 1593 |
Mmmm. That would be nice. Someone has said that they are going to attempt that but there have been no reports of any progress. Bill Keep safe. Live long and prosper. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
I hate to mention something of a competitor on here, but it's perfectly feasible to write a BASIC compiler to native PIC code, with assembler & linker all in BASIC. That's been done with GCBasic. I'm not saying it was easy though. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Just to reiterate - I was suggesting something that you would use to compile a finished MMBasic program to an executable that would run on the same platform. This could possibly remove the need for c-functions? It wasn't intended to produce something that would run on a different platform, i.e. Windows. Back in the day I found that being able to create a compiled executable from the current dBase code was very useful. It ran much faster than in the dBase interpreted environment & was immune from users being able to modify the code. My thought was that apart from producing a much smaller code than than the native basic program it would run so much faster & be more immune from corruption in the working environment. To create such a compiler would obviously need the expertise of someone familiar with the PIC environment, like GeoffG or PeterM. There could well be a commercial opportunity in such a product. As I said, just thinking... B |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
My point was that you could scan the BASIC prior to uploading to the PIC and compile it on the PC - not run it on the PC. It *may* be possible to write that compiler in BASIC - a language that most of us are more familiar with. The process would be similar to the way GCBasic (which was also written in BASIC) works - producing an assembler listing from the BASIC (possibly from the ASCII file rather than the BASIC tokens), linking in libraries where needed then compiling to PIC native code which can be uploaded. The resulting code would probably look similar to the output of GCBasic, as it would be compiled for more or less the same target. I don't think it would be possible to have the Micromite firmware, BASIC program, compiler, libraries (although some of those might conceivably be bits of the firmware called directly) and target code all on the PIC at the same time, even without an intermediate assembly listing. I suppose, if you could, then the final stage would be to change the start address to point to the compiled code so that it would auto-run. You've lost all Micromite control at that point though, along with all its advantages. Whether the PIC native code has a huge speed advantage over compiled BASIC is something else. Yes, it's obviously much, much faster but do you really need to sit in faster loops waiting for things to happen? The speed of the display is another bottleneck. On the whole I think the current system of adding c-functions where necessary is pretty good, although I'm certainly no fan of C. Good mind games though... :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
An interesting in-between solution is the Bypic. No longer being developed but the hex file is free. Not quite as friendly as MM and a sort of mix of BASIC/C/FORTH. It runs on the MX170/MX370 and is interactive. The 40MHz MX170 executes code ~300% faster than the ARMMITE H7 @480MHz. A past member of this forum, loaded it up in a MM-Basic product and it ran just fine. The developer retired, a couple of years ago. I posted the benchmark results in this benchmark thread. Benchmark Edited 2019-11-23 20:12 by Tinine |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Thank you gentlemen for your mind games musings  My thought on having a compiled program for the 'Mite was that as well as faster execution you could fit in a much larger program (or am I dreaming). Scenario would be something like: 1. Develop your MMBasic program on the 'Mite up to the limits of memory - deliberately minimising arrays dimensions to keep more program memory available when testing. 2. When testing complete then dimension our arrays to the required values. 3. Transfer program to compiler machine & compile to produce what should be a much smaller executable to run on the 'Mite. Probably very much over simplified, & something major overlooked. I did say it was an idle thought, but once a thought becomes not idle who knows what might eventuate? And I do like the fact that the end user is presented with a system that can't be changed (deliberately or otherwise). Cheers B |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
You guys seem to be suggesting a "P" code or object code tokenized interpreter rather than a full fledged compiler. A real compiler, like Watcom C or IBM COBOL, writes intermediate tokenized "Pre-compiled" object code which consists of calls to assembled or compiled routines in a linkable library. A separate linker then reads the tokenized "P" object code, adds the needed executable routines from the link libraries and packs it all into an executable file. The size of the resultant executable depends on the linker to only include the routines from the library which are actually needed and on the granularity of the linkable library. Gadgets like Visual Foxbase take an ASCII text file and translate it to tokenized "P" object code and then link it, at run time, to a complete library of executable code which exists in the Foxbase runtime library which may be either in a separate file or in the runtime P code interpreter. There is no opportunity to selectively link in only the required executable code from the library -- the entire library must be loaded in one piece. Geoff may tell me I'm all wet, but I believe that MMBasic translates the ASCII text file you provide into tokenized "P" code when it is loaded and links it, at run time, to the complete library of executable code which exists in the MMBasic executable. In other words, MMBasic is already a "P" code interpreter. It might be possible to split the MMBasic library and run time linker into a separate program, then add code to the main interpreter to write the user program out in unreadable tokenized "P" code form as an object file. The MMBasic runtime would then read the tokenized object code and run it while resolving library links at runtime, however, the entire executable library would still have to be loaded. There would be no opportunity to leave behind sections of the library which would not be needed by the individual user program. The resultant interpreter would be a little larger than the current MMBasic interpreter executable because of the added code to write the tokenized "P" code to an object file. The resultant combination of the runtime linker and the P code object file would be a little smaller than the current MMBasic interpeter plus the loaded user program. It may, therefore, be possible to run slightly larger programs. The combination of the MMBasic runtime and the P code object file would not necessarily run very much faster than the current combination of the full interpreter plus the user program since the run time linking within MMBasic is already VERY fast, and the tokenization of the user ASCII file takes place at user program load time before the user program is actually run so the tokenization does not slow the execution down. The advantage in the slightly larger maximum size of the user program, in most cases, could be largely offset by clean, tight user programming habits, which usually make the program less readable. Jim's excellent MMedit program can help a lot by eliminating blank lines, leading spaces and remarks. The individual programmer could help by pre-processing individual code by cryptically shortening variable names to the absolute minimum number of characters, being carefully not to turn variable names into MMBasic reserved words. However, the resultant individually pre-processed or "P" code would be extremely difficult to read! Overall, I believe that splitting MMBasic into a two step "P"re-processor tokenizer writing an object code file then using a runtime liker/library to load the tokenized object file and run it would not be a good use of time. The real key to generating the smallest possible executable would be in re-writing the executable library so that a linker would be able to incorporate only the individually required code in the final executable. This would be an enormous task! Perhaps we should cooperatively attempt to write a real CRUNCH.EXE program. Jim's excellent MMedit program can already build a report of the variables found in an ASCII program file. It might be possible to use this variable table to replace all variable names with minimum length cryptic names. Paul in NY |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
I believe it was KeepIS who recently realised the huge time-saving of a literal pin number, compared with a CONST. I responded with a one-liner that suggested a pre-processor that could use a xref to run through the text, replacing the CONSTs with literals. This could also replace descriptive variables with truncated equivalents. Cheers, Craig |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
CONST is always going to run slower as it needs a lookup before it can be processed. For speed you almost always have to sacrifice space in BASIC, so inline routines rather than GOSUB or CALL will be noticeably quicker, especially if they are in a loop. At one time it was a good idea to stick to integer maths too, but with on-chip FP handling this is less of an issue now. Like Paul, I also suspect that MMBasic is using P code. I don't think it would be this fast if it was merely tokenised as parsing a line takes too long. As for program protection, IIRC there is a flag on all PIC chips especially for this. It only needs to be set on the final upload of the program doesn't it? Have I missed something about this? Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8573 |
MMBasic does not use P-Code. When you type RUN the only things tokenised are the in-built commands, functions and operators. In addition a table of user functions is built. All user variables etc. are left as ASCII text. The interpreter reads the lines character by character and "interprets" them. When it finds a variable it does a sequential search through the current list of variables to find the value. If the variable does not already exist it creates it (except arrays and except when OPTION EXPLICIT is set). This is why using short variable names is faster as they are easier to match. In addition the match does a pre-filtering on the first character so avoiding lots of variables starting "myvar" etc. will speed things up. Literals can be faster because there is no lookup just an ascii to binary conversion. Not sure if this would always be true for floating point literals as the conversion is more complex. MMBasic is probably not as fast as some other interpreters but they won't match its power in correctly resolving complex multi-bracketed expressions with user functions and proper parameter passing on 64-bit integers and full floating point numbers - compare the ultra-limited Basic on the PICAXE MMBasic could also probably be made faster by using variable hash tables etc. but this would risk destabilising code which is extraordinarily robust and there is always the option with MMBasic of using a faster processor if speed is really an issue. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5710 |
I'm even more impressed now! :) I thought a straightforward interpreter would have been a lot slower. It says a lot for the efficiency of MMBasic and the integration with the PIC hardware. IMHO a compiler would be interesting, but it sort of breaks the elegant, interactive beauty of the Micromite system. There are already compilers for the PIC. Even the code protection aspect is a bit of a no-no for me. Mind you, I'm not interested in selling anything that might require it. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
I love the fact that this is an interpreter. I have been using megabuck big-name controllers for many years and they also have a very crude form (one data type) of BASIC-like interpreter. The previous generation only executed one instruction per millisecond but was still fast enough for process control. My entire state-machine loop runs seven times in one millisecond on the 100MHz E100 and now I am moving to the H7. The deterministic stuff runs on co-processors on a RS422 bus but any tweaks there are purely parametric. Having MM-Basic run the show is making life very easy indeed. I have big plans for the ultra-amazing new Parallax P2 processor but it will still be managed by this BASIC interpreter. Cheers, Craig. |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
I think I'm beginning to see that we don't want / need to mess with the already brilliant MMBasic environment. When I originally posted this thread I was having a trip to by-gone days when one had to make the very most out of the processors of the time (circa 1970s). I was having all sorts of difficulty in writing dBase code to work productively on the then just new Pentium CPUs. The disk I/O speed was an issue as well. That is why I was a big fan of the dBase compiled environment - you could really notice the difference. Perhaps I do need to embrace the modern world a bit more... My biggest frustration currently is that because I spend a lot of time sorting clients' Windows issues I have little time to spend on my first love - micros. I really had a buzz porting an Apple II basic school timetable program to a Commodore 128. It really did work, but garbage collection of memory was a major issue & took ages. On the subject of garbage collection, is this an issue in MMBasic? If not, why not? More idle thought... B |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Well Peter, I guess we speak different languages sometimes ... or, what is more likely, I don't explain myself adequately. To me, "P" code, or partially pre-processed code, refers to tokenizing the reserved words, (commands, operators and internal functions), of the language. It does not generate a full fledged object file where the user defined variable memory locations are mapped before linking and running. From your description that seems to be exactly the architecture that Geoff devised. It gets you sort of half way to a fully defined object file. As you say, the salient fact is that MMBasic is EXTRAORDINARILY ROBUST and STABLE as it is. If it ain't broke don't fix it!!! If you need more space or more speed then shorten your user defined variable names and avoid using the same first letter for the majority of your variables out of habit, thus, my suggestion to pre-proccess the user ASCII code more radically than MMedit does. If you then still need more space or speed then wait a few days and some foundry or other will provide a more powerful chip at an even lower price. As to the PICAXE basic I do not consider it a high level language since it requires you to map user named variables to memory locations. I think of it as a super-assembler dressed up with BASIC like syntax. Hey Brian, you're almost as old as I! The basket case in terms of garbage collection was the IBM 1401 Autocoder assembler (circa 1956???)! It needed many repetitive compile .. link .. compile .. link sequences (all using punched tape or Hollerith cards) to produce a clean memory map. It was usually using a 8K word (6 bit words) magnetic memory core and runtime garbage collection was impossible. (Gary Mokotoff, coauthor of Autocoder, recently donated copies of his SPS-1, SPS-2 and Autocoder source code to the Charles Babbage Institute, University of Minnesota.) As to garbage collection in MMBasic I'll let Geoff or Peter comment. I really don't know how MMBasic accomplishes it but I've never seen any observable hiccups in a running program. Paul in NY |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
No, MMBasic does not need a garbage collection routine for two reasons. Firstly MMBasic makes extensive use of a temporary memory allocation scheme which only lasts for the length of the command. For example, an expression such as IF A$ + B$ = C$ THEN ... would temporarily allocate memory for the result of concatenating A$ and B$ but that memory would be automatically recovered at the end of the command. I suppose that it is a garbage collection of sorts but very simple. There are some commands which need memory for longer (such as an open serial COM port) but these are limited and I play very close attention to them to make sure that they are not responsible for memory leaks. The bottom line is that there are no memory leaks and no need for a full scale garbage collection scheme. I have one Micromite that is part of a burglar alarm and it has been running perfectly for five years without a reboot - something that you could not say for a more sophisticated system (such as Windows). Geoff Edited 2019-11-25 16:16 by Geoffg Geoff Graham - http://geoffg.net |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Sooo true  Thanks Geoff - makes a lot of sense. Just goes to show the value of a well thought out & carefully tested codebase. Microsoft sure has a lot to learn. Paul_L said: "Hey Brian, you're almost as old as I!" Yeah - must be pretty close. Grumpy too...  B |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Probably mentioned this before but my E100-based CNC Tube bender is sat right next to a megabuck Trumpf laser (sheet-metal cutter). The Trumpf has a Siemens CNC with a Windows front-end. The machine requires a "Microsoft Reset" (power-down/up) "at least 5 times/week"....and they only work a 4-day week [Trumpf Response]: "It is a problem with the Profibus but we are unsure if it is the PC side or the CNC side....this issue is normal for this machine". E100? Not a single glitch. The front-end is a Android tablet, connected via Bluetooth. They carry the tablet, out-of-range, to program it in the comfort of the office, while the bender is still making parts. They bring it back in to range, hit the "Update Machine" button and they are now making a different product. Just because it has a big name and huge marketing budget, doesn't make it a great product. Engineers who get suckered in to this stuff, remind me of the people who queue all-night for the latest iPhone  |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 375 |
Maybe try glbpp, I don't know much about it Edited 2019-11-29 05:33 by zeitfest |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 375 |
In general I think the glbpp original utility was to translate basic to C, which was then compiled, assembled, linked etc as usual. So I guess theoretically much of MMBasic could be be mapped using elements of glbpp basic, the utility could be used as a preprocessor and the resulting C processed ( ed - to microchip pic machine code) in the normal way. The MPLAB IDE originally incorporated GNU C and associated assembler etc. With a bit of luck it could all be operated from MPLAB...but it would be a lot of work to get it going, risky, incomplete, and little to gain. Edited 2019-11-29 09:03 by zeitfest |
||||
| Page 1 of 2 |
|||||
 Print this page |
