Epiphany BASIC

Forum for anything not suitable for the other forums.

Epiphany BASIC

Postby polas » Fri Mar 06, 2015 7:01 pm

I have developed a dialect of BASIC and interpreter for the Epiphany. It is called Epiphany BASIC and the aim is for a novice to be able to get some code up and running on the Epiphany cores in less than a minute and get results immediately. The interpreter, code and data all reside on the cores, running independently from each other. A simple dialect of BASIC has been extended with some parallelism support (core to core messaging, broadcasting data, reductions, synchronisation and access to coreid) so that cores can communicate and parallelism managed message passing style. There is also support for some functionality not directly available on the Epiphany (such as IO) where core(s) will instruct the host to undertake any necessary actions.

Lots of the users of the Parallella will not necessarily be programming experts and there are quite a few bits to think when even writing simple codes for the device in C. The aim of the language is to be a zero barrier to entry educational/fast prototyping tool which people can use to learn about parallelism and parallel algorithms in general or to quickly try their code on the Epiphany.

The current version is in GitHub at https://github.com/mesham/ebasic, which also contains documentation and examples in the docs folder (the README describes how to make and run it.)

For instance, hello world is:
Code: Select all
print "Hello world from core "+coreid


To broadcast a random number (0 to 100 due the modulo) from core 0 to all the others and display it:
Code: Select all
bcast random%100 from 0 into a
print "Random number from 0 on core "+coreid+" is "+a


There are a few command line options for overriding defaults (also documented) such as running on a subset of the cores, to place the user's code/data in shared memory and to report timing information on completion. For instance, it is quite interesting to see the timing difference between runs when code/data is in core local memory (as default) and when it is overridden to live in shared memory.

Whilst I think it is quite usable in its current state, I have a few things in mind that I want to add. So please let me know if you find any bugs or have any ideas how the language might be further extended.

Cheers,
Nick
polas
 
Posts: 46
Joined: Thu Mar 05, 2015 9:41 pm

Re: Epiphany BASIC

Postby aolofsson » Fri Mar 06, 2015 10:22 pm

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. :D
Do you have a summary table of the difference in your dialect versus "regular" BASIC?

Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: Epiphany BASIC

Postby stingraze » Fri Mar 06, 2015 11:37 pm

Thank you Nick! I will try it out from now!
stingraze
 
Posts: 6
Joined: Mon Oct 27, 2014 11:36 am
Location: Japan

Re: Epiphany BASIC

Postby polas » Sat Mar 07, 2015 12:14 am

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 http://htmlpreview.github.io/?https://raw.githubusercontent.com/mesham/ebasic/master/docs/documentation.html 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
polas
 
Posts: 46
Joined: Thu Mar 05, 2015 9:41 pm

Re: Epiphany BASIC

Postby mikebell » Sat Mar 07, 2015 9:51 am

This is great :)

I put together a quick program to display the mandelbrot set:
Code: Select all
outstr=""

x=-2.0
y=-1.0 + (coreid*0.125)

for i=0 to 66
  re = x
  x = x + 0.05
  im = y
  for j=0 to 20
    re = re*re - im*im + x
    im = 2*re*im + y
  next
  if re*re + im*im < 4.0 then
    outstr = outstr+"#"
  else
    outstr = outstr+" "
  end if
next

sync
for i=0 to 15
  if coreid=i then
    print outstr
  end if
next


This seems to nearly work, but I get inconsistent output and it sometimes hangs. I realise the method of trying to order the core output is not ideal, but I tried passing a signal along from core to core but that seemed even less reliable.

Do you see the same problems?

Also one minor bug - comparing float and int doesn't work as expected (hence the 4.0 instead of 4 in that program).

Cheers, Mike
mikebell
 
Posts: 41
Joined: Thu Jan 08, 2015 9:46 pm

Re: Epiphany BASIC

Postby polas » Sat Mar 07, 2015 6:53 pm

Hi Mike,

Thanks for the feedback - wrt Mandlebrot, that's great you have put it together, I will take a look and figure out why you are seeing what you are. To be honest all the testing I have done so far is with small toy examples, so now I am going to do some more HPCesk examples (Jacobi, red black SOR and dart board method for pi are my first targets.)

In terms of the signal from core to core, all communications are blocking so I wonder if you are falling fowl of a wait somewhere? For instance the following code works on my Parallella, but I had to be careful with the send and recvs.

Code: Select all
a=0
if coreid > 0 then
recv a from coreid-1
end if
if coreid < 15 then
send a+coreid to coreid+1
else
print "Accumulated value is "+(a+coreid)
end if


Cheers,
Nick
polas
 
Posts: 46
Joined: Thu Mar 05, 2015 9:41 pm

Re: Epiphany BASIC

Postby dar » Mon May 25, 2015 1:18 pm

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
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: Epiphany BASIC

Postby polas » Wed May 27, 2015 12:31 pm

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
polas
 
Posts: 46
Joined: Thu Mar 05, 2015 9:41 pm

Re: Epiphany BASIC

Postby dar » Wed May 27, 2015 1:03 pm

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
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: Epiphany BASIC

Postby polas » Wed May 27, 2015 2:09 pm

dar wrote: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.


Yes, although 0x6000 is arbitrary and I think this could be decreased. Interesting I used some switch & case statements initially and compared to if-else this made for a larger binary file.

Cheers,
Nick
polas
 
Posts: 46
Joined: Thu Mar 05, 2015 9:41 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 10 guests