Compiler Grammar/Token Rules
Does anyone have any specifications for the grammar/token rules of the Basic
Stamp I/II?
I would like to add to the language and would like to avoid reverse
engineering each reserved word one by one.
Thanks!
Brian Gillis
Gillis Software & Development
Voice[noparse]:([/noparse]541) 954-0851
Fax[noparse]:([/noparse]541) 683-2201
E-Mail:Brian@g...
Stamp I/II?
I would like to add to the language and would like to avoid reverse
engineering each reserved word one by one.
Thanks!
Brian Gillis
Gillis Software & Development
Voice[noparse]:([/noparse]541) 954-0851
Fax[noparse]:([/noparse]541) 683-2201
E-Mail:Brian@g...
Comments
The token list is not 'formally' available or provided by Parallax but there
are those that spend time generating a list of the tokens being sent. You
couldn't really add to the features or functions unless you limited your new
functions to capabilities derived from the existing interpreter functions as
presented by the stamp. These functions are the source of all the useful work;
very little is done on the pc other than tokenizing the basic syntax. You could
play with the syntax and other things in the source structure but ultimately
your new functions would have to tokenize to the finite, existing set of
features being provided by the interpreter on the stamp. There is also the
issue of providing the serial line(s) sequencing that causes the stamp to reset,
enter programming mode, etc. This would also have to be reproduced in your new
editor/compiler.
Bill
Brian Gillis wrote:
> Does anyone have any specifications for the grammar/token rules of the Basic
> Stamp I/II?
>
> I would like to add to the language and would like to avoid reverse
> engineering each reserved word one by one.
>
> Thanks!
>
> Brian Gillis
> Gillis Software & Development
> Voice[noparse]:([/noparse]541) 954-0851
> Fax[noparse]:([/noparse]541) 683-2201
> E-Mail:Brian@g...
Scenix
processor coding that I forgot why I wanted a basic compiler to begin with(g).
Someday I'd like to get back to that compiler but I'm having too much fun just
programming directly to the sx for now. Parallax used to refer to a compiler
project of their own back then also. I've been sort waiting to see what they
were
working on before I dove in...I guess priorities change over time, I haven't
heard
anything about a compiler project for quite some time.
Bill M. - DCS
Larry Pfeffer wrote:
> a) there is a PBasic superset called PicBasic Pro. See www.rentron.com -
> e.g. downloadable manual at http://www.rentron.com/PicBasic.htm
>
> b) it would be feasible/useful/easy to write a pre-processor to the
> Parallax PBasic - e.g. for compile time logic. Language extension via a
> pre-processor would be fully compatible w/the existing compiler. Downside:
> two steps would be required to compile a program - the pre-processor and
> then the compile/download steps
>
> Larry Pfeffer
>
> At 06:24 AM 6/4/00 -0400, you wrote:
> >Brian,
> >
> > The token list is not 'formally' available or provided by Parallax but
> >there
> >are those that spend time generating a list of the tokens being sent. You
> >couldn't really add to the features or functions unless you limited your new
> >functions to capabilities derived from the existing interpreter functions as
> >presented by the stamp. These functions are the source of all the useful
> work;
> >very little is done on the pc other than tokenizing the basic syntax. You
> >could
> >play with the syntax and other things in the source structure but ultimately
> >your new functions would have to tokenize to the finite, existing set of
> >features being provided by the interpreter on the stamp. There is also the
> >issue of providing the serial line(s) sequencing that causes the stamp to
> >reset,
> >enter programming mode, etc. This would also have to be reproduced in
> your new
> >editor/compiler.
> >
> > Bill
> >
> >Brian Gillis wrote:
> >
> >> Does anyone have any specifications for the grammar/token rules of the
Basic
> >> Stamp I/II?
> >>
> >> I would like to add to the language and would like to avoid reverse
> >> engineering each reserved word one by one.
> >>
> >> Thanks!
> >>
> >> Brian Gillis
> >> Gillis Software & Development
> >> Voice[noparse]:([/noparse]541) 954-0851
> >> Fax[noparse]:([/noparse]541) 683-2201
> >> E-Mail:Brian@g...
> >
> >
> >
> >
http://members.aol.com/stamp2book/ . It's quite good and very
thorough.
e.g. downloadable manual at http://www.rentron.com/PicBasic.htm
b) it would be feasible/useful/easy to write a pre-processor to the
Parallax PBasic - e.g. for compile time logic. Language extension via a
pre-processor would be fully compatible w/the existing compiler. Downside:
two steps would be required to compile a program - the pre-processor and
then the compile/download steps
Larry Pfeffer
At 06:24 AM 6/4/00 -0400, you wrote:
>Brian,
>
> The token list is not 'formally' available or provided by Parallax but
>there
>are those that spend time generating a list of the tokens being sent. You
>couldn't really add to the features or functions unless you limited your new
>functions to capabilities derived from the existing interpreter functions as
>presented by the stamp. These functions are the source of all the useful
work;
>very little is done on the pc other than tokenizing the basic syntax. You
>could
>play with the syntax and other things in the source structure but ultimately
>your new functions would have to tokenize to the finite, existing set of
>features being provided by the interpreter on the stamp. There is also the
>issue of providing the serial line(s) sequencing that causes the stamp to
>reset,
>enter programming mode, etc. This would also have to be reproduced in
your new
>editor/compiler.
>
> Bill
>
>Brian Gillis wrote:
>
>> Does anyone have any specifications for the grammar/token rules of the Basic
>> Stamp I/II?
>>
>> I would like to add to the language and would like to avoid reverse
>> engineering each reserved word one by one.
>>
>> Thanks!
>>
>> Brian Gillis
>> Gillis Software & Development
>> Voice[noparse]:([/noparse]541) 954-0851
>> Fax[noparse]:([/noparse]541) 683-2201
>> E-Mail:Brian@g...
>
>
>
>
Date: Sun, 04 Jun 2000 16:38:34 -0700
From: Larry Pfeffer <lpfeffer@a...>
b) it would be feasible/useful/easy to write a pre-processor to the
Parallax PBasic - e.g. for compile time logic. Language extension via a
pre-processor would be fully compatible w/the existing compiler.
Downside:
two steps would be required to compile a program - the pre-processor and
then the compile/download steps
>>>>
I had been thinking about this and possibly writing a QBASIC program
to do it - you could always edit the pre-processor generated PBasic.
E.g. you could have it recognise IF ... THEN .... ELSE and generate
the equivalently more complex BSII PBasic text.
Big question? Has anyone done this and is anyone doing this?
Hope so! premena
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
> to do it - you could always edit the pre-processor generated PBasic.
> E.g. you could have it recognise IF ... THEN .... ELSE and generate
> the equivalently more complex BSII PBasic text.
> Big question? Has anyone done this and is anyone doing this?
<
>
I have started a pre-processor for PBASIC like this, however it has been put
on the back-burner for a short while due to some other priorities of mine.
If anyone has any suggestions on what they would like to see in a program
like this, feel free to email me OFF-LIST at electrolinx@y... and I
will be sure to add any do-able suggestions to the program.
Thanks,
Jared
Electrolinx - http://www.geocities.com/electrolinx/
VB Overdrive - http://extreme-vb.net/vboverdrive/
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
You could do:
IF THEN ELSE ENDIF
DO WHILE LOOP
DO UNTIL LOOP
DO LOOP WHILE
DO LOOP UNTIL
Context-sensitive I/O pin definitions. For example, I'd like to be able to
write:
chipselect io 1 ' io pin 1 is chipselect
output chipselect
chipselect=1
This would translate into something like:
chipselect con 1
i_chipselect var in1
o_chipselect var out1
output chipselect
o_chipselect=1
etc.
Would be easy to do in Perl, but then you have to assume everyone has Perl
(which is free). A little harder to do in C++ but then you could have a
stand-alone executable.
Sure would break up the development cycle though because you'd have to use
one editor to create, the translator, and then the Parallax program.
Regards,
Al Williams
AWC
*Floating point math for the Stamp, PIC, SX, or any microcontroller:
http://www.al-williams.com/awce/pak1.htm
>
Original Message
> From: s premena [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=KQE8EM-lqPuBOMB5EZGpIGObEIxEeXSY5bmHzKM9ovZEYg2jVE8agua7sk09lFoPs7kCKfwI7kU]premzee@j...[/url
> Sent: Tuesday, June 06, 2000 1:52 PM
> To: basicstamps@egroups.com
> Subject: [noparse][[/noparse]basicstamps] Re: Compiler Grammar/Token Rules
>
>
> <<<<
> Date: Sun, 04 Jun 2000 16:38:34 -0700
> From: Larry Pfeffer <lpfeffer@a...>
>
> b) it would be feasible/useful/easy to write a pre-processor to the
> Parallax PBasic - e.g. for compile time logic. Language extension via a
> pre-processor would be fully compatible w/the existing compiler.
> Downside:
> two steps would be required to compile a program - the pre-processor and
> then the compile/download steps
> >>>>
>
> I had been thinking about this and possibly writing a QBASIC program
> to do it - you could always edit the pre-processor generated PBasic.
> E.g. you could have it recognise IF ... THEN .... ELSE and generate
> the equivalently more complex BSII PBasic text.
>
> Big question? Has anyone done this and is anyone doing this?
>
> Hope so! premena
>
>
>
> ________________________________________________________________
> YOU'RE PAYING TOO MUCH FOR THE INTERNET!
> Juno now offers FREE Internet Access!
> Try it today - there's no risk! For your FREE software, visit:
> http://dl.www.juno.com/get/tagj.
>
>
program
> to do it - you could always edit the pre-processor generated PBasic.
> E.g. you could have it recognise IF ... THEN .... ELSE and generate
> the equivalently more complex BSII PBasic text.
>
> Big question? Has anyone done this and is anyone doing this?
<
>
I have started a pre-processor for PBASIC like this, however it has
been put
on the back-burner for a short while due to some other priorities of
mine.
If anyone has any suggestions on what they would like to see in a
program
like this, feel free to email me OFF-LIST at electrolinx@y...
and I
will be sure to add any do-able suggestions to the program.
Thanks,
Jared
Electrolinx - http://www.geocities.com/electrolinx/
VB Overdrive - http://extreme-vb.net/vboverdrive/
the product produced by the company that hosts thislist.
Why go through all this trouble. Just buy PICBasic Pro and have the features
you want today. I know I will hear the inevitable "it costs so much". I look
at it this way. If I do any freelance work I have no problem getting
$50.00/hour. There is no way anyone is going to write this tool being
discussed in 6 hours. So if I freelance for 6 hours I can just buy the
program and a programmer and start working on projects right away instead of
making the building of a software package my project.
Just my 2 cents.
Tim
[noparse][[/noparse]Denver, CO]
somewhere. It is plain that Aho, Wienberg, and Kernigham (AWK) knew Snobol
and Perl borrows from AWK a lot. Not as notationally clean as Snobol, but...
I had not even thought of a PC-based Snobol.
YACC is nice (or GNU's Bison) but I have found them to be overwrought for
Basic.
Yes, a #define and #if type facility would be nice. Of course, you can do
that now with M4. In fact, I wonder if we couldn't cobble up M4 macros so
you could write:
%if blah then
yadda
%else
yadda
%end if
My M4 is rusty, I'm afraid.
Regards,
Al Williams
AWC
*Expand your Stamp I/O: http://www.al-williams.com/awce/pak3.htm
>
Original Message
> From: Larry Pfeffer [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=gXjUuvSQz8Kxbe87Uwh8lKFqoc1wFxaMsrha8CYyg-WQxu-FVIBJrS_OzA1cvLVAc_b_gJ690Ck]lpfeffer@a...[/url
> Sent: Wednesday, June 07, 2000 12:51 AM
> To: basicstamps@egroups.com
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Compiler Grammar/Token Rules
>
>
> Suggestions:
>
> a) of all languages probably SNOBOL or SPITBOL are most suitable ---
> probably much faster to write/more malleable than in PERL. S*BOL-s are a
> vintage 1960 family with amazingly powerful string processing/pattern
> matching. Downside -- the language is kind of dead (stopped evolving). See
> www.snobol4.com
>
> b) also, there must be many generic macro/pre-processors with ability to
> define grammar (extended PBasic++) and emitted code (PBasic). Compiler
> writing tools a la YACC may be worth looking at ...
>
> c) one of the most valuable features of a pre-processor is adding compile
> time capabilities - e.g. to be able to generate device specific PBasic fro
> a more generic program --- and someting even simpler & essential: #include
> to be able to include (conditionally or unconditionally) library code. A
> rudimentary pre-processor would allow support BS1 & BS2 processors from a
> single PBasic++. ...
>
>
>
>
> At 07:30 PM 6/6/00 +0000, you wrote:
> >> I had been thinking about this and possibly writing a QBASIC
> >program
> >> to do it - you could always edit the pre-processor generated PBasic.
> >> E.g. you could have it recognise IF ... THEN .... ELSE and generate
> >> the equivalently more complex BSII PBasic text.
> >>
> >> Big question? Has anyone done this and is anyone doing this?
> >
> ><
>
> >
> >I have started a pre-processor for PBASIC like this, however it has
> >been put
> >on the back-burner for a short while due to some other priorities of
> >mine.
> >
> >If anyone has any suggestions on what they would like to see in a
> >program
> >like this, feel free to email me OFF-LIST at electrolinx@y...
> >and I
> >will be sure to add any do-able suggestions to the program.
> >
> >Thanks,
> >Jared
> >
> >Electrolinx - http://www.geocities.com/electrolinx/
> >VB Overdrive - http://extreme-vb.net/vboverdrive/
> >
> >
> >
> >
> >
>
>
>
>
> From: Larry Pfeffer <lpfeffer@a...>
>
> b) it would be feasible/useful/easy to write a pre-processor to the
> Parallax PBasic - e.g. for compile time logic. Language extension via a
> pre-processor would be fully compatible w/the existing compiler.
> Downside:
> two steps would be required to compile a program - the pre-processor and
> then the compile/download steps
> >>>>
>
> I had been thinking about this and possibly writing a QBASIC program
> to do it - you could always edit the pre-processor generated PBasic.
> E.g. you could have it recognise IF ... THEN .... ELSE and generate
> the equivalently more complex BSII PBasic text.
>
> Big question? Has anyone done this and is anyone doing this?
>
> Hope so! premena
>
>
>
I´m working on something like that, but i want to use Visual Basic.
The thing is that i need information about the PBasic compiler
source in order to get an ActiveX developed.
If anyone has any information I will really apreciate it.
Pablo.
the attitude that leads people to create.......
Two thumbs up...;o]
Bruce
http://www.rentron.com
> Pragmatic approach. Yet .... things may be perhaps more complex.
>
> People often want to build something not because the custom built thing is
> cheaper, but because it fulfills other needs: "tinkering",
self-expression,
> exploration, research ... Curiosity is a powerful and important life force
> --- not all can and should be measured in $-s. To give an example - there
> are some who climb mountains, eventhe Himalayas, at the risk of their
life.
> They are not the first to climb it - thus won't be immortalized for their
> supreme effort, risk taking and having reached the peak. If all they
wanted
> to see is the "View from the Peak" --- they could have bought some photos
> taken by a past climer, or better yet, by an aerial overflight. The
> mountain climbing experience clearly provides a rare and cherished view of
> a different sort ...
>
> Seems to me there is much value being able to tinker with the language
> level used to think about/construct micro-controller based systems. The
> issue is not so much a few more high level instructions in a PBasic++
> (which would assuredly be helpful - PBasic has many "weirdnesses" and
> limitations.) New types of languages may allow thinking in new ways about
> both single and massively many micro-contrlers applied to a task. The
> margin of this eMail is to small to include a description of a massively
> parallel programmijng language called StarLogo (MIT Media Lab). This
> language, for example, was born on the massively parallel processor at
> Thinking Machines. It was a parallelized, distributed control version of
> the popular previous MIT language: LOGO (of the Logo turtle ...). Some
Star
> Logo constructs (of amazing power)
>
> create 100
>
> (creates 100 "screen turtles" - could, with equal ease,
> initialize/instantiate 100 processors/proceses on 100 Basic Stamps or,
more
> likely, 100 sub $2 PIC processors linked by a multi-access IR link or an
> I2C bus.)
>
> forward random 50
>
> (each "turtle" moves forward a random number between [noparse][[/noparse]0,49] --- other
> "verbs" may have different effects of i/o or internal program satte on the
> 100 processes created by the above "create 100")
>
> if color = red [noparse]/noparse]repeat 36 [noparse][[/noparse]forward 1 right 10
>
> where each "red" turtle draws a circle ... (or performs another "action"
> following the predicate)
>
> In StarLogo the notion of one command "marshalling" a potentially very
> large number of processes/processors is finely developed - and processors
> may form groups and etc. and certain commands may apply only to some
groups
> .. High level commands such as above could effectively mask enourmous
> complexity in some embedded applications ....
>
> Those who experienced languages like LISP, APL, SETL, SNOBOL, SMALLTALK
> will appreciate the radical impact the unique language has on one's
> perception of vast proble spaces. Programming large "hordes" of
> collaborating micro-controllers in a language based, say, on radically
> distributed "turtle talk" is a vastly different experience than
programming
> the by say PBasic or PIC assembler .... I recently read a book about Jim
> Clark, founder of SGI, Netscape, Healthion. Much of the book dealt with
all
> the trials & tribulations of Clark & friends programming, debuggong the
> MANY sensors & affectors of Clark's hi-tech, computer driven sailboat:
> Hyperion via 25 networked SGI machines on the boat. With all the
> programming and engineering talent at Clark's disposal (and all the time
> Clark himself spent coding) it seems that Hyperion wasn't quite sea-worthy
> - possibly due to the programinmg language not being well matched to what
> was essentially a large and truly mission critical home automation
project.
>
> Seekijng to develop a pre-processor for systes like the BasicStamp may
pave
> the way to extensible languages for these types of processors and may
> facilitate experimenting with new types of "mini-languages", say like a
> StarLogo, which can eventualy grossly simplify solution of complex
embedded
> sysetm problems (and render solutions much more robust), and may also lead
> to discovery of new problems to be solved.
>
> Buying PicBasic PRO is worthwhile, but a very different experience.
>
> Larry Pfeffer
> Jerusalem
>
>
>
>
>
a) of all languages probably SNOBOL or SPITBOL are most suitable ---
probably much faster to write/more malleable than in PERL. S*BOL-s are a
vintage 1960 family with amazingly powerful string processing/pattern
matching. Downside -- the language is kind of dead (stopped evolving). See
www.snobol4.com
b) also, there must be many generic macro/pre-processors with ability to
define grammar (extended PBasic++) and emitted code (PBasic). Compiler
writing tools a la YACC may be worth looking at ...
c) one of the most valuable features of a pre-processor is adding compile
time capabilities - e.g. to be able to generate device specific PBasic fro
a more generic program --- and someting even simpler & essential: #include
to be able to include (conditionally or unconditionally) library code. A
rudimentary pre-processor would allow support BS1 & BS2 processors from a
single PBasic++. ...
At 07:30 PM 6/6/00 +0000, you wrote:
>> I had been thinking about this and possibly writing a QBASIC
>program
>> to do it - you could always edit the pre-processor generated PBasic.
>> E.g. you could have it recognise IF ... THEN .... ELSE and generate
>> the equivalently more complex BSII PBasic text.
>>
>> Big question? Has anyone done this and is anyone doing this?
>
><
>
>
>I have started a pre-processor for PBASIC like this, however it has
>been put
>on the back-burner for a short while due to some other priorities of
>mine.
>
>If anyone has any suggestions on what they would like to see in a
>program
>like this, feel free to email me OFF-LIST at electrolinx@y...
>and I
>will be sure to add any do-able suggestions to the program.
>
>Thanks,
>Jared
>
>Electrolinx - http://www.geocities.com/electrolinx/
>VB Overdrive - http://extreme-vb.net/vboverdrive/
>
>
>
>
>
>OK, I can't resist asking the question even though is is not in support of
>the product produced by the company that hosts thislist.
>
>Why go through all this trouble. Just buy PICBasic Pro and have the features
>you want today. I know I will hear the inevitable "it costs so much". I look
>at it this way. If I do any freelance work I have no problem getting
>$50.00/hour. There is no way anyone is going to write this tool being
>discussed in 6 hours. So if I freelance for 6 hours I can just buy the
>program and a programmer and start working on projects right away instead of
>making the building of a software package my project.
>
>Just my 2 cents.
>
>Tim
>[noparse][[/noparse]Denver, CO]
Pragmatic approach. Yet .... things may be perhaps more complex.
People often want to build something not because the custom built thing is
cheaper, but because it fulfills other needs: "tinkering", self-expression,
exploration, research ... Curiosity is a powerful and important life force
--- not all can and should be measured in $-s. To give an example - there
are some who climb mountains, eventhe Himalayas, at the risk of their life.
They are not the first to climb it - thus won't be immortalized for their
supreme effort, risk taking and having reached the peak. If all they wanted
to see is the "View from the Peak" --- they could have bought some photos
taken by a past climer, or better yet, by an aerial overflight. The
mountain climbing experience clearly provides a rare and cherished view of
a different sort ...
Seems to me there is much value being able to tinker with the language
level used to think about/construct micro-controller based systems. The
issue is not so much a few more high level instructions in a PBasic++
(which would assuredly be helpful - PBasic has many "weirdnesses" and
limitations.) New types of languages may allow thinking in new ways about
both single and massively many micro-contrlers applied to a task. The
margin of this eMail is to small to include a description of a massively
parallel programmijng language called StarLogo (MIT Media Lab). This
language, for example, was born on the massively parallel processor at
Thinking Machines. It was a parallelized, distributed control version of
the popular previous MIT language: LOGO (of the Logo turtle ...). Some Star
Logo constructs (of amazing power)
create 100
(creates 100 "screen turtles" - could, with equal ease,
initialize/instantiate 100 processors/proceses on 100 Basic Stamps or, more
likely, 100 sub $2 PIC processors linked by a multi-access IR link or an
I2C bus.)
forward random 50
(each "turtle" moves forward a random number between [noparse][[/noparse]0,49] --- other
"verbs" may have different effects of i/o or internal program satte on the
100 processes created by the above "create 100")
if color = red [noparse]/noparse]repeat 36 [noparse][[/noparse]forward 1 right 10
where each "red" turtle draws a circle ... (or performs another "action"
following the predicate)
In StarLogo the notion of one command "marshalling" a potentially very
large number of processes/processors is finely developed - and processors
may form groups and etc. and certain commands may apply only to some groups
... High level commands such as above could effectively mask enourmous
complexity in some embedded applications ....
Those who experienced languages like LISP, APL, SETL, SNOBOL, SMALLTALK
will appreciate the radical impact the unique language has on one's
perception of vast proble spaces. Programming large "hordes" of
collaborating micro-controllers in a language based, say, on radically
distributed "turtle talk" is a vastly different experience than programming
the by say PBasic or PIC assembler .... I recently read a book about Jim
Clark, founder of SGI, Netscape, Healthion. Much of the book dealt with all
the trials & tribulations of Clark & friends programming, debuggong the
MANY sensors & affectors of Clark's hi-tech, computer driven sailboat:
Hyperion via 25 networked SGI machines on the boat. With all the
programming and engineering talent at Clark's disposal (and all the time
Clark himself spent coding) it seems that Hyperion wasn't quite sea-worthy
- possibly due to the programinmg language not being well matched to what
was essentially a large and truly mission critical home automation project.
Seekijng to develop a pre-processor for systes like the BasicStamp may pave
the way to extensible languages for these types of processors and may
facilitate experimenting with new types of "mini-languages", say like a
StarLogo, which can eventualy grossly simplify solution of complex embedded
sysetm problems (and render solutions much more robust), and may also lead
to discovery of new problems to be solved.
Buying PicBasic PRO is worthwhile, but a very different experience.
Larry Pfeffer
Jerusalem