Shop OBEX P1 Docs P2 Docs Learn Events
Binary too large for RAM by 1 Longs (again) — Parallax Forums

Binary too large for RAM by 1 Longs (again)

wpdwpd Posts: 10
edited 2012-08-26 17:51 in Propeller 1
Hello,
I am brand new to propeller programming and am starting by making very simple modifications to the code for the CMUCam4 (see www.cmucam.org, if you are interested). I still don't know what I don't know yet, but I started by adding a character to the banner string that is displayed when the application starts. I was quite surprised to learn that by adding one character to the banner string, the program was now "too large for RAM by 1 Long".


When I compile the baseline code, I get the following: 
bstc -e !CMUcam4_Firmware.eeprom -ls !CMUcam4_Firmware.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved

Compiled for i386 Darwin at 08:17:49 on 2009/07/20
Loading Object !CMUcam4_Firmware
Loading Object SD-MMC_FATEngine.spin
Loading Object Full-Duplex_COMEngine.spin
Program size is 23356 longs
Compiled 4336 Lines of Code in 0.248 Seconds

I believe there must be a bug in the "bstc" tool, since there is no way that 23356 longs can fit into 32k bytes of memory, but looking at the listing file, I suspect that the word "longs" should be "bytes".

If I'm only using 23356 bytes, why does adding 1 byte make the code too large to fit into RAM?

Where should I start to look to figure this out on my own?

Thanks for any tips you can give.

--wpd

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2012-08-26 05:23
    Stack and reserved space add up to 642 longs (baseline code). That's also the minimum required by the code itself (around line 54, 640+2). By adding another character you're eating into this reserved space which throws up this error message. Better make some space somewhere else first.

    Unused code removal will get you about 200 longs which isn't much but a start.
  • wpdwpd Posts: 10
    edited 2012-08-26 05:39
    Thanks for the quick reply. I saw the 642 longs, but I'm still confused by the math. 23356 bytes + 4*642 = 25924 bytes. This is less than the 32768 bytes available? What is using the other 6844 bytes?
  • kuronekokuroneko Posts: 3,623
    edited 2012-08-26 05:45
    wpd wrote: »
    What is using the other 6844 bytes?
    That's VARiable space.
  • T ChapT Chap Posts: 4,223
    edited 2012-08-26 07:45
    Which program are you compiling with? If BST, do you have optimization on for Eliminate unused and Generic Safe?
  • SRLMSRLM Posts: 5,045
    edited 2012-08-26 08:39
    T Chap wrote: »
    Which program are you compiling with? If BST, do you have optimization on for Eliminate unused and Generic Safe?

    He's using BSTC (it's in the command line).

    I agree: what is this "23356 longs" business?
  • T ChapT Chap Posts: 4,223
    edited 2012-08-26 09:47
    Well, shouldn't there also be an additional extension for safe optimize.
  • wpdwpd Posts: 10
    edited 2012-08-26 11:03
    Hi All,

    kuroneko: Thanks for pointing out the VARiable space. I had assumed it was included, but obviously it is not.

    T Chap: Thanks for the suggestion to turn on -Og and -Or. I'd like to think I would have gotten around to that sooner or later, but I was stuck on "why don't the numbers add up in the first place?" kuroneko's answer provided the key.

    SRLM: The "23356 longs" is what bstc spits out for a program size. It appears to be a typo and should be fixed to read "23356 bytes", and it would have been less confusing to me if it had said something like:

    Code size: 23356 bytes
    Stack Size: 640 longs (or, even better, 2560 bytes) (_STACK=640 is in the code)
    Free Size: 2 longs (8 bytes) (_FREE = 2 is in the code)
    VAR size: 6840 bytes (I got this by adding up the sizes of the 3 VBASE sections in the .list file)

    But I'm still off by 4 bytes. When I look at the .list file, I see the last address used is 0x5B3F, which feels a lot like a code size of 23360, which accounts for my missing 4 bytes. Now I'm totally confused about what bstc is trying to tell me when it prints out "Program size is 23356 longs".

    Oh well. At this point I'm willing to consider this "question asked and answered". Thanks for the help folks!

    --wpd
  • kuronekokuroneko Posts: 3,623
    edited 2012-08-26 16:41
    FWIW, if you update to v0.15.4-pre13 you'll get the same numbers as shown by the PropTool (5836 longs for code, remainder from the list file).

    However, using this version will confront you with 3 errors (in the DAT section just add a 0, e.g. long 0-constant instead of long -constant, in the CON section replace -1 with $FFFFFFFF).
  • wpdwpd Posts: 10
    edited 2012-08-26 17:37
    Hi kuroneko,
    Thanks for the tip. I already ran into the "3 errors" problem with the "latest" distribution, and fixed it by prepending 0 to the unary minus (even for the 0-1 case).

    --wpd
  • kuronekokuroneko Posts: 3,623
    edited 2012-08-26 17:51
    wpd wrote: »
    I already ran into the "3 errors" problem with the "latest" distribution ...
    Ah, I was wondering why it didn't come up yet.

    Also, the unary + is silently clamped to 0 when used in the simple (alignment only) form, e.g. 
    long    long    +1          ' flagged as error
long    +1                  ' compiled as 0
Sign In or Register to comment.