ideas for a BASIC compiler

I've started a BASIC compiler, first for PICs, but later I plan to use this
for ARM platforms, too. This is an example source code:

http://www.frank-buss.de/tmp/test.bas.txt

this is the generated assembler code:

http://www.frank-buss.de/tmp/main.asm.txt

and this is the compiler:

http://www.frank-buss.de/tmp/compiler.lisp.txt

A lot of things are missing, like a full expression evaluator and a some
more BASIC keywords, like if-endif, but at least it works.

It is inspired by BASIC stamp and PIC Basic, but I'm not sure about how to
handle register access (or memory access on ARM). PEEK and POKE looks too
cumbersome to write each time I need it, because in embedded systems it is
needed a lot. My idea is to use some default rules: If you write 

timerValue = TMR0

this means, the register TMR0 is read and the result is saved in the
register timerValue. But if you write:

foo = 42

this means, the value 42 is saved to register foo. So in general, if you
use symbols, the values of the symbols are read or written, but if you use
numbers, the numbers themselfs are used. I think this is the most common
usage.

If you really want to read the register 42, I think a C-like syntax would
be good:

foo = *42

Same if you want to get the register address, instead of the register
value:

foo = &TMR0

You can write the full form every time you want. This is the same:

timerValue = TMR0
*timerValue = *TMR0

Do you think this is easy to understand for programmer beginners? Should I
implement arrays, structs and strings, too? The goal is that it can be used
by beginners without problems, but it should be powerful enough to use all
features of the platform where it runs.

Another question is how to use functions. On a PIC there is no data stack,
so parameter passing has to be done with implicit defined variables, which
makes the compiler more complex. And I'm not sure, if it makes sense for
small PICs like the 12F508, which has a call stack of 2 levels, only.

But on ARM CPUs the BASIC programs could become really large, so structured
programming with functions would be nice. Do you think it is better to
develop two different BASIC implementations, a small one for small PICs and
a large one, with functions, arrays, interrupts, mutithreading etc., for
bigger PICs and other bigger CPUs? This would make it more difficult to
share source code between the systems, e.g. a general program for a sigma
delta converter.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

In article <vy0visejb8py$.1okedkurk85cw$.dlg@40tude.net>, Frank Buss 
says...
> 
> It is inspired by BASIC stamp and PIC Basic, but I'm not sure about how to
> handle register access (or memory access on ARM). PEEK and POKE looks too
> cumbersome to write each time I need it, because in embedded systems it is
> needed a lot. My idea is to use some default rules: If you write 
> 
> timerValue = TMR0
> 
> this means, the register TMR0 is read and the result is saved in the
> register timerValue. But if you write:
> 
> foo = 42
> 
> this means, the value 42 is saved to register foo. So in general, if you
> use symbols, the values of the symbols are read or written, but if you use
> numbers, the numbers themselfs are used. I think this is the most common
> usage.
> 
> If you really want to read the register 42, I think a C-like syntax would
> be good:
> 
> foo = *42
> 
> Same if you want to get the register address, instead of the register
> value:
> 
> foo = &TMR0
> 
> You can write the full form every time you want. This is the same:
> 
> timerValue = TMR0
> *timerValue = *TMR0
> 
> Do you think this is easy to understand for programmer beginners? Should I
> implement arrays, structs and strings, too? The goal is that it can be used
> by beginners without problems, but it should be powerful enough to use all
> features of the platform where it runs.

Well if you *must* use basic :) why not steal a common extension used by 
some C compilers and use @ to place a vatiable at a specific address?  
Something like

DIM TMR0 as Integer @42

Maybe add a prefix to the address if you need to separate address 
spaces.

Robert


> 
> 
** Posted from http://www.teranews.com **

On Mon, 2 Jun 2008 00:42:24 +0200, Frank Buss <fb@frank-buss.de> wrote:
>I've started a BASIC compiler, first for PICs, but later I plan to use this
>for ARM platforms, too. This is an example source code:

Lovely.  Pick a language that in it's 'standard' form is too much of a piece
of shit to do anything useful.  Pick a language that has to be extended to
the point of being incompatible with the other thousand varients calling
themselves basic.  Where can I sign up?  I really want a language that won't
permit me to reuse any of of my code and which won't work with any previously
developed libraries.

At least pascal has data structures.  By the time you make your BASIC useable,
it won't be BASIC any more.

Read a book on yacc.  It'll let you build compilers for just any
architecture and in any grammar.

Frank Buss wrote:
> I've started a BASIC compiler

Welcome to 1974! We hope you enjoy your stay.

Robert Adsett wrote:

> Well if you *must* use basic :) 

Usually I'm using C, but I think this would be too difficult for the
beginner.

> why not steal a common extension used by 
> some C compilers and use @ to place a vatiable at a specific address?  
> Something like
> 
> DIM TMR0 as Integer @42

Thanks, this looks like a good idea.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

AZ Nomad wrote:

> Lovely.  Pick a language that in it's 'standard' form is too much of a piece
> of shit to do anything useful.  Pick a language that has to be extended to
> the point of being incompatible with the other thousand varients calling
> themselves basic.  Where can I sign up?  I really want a language that won't
> permit me to reuse any of of my code and which won't work with any previously
> developed libraries.

