Shop OBEX P1 Docs P2 Docs Learn Events
Compiler Grammar/Token Rules — Parallax Forums

Compiler Grammar/Token Rules

ArchiverArchiver Posts: 46,084
edited 2000-06-07 09:40 in General Discussion
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...

Comments

  • ArchiverArchiver Posts: 46,084
    edited 2000-06-04 11:24
    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...
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-04 15:44
    I started down this road almost 2 years ago and got so wrapped up in native
    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...
    > >
    > >
    > >
    > >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-04 16:31
    There's a book describing the inner workings of the BS2-- see
    http://members.aol.com/stamp2book/ . It's quite good and very
    thorough.
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-05 00:38
    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...
    >
    >
    >
    >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 19:51
    <<<<
    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.
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 20:03
    > 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/




    __________________________________________________
    Do You Yahoo!?
    Talk to your friends online with Yahoo! Messenger.
    http://im.yahoo.com
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 20:07
    I have often thought of doing this also. Sort of like RATFOR for Fortran IV.
    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.
    >
    >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 20:30
    > 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/
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 21:13
    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]
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 21:28
    Wow! I played with Snobol years ago. Still have the old "green book" around
    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/
    > >
    > >
    > >
    > >
    > >
    >
    >
    >
    >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-06 21:29
    > 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
    >
    >
    >
    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.
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-07 00:12
    Well said Larry. Thinking "Outside The Box" is
    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
    >
    >
    >
    >
    >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-07 06:50
    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/
    >
    >
    >
    >
    >
  • ArchiverArchiver Posts: 46,084
    edited 2000-06-07 09:40
    At 02:13 PM 6/6/00 -0600, you wrote:
    >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
Sign In or Register to comment.