Anyone here ever written there own BASIC interpreter?

Brietech

Senior Member
Anyone think it's possible to write a sort of "meta-BASIC" interpreter using the picaxe "native" basic? I know I and hippy have both made assembly-like "meta-languages", but the 28X-1, with its 4k of program memory, makes me think this would be really possible (and hey, the 08M only has 32 BASIC instructions, i think!). So anyway, has anyone here ever written a simple basic interpreter? I'm looking for advice (particularly in implementing things like For-loops and such).
 

Jeremy Leach

Senior Member
Hi

What are you really trying to do? Are you going to create an application where you can write code in your own 'super high level picaxe language' and the app 'compiles' this language into normal Picaxe Basic?

Or a high-level interpreted tokenised language that just calls pre-defined subroutines?

I've always wanted to invent a name for a language, so my offering is 'SPLAT' ...
Simple
Picaxe
Language
to Allieviate
Toil

<img src="wink.gif" width=15 height=15 align=middle>

Damn ...someone beat me to it <A href='http://www.cs.utexas.edu/users/qr/robotics/splat/' Target=_Blank>External Web Link</a>

Edited by - jeremy leach on 13/07/2007 10:16:16
 

Michael 2727

Senior Member
Jeremy you can't use SPLAT, there is a SPLAT brand of Microcontroller here in OZ.
They may not be that common but have been in use here for a decade or so.
 

GKCS

New Member
Basic for the SX28, mhmhmhmhmh, just call it SX/B and download it from Parallax's website for free ....

G-)
 

Brietech

Senior Member
Jeremy - The latter, I believe. Hippy and I have already created &quot;meta-languages&quot; by writing an interpreter for an assembly-like language IN picaxe BASIC, so that way the picaxe can run programs in our languages off of i2c memory chips (the main reason - allows unlimited program length). I would love a full-on BASIC interpreter written IN picaxe BASIC though, as writing programs in assembly can get tedious quickly. I've never written an interpreter that really had to implement stacks and things (for looping and such), though, so I was wondering if anyone here ever had.
 

hippy

Technical Support
Staff member
One could write an interpreter for PICAXE tokenised code in PICAXE Basic but it would be awfully slow. It would be possible to write an interpreter which used a modified version of the tokenised code which was more friendly for execution speed.

In the sense of how the ZX80's, Ataris and so on did it, by storing the source ( or a compacted version of it ) and interpreted that, then it's possible but involved. It would probably need a 28X1 to deliver the capabilities of an 08.

As to the fastest Basic interpreter, there are so many factors that it makes comparison hard. The main are tokenised code format, native microcontroller instruction set and CPU hardware.

PICAXE's have bit-aligned, varying length tokens which maximises code space ( generally, but some design decisions undermined that in places, but back on track for the X1 ); that increases the time to fetch, decode and execute tokens. A different tokenised format would improve execution speed but reduce maximum program size, so one cannot compare like with like. I believe that using tokens in multiples of 4-bits and careful design would allow programs of nearly the same size and improve execution speed.

For fastest on a PICmicro executing the PICAXE tokenised code without change, I believe Rev-Ed are quite close to the maximum they could be. Without the constraints of Firmware size, execution speed can, I believe, be improved further and there are tricks which can optimise particular things, especially RETURN time.

If the PICAXE used hardware which included an ALU 'barrel shifter' that would give a very noticeable speed improvement. The X2's using 18F's will bring speed improvements through a better native instruction set, something based on the dsPIC30F would zing along.

Optimising Firmware may save a few cycles here or there but the big gains come from simply running the chip faster. The X2 can run ten times faster than a PICAXE at 4MHz, and another way to look at that is, a PICAXE command takes only 25 times longer than a native instruction would to do the same job at 4MHz.
 

demonicpicaxeguy

Senior Member
i haven't looked at it with any degree of seriousness but
how many instructions does it take to readout a byte from an i2c eeprom vs program memmory?

is the external memmory any quicker?
it'd be nice to see a picaxe that reads code off a 24lc256
 

hippy

Technical Support
Staff member
As posts are crossing -

