Epiphany BASIC

[polas]

[aolofsson]

Nick,

I absolutely love it!! Anything that can reduce the barrier to entry for programming the epiphany is HUGE!!
I have never used BASIC but I am sure this will bring back memories for a lot of folks.
Do you have a summary table of the difference in your dialect versus "regular" BASIC?

Andreas

[stingraze]

Thank you Nick! I will try it out from now!

[polas]

Thanks guys, yes the idea was to lower the barrier to running code on the Epiphany as much as possible - and BASIC is so simple which also means that it keeps the code size small too.

The HTML of the documentation is at which is a very short, simple walk through with examples but I think illustrates how easy it is to get code written with it. There is no real BASIC standard, so I have adopted an approach that keeps the simplicity and familiarity but with some modern thinking too - it can be thought of as a scripting language really.

The way it works is that it uses lex and yacc on the host to do the lexing & parsing and effectively builds up a byte code representation of the user's code which is then put on each core and executed by them,. Therefore it is trivial to change the language, as it is mainly just a parser change so it should be very possible to keep the same code base for other more modern languages such as python.

If I get the time this weekend I will write a more complete, traditional, HPC example rather than the toy codes that are currently in the repo.

Cheers,
NIck

[mikebell]

[polas]

[dar]

Nick,

This looks cool. Just saw it connected to latest blog post. As I understand you have the custom byte code interpreter running on the cores. Just curious. How much program space does it use, or conversely how much of the 32KB is free for data and stack. Just curious. Thanks.

-DAR

[polas]

Hi Dar,

Yes you are right - it does the lexing and parsing on the host, translating to a byte code representation which is put onto the cores and interpreted on there (along with symbol table etc...) The reason I adopted this approach is because I wanted to use lex & yacc (rather than having to write my own parser) and there is no way that the generated code & library requirements would fit into the memory per core. I think the added advantage of this is that much of the back-end can be trivially reused for other languages - I was thinking about supporting a simple subset of Python which would require mainly changes to the tokens and grammar.

In terms of your question, the simple answer is I don't know (and not entirely sure how to determine it either.) Everything (symbol table, byte code, data area etc) is placed starting at 0x6000 and packed in, which seems to work ok. Additionally it is possible (via command line options and/or if the byte code reaches a certain size) to locate the byte code in the shared memory instead. Similarly for the data area (used for arrays), this can be on core or in shared memory and the sdim keyword (as opposed to dim) will locate an array in shared memory programatically. Obviously when locating these items in shared memory there is a performance penalty, but the interpreter isn't particularly fast in the first place so it doesn't really matter.

I am currently extending eBASIC (which is limited by my free time) to support hybrid execution of codes across both the cores and host ARM processor.

Cheers,
Nick

[dar]

Nick,

Thanks. Design choices sound reasonable. Lex/yacc is how I would have tried to implement BASIC.

So if you put byte code, etc., at 0x6000 then does the interpreter itself reside in lower memory? I was just curious how large the interpreter was, roughly.

Interesting project. I am interested in various applications of dynamic binary translation with Epiphany, so your use of byte code interpreter, I find that to be interesting. Its sort of related conceptually. Thanks for the info.

-DAR

[polas]