Shop OBEX P1 Docs P2 Docs Learn Events
Object exceeds 32k — Parallax Forums

Object exceeds 32k

Dave HeinDave Hein Posts: 6,347
edited 2013-04-17 20:14 in Propeller 1
I have a·Spin program·with several objects that has about 2000 longs of free space.· If I add an array of more than 575 longs I get an error message that says "Object exceeds 32k", even though I should have more than 1400 longs of free space.· If I eliminate the top object and recompile I can get to within a few longs of 32k without an error message.· Has anybody else encountered this problem?· Is there a work-around for it?

Comments

  • Patrick1abPatrick1ab Posts: 136
    edited 2010-05-04 21:59
    Hmm... 1400 longs is quite a lot of free space. Otherwise I would have guessed that you may have a lot of local (temporal) variables. As these do not appear in the memory calculation.
  • rjo_rjo_ Posts: 1,825
    edited 2010-05-04 22:02
    As I recall... and I hate to use my memory like this... and someone please correct me if I am wrong[noparse]:)[/noparse]

    Constants and/or variables declared in the DAT section aren't counted in the calculated variable space?

    Time to start hacking away at your objects[noparse]:)[/noparse]

    You do what I do... rather than being systematic about it all, I just start out with a big unused array declaration and when I get a memory error or something spilling over into my graphics, I know I am getting close to my limit. Not very scientific, but it works for me[noparse]:)[/noparse]

    I've noticed that in some of the newer objects, the guys are including the number of longs used as a comment.

    Rich
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-04 23:09
    It seems to be a bug in the prop tool.· There is no reason that it should complain that the object exceeds 32k, when it is actually 1400 bytes less than 32k.· If I don't add the extra DAT array it shows that I have 2000 longs available, and it reports 30 longs in the VAR space.· The 30 longs actually come from 3 instances of an object with 10 longs per instance.
  • RaymanRayman Posts: 14,665
    edited 2010-05-04 23:18
    I think if there were a bug like that, I'd have found it by now [noparse]:)[/noparse]

    The Prop tool shows a nice little memory map when you compile.· Can you use that to see what's going on?



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-04 23:42
    Yes, the memory map pops up when I use the F8 key.· It's definately a bug in the prop tool.· My code compiles fine under BST up to the point where there are only 16 longs left available.

    Anybody at Parallax interested in looking into it?· I can zip up the code and send it to you.

    Dave
  • BradCBradC Posts: 2,601
    edited 2010-05-05 00:29
    Can you send the code to me? bst is far more relaxed about a few things than the Prop Tool. brad <at> proptools.org. Ta [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-05-05 00:34
    There was a bug in the older PropTool which was similar. But it was with very little code and if you created dummy dat code to waste some space it compiled. Not sure if this helps or not.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • RaymanRayman Posts: 14,665
    edited 2010-05-05 00:54
    You're not using _stack or _free are you? I'd really be surprised if you found an actual bug and not a "feature"...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-05 04:16
    I attached a ZIP file containing the code in cdos049.zip.· The top object is cdos.spin.· I define a DAT dummy array of 368 longs, which works OK and leaves me with 1,508 longs of free space.· If I change this from 368 to 369 the Prop tool will fail with the message "Object exceeds 32k".· I haven't tried this specific version with BST, but an earlier version that failed with the Prop tool worked OK with BST.

    Feel free to try out the cdos app if you want.· It still needs a lot of work, and I haven't documented it yet.· It's basically a test program for the file I/O routines I'm adding to CLib.· It includes an interface to the FSRW object for SD cards and an EEProm files system I'm writing.· I also included a YModem object based on Rayman's YModem code.

    cdos talks to a serial terminal at 57,600 baud using the standard I/O pins 30 and 31.· It uses the boot EEProm for the EEProm file system, so you have to load directly into RAM with F10 to avoid wiping out the file system.· I have the SD card interface set up on I/O pins 16, 17, 18 and 19.· This can be changed in fsrwif.spin.· The EEProm is mounted at /disk1 and the SD card is mounted at /disk2 in the cdos file system.

    Dave
    zip
    zip
    cdos049.zip
    77K
  • BradCBradC Posts: 2,601
    edited 2010-05-05 08:06
    I have a theory.

    Every man and his dog includes clib.
    clib is *huge* consuming 50% of the available program space.

    I suspect the Propeller Tool is building the binary image prior to doing its duplicate object reduction, and hitting the 32k object size limit while trying to pack the objects together before it has a chance to pare them down.

    bst works differently in that it compiles each object completely separately and then stitches them together. It also looks at the referenced objects from a source path perspective, and does not bother to compile it again if it is already in the object pool. Only when all objects have been compiled does it do a binary compare to weed out any it might be able to reduce.

    It's a completely different method of assembly to the way the Propeller tool does things.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
  • RaymanRayman Posts: 14,665
    edited 2010-05-05 13:03
    Wow, so it really is a bug, interesting...
    I just compiled CDOS and I must say it might have the most extensive object tree I've seen...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-05 15:53
    jazzed,

    You can change some constants in eefs.spin to use a different area of the EEPROM.· Change disk_start to $8000 and disk_end to $10000 to use the second half of a 64K EEPROM.· Also, check out the redirection capabilty in cdos.· It will handle commands like the following:

    cd /disk1
    echo "This is a test" >test1
    echo "This is another test" >test2
    cat test1 test2 >test3
    echo "This is line 3" >>test3
    cat test3

    I had to stub out references to cfloatstr.spin in clib.spin to get cdos to build.· cfloatstr.spin uses 308 longs.· If I add the line

    · fstr : "cfloatstr"

    to the end of the OBJ section in cdos.spin if will fail.· If I reduce the size of dummy1 from 368 to 59 it will work OK with 1,508 free longs.· cfloatstr.spin takes up 308 longs plus 1 long in cdos's method/object table.· If the size of dummy1 is greater than 59 longs it will fail.

    If I try to add cfloatstr to clib.spin I cannot get it to work.· In theory, it should add the same size to the memory image as it did when I added it to cdos.spin.· However, this will not build even if dummy1 is removed.· As Brad said, it must have something to do with the Spin tool not accounting for duplicate objects correctly.

    Dave
  • mr23mr23 Posts: 21
    edited 2013-04-13 21:16
    It's been 3 years (almost, on this thread;) I just ran into this recently, after create a wrapper object that is used in a number of places.

    Is Parallax ever going to fix it ?
    Or has everyone moved on to other toolsets ?
  • SRLMSRLM Posts: 5,045
    edited 2013-04-13 21:57
    mr23 wrote: »
    It's been 3 years (almost, on this thread;) I just ran into this recently, after create a wrapper object that is used in a number of places.

    Is Parallax ever going to fix it ?
    Or has everyone moved on to other toolsets ?

    Well, if it's not fixed yet then it probably won't ever be. Parallax is sponsoring the development of a new open source Spin compiler to replace the original closed source compiler.

    https://code.google.com/p/open-source-spin-compiler/
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-04-14 00:19
    There is another solution that has become available in the last few months. Convert the spin program to C and store the program in external memory. The external memory can be a serial ram chip, or flash ram, or even an SD card. It is not even necessary to understand C.

    The only catch is that it takes (usually) 4 pins to talk to whatever external memory is used, and also, once the program grows it does take longer to download.

    Spin programs can now be gigabytes in size!
  • mr23mr23 Posts: 21
    edited 2013-04-14 08:51
    Dr_Acula wrote: »
    There is another solution that has become available in the last few months. Convert the spin program to C and store the program in external memory. The external memory can be a serial ram chip, or flash ram, or even an SD card. It is not even necessary to understand C.

    The only catch is that it takes (usually) 4 pins to talk to whatever external memory is used, and also, once the program grows it does take longer to download.

    Spin programs can now be gigabytes in size!

    Dr_Acula, can you point me to a thread that covers this (please save me searching the forum etc) ? Hopefully one that is a step-by-step so I don't have to kill a chunk of time in discovery, evaluating the approach and converting to it. I already have a SD card interfaced, and was eventually going to look into loading operations anyway.

    Is there also a thread that evaluates the open source SPIN compiler and the status? Since I'm at a fork in the road, time to evaluate the options.
  • jazzedjazzed Posts: 11,803
    edited 2013-04-14 10:21
    @mr32,

    If possible start a separate forum thread asking questions and describing goals.

    Others may have similar concerns and it's easier to find a thread than a few posts in a Google search.

    Many here are happy to help.
  • mr23mr23 Posts: 21
    edited 2013-04-14 10:48
    I think my question was relevant; I wish I had found this thread earlier (and would have 'cut over' to a different solution earlier) and that it had the information I ask for (pointed to, not detailed here). All I'm asking for is a link to relevant threads so I can avoid searching, assuming someone knows where the best threads are.
    I do have a separate thread about my project. Won't post it here as not relevant.
  • jazzedjazzed Posts: 11,803
    edited 2013-04-14 11:10
    Was just trying to help.

    I've exhausted propeller resources many times and am sure others have too. I suppose this thread is just as good as any for the problem.

    There are different ways to get around the problem. It's probably best for Dr_Acula to talk about works for him. There are different solutions depending on your needs.

    I've never seen your thread before now. Sounds like a great topic.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2013-04-14 11:36
    mr23,

    This is a big reason people use bst, IDE, compiler and loader. It filters out unused methods, among other nice features.
    The original thread.
    It is the one I use 99% of the time, partly because I work on a mac. There is a recent thread about its future or lack thereof. Is-BST-dead. But, I reiterate, it does still work great on most systems.

    There is a new SimpleIDE initiated by Jazzed who posted just above, and I just yestereday realized that it can compile spin code as well as C code and also run on a mac. At present it appears to use the bstc compiler. The new Parallax sanctioned compiler that SRLM mentioned above could at some time replace that, but it does not yet have the optimizations.
  • mr23mr23 Posts: 21
    edited 2013-04-17 20:14
    Thanks Tracy. I just switched over to BST and can now proceed again with development, with unused-methods enabled I have plenty of space left now and code runs as it did before. I do appreciate some of the new capabilities vs PropTool, including the compiler warning section.

    I have a structured text display which can display to PST or a VT100. So far (in 15 minutes) I haven't figured out what BST's serial terminal uses, if anything. Does it have clear-screen, clear-end-of-line, go-to-position, etc functionality? In the meantime I can use PST...

    Moved to thread: http://forums.parallax.com/showthread.php/133731-BST-and-PST?p=1178082&viewfull=1#post1178082
Sign In or Register to comment.