Brietech : Stacks are very easy to do -<code><pre><font size=2 face='Courier'> Symbol sp = b13
Symbol STACK = $50

InitStack:
sp = STACK-1
Return

PushB0ToStack:
sp = sp + 1
Poke sp, b0
Return

PopB0FromStack:
Peek sp, b0
sp = sp-1
Return </font></pre></code> Stack underflow and overflow is easy to add. A stack based machine is also easy to implement ...<code><pre><font size=2 face='Courier'>Add:
Gosub PopB0FromStack
b1 = b0
Gosub PopB0FromStack
b0 = b0 + b1
Gosub PushB0ToStack
Return </font></pre></code> The biggest problem for a PICAXE is that 256 GOSUB's soon turns out to not be a lot. The two Pops of that above Add will be common for all binary operators and comparisons so a single subroutine can replace those, reduce program size, reduce Gosub calls, but it does then add extra execution time. It's a never ending battle of balance. The conclusion you should come to is that PICAXE is not the most suitable tool for the job :)

For ideas on how a program can be stored and interpreted it's worthwhile looking at the sites of people who did get deep into pre-PC computer hacking and detail exactly how their firmware worked. <A href='http://www.ncus.org.uk/fmay98.htm' Target=_Blank>External Web Link</a> is a good starting point.

DPG: Executing from external I2C is slower than from internal Eeprom/Flash. I've no idea by how much, but for an internal read it's a simple case of just loading two address SFR's, setting a flag and reading the result, around 10uS at 4MHz.

With 40MHz operating speeds there's an argument to allowing 64KB or larger code sizes externally with extra overhead without much loss of interpretation speed but this makes the Firmware much more complex and there would have to be radical design changes to make it useful. I expect the conclusion is that it would not be worthwhile, with little return on investment.

I'd much rather see development go towards PIC24 and dsPIC's which will double native execution speed over the X2, trim loads off the interpreter speed, and these have up to 128KB Flash, which is plenty for Firmware and user Code. Hobby-unfriendly chip packaging isn't a problem if delivered on DIP PCB's, even if not all chip legs are bought off board.
 

Jeremy Leach

Senior Member
Going off track, but one tiny idea that might be interesting - an 08M paired with a 24LC256. 08M with a VERY reduced instruction set, running 'tokens' on the EEPROM. What interests me is the huge program memory for what is a 16-pin solution. With a carefully chosen small set of instructions it might be possible to get some powerful (but probably slow) results.

CORRECTION : Er...except for the fact that the 08M doesn't support i2C <img src="wink.gif" width=15 height=15 align=middle>

Edited by - jeremy leach on 13/07/2007 15:24:36
 

hippy

Technical Support
Staff member
It's not really going off-track, but back towards Brietech's original interpreter.

I've frequently used this technique in micro and PC applications and it's basically 'scripting' but using something more suited to the task and my coding.

It's a trick which is well worth learning and has many applications. My solution to the recent discussion on emulating lighthouse light flashing was effectively an emulator/interpreter which had a minimal instruction set and could run multiple 'lighthouse programs' ( <A href='http://homepage.ntlworld.com/the.happy.hippy/picaxe/flashing.txt' Target=_Blank>External Web Link</a> ).

In the Good Old Days (TM) many CPU's had a microcode engine which was effectively an interpreter for the instruction set the user gets to use. That was a very high-speed, finely tuned interpreter which moved registers about and altered them based on whether bits were set or not. Very simple but powerful. Game Console Emulators use the same trick except the 6502 ( or whatever ) instruction set is implemented in software native to the PC it runs on.

It can soon get mind-blowing; a microcode interpreter for the native instruction set, which runs an emulator interpreting the 6502 instruction set, which runs an interpreter which interprets Basic commands, which is a user program which itself is interpreting some other instruction set.

They key is the bottom level; the faster it goes the faster the top end runs. Every level might give a 100 fold or more decrease in speed.
 

demonicpicaxeguy

Senior Member
yes don't drool on the keyboard


the pic24's and the dsp pics are somting i was looking at to stick an interpreter into
the sx's come to mind as they can run at 75mhz!
haven't given this one much thought but what about a basic interpreter for the arm processor?

