PUB/CON list overflow in Propeller Tool 1.3.2

Larry Martin

Hello, I am adding features to a propeller design that I have been shipping since 2010. Today I had my first encounter with the error message "PUB/CON list overflow". I added about 50 constants last night, and got this error on my first attempt to compile. It goes away if I remove my last 20 constants, for a total of 255 CON section entries. But if I then add short entries like "kD1=1" to make more symbols, I don't get the error. This file has 166 PUB functions, no PRI functions, and I want to end up with around 325 well named constants. If teh symbol names are a factor, I tend to like long names.

I am using Propeller Tool 1.3.2

Can someone explain what this error message is about, so I don't have to gut my legacy symbols to fit my new ones?

Thanks,
Larry

DavidZemon

This is a guess completely out of thin air - my apologies if I'm way off - but have you tried compiling with openspin? If it's simply a compiler limitation and not a hardware limitation, perhaps OpenSpin will solve the problem for you.

http://forums.parallax.com/showthread.php/137452-OpenSpin-Spin-PASM-compiler-in-C-C

Larry Martin

Thanks, but no dice:

C:\GlueLogix\Development\Products\LineLogix\Propeller>openspin TCU_xxxxx.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.70 Compiled on Mar 10 2014 23:53:34
Compiling...
TCU_xxxxx.spin
TCU_xxxxx.spin(2287:1) : error : PUB/CON list overflow
Line:
PUB MM_Read | ok
Offending Item:

This is the same line that Propeller Tool fails on. It changes if I delete constants.

Good thing is, now I have source so I can see where things go bad.

Thanks!

Duane Degn

I've run into this before. It's kind of strange that lots of constants causes a problem since adding constants doesn't increase the code size.

I think I just made due with fewer constants. Sorry, not much help.

David Betz

Duane Degn wrote: »

I've run into this before. It's kind of strange that lots of constants causes a problem since adding constants doesn't increase the code size.

I think I just made due with fewer constants. Sorry, not much help.

There must be a fixed-size table in the compiler. OpenSpin duplicates Chip's original compiler pretty closely so it probably has the same limits. They would probably be pretty easy to change in the OpenSpin source but Roy would know for sure.

doggiedoc

Just a guess, but on the off chance the 255 limit is per CON section, perhaps a second CON section would solve the problem. Like I said, just a guess.

Phil Pilgrim (PhiPi)

The original Spin compiler was written in X86 assembly. As such, I suspect there's a hard limit of 255 entires in the symbol table for each object, in order to facilitate byte-sized indexing. But, seriously, I think that limit is a Good Thing: a monolithic program that uses up more than 255 distinct symbols should probably be broken up into multiple objects anyway -- just for readability's sake.

-Phil

David Betz

Phil Pilgrim (PhiPi) wrote: »

The original Spin compiler was written in X86 assembly. As such, I suspect there's a hard limit of 255 entires in the symbol table for each object, in order to facilitate byte-sized indexing. But, seriously, I think that limit is a Good Thing: a monolithic program that uses up more than 255 distinct symbols should probably be broken up into multiple objects anyway -- just for readability's sake.

-Phil

While this is generally true, I don't think one should be forced into this by a limitation in the compiler. There is certainly no reason that OpenSpin needs to impose this limit except maybe if one of its design goals is to only support compiling programs that can also be compiled with the original x86 compiler. Also, there are some cases were a program might need lots of constants (but probably not variables or methods). Think of the implementation of a virtual machine with byte-sized opcodes. You might want a CON entry for each opcode.

Duane Degn

David Betz wrote: »

While this is generally true, I don't think one should be forced into this by a limitation in the compiler. There is certainly no reason that OpenSpin needs to impose this limit except maybe if one of its design goals is to only support compiling programs that can also be compiled with the original x86 compiler. Also, there are some cases were a program might need lots of constants (but probably not variables or methods). Think of the implementation of a virtual machine with byte-sized opcodes. You might want a CON entry for each opcode.

I was just about to say (almost) the same thing. While the limit doesn't effect many of my projects, some of my controller to robot communication protocols can have lots of opcodes I want to list. So far, listing the opcodes in a header file has kept this from being much of a problem but the limit of 255 constants per object seems like it's an unnecessary constraint.

Larry Martin

Hi, guys, thanks for all the info. Things got exciting for a while and I forgot to check back.

The limit did not seem to be 255, exactly. As I was trimming symbols, things started working at 255, but then I could add trivial symbols so there were more than 255, and it kept compiling.

In any case, since this was a special version, I deleted a bunch of unused code and associated symbols and got running again in an our or two.

BR,
Larry

Sapphire

Duane Degn wrote: »

So far, listing the opcodes in a header file has kept this from being much of a problem but the limit of 255 constants per object seems like it's an unnecessary constraint.

Duane,

How do you create a header file? I tried a .spin file with just CON but it says "No PUB routines found." Am I missing something?

msrobots

If this restriction applies per object you could put your constants in different sub Objects and access from the main object as

subObj#ConstantName

The sub Object has to have at least one PUB method (even if empty) or it will not compile.

Enjoy!

Mike

Sapphire

Thanks Mike. Apparently, I'm missing nothing, as in a PUB with nothing.

