Hello,

Does anyone know of a basic compiler for msp430's?

TIA,

Guy

On Sun, 27 Jun 2004 16:11:53 +1200, Guy wrote:

>Does anyone know of a basic compiler for
msp430's?

Paul Curtis, of Rowley Associates Ltd (http://www.rowley.co.uk), is your more
likely friend for this question.  I think he's claimed one that is
"fairly
stable" somewhere in these posts, here.  Look for the title "BASIC
Compiler for
MSP430," back circa Feb 2004.

Jon

Hi Jon, Guy,

The BASIC compiler is stable, but has little interest, hence taken no
further.  It uses the same intermediate representation as our C compiler
so it seamlessly integrates with C.  The runtime support is written in C
and assembly code--any improvements we make for the C system will get
reflected in the BASIC system.  The debugger can debug compiled BASIC
programs (it doesn't care about source language when debugging).

The BASIC interpreter I've written has been distributed to various
interested parties.

We're working on something that'll make the MSP430 C product much more
useful; this may be rolled into making the BASIC compiler more
attractive too.

This is the type of thing it can compile:

    27: X = 4 + IF X\2 > 3 THEN MAX(X, Y) ELSE 3 ENDIF * 3

1196  0f4b                      MOV.W   R11, R15
1198  0f93                      CMP.W   #0, R15
119a  0134                      JGE     @10      ; = 119E
119c  1f53                      ADD.W   #1, R15
119e                    @10
119e  0f11                      RRA.W   R15
11a0  2f92                      CMP.W   #4, R15
11a2  0334                      JGE     @11      ; = 11AA
11a4  3f400300                  MOV.W   #3, R15
11a8  043c                      JMP     @12      ; = 11B2
11aa                    @11
11aa  0f4b                      MOV.W   R11, R15
11ac  0e4a                      MOV.W   R10, R14
11ae  b012e211                  CALL    #___int16_max
11b2                    @12
11b2  3e400300                  MOV.W   #3, R14
11b6  b012ce11                  CALL    #___int16_mul
11ba  2f52                      ADD.W   #4, R15
11bc  0b4f                      MOV.W   R15, R11

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

> -----Original Message-----
> From: Jonathan Kirwan [mailto:jkirwan@jkir...] 
> Sent: 27 June 2004 06:14
> To: msp430@msp4...
> Subject: Re: [msp430] Basic compiler
> 
> 
> On Sun, 27 Jun 2004 16:11:53 +1200, Guy wrote:
> 
> >Does anyone know of a basic compiler for msp430's?
> 
> Paul Curtis, of Rowley Associates Ltd 
> (http://www.rowley.co.uk), is your more likely > friend for 
> this question.  I think he's claimed one that is "fairly 
> stable" somewhere in these posts, here.  Look for the title 
> "BASIC Compiler for MSP430," back circa Feb 2004.
> 
> Jon
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~--> 
> Yahoo! Domains - Claim yours for only $14.70 
> http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA> /CFFolB/TM
> 
> 
> --------------------------
> ------~-> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

>>> The BASIC compiler is stable, but has little interest, hence
taken no
further.

Tell me about it!

A few years ago I decided to write a BASIC for the Siemens C167 / C167.
My initial "freeware" integer-only version was downloaded a lot ....
with never a thank you, only lots of impolite emails demanding
the source code.
I then wrote a commercial floating point version with full signal processing and
other primitives built-in. Not a flicker of
interest.

Another time I wrote a clone of TPW [Turbo Pascal For Windows]. I released this
product BEFORE Borland's version ... but again
hardly a sniff of interest. Borland's version then came out and swept the
world! More annoyingly, my version could single step
Pascal Window's apps which TPW could NOT do.

I learned my lesson ... selling development tools is HARD. I take my hat off to
anyone who succeeds in that market.

regards,

Richard


----- Original Message ----- 
From: "Paul Curtis" <plc@plc@...>
To: <msp430@msp4...>
Sent: Sunday, June 27, 2004 8:53 AM
Subject: RE: [msp430] Basic compiler


> Hi Jon, Guy,
>
> The BASIC compiler is stable, but has little interest, hence taken no
> further.  It uses the same intermediate representation as our C compiler
> so it seamlessly integrates with C.  The runtime support is written in C
> and assembly code--any improvements we make for the C system will get
> reflected in the BASIC system.  The debugger can debug compiled BASIC
> programs (it doesn't care about source language when debugging).
>
> The BASIC interpreter I've written has been distributed to various
> interested parties.
>
> We're working on something that'll make the MSP430 C product much
more
> useful; this may be rolled into making the BASIC compiler more
> attractive too.
>
> This is the type of thing it can compile:
>
>     27: X = 4 + IF X\2 > 3 THEN MAX(X, Y) ELSE 3 ENDIF * 3
>
> 1196  0f4b                      MOV.W   R11, R15
> 1198  0f93                      CMP.W   #0, R15
> 119a  0134                      JGE     @10      ; = 119E
> 119c  1f53                      ADD.W   #1, R15
> 119e                    @10
> 119e  0f11                      RRA.W   R15
> 11a0  2f92                      CMP.W   #4, R15
> 11a2  0334                      JGE     @11      ; = 11AA
> 11a4  3f400300                  MOV.W   #3, R15
> 11a8  043c                      JMP     @12      ; = 11B2
> 11aa                    @11
> 11aa  0f4b                      MOV.W   R11, R15
> 11ac  0e4a                      MOV.W   R10, R14
> 11ae  b012e211                  CALL    #___int16_max
> 11b2                    @12
> 11b2  3e400300                  MOV.W   #3, R14
> 11b6  b012ce11                  CALL    #___int16_mul
> 11ba  2f52                      ADD.W   #4, R15
> 11bc  0b4f                      MOV.W   R15, R11
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors
>
> > -----Original Message-----
> > From: Jonathan Kirwan [mailto:jkirwan@jkir...]
> > Sent: 27 June 2004 06:14
> > To: msp430@msp4...
> > Subject: Re: [msp430] Basic compiler
> >
> >
> > On Sun, 27 Jun 2004 16:11:53 +1200, Guy wrote:
> >
> > >Does anyone know of a basic compiler for msp430's?
> >
> > Paul Curtis, of Rowley Associates Ltd
> > (http://www.rowley.co.uk), is your more likely > friend for
> > this question.  I think he's claimed one that is "fairly
> > stable" somewhere in these posts, here.  Look for the title
> > "BASIC Compiler for MSP430," back circa Feb 2004.
> >
> > Jon
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > --------------------~-->
> > Yahoo! Domains - Claim yours for only $14.70
> > http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA> /CFFolB/TM
> >
> >
> > --------------------------
> > ------~->
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>

On Sun, 27 Jun 2004 09:44:51 +0100, you wrote:

>A few years ago I decided to write a BASIC for the
Siemens C167 / C167.

I've a few, drifting thoughts...  None of them terribly wise, but born of
small
experiences...



>My initial "freeware" integer-only
version was downloaded a lot .... with
>never a thank you, only lots of impolite emails demanding the source code.

No thanks?  Did you ever get verification that anyone actually *used* it?  Or
that they just downloaded it on a lark, without actually ever programming it up?
I don't mean this harshly -- it's a serious question.  Do you know it
was being
used, without gratitude?

>I then wrote a commercial floating point version
with full signal processing
>and other primitives built-in. Not a flicker of interest.

Before I get to your comment here, I have to say that I'm not familiar with
the
C167, except enough to realize that it would over complicate my designs.  144
pins is almost always way beyond my application space -- plus, they include ROM
for those high volume applications they are targeting, as I understand it, but
not flash (if memory serves.)   In other words, the required external CPU
support cluster of chips would over-burden the design, as if the huge pin count
on the CPU alone didn't already do so.

Now, to your point.

It seems to me, whether or not a BASIC would be commercially viable here would
depend a lot on how these CPUs are used -- their application spaces.  If the
external support chips in the designs vary widely and use various, and differing
chips ... and if your BASIC forced a narrowing of those choices ... then it
would be hard to make many in-roads.  More, it seems the C167 was really
designed for higher-volume applications and that doesn't connect really
well
with where I've seen BASIC get a toe-hold.

I've only experienced two places in the micro world have I seen and used
BASIC
as a development for paying applications.  The 8051 BASIC and the market that
the BASIC Stamp from Parallax represents.  These are, both of them, proto-type
quantities or one-off application spaces like where the PC-104 marketplace is
sold into.  Laboratories, university classes, home-brew robotics, and custom
software for very specialized applications are homes to these.  These are
essentially all small volume applications.  And it is having both the hardware
and integrated software that makes the development and prototyping fast and
worthwhile.

An example from my experience with 8051 BASIC:  A chicken hatchery needed some
kind of controller (PID, is what I used) for maintaining the temperature of
their 10's of thousands of eggs.  There were some "custom"
features, though, so
they needed more than just an off-the-shelf PID controller.  They didn't
have a
big budget for this project, but they were going to have to pay for all of it
since it was a custom job for one customer and little likelihood that it would
apply to any other purpose.  So manpower needed to be kept to a dead minimum.
Turns out that off-the-shelf 8051 BASIC boards were available at the time, with
lots of appropriate I/O and I'd already done enough PID work that I could
whip
up a BASIC version in very little time.  4 hours, it turned out.  This kept the
costs well within budget.

My experience is that this is where BASIC and micros do better.  Parallax
putting BASIC on their Stamp, for example, was a great way to go.  Once they got
past just programming chips and into making modules, they were making the
hardware AND the software, too.  It was part of a package that was, from the
ground up, the very kind of thing that people might use in one-off designs.  The
right fit.  And they advertised on the inside front covers a lot, as well.

Did the C167 make inroads into these kinds of areas?  Did you do your diligence
in this market area?

>Another time I wrote a clone of TPW [Turbo Pascal
For Windows]. I released this
>product BEFORE Borland's version ... but again hardly a sniff of
interest.
>Borland's version then came out and swept the world! More annoyingly,
my version
>could single step >Pascal Window's apps which TPW could NOT do.
>
>I learned my lesson ... selling development tools is HARD. I take my hat off
to
>anyone who succeeds in that market.

hehe.  :)

It IS hard!

Retail distribution channels will begrudgingly accept your product, but they
won't really sell it.  And they will want a huge percentage, too. 
It's not
uncommon to see 40%-45% to the retailer, another 15%-20% to the distribution
prior to the retailer, which may leave you 40%, or so.  Out of that, you still
need to push the customers into their doors, so you've got various
advertising,
seminars for technical products (which is a wider field than just tools for
engineers -- it includes things like security analysis tools, accounting
packages, etc), joint projects with other companies, getting authors at
periodicals to write articles about your product, making sure that *your*
bulleted features get added to the bullet lists prepared by magazine comparisons
*before* they get published, and otherwise pushing and cajoling the customers to
go buy from the retail and distribution places -- places that will not lift a
single finger to help you and will still take an incredible percentage for it.

So, you decide to sell direct and avoid all that.  But then you are faced with a
great many new challenges.  You may keep more of your customers' money, but
you
will earn certainly it, too!

And then, no matter which sales channels you use and after you put in the effort
to make a great product and then put in all the effort it takes to get it into
paying customers' hands, you will then be faced with customers wanting you
to
help them use your product to solve their specific problems!  They not only want
your tool for the money, but they want you to be their personal mechanic in
using it to solve their problem, too!  And you will also have "defect
customers"
who complain that your product doesn't work and you will find out, only
after
debating with them, that the reason your software isn't showing up on the
screen
is only because they didn't TURN THE DARNED PC MACHINE ON!!!

    "You mean I need to plug the computer in?  How do I do that?
     Oh, I wondered what that black cord was for..."

-- or -- 

    "Is *what* switch ON?  You mean the BIG RED one?  That one?
     Oh.  Okay.  You mean it will work, now?"

(I've been there!  Sometimes, I've amused myself wondering about who
they get to
actually feed them each day.)

And need I bring up hiring employees and the myriad issues there?

...

I have noted the comments of several of the compiler vendors here who say they
want to stay a certain size and I completely empathize.  The greatest place to
be is where your business is just big enough for your own family (okay, and a
few key people you trust well) and no bigger.  You want a nice, tiny niche that
the big guys think is too small to get into and is yet just big enough to keep
you comfortably busy on interesting projects and generally happy.

Smaller, and you don't survive the long term.  Larger, and either someone
buys
you out or else replaces you after you have done the hard work to prove out a
market (thus, saving themselves many of the dead-end troubles you went through.)

Jon

On Fri, 1 Oct 2004 11:36:32 +1000, Kris wrote:

>Read you post with great interest, and I'd
have to say I agree on all your
>points.

Hehe.  That's an achievement, I must say!

>In my opinion, the only way incremental development
in Basic is truly
>time saving and fast/efficient is when the interpreting/byte tokenising
>is inside the machine IOW - NO compiling on a PC, it seems to void the
>incremental advantage greatly IMHO.

That's my preference for such things, as well.

>PS : We're very close to releasing the first
run of MSP430 with inbuilt
>Basic interpeter and 900 MHz transparent RF networking thru Basic.
>I'll announce when ready to go.
>We'll release 3 starter kit / dev boards, they all take the RF OEM
module.
>Pics and info will be available soon.
>The starter kits have I/O, power electronics/analog interface etc etc.

Kris, as I've written a hard-used BASIC interpreter on a system with 16k
word of
total system memory, complete with floating point support, in my distant past, I
have a couple of questions about what your interpreter will do.  (I'm sure
I'll
have many follow-up questions.)

(1)  Do you require line numbers?  I recommend it, as it removes the need for an
adequate editor, which I imagine is a distraction.  Line numbers tell you
whether or not something is being inserted, replaced, deleted, etc.  Works well
and is not inconsistent with BASIC.

(2)  Since the MSP430 does NOT have an external memory interface (conflict with
low power goals), are you entirely depending on the internal memory system?  If
so, how are you handling adding, deleting, replacing lines in flash?  Further,
how are you going to handle wear-leveling of the flash, if so.

(3)  Floating point support?  If so, will you include transcendentals, as well?
How are they generated?  There are general approaches, which include angle
rotation (CORDIC) or polynomial (Taylor's [bounds avg error with next
term],
Chebyshev [bounds max error], etc.) and there are methods which also take into
account the imprecise calculations with imprecise constants and minimize the
maximum error over the range (including non-linear methods like minimax, etc.)
Just curious if you are doing any of this.

(4)  String support?

(5)  In the system I developed, each line had a line number that was stored in
binary (not ASCII) form and the keywords were tokenized.  Also, statements
referencing line numbers (such as GOTO 1000) had their line number replaced, not
with the binary number, but with a memory pointer to the line prefixed with that
line number.  In other words, the search for the line was preformed immediately
and the value stored was an indirect reference, not the value itself.  During
execution, this made the GOTO and IF very fast.  Similarly, all variables were
replaced with a pointer to their entry in a vartable.  Again, no searching, just
fast access to an entry that described the type and value and name (the name
wasn't used at run time but was there for listing purposes.)

(6)  Will you support initialized constant arrays, such as sine tables or CRC
tables?  (Or, will it require a DIM plus some READ/DATA statements to set up?)
Or what?

Be interesting to see, Kris.  An MSP430 system presents some interesting
problems.

Jon

Kris, Jonathan, 

> I presume RAL's RTL uses Taylor Expansion for
the RTL, so 
> that's something for RAL :-)

No, we use a minimax approximation.


> > Also, statements
> > referencing line numbers (such as GOTO 1000) had their line number 
> > replaced, not with the binary number, but with a memory 
> pointer to the 
> > line prefixed with that line number.
> 
> I've been very tempted to use a JUMP as well as a GOTO 
> statement for exactly that reason :-) Line numbers are stored 
> in binary for GOTOs, but not a pointer.
> JUMP will do that later.
> Alpha testers seemed to think that introducing JUMP would 
> confuse users, and that it's better to stick to simplicity, 
> also you can't forward reference then at edit time.
> (ie. GOTO 1000 when 1000 doesn't exist yet) Another reason is 
> to only need a single linked list instead of a double one, 
> and to enable the use of the REN (renumber) statement with 
> single list.

Take a leaf out of Atom Basic's book: Use labels, not line numbers.
This turns out to be so simple, and with 27 labels, it's not a problem.
I can't repro a shifted-inverse-A here, but this is what Atom Basic
looked like:

10 GOSUB A: GOSUB A: GOSUB A
20 GOTO 10
100A PRINT "HELLO": RETURN

It looks a lot better on the Atom with the A's inverted.  My latest is:

10 GOSUB LABEL A: GOSUB LABEL A: GOSUB LABEL A
20 GOTO 10
100 LABEL A: PRINT "HELLO": RETURN

LABEL is another keyword.  The interpeter looks down the linked list of
line numbers, notes each line that starts with a LABEL and registers its
address.  Then, GOSUB LABEL A is a cinch and performed in constant time.
If the program were held in RAM, it's easy to fix things up, but with
the program in FLASH you really do need some extra help.  The LABEL
concept certainly does help the interpreter and is a good programmer
aid.

Giving away all the secrets here, but I'm going to publish the
interpreter at some point anyway.

> You know where it hurts ! :-)
> A simple string support scheme is used for now that tries to 
> avoid garbage collection issues. Full strings is for later, I 
> don't expect users to need strings too advanced in the first 
> generation on embedded systems.

Again, use Atom Basic as a good example of how to give users strings
without the pain of heap management.  Atom Basic even had an assembler,
and all in 4K, with OS support...

-- Paul.

> 
> Take a leaf out of Atom Basic's book: 

The guys at Acorn really produced some fantastic versions of BASIC. 
Atom and the later BBC flavour were incredibly efficient and had some
really neat extensions.  Considering that the BBC was a 2MHz 6502 it
could knock spots off just about every other machine around at the
time.  IIRC 10X faster than BASIC on an IBM-pc of a similar vintage.
  
Having a published OS interface and built in assembler (16K OS and 16K
for the BASIC interpreter) it just went to prove what is possible in
small processor environments.

Ian

----- Original Message ----- 
From: "Ian Okey" <ian.okey@ian....>
To: <msp430@msp4...>
Sent: Thursday, July 01, 2004 11:17 AM
Subject: Re: [msp430] Basic compiler


> >
> > Take a leaf out of Atom Basic's book:
>
> The guys at Acorn really produced some fantastic versions of BASIC.
> Atom and the later BBC flavour were incredibly efficient and had some
> really neat extensions.  Considering that the BBC was a 2MHz 6502 it
> could knock spots off just about every other machine around at the
> time.  IIRC 10X faster than BASIC on an IBM-pc of a similar vintage.
>
> Having a published OS interface and built in assembler (16K OS and 16K
> for the BASIC interpreter) it just went to prove what is possible in
> small processor environments.

The 6502 ran BASIC programs very fast, due to the zero-page addressing mode,
IIRC. It wasn't much good at anything else, IMHO.

Leon

Hi Leon, 

> The 6502 ran BASIC programs very fast, due to the
zero-page 
> addressing mode,
> IIRC. It wasn't much good at anything else, IMHO.

Huh?  I don't think that's particularly nice, Leon.  The 6502 is a
fantastic machine, 128 16-bit pointers, what more can you ask for?  It
didn't have many registers, but those 256 zero-page addresses are very,
very flexible.  The 6502 is a fantastic machine and still lives on.  Not
a good target for a C compiler, but I wrote a whole two-pass assembler
(from memory or disk to memory or disk) with on-screen editor, and much
much more, in assembly code for the C64 and 3000-series Pets.

-- Paul.