[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | +--------------------------------+-------------------------------------+ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |