Need help from Propeller "language" writters. (femtoBASIC, HydraBasic, etc.)
Microcontrolled
Posts: 2,461
I am writting a type of Propeller language and I need some help. It stores the written program in an EEPROM and then loads it into a buffer for examination. The help I need is: How do I compare keystrokes with code-words and how do I run the program once it is created?
ALL help is appreciated and other comments and hints are welcome! Thank You!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
ALL help is appreciated and other comments and hints are welcome! Thank You!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
Comments
The first thing you need if you don't want horrible performance is to abstract out page reading. As you crawl through the program a byte at a time figuring out what it does, you don't want to be initting the EEPROM and setting it up to read one byte every time you read a byte. Allocate yourself a page buffer (all the big EEPROMS you'd be using have 128 byte pages). Allocate yourself a byte to indicate which page is loaded, or a word if you want to remember that by address, and then make a routine that returns one byte at an absolute address -- but if it's from a page you've already loaded, have it read from the RAM buffer. If it's from a different page, have it load the new page then return the byte.
Now, with this getabyte tool, you'll crawl your program; the traditional name for the word that holds your pointer is the Program Counter or PC. The next trick you must teach the prop is called parsing, and you can do it with fairly simple code. It's a little different on the prop than other platforms because bytemove and strcomp are so much faster than spin that it's worth setting things up to use them -- but they require null terminated strings. So what you do is you allocate yourself a keyword buffer.
Create a routine I called SPSKIP when I reverse engineered Tiny Basic, which will increment the PC until it is pointing at a byte that is not white space.
Now let's say your PC is pointing at the start of a line. You call SPSKIP to find the start of the first keyword. Now you need a routine to transfer that keyword to your keyword buffer; you do that by loading and copying bytes (you can't use bytemove because you might cross a page boundary in getabyte) until you reach more white space, or something else like a math symbol that can't be part of a keyword. Now you copy a null at the next byte in your keyword buffer, and as the French say WA-LA, you got yourself a null terminated string. You can now use STRCOMP to successively compare the string @keywordbuf to all the possible keyword literals and if you find a match, go for it. This sounds horribly slow but STRCOMP is so fast that in Spin it works reasonably well. This is how I interpreted user commands in DOSCMD, which is in the obex if you want to look at some example code -- though in that case I null terminated the strings right in the buffer where they'd been collected as the user typed them in.
You will find some other utility routines useful. You should write one that blows through to the end of the current line, and another that blows past white space and finds anything BUT the end of a line. Using those, you'll want to write one that starts at the start of your program and finds a line -- blow to next line, take first keyword, see if it's a jump target, if it's the jump target you're looking for return otherwise keep going until you reach the end of the file.
Oh yeah, you need an end of file marker that's different from the end of line. Whenever you are processing a line you should always end by calling "blow through white space until I reach the end of the line," and if THAT routine finds the end of file instead it should abort or otherwise deal with the situation.
Good luck with your project; something like what you're trying to do is how I taught myself to program back around 1978. (It should be a lot easier in Spin than it was in 8080A assembly language.) You will eventually find that there is a bit of a mystery as to how to deal with math expresssions like (3 + 2 * 5) / 16, let me know if you want the hint there.
Also check out the FemtoBasic source; it's basically a port of Tiny Basic too, and while it interprets from RAM instead of EEPROM you'll note a few routines that load and blow past bytes as I've described. You can essentially replace these with equivalents that load and blow past bytes using your page at a time getabyte kernal, and just *cough* borrow the rest of the language kernal wholesale, replacing the keywords for commands, math functions, and operators as you wish.
Any more comments are appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
I'm sure all the ideas he show there in Pascal can be done in Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.