also with external memmory what about some kind of highspeed parallel ram or rom chip eg somthing like the 684000 by hitachi it's data transfer is done by parallel so you'd be sacrificing at least 20 odd pins just for that , but if you used a high pin cound pic it wouldn't be so much as a problem it's got a 30ns access time moving data in and out by parallel might be just as quick as reading it's own program memmory

spelling fixed by - demonicpicaxeguy on 13/07/2007 23:02:57

Edited by - demonicpicaxeguy on 13/07/2007 23:03:41

Edited by - demonicpicaxeguy on 14/07/2007 00:37:36
 

Brietech

Senior Member
there is a chip with a basic interpreter an an ARM already, i think, from a company called NetMedia (www.basicx.com). I actually have one that someone gave me for free, and I haven't gotten a chance to use it yet. The specs for it show 83,000 Instructions/second (vs. something like 2-8,000 for the picaxe)!!!! I really should put that to use, but I like the challenge of cramming stuff into a picaxe.
 

hippy

Technical Support
Staff member
Is there a compelling reason for any external memory when there are top-end PICmicro's with 256KB Flash and 30KB RAM ? I'd much rather pay the price and not have to find and wire-up another device. That PICAXE is single-chip is a major selling feature. With it all on a DIP carrier I suppose it wouldn't matter.

AVR's I haven't touched since AT90S1200; are they as robust I/O-wise as PICmicro's ? That I've seen pure software bit-banged USB and Ethernet proofs of concept impressed me and shows what a well designed, high-speed chip can deliver.

With ARM the potential for very high speeds is appealing, but perhaps at a price. No idea of how they stack up I/O-wise or on the on-chip peripheral front.

There's always the ASIC route, multiple PICmicro cores etc on a chip as per Propeller.

For Rev-Ed I'd expect the obvious course to be up the PICmicro path, because of their knowledge base and the ease of porting code. If it's Assembler then there's a long haul in re-coding and a lot of learning how new instruction sets and peripherals work.

Where I'd really like to see PICAXE going is not only more capacity but Ethernet and USB with simple commands to interact with both ). I think that's a market waiting to be hit there.
 

hippy

Technical Support
Staff member
The ARM with Basic ( Compiler ) is probably the Coridium - http://www.coridiumcorp.com ( <A href='http://www.coridiumcorp.com/' Target=_Blank>External Web Link</a> )
 

Brietech

Senior Member
If I need raw-processing power, I could always go with my own IC =) I finally taught myself Verilog, so I was able to make a 16-bit CPU that chugs along at a blistering 100 Mhz in my Spartan3 board! It's also got about 64 I/O pins I think. My motivation for doing the interpreter-in-a-picaxe thing was mostly out of laziness on my part. Coding complex things in assembly gets to be a hassle quickly, not to mention the serial port in my laptop can't power my PIC programmer, and I'm stuck with just that 'till the end of summer. Since it's just one of those &quot;for-fun&quot; projects, I don't really mind if it is slow. It would just be fun to see it working.
 

demonicpicaxeguy

Senior Member
if rev-ed were to picaxe an sx chip that would make a nice mess of the parallax forum
although i might have a look at the two instruction sets side bye side and see how hard/easy it would be to write my half finished interpreter in sx asm

one thing that has me stumped with the interpreter that i'm doing is that implementing a simple &quot;poke&quot; command (where you specify a register and new value for it) in pic asm is stumping me slightly, might just be the wild turkey :)
 

hippy

Technical Support
Staff member
I hadn't realised SX reached end of life at Ubicom (Scenix) and is now only available through Parallax ( <A href='http://www.ubicom.com/processors/sx/sx_obsolescence_notice.html' Target=_Blank>External Web Link</a> ). The range available is quite limited; 2K/4K Flash, 136/262 RAM. On the grounds there are PICmicro's with much more I'd skip the SX as an opportunity missed.

Poke for PICmicro should be very easy. For your interpreter, get the address to poke to FSR, get the value to write to W, move W to INDF. Finito. You probably have to preserve FSR while getting the value to write, and if poking using variables, you have to put the variable's address to FSR and read INDF to get their contents.
 

Tom2000

