It means there are local variables or function arguments that need 64K or more. In the default setup, the C stack has space for 512 bytes (starting at 0x700 and growing down).
[..]
local 32761 of size 2 @ offset 65518
local 32762 of size 2 @ offset 65520
local 32763 of size 2 @ offset 65522
local 32764 of size 2 @ offset 65524
local 32765 of size 2 @ offset 65526
local 32766 of size 2 @ offset 65528
local 32767 of size 2 @ offset 65530
local 32768 of size 2 @ offset 65532
local 32769 of size 2 @ offset 65534
rcc: ./build/gt1.c:4437: local: Assertion `offset < 0x10000lu' failed.
Utils/lcc/build/lcc: fatal error in Utils/lcc/build/rcc
Makefile:266: recipe for target '../nanotode/test/connectome.o' failed
make: *** [../nanotode/test/connectome.o] Error 1
Is there a way to identify what is causing it in the source I am trying to compile? I might be able to rework it to stop this.
jurkstas wrote: ↑10 Aug 2019, 17:19
Is there a way to identify what is causing it in the source I am trying to compile? I might be able to rework it to stop this.
I isolated 'my' troublesome expression (it comes from mscp.c) by trial and error: using #if 0...#endif to disable large chunks of the C program until the error disappears or changes. The way I understand it, any nested expression with * / << or >> can potentially trigger this.
In new programs it's easy to workaround it. I still have hopes we can find a fix once we can put our mind to it. It will be a great boost for the memory card subproject. (But we always have cc65 as a backup for that.)
That being resolved, should I move to another topic or just rename this topic to something like "compiling nanotode library" and continue with other troubles?
Now I get this:
Application uses 656 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 8183 bytes for local variables. Maximum is 8192 bytes.
I just judge by glancing over the source code. When you're writing new code, it becomes evident along the way because you have the intermediate .gt1 files. You can dump these with Utils/gt1dump.py to see where you are. The author sure didn't add a lot of user messages, and when it crashes, it leaves nothing behind. Well, he did call it "rudimentary" for a reason.
656+9 bytes isn't too much by itself, but under 32K everything must be distributed over 96-byte segments as well. With code the compiler fixes that for you. With data it can't do that. I couldn't compile mscp.c yet for that reason: it needs the large unsegmented chunk above 32K.