Missing optimisations, non-optimal defaults?

[ioncube]

Hi CCS
Just got CCS M to play with and it's going well so far, thanks for a good value tool. I did spot a few cases where a basic optimisation opportunity was missed though, and I wondered if these simply aren't done, or whether the MPLAB defaults aren't the maximum. If they are, perhaps these cases could be handled in a future update.

For example:

* Jumps to jumps. This can happen with the break of the last case block in a switch statement. Omitting the break is a fix.

* bit test rewriting
Example:

[PCM programmer]

Regarding switch-case statements, read Ttelmah's comments:
http://www.ccsinfo.com/forum/viewtopic.php?t=47315
http://www.ccsinfo.com/forum/viewtopic.php?t=45415

[Ttelmah]

Also, understand _this is not CCS_. This is a user forum. If you want to suggest optimisations to them, then you need to talk to them....
Read the top right corner of the forum page. Box there. Second line down.

Best Wishes

[ioncube]

Thanks for the replies, and I got that it's not a CCS operated forum. I wittingly posting here and had been reading over the last week or two before purchasing.

Working on a project to finally build light switches for the house (partner has enough of t&e and cat5 poking out of the wall!) and just getting to know the code generator to see what coding styles give the best code and when to #asm.

byte x = (y & 1 ? 10 : y & 2 ? 11 : y & 4 ? 12 : 0);

that can be coded with sequence of movlw and btfsc operations was another poor one. Inefficient mults by small constants I saw the other day too; e.g. i + i + i is fine whereas i * 3 is not. Normally I code in asm so can always drop out to that when needed, and if not pushed for speed and space then it's no big deal anyway. Productivity gains of C should really help on this one.

[RF_Developer]

You're writing C, So write C unless its absolutely necessary. I personally doubt that any home automation application needs assembly for any purpose whatsoever. Yes, if you are using the very smallest PICs then it might be justified on code size grounds, but for speed, no. Programming is not some contest on who can write the fastest possible code. Professional programming is often about meeting requirements in the shortest practical development timeframe, and that pretty much means no assembler.

I know you come from an assembly background. Many of us have done all sorts of hardware, assembler for all sorts of processors: micro, mini and mainframe, as well as lots of C, C++, C#, Java, Algol, Fortran, Basic, etc, etc. Pretty much all of us will program PICs in C alone. There being no need ever to go to assembler. If we really have a problem that needs pure speed, then we sure wont be using PICs, we'll, be using something with far more grunt. What I am trying to say is try to change your mindset to a C one. Forget assembler for now. Write in C. Sure the C won't be optimal for speed, nor size, but unless that really matters, it doesn't matter.

RF Developer.

[RF_Developer]

[Ttelmah]

Not quite.
Though the multiplication itself needs only one cycle, the hardware multiply on the PIC doesn't support as many addressing modes as things like simple addition, so typically takes a cycle more, while you move things around. Hardly 'major' though. Using the CCS libraries, + and - using 8bit int's, take 3 machine cycles, while * takes 4.
However I'd disagree with "most if not all currently used PIC's have at least an 8x8 bit hardware multiply". _None_ of the PIC 16's do, and for a lot of stuff, including tiny embedded controllers of the type being talked about, these are still the commonest chips. In fact I think these are the commonest chips in existence, in things like RFID tags etc.. One project I was involved with moved 42million of these last year.

However I'm wondering what compiler version is being used here.

[ioncube]

Thanks for the replies, the PIC community is great.

Of course I know that some PICs have the hw mults, just as I know that the ones I'm using right now don't I often use 12f683's (my favourite PIC so far), and right now a 16f688 as I've an ICD header for it. After proof of concept I need a 16 with self write so the light switches can receive firmware updates.

I started on Z80's and 6502's as a kid and my projects tend to be pushing PIC's to the limits where every cycle counts, so asm's been a good choice for me; the last 683 project was emulating a 1-wire memory slave combined with IR sender to control our office aircon with cron jobs, from PHP, remotely etc. In asm and without an xtal for a higher clock it was a challenge, in pure CCS C it would likely have been impossible. For this task though a compiler seemed a good choice because as RFD said performance shouldn't be an issue, though there's still PWM to do on leds in the switches, LED animations and other odds and ends, so any grossly inefficient code could be an issue. Much as I like asm, of course it is nice to be using C for a change as certain effort just goes away which is what I wanted here.

The biggest challenge though in all this will be fitting it in a UK single light switch backbox, and finding some small IDC connectors for the cat5. That's where I predict issues.

[asmboy]

[ioncube]

T&E in the wall is a "backup" plan in case the networked switches didn't work or get done, and have given us some minimal control in a few places. It's an 1822 house that had to be rewired, including an extension at the back with a low ceiling that we gutted to raise the ceiling and floor above by a foot. Lots of new steels including one extra that we got in the wrong place to support the raised floor upstairs. Perfect chance to slap in some networks A 1-wire cat5 network snakes around the house for temperature sensors. Cat5 for an rs485 net loops between the wall sockets. DMX for lights. FitPC on the wall in a cupboard runs the networks and some other stuff. Small HDMI touch screen on the other side of the wall programmed with QML gives a basic interface that has new features creeping in as and when there's time. Loads of unnecessary wiring and some that has got lost, but an interesting project.

X10 is hopeless for scene setting (been there, done that), though the stick-a-switches are not too bad provided that you have an RF receiver into a USB port (built one of those) to give no perceptible latency. I want the wall switches to have LED's for status feedback, so realistically batteries are out. Going mostly for Halers Evoled LED lights which dim surprisingly well in tests so far off cheap Chinese DMX dimmer packs.

[asmboy]

is this going to be a theater ( or theatre ?) or residence ?
or something else entirely ?

and even though the wiring may be there - have you considered something simpler than an ethernet ? ( and wireless) like Zigbee etc etc ?

I see you mentioned RS485 - and I am sure you could run THAT on an ether twist cable ( you don't mean you have ancient ethernet COAX right ? )

[ioncube]

This is for home. I used the cat5 (pink clipsal stuff) for the 1-wire network and light switches. It's simple rs485 rather than ethernet, cat5 is just a convenient cable to use. RF would work, but I'd go for 434 or 868Mhz rather than the Ghz range with zigbee and others.