But this isn't so convenient, as all the constants then have to be referred to by header#constant.

I think I'll keep the number of constants below 255.

Kye

This issue makes porting the Omnia Creator interface library to spin difficult...

Duane Degn

Kye wrote: »

This issue makes porting the Omnia Creator interface library to spin difficult...

Another very good reason to get rid of this limit in new Spin compilers. I for one really want to use Kye's Omnia Creator with Spin.

localroger

I ran into a similar issue with my generic string function object. PropTool has to separately compile every instance of every object even if one object is used many times with DAT storage to make them all "the same." And there's a hard 64K limit on the cache for all these copies. I had to switch to BST (Brad's Spin Tool) for that development thread. BST might also be immune to this odd limitation.

Jeff Martin

Hi guys,

I think the issue is somewhat clouded. I can't duplicate it as purely a CON based issue. Attached is a simple test I created with 600 constants. It compiles fine with both the original Spin compiler and OpenSpin.

There are definitely limitations for things like PUBs/PRIs and others. I don't know of a CON limitation, but I may be forgetting something.


CON Test.spin

Jeff Martin

Here's an updated test, that includes 255 PUBs; just under the limit. Still no error like the one reported in this thread; so I'm missing something. I have a feeling the error is related to a symbol list generated by the compiler for use by the GUI, but I'd like to duplicate and prove/disprove that.

CON Test.spin

Roy Eltham

The pub/con list is an 8K buffer that holds the symbol names and information about each PUB function and CON entry. It's attached to the end of each child object during compilation so that a parent object can access the PUBs and CONs in the child. It is a limit per object, and it's arbitrary. I could easily increase the size of this buffer. It could also be changed to not use a fixed size buffer at all.

Heater.

It's kind of weird to have such arbitrary limits in applications now a days. Harks back to the days of 64K segments in DOS programs.

I can understand that perhaps there are other limits on Spin language constructs imposed by the nature of the Spin bytecodes or the Spin interpreter.

Jeff Martin

Thanks Roy!

That's what I suspected, it had to do with that symbol buffer; so symbol size is an issue in this case.

Here's an updated test object that causes the error at my 586th constant. Note: it'd be different with different sized symbols and method names / method count.

CON Test.spin

Since it is arbitrary, we can adjust it. We'll look into this.

Jeff Martin

Heater. wrote: »

It's kind of weird to have such arbitrary limits in applications now a days.

Things like this were implemented with a reasonable space based on estimates of usage. Remember, the compiler was written in x86 assembly to begin with. Now we have an easier means of handling otherwise arbitrary limitations so they don't become issues.

Duane Degn

Jeff Martin wrote: »

Note: it'd be different with different sized symbols and method names / method count.

This probably explains why this has happened to me several times. I often run into the 30 character limit on variable and constant names. Apparently I'm abbreviation intolerant.

Roy Eltham

Duane,

OpenSpin allows for symbol names up to 254 characters,

Heater.

On the one hand I think there should not be any arbitrary limits on the length of symbols.

OnTheOtherHandIThinkUsingVeryLongVariableAndMethodNamesIsPerhapsNotSuchAGoodIdea.

Heater.

Hmmm...that's interesting.

The forum software inserts a space after 50 consecutive printable characters thus breaking the entire meaning of my post.

So much for the semantic web idea.

average joe

CON overflow is an issue I've been bumping into for quite some time. At this point, my (network) host program hierarchy looks like this:

            BaseStation.spin
              │
              ├──NetHost.spin
              │    │
              │    ├──MemWrapper.spin
              │    │    │
              │    │    ├──SPI_Asm.spin
              │    │    │
              │    │    ├──Basic_I2C_Driver.spin
              │    │    │
              │    │    └──Settings.spin
              │    │
              │    ├──PacketDriverHost.spin
              │    │    │
              │    │    ├──XBee_ObjectC.spin
              │    │    │    │
              │    │    │    └──Settings.spin
              │    │    │
              │    │    ├──Numbers.spin
              │    │    │
              │    │    ├──MemWrapper.spin
              │    │    │    │
              │    │    │    ├──SPI_Asm.spin
              │    │    │    │
              │    │    │    ├──Basic_I2C_Driver.spin
              │    │    │    │
              │    │    │    └──Settings.spin
              │    │    │
              │    │    └──Settings.spin
              │    │
              │    ├──Numbers.spin
              │    │
              │    ├──Timer_better.spin
              │    │
              │    ├──mathsExtended.spin
              │    │
              │    ├──Settings.spin
              │    │
              │    └──Stack Length.spin
              │         │
              │         └──Parallax Serial Terminal.spin
              │
              ├──Numbers.spin
              │
              ├──FullDuplexSerial4portPlus_0v3.spin
              │
              ├──MemWrapper.spin
              │    │
              │    ├──SPI_Asm.spin
              │    │
              │    ├──Basic_I2C_Driver.spin
              │    │
              │    └──Settings.spin
              │
              └──Settings.spin

Settings.spin is the named constant file and as you can see, there are 7 instances of this file. I've been able to work around this limitation by selectively commenting and un-commenting sections for host and node but this can get tiresome. Although I know any changes won't end up in the PropTool, perhaps OpenSpin could have a setting to adjust this arbitrary limit?