Shop OBEX P1 Docs P2 Docs Learn Events
BS2SX program size control — Parallax Forums

BS2SX program size control

ArchiverArchiver Posts: 46,084
edited 2002-08-08 16:18 in General Discussion
I am about 90% complete with the code for a project and have
discovered that I am almost out of code space. It is clear that I
will run out before all the code is complete.

I have a few questions that I have not seen addressed on the list:
If they have, please point me in the right direction, and I
appologize. I would also be interested in any articles or books that
might have some insight.

Is it possible to minimize code size through different
structure/architectures? For example, if I have a small subroutine of
only 2-3 lines, and I only need to call it from 2 different places,
will the code be smaller if I just embed the routine 2X, or if I
leave it a subroutine? The manual implies that a single subroutine
will use less space.

I understand that commented lines (') don't get tokenized and
therefore do not contribute to program size. If I am wrong that
would help some.

Are there any instructions that are known to use more than the normal
amount of program space? (e.g. does the branch statement use more
space than 4 If .. then statements)

These may seem like silly questions, but I will need to find a way to
save every byte.

Comments

  • ArchiverArchiver Posts: 46,084
    edited 2002-08-08 02:07
    Have a look at this article in the Basic Stamp FAQ:

    http://www.faq-pro.com/faq/index.php?qframe=1&faq=1&article=53

    Al Williams
    AWC
    * NEW: PAK-VIa - Read PS/2 keyboards or mice -- double the buffer, lower
    current consumption.
    http://www.al-williams.com/awce/pak6.htm




    >
    Original Message
    > From: c_holm10017 [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=vEQjJ5awiX_J2XDYG1DVvXE5fdRlUc3Vg7DRX6cwEXHZir5dy9L8hO1Jn1ydxMn7gs9vE29sHKOE]cholm@m...[/url
    > Sent: Wednesday, August 07, 2002 2:52 PM
    > To: basicstamps@yahoogroups.com
    > Subject: [noparse][[/noparse]basicstamps] BS2SX program size control
    >
    >
    > I am about 90% complete with the code for a project and have
    > discovered that I am almost out of code space. It is clear that I
    > will run out before all the code is complete.
    >
    > I have a few questions that I have not seen addressed on the list:
    > If they have, please point me in the right direction, and I
    > appologize. I would also be interested in any articles or books that
    > might have some insight.
    >
    > Is it possible to minimize code size through different
    > structure/architectures? For example, if I have a small subroutine of
    > only 2-3 lines, and I only need to call it from 2 different places,
    > will the code be smaller if I just embed the routine 2X, or if I
    > leave it a subroutine? The manual implies that a single subroutine
    > will use less space.
    >
    > I understand that commented lines (') don't get tokenized and
    > therefore do not contribute to program size. If I am wrong that
    > would help some.
    >
    > Are there any instructions that are known to use more than the normal
    > amount of program space? (e.g. does the branch statement use more
    > space than 4 If .. then statements)
    >
    > These may seem like silly questions, but I will need to find a way to
    > save every byte.
    >
    >
    >
    >
    > To UNSUBSCRIBE, just send mail to:
    > basicstamps-unsubscribe@yahoogroups.com
    > from the same email address that you subscribed. Text in the
    > Subject and Body of the message will be ignored.
    >
    >
    > Your use of Yahoo! Groups is subject to
    > http://docs.yahoo.com/info/terms/
    >
  • ArchiverArchiver Posts: 46,084
    edited 2002-08-08 05:08
    >I am about 90% complete with the code for a project and have
    >discovered that I am almost out of code space. It is clear that I
    >will run out before all the code is complete.
    >
    >I have a few questions that I have not seen addressed on the list:
    >If they have, please point me in the right direction, and I
    >appologize. I would also be interested in any articles or books that
    >might have some insight.

    Brian Forbes' book "Inside the basic stamp II" is an excellent
    resource if you want to understand how the tokenizer does its thing.
    <http://members.aol.com/stamp2book/ > The book is technical,and if
    you like that sort of thing, you will come away with some very
    practical knowledge of how to optimize your programs. But it is not a
    "made easy" book.

    >Is it possible to minimize code size through different
    >structure/architectures? For example, if I have a small subroutine of
    >only 2-3 lines, and I only need to call it from 2 different places,
    >will the code be smaller if I just embed the routine 2X, or if I
    >leave it a subroutine? The manual implies that a single subroutine
    >will use less space.

    The best way to gain insight is to try it both ways, with that one
    factor being the only difference, and compare the detailed memory
    maps. (You know how to view that, right?) Each subroutine call adds
    14 bits at the very top of the program, and there is also overhead in
    the return, so in the case of very short subroutines, inserting the
    statement twice may be better. For example,
    ' silly subroutine
    gohigh0:
    high 0
    return

    will certainly be better handled as
    high 0
    every time it occurs.



    >I understand that commented lines (') don't get tokenized and
    >therefore do not contribute to program size. If I am wrong that
    >would help some.

    commented lines make no difference in program size, and neither do
    labels nor variable definitions or definition of alias variables.
    Also, parentheses inserted for clarity (as opposed to essential for
    function) make no difference.

    >Are there any instructions that are known to use more than the normal
    >amount of program space? (e.g. does the branch statement use more
    >space than 4 If .. then statements)

    One BRANCH will certainly use less than 4 IFs. (try it and see!)

    One thing that eats a huge amount of space is text within SEROUT or
    DEBUG statements. If you have a lot of text to display, it is better
    to put it in DATA statements and have a small routine to read and
    display it. For example,

    serout 16,$54,[noparse][[/noparse]"simon says stand on your head",cr]

    The trouble is, each letter in the string takes up 14 bits in the
    interpreter code, whereas, stored as DATA, each letter only takes up
    8 bits. There is a lot of overhead in each SEROUT command.
    Something like the following can save a huge amount of code space:


    head DATA "simon says stand on your head",cr,0 ' null terminated
    foot DATA "simon says tap your foot on the floor",cr,0 ' null terminated

    pointer=head ' program selects string
    gosub showstring

    showstring:
    i=0
    showstringloop:
    read pointer+i,char
    branch char,[noparse][[/noparse]exitshowstringloop] ' branch saves space over IF here
    serout 16,$54,char
    i=i+1
    goto showstringloop
    exitshowstringloop:
    return

    Despite the subroutine, this pays off rapidly if you have even a few
    "simon sez" strings. Since you are using a BS2sx, this kind of
    subroutine lends itself to one of the alternate program banks.

    Here is another little thing. Let's say you need to set an output to
    1 when some variable is greater than 50. I see things like this:

    if x>50 then xbig
    xsmall:
    out5=0
    goto onward
    xbig:
    out5=1
    onward:
    '...
    which is not only ugly (as the Stamp has no capability for
    expressions as in THEN out5=1 ELSE out5=0), but uses a lot of eeprom.
    You can accomplish the same thing and save a lot of bytes with a math
    expression:
    out5 = x max 50 - 50 max 1
    which comes out the same. I have more of that kind of thing on my
    math pages at
    http://www.emesys.com/BS2math4.htm#ifThenLet

    Even simple things can save a few bits. For example, PAUSE 1024 will
    take less space in eeprom than PAUSE 1000, because the Stamp
    tokenizer stores powers of 2 more efficiently than other numbers.

    >
    >These may seem like silly questions, but I will need to find a way to
    >save every byte.


    Not at all silly. Saving bytes is the Way of the Stamp.

    -- best regards
    Thomas Tracy Allen PhD
    electronically monitored ecosystems
    http://www.emesystems.com
    mailto:tracy@e...
  • ArchiverArchiver Posts: 46,084
    edited 2002-08-08 16:18
    Thank you Tracy. Your pointers and suggestions were exactly what I needed.
    I now have hope for a successful complete project.


    Original Message
    From: Tracy Allen [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=jBNcNZPAiQGie0mJNYFLEcy66O0sf5UtzqwBl8o9RYmw6VtmeiKOCPM0oG0I2eVyV3i9JIVFN9CgNwDZs1o]tracy@e...[/url
    Sent: Thursday, August 08, 2002 12:08 AM
    To: basicstamps@yahoogroups.com
    Subject: Re: [noparse][[/noparse]basicstamps] BS2SX program size control


    >I am about 90% complete with the code for a project and have
    >discovered that I am almost out of code space. It is clear that I
    >will run out before all the code is complete.
    >
    >I have a few questions that I have not seen addressed on the list:
    >If they have, please point me in the right direction, and I
    >appologize. I would also be interested in any articles or books that
    >might have some insight.

    Brian Forbes' book "Inside the basic stamp II" is an excellent
    resource if you want to understand how the tokenizer does its thing.
    <http://members.aol.com/stamp2book/ > The book is technical,and if
    you like that sort of thing, you will come away with some very
    practical knowledge of how to optimize your programs. But it is not a
    "made easy" book.

    >Is it possible to minimize code size through different
    >structure/architectures? For example, if I have a small subroutine of
    >only 2-3 lines, and I only need to call it from 2 different places,
    >will the code be smaller if I just embed the routine 2X, or if I
    >leave it a subroutine? The manual implies that a single subroutine
    >will use less space.

    The best way to gain insight is to try it both ways, with that one
    factor being the only difference, and compare the detailed memory
    maps. (You know how to view that, right?) Each subroutine call adds
    14 bits at the very top of the program, and there is also overhead in
    the return, so in the case of very short subroutines, inserting the
    statement twice may be better. For example,
    ' silly subroutine
    gohigh0:
    high 0
    return

    will certainly be better handled as
    high 0
    every time it occurs.



    >I understand that commented lines (') don't get tokenized and
    >therefore do not contribute to program size. If I am wrong that
    >would help some.

    commented lines make no difference in program size, and neither do
    labels nor variable definitions or definition of alias variables.
    Also, parentheses inserted for clarity (as opposed to essential for
    function) make no difference.

    >Are there any instructions that are known to use more than the normal
    >amount of program space? (e.g. does the branch statement use more
    >space than 4 If .. then statements)

    One BRANCH will certainly use less than 4 IFs. (try it and see!)

    One thing that eats a huge amount of space is text within SEROUT or
    DEBUG statements. If you have a lot of text to display, it is better
    to put it in DATA statements and have a small routine to read and
    display it. For example,

    serout 16,$54,[noparse][[/noparse]"simon says stand on your head",cr]

    The trouble is, each letter in the string takes up 14 bits in the
    interpreter code, whereas, stored as DATA, each letter only takes up
    8 bits. There is a lot of overhead in each SEROUT command.
    Something like the following can save a huge amount of code space:


    head DATA "simon says stand on your head",cr,0 ' null terminated
    foot DATA "simon says tap your foot on the floor",cr,0 ' null terminated

    pointer=head ' program selects string
    gosub showstring

    showstring:
    i=0
    showstringloop:
    read pointer+i,char
    branch char,[noparse][[/noparse]exitshowstringloop] ' branch saves space over IF here
    serout 16,$54,char
    i=i+1
    goto showstringloop
    exitshowstringloop:
    return

    Despite the subroutine, this pays off rapidly if you have even a few
    "simon sez" strings. Since you are using a BS2sx, this kind of
    subroutine lends itself to one of the alternate program banks.

    Here is another little thing. Let's say you need to set an output to
    1 when some variable is greater than 50. I see things like this:

    if x>50 then xbig
    xsmall:
    out5=0
    goto onward
    xbig:
    out5=1
    onward:
    '...
    which is not only ugly (as the Stamp has no capability for
    expressions as in THEN out5=1 ELSE out5=0), but uses a lot of eeprom.
    You can accomplish the same thing and save a lot of bytes with a math
    expression:
    out5 = x max 50 - 50 max 1
    which comes out the same. I have more of that kind of thing on my
    math pages at
    http://www.emesys.com/BS2math4.htm#ifThenLet

    Even simple things can save a few bits. For example, PAUSE 1024 will
    take less space in eeprom than PAUSE 1000, because the Stamp
    tokenizer stores powers of 2 more efficiently than other numbers.

    >
    >These may seem like silly questions, but I will need to find a way to
    >save every byte.


    Not at all silly. Saving bytes is the Way of the Stamp.

    -- best regards
    Thomas Tracy Allen PhD
    electronically monitored ecosystems
    http://www.emesystems.com
    mailto:tracy@e...

    To UNSUBSCRIBE, just send mail to:
    basicstamps-unsubscribe@yahoogroups.com
    from the same email address that you subscribed. Text in the Subject and
    Body of the message will be ignored.


    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



    This e-mail message may contain legally privileged and/or confidential
    information. If you are not the intended recipient(s), or the employee
    or agent responsible for delivery of this message to the intended
    recipient(s), you are hereby notified that any dissemination,
    distribution or copying of this e-mail message is strictly prohibited.
    If you have received this message in error, please immediately notify
    the sender and delete this e-mail message from your computer.




    [noparse][[/noparse]Non-text portions of this message have been removed]
Sign In or Register to comment.