Senior Member
<i>I hadn't realised SX reached end of life at Ubicom (Scenix) and is now only available through Parallax ( External Web Link ). The range available is quite limited; 2K/4K Flash, 136/262 RAM. On the grounds there are PICmicro's with much more I'd skip the SX as an opportunity missed. </i>

Agreed. The SX line showed great promise at one time. (Before the lawsuit?) But has virtually died since. I have the sense that Parallax isn't going to be doing much development in that line. (I don't even know if they have the rights to do so.)

Me? I'm more interested in the PIC 24 and dsPIC line. Matter of fact, my 4-year-old old serial Easy ICD2 programmer just packed it up a couple of nights ago. I ordered a fancy new USB version that supports the dsPIC line (which my old one didn't). I'm planning to explore the dsPIC family with the new hardware.

There is absolutely amazing potential hiding within that line, which opens to door to potential projects that I wouldn't have considered implementing on a microcontroller before now.

Tom
 

demonicpicaxeguy

Senior Member
i thought the sx chips we're a more recent devlopment
the old 8051's are interesting though because they seem to be used in some of the rf transciever chips and a few others

i'll give that a go in the morning and see how it goes
 

Brietech

Senior Member
the website appears to be down now, but someone built a &quot;cluster&quot; of something like 16 dsPIC's, all on one board. They were supposed to be capable of something like 30 MIPS each, although I don't think the guy wrote any software for it.
 

hippy

Technical Support
Staff member
Having dissed the notion of external memory, I'm starting to be swayed in that direction, at least for some scenarios.

Slow processors need their code/data ready to execute quickly, faster processors can get their code/data slower and still have the same throughput. With large memory and speed it doesn't matter if the instruction set is minimal, inefficient and therefore slow when a lot needs to be done to achieve a simple task.

I'm not keen on parallel devices tying up lots of I/O, but large SPI Eeproms would not be so bad. Parallel would boost throughput but I'm not sure by how much considering having to increment and set 'address ports' versus having set SPI for streaming reads; once setup, ask and a byte arrives. Only having to update the address on a Branch would be handy.

My thoughts now are - 28/40-pin DIP carrier so off-chip isn't a problem, 1Mb/4Mb SPI Eeprom to save I/O, small cheap PICAXE/processor/FPGA running an inefficient but fast instruction set.
 

Brietech

Senior Member
In the picaxe-arena, I was thinking about this: Using an 18X at 8 Mhz, and a 400 Khz I2C EEPROM, I was able to achieve about 256 Instructions/sec. Now, using a 28X-1, I can up the frequency to 16-20 Mhz no problem (I'm going to carry out some tests at 24 and 32 Mhz soon, too!), and using the new 1 Mhz I2C mode, that should also shave some time off. I could even toss in some caching now, if I'm feeling ambitious. Anyway, I think it could be reasonable to get 500-750 Instr/sec with a &quot;meta-language&quot; on a picaxe, which is quite useful for doing most tasks.
 

Jeremy Leach

Senior Member
I'll throw this in - as I've got a little concept formulating here that's intruiging me, relating to just an 08M:

On the 08M you can use the EEPROM statement and use up code space to store data. If I devised a VERY simple, reduced instruction set, and stored the 'program' as data, could I get more functionality out of an 08M than if I just used ordinary Picaxe Basic?

By <i>more functionality </i> I loosely mean that I can make the picaxe do more. Probably in a very narrow field of application.

I know it depends on a lot of factors but could be interesting. I'm thinking of the program being written in bits not bytes. The choice and implementation of the commands would be crucial. Perhaps use RAM as a variable store.

Just thinking...


Edited by - jeremy leach on 18/07/2007 14:52:07
 

BeanieBots

Moderator
I would have thought the opposite. ie reduced functionality. Maybe I've missed the plot here but my understanding is that the PICAXE (and therefore PICAXE BASIC) would be interpreting your 'program' and hence could only do whatever PICAXE basic can do. Using EXTERNAL ROM/RAM would mean you could do more of it (longer program) but I don't see how it could ever do anything a PICAXE could not already do.
 

hippy

Technical Support
Staff member
I think it depends on how one looks at it -

<i>Increased Functionality </i> in that the interpreted language is better tailored to the task, allows a complex construct to be represented or used more simply, or allows more to be done than otherwise.

<i>Same Functionality </i> in that you cannot get a PICAXE to do more than a PICAXE can do.

<i>Reduced Functionality </i> in that it will do it slower and requires tools to get the interpreted language into the PICAXE which probably don't exist.

I think there's a balance between a language conversion tool and a compiler/interpreter.

The former simply converts what the user wants to write into what they should have written. Should be no performance hit and that's offset by productivity gains.

The later are also about productivity gains; allowing one line commands to create the multiple instructions which are needed to do the job, thus simplifying the task.

Simplifying the task is what an interpreter is a tool for doing; presenting an abstract machine which is (hopefully) easier to code for and use.

Interpreters are really 'adventures' for people with a hobby, or a means of doing something with the tools one has when something different was needed. Their prime purpose is in extending functionality; for example letting a PICAXE have a 64MB program, but against that is set the loss of execution performance.
 

Jeremy Leach

Senior Member
Well, maybe I didn't explain clearly and maybe functionality isn't the best word.

My particular plot is that by writing programs in your own language you might be able to 'do more' than writing in picaxe basic. An extreme example might be that you could implement a floating-point algorithm on an 08M, whereas using picaxe basic you can't (or it's unlikely).

