Bloody tired of this... 3.201 code size

[dbotkin]

Man, it just gets worse. I have an application that *barely* squeezes into a 12F675. PCW 3.184 compiled it to 1017 words. So I tried 3.190 -- 1030 words. Opened a case with CCS. Exchanged email, but of course only when I prompted them. Case open for several weeks now, no response, no fix forthcoming. Now I see 3.201 available and try it -- 1043 words. If I use #opt 10 it's even worse.

If we had not gone through this exact same thing before I wouldn't be as frustrated with them, but we have, and I am. If I hadn't opened a support case and given them a few weeks to work on it I wouldn't be as frustrated, but I have, and I am.

Now it looks like I'm stuck with 3.184 for the foreseeable future. Grrr.

[Darren Rook]

I can't give a good answer (I haven't seen your case), but realize that in order to fix a bug it usually means adding more code to fix the problem.

[dbotkin]

Email IDs are 4DA481 & 4DC243. It's not hard to figure out, and CCS fixed this exact same problem several revs back. It's a poor choice of coding when doing a bit test. Now it's broken again. Very frustrating. Even more frustrating is the lack of response from CCS; it's been a month since I sent the first report, and over twoo weeks since the CCS person (who did not bother to mention their name or anything, of course) asked for more information, which I supplied on 5/10. It appears that nobody cares.

[Darren Rook]

I compiled your code and you have 7 bytes free. It's very possible that any bug fixes since 3.184 made have caused it to grow over the 7 bytes. You may be hearing people talking about 10% optimization in the newer compilers, but that is PIC18 only.

[dbotkin]

Darren,

Actually, the compiler steadfastly refuses to use anything past 1020 anyway (try adding four NOPS and see what happens), which is another thing I've been waiting for a fix on for many moons, but that's beside the point. If you diff the list files, it's pretty easy to see where the problem is. As I said, I reported this same exact problem with an earlier version, and it was subsequently fixed. What "bug fix" would cause every bit compare to go from two instructions to three? It doesn't seem to make a lot of sense. To me it looks like that *IS* a bug itself.

I don't expect a 10% gain in optimization, since I've already hand-optimized large sections of the code anyway. What I do expect is for it not to get any worse, which is exactly what has happened. And it's getting worse with each release. 3.190 was bad, 3.201 is considerably worse.

[Darren Rook]

Which files am I diffing? You are assuming that I have all the files, I don't.

All I know is that you have 7 bytes free, and it's easy to lose 7 bytes. I don't know how much more code is being added since 3.184, you are not telling me.

I can't help you if you don't provide more information.

[dbotkin]

Sorry, since you had one file to compile I thought you had all of it that I sent in a while back. I got a response to my initial email asking me to compile it fot 16F877 with 3.184 and 3.190 and send those two LST files. I did, though I used the 12F683 instead of the 16F877 so I wouldn't have to rewrite a bunch of device-specific stuff. That's the lasst I heard from CCS.

The code went from 1017 words (3.184) to 1030 words (3.190) to 1043 words (3.201). At this rate I'll need to switch to a 16F877 by the time V4 comes out anyway. I can send you the source and LST files if you want; I've already sent them to one of the support guys, but if you want to take a look I'll be more than happy to send you a copy as well.

[Darren Rook]

I found the problem (bit tests got less effecient) and passed it off to the developer. I don't have access to modify the compiler. Hopefully he will fix it soon, thankfully for you he works on weekends so maybe in 3.202.

[dbotkin]

Thanks, Darren. Maybe a comment line in the compiler source noting not to change it back would be in order -- someone keeps doing it!

If you've got one of those bloody mainframe-sized 18Fs or an '877 to play with, sure, a dozen words or so is usually not a big deal. In this case, though, there's literally nowhere to go from the 12F675 for this application. I'm told the '683 will be available some day, but we've heard that from MCHP before so I'm not counting on it!