Usually you don't need previously developed libraries for small embedded
systems and products like this:

http://www.wilke-technology.com/embeddedcomputermodule.php
http://www.pic-basic.de/en/index.html
http://www.parallax.com/Default.aspx?tabid=295

demonstrates that there is some use for BASIC on embedded systems. Which
language would you recommend, which is easy to use for beginners (so no C)
and can be compiled to small PICs?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Mon, 2 Jun 2008 06:23:31 +0200, Frank Buss <fb@frank-buss.de> wrote:
>Robert Adsett wrote:

>> Well if you *must* use basic :) 

>Usually I'm using C, but I think this would be too difficult for the
>beginner.

Is the embedded application going to be in a playskool busibox?
Is that the target audience?

Anybody who can figure out how to incorporate an embedded processor can
figure out how to use a real programming language or find somebody who can.

Frank Buss wrote:
> AZ Nomad wrote:
> 
>> Lovely.  Pick a language that in it's 'standard' form is too much
>> of a piece of shit to do anything useful.  Pick a language that
>> has to be extended to the point of being incompatible with the
>> other thousand varients calling themselves basic.  Where can I
>> sign up?  I really want a language that won't permit me to reuse
>> any of of my code and which won't work with any previously
>> developed libraries.
> 
> Usually you don't need previously developed libraries for small
> embedded systems and products like this:
> 
> http://www.wilke-technology.com/embeddedcomputermodule.php
> http://www.pic-basic.de/en/index.html
> http://www.parallax.com/Default.aspx?tabid=295
> 
> demonstrates that there is some use for BASIC on embedded
> systems. Which language would you recommend, which is easy to
> use for beginners (so no C) and can be compiled to small PICs?

Pascal, to ISO 7185.  Complete, properly designed, with a proper
standard.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

Frank Buss wrote:

> I've started a BASIC compiler, first for PICs, but later I plan to use this
> for ARM platforms, too. This is an example source code:
> 
> http://www.frank-buss.de/tmp/test.bas.txt
> 
> this is the generated assembler code:
> 
> http://www.frank-buss.de/tmp/main.asm.txt
> 
> and this is the compiler:
> 
> http://www.frank-buss.de/tmp/compiler.lisp.txt
> 
> A lot of things are missing, like a full expression evaluator and a some
> more BASIC keywords, like if-endif, but at least it works.
> 
> It is inspired by BASIC stamp and PIC Basic, but I'm not sure about how to
> handle register access (or memory access on ARM). PEEK and POKE looks too
> cumbersome to write each time I need it, because in embedded systems it is
> needed a lot. My idea is to use some default rules: If you write 
> 
> timerValue = TMR0
> 
> this means, the register TMR0 is read and the result is saved in the
> register timerValue. But if you write:
> 
> foo = 42
> 
> this means, the value 42 is saved to register foo. So in general, if you
> use symbols, the values of the symbols are read or written, but if you use
> numbers, the numbers themselfs are used. I think this is the most common
> usage.
> 
> If you really want to read the register 42, I think a C-like syntax would
> be good:
> 
> foo = *42
> 
> Same if you want to get the register address, instead of the register
> value:
> 
> foo = &TMR0
> 
> You can write the full form every time you want. This is the same:
> 
> timerValue = TMR0
> *timerValue = *TMR0
> 
> Do you think this is easy to understand for programmer beginners?

If you are gettng that close to C, you are going to confuse beginners.
clearer is more Pascal like :
foo = ADDRESS(TMR0)

> Should I implement arrays, structs and strings, too? 

Without those, it will be very limited.

> The goal is that it can be used
> by beginners without problems, but it should be powerful enough to use all
> features of the platform where it runs.
> 
> Another question is how to use functions. On a PIC there is no data stack,
> so parameter passing has to be done with implicit defined variables, which
> makes the compiler more complex. And I'm not sure, if it makes sense for
> small PICs like the 12F508, which has a call stack of 2 levels, only.
> 
> But on ARM CPUs the BASIC programs could become really large, so structured
> programming with functions would be nice. Do you think it is better to
> develop two different BASIC implementations, a small one for small PICs and
> a large one, with functions, arrays, interrupts, mutithreading etc., for
> bigger PICs and other bigger CPUs? This would make it more difficult to
> share source code between the systems, e.g. a general program for a sigma
> delta converter.

That's a big jump, from a vanilla PIC, to ARM.

You need to think about Debug, and simulation, and if possible, allow
syntax that allows a PC version of the compiler to compile code 
(possible with different header files) - OR make it work really well
with a vendors low cost ICE, so simullation uses silicon.

What are the PIC In_circuit_debug solution priced at ?

-jg

AZ Nomad wrote:

> Is the embedded application going to be in a playskool busibox?
> Is that the target audience?

Yes, it should be as simple as possible to be used by everybody. There were
some experiments with using programming languages even in kindergartens,
e.g. http://home.utad.pt/~leonelm/papers/eurologo2003/EuroLogo2003.htm
I don't know if this makes sense, but maybe starting with the age of 10, I
think it would be too difficult to use C.

Or maybe even a visual environment, like LabView or RCX code:

http://artdecom.mesh.de/projekte/werkzeuge/software/microcomputer-sensorik_familie/lego/mindstorms.htm

But this would be difficult to compile for small PICs.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de