We're talking algorithms and finding the most efficient (in terms of bytes used) way of implementing them. I'm just saying that there might be a better custom language that could be designed to implement a particular algorithm. All a bit deep really, but it keeps me off the streets <img src="wink.gif" width=15 height=15 align=middle>

I think Hippy knows far better than me what I'm going on about !

It would be good if someone had a tough problem that they wanted to do with an 08M, but couldn't because of code space, and then we could see if this idea might offer a solution....only sensible suggestions accepted though!

I only say 08M because it's the extreme example.

Oh, and I'm assuming speed isn't a factor.

Edited by - jeremy leach on 18/07/2007 19:04:41
 

hippy

Technical Support
Staff member
In that respect you are correct, and with the right interpreter there's no reason you couldn't have ...<code><pre><font size=2 face='Courier'>EEPROM( &quot;A = 9.27&quot; )
EEPROM( &quot;B = SIN(A)&quot; )
EEPROM( &quot;PRINT A,B&quot; ) </font></pre></code>
 

Brietech

Senior Member
one possibility would be to combine an 18X and an EEPROM (up to 128 kilobytes), and fit it all into a 28-pin socket, and you could fit quite a decent &quot;meta-interpreter&quot;. I'm currently working on one that is more BASIC-like than assembly-like (maybe i will call it Assemblic!). Having 32 or 64 kilobytes of conveniently addressable RAM is a nice reason as well =)
 

demonicpicaxeguy

Senior Member
the main intention with my interpreter is to give the user access to as much of the chip capibilities as possible without taking up a great deal of space
however given the fact that i've only got 3 instructions (&quot;if&quot;,&quot;=&quot; and &quot;gto&quot;) i'm tempted to go the other way and write a simple compiler for it that compiles down to pic asm, i don't imagine it being too hard

i'll stick up the picaxe code version of the interpreter a bit later when i get my laptop back


Edited by - demonicpicaxeguy on 19/07/2007 06:35:01
 

Jeremy Leach

Senior Member
I think the picaxe is a brilliant development platform for trying all these ideas out. It's got me thinking about whacky ideas for custom interpreted languages, all testable on an 08M. For instance...

1. Why have just one program counter? Could have,say, 4 and cycling through them and executing the command at each location. Similar to multi-tasking but not quite.

2. Could store the program (or part of the program) in RAM not EEPROM and make the code self-modifying.

3. Code that runs backwards under certain conditions !

4. Could have very simple commands that chuck and mix data together in some complex, special way.

I haven't got any concrete ideas here and it might lead nowhere, but the way I look at it there are lots of ways to get very complex behaviour and patterns out of even an 08M - and out of that complexity might come some method that's unique and useful. I still think there's room for breakthrough ideas.


Edited by - jeremy leach on 19/07/2007 08:35:11
 
Top