gnupic: sdcc init code takes up too much space in PIC
Subject:
sdcc init code takes up too much space in PIC
From:
"R. Timothy Edwards" ####@####.####
Date:
10 Jun 2007 19:00:06 +0100
Message-Id: <466C3C1E.6020008@multigig.com>
Dear David,
>> Admittedly, the 16F676 has a meager amount of memory and is probably
>> not the best thing to be compiling code for
> Yep. You probably already know this, but when you compile code from C,
> there's a little bit of fixed overhead along with a little bit of
> variable overhead. On your chip, the fixed overhead probably eats up
> most of your RAM. Plus in C it's easy to make much bigger programs
> RAM-wise without realizing it.
I guess I should have explained that my original purpose in delving
into the sdcc and gputils code is that my colleague at work has a
USB-based digital I/O system that he designed around a PIC 16F676,
and he wrote the program for it using the sdcc/gputils/picp flow.
We decided to get that flow up and running at work, so we could use
PIC processors as interfaces into evaluation boards for our own chip
product line (we're a fabless semiconductor startup company). So I
was surprised to find that I used the same flow to compile the
program for the digital I/O board, and found it wouldn't compile.
After some days of looking into the source, and getting enormously
useful feedback from the people reading this mailing list (all of
whom have been quite restrained in not calling me an idiot), I've
located the source of the problem in the assembly code for the
program. The original version was compiled by an older version of
sdcc, and puts in the most trivial possible initialization code (it
jumps directly to the program). Recent versions of sdcc drop in a
sizeable block of initialization code and immediately grabs 32 bytes
of RAM under the heading "sharebank udata_ovr 0x0020" and another 14
under "UDL_usb1_0". This takes up more than half of the available
RAM on the 16F676. In other words, the "fixed overhead" used to be
almost nothing, and has become bloated until it prevents sdcc from
being useful on small devices (isn't that what "sd" in "sdcc" stands
for? Maybe they should rename it "mdcc").
I can hand-edit the .asm file to remove the call to __sdcc_gsinit_startup,
and replace it with the original (inlined) startup "goto" statement,
and the program compiles and links properly. So I'll quit the
discussion here and take it over to an sdcc forum, unless anybody on
this mail list has any ideas on less kludgy ways to grab back the RAM
space used by the sdcc init routine.
Thanks,
Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: ####@####.#### |
| MultiGiG, Inc. | web: http://www.multigig.com |
| 100 Enterprise Way, Suite A-3 | phone: (831) 621-3283 |
| Scotts Valley, CA 95066 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
