CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Has anyone else noticed CCS have changed array maths.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 13528

View user's profile Send private message

Has anyone else noticed CCS have changed array maths.
PostPosted: Sun Oct 01, 2017 4:14 am     Reply with quote

Hi,

Was re-compiling an old program that has always generated an 'interrupts disabled to prevent re-entrancy' warning, because it uses a structure array access inside an interrupt, and it uses the int16 multiply to calculate the location needed in this. Given this is a modern PIC with a hardware multiplier, it is only a very few instructions, but was always slightly 'annoying', since such accesses are very fundamental. Had last compiled it on 5.070, and switched to 5.074, and was surprised to see the warning disappear.

A quick change backwards and forwards confirmed the change. On .074, the compiler is generating two copies of some of the integer maths routines, without being asked.
Has anyone else noticed this?.

Will have to investigate to see if it also applies to chips without the hardware multiply.

Can't see anything about this in the change list, except a mention of an optimisation bug being fixed in interrupt handlers.
It is still giving the warning in 5.072, and not in 5.073.
It is using 100bytes more ROM in my case.

So has anyone else noticed?.
Any issues seen?. (If anything I'd expect things to be better!...).

Current tests are looking hopeful for me.
PCM programmer



Joined: 06 Sep 2003
Posts: 20385

View user's profile Send private message

PostPosted: Sun Oct 01, 2017 6:59 am     Reply with quote

It still gives me a warning for divide by 16. It may have been removed for
for structures, but not for general math. This was tested with vs. 5.074.
Quote:

Executing: "C:\Program files\Picc\CCSC.exe" +FH "PCH_Test.c" +DF
+LY -T -A +M -Z +Y=9 +EA #__buildcount__="0" #__18F46K22=TRUE
>>> Warning 216 "PCH_Test.c" Line 23(1,2): Interrupts disabled during
call to prevent re-entrancy: (@DIV1616)
Memory usage: ROM=1% RAM=1% - 1%
0 Errors, 1 Warnings.
Build Successful.

Test program:
Code:

#include <18F46K22.h>
#fuses INTRC_IO,NOWDT,PUT,BROWNOUT
#use delay(clock=4M)

int16 timer1_value;

#int_timer1
void ccp1_isr()
{
timer1_value = get_timer1() / 3;
}


//=====================================
void main(void)
{
int16 value;
int16 result;

result=value/3;

while(TRUE);
}
Ttelmah



Joined: 11 Mar 2010
Posts: 13528

View user's profile Send private message

PostPosted: Sun Oct 01, 2017 7:40 am     Reply with quote

I think it is only the array index calculation that has been changed. Makes sense if you think about it, since it is always just a simple multiplication and addition, with the size determined by the RAM size of the chip. To add the whole library would be a lot bulkier (as you know we can trick it to do this if required), but it has always been a bit annoying, when you use anything other than a simple array, and end up with the warning. I was using a 2 dimensional array to hold lines of data and pointers to them. Far the easiest way to do what I wanted, but came with the warning, that I accepted. To suddenly have it disappear, was a surprise... Smile

So far been running since last night without any glitches, so it suggests the change hasn't brought any unwanted 'luggage', except a bit more code space used.
newguy



Joined: 24 Jun 2004
Posts: 1517
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Sun Oct 01, 2017 8:49 am     Reply with quote

It's nice that they changed it, but I didn't notice. Quite some time ago I did notice that same warning, so I dug a bit and found that a mul at the heart of an array access in an isr was to blame. To get round the warning, I encapsulated the multiplication in my own function, my_mult(), so as to force the compiler to use two different multiplications - one "virgin" for the isr, and the other, for everything else.
Ttelmah



Joined: 11 Mar 2010
Posts: 13528

View user's profile Send private message

PostPosted: Sun Oct 01, 2017 9:16 am     Reply with quote

That was neat. You can actually make the whole maths library 'duplicate' (just as with the delay functions), but it is quite cumbersome. Your approach was a neat way round.
jeremiah



Joined: 20 Jul 2010
Posts: 994

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 6:58 am     Reply with quote

newguy wrote:
It's nice that they changed it, but I didn't notice. Quite some time ago I did notice that same warning, so I dug a bit and found that a mul at the heart of an array access in an isr was to blame. To get round the warning, I encapsulated the multiplication in my own function, my_mult(), so as to force the compiler to use two different multiplications - one "virgin" for the isr, and the other, for everything else.


That's neat. A question on how this works:

Say one uses my_multi() which does a multiply and the main code does a multiply. What prevents the compiler from making one internal function for multiplying and simply just calling that both in the main and in my_multi?

Just wanting to make sure I understand so we don't get bugs down the line if the compiler decides to change how it does things.
newguy



Joined: 24 Jun 2004
Posts: 1517
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 7:14 am     Reply with quote

This was quite some time ago, so bear with me... I believe that I wrapped it in a #separate, which forced the compiler to treat it as a completely separate function.

The point about accessing an array is that (apparently until recently), CCS was using a multiply to figure out the offset into the array. That sort of implementation, of course, is going to be inlined by the compiler. In other words, bypassing your new multiply function. No need to disable interrupts anymore with that sort of code structure.

I can't take the credit for the idea. PCM, on a number of occasions I believe, has recommended wrapping printf in your own wrapper, my_printf(), for similar reasons. I was just following his lead when I did this with the multiply.
Ttelmah



Joined: 11 Mar 2010
Posts: 13528

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 7:26 am     Reply with quote

Yes, I too have wrappered printf here for quite a few things. For a program that has to do just one maths operation in a interrupt it makes an alternative to the #ORG solution (you can use an explicit #ORG before the interrupt handler so that the maths library routines used are loaded 'with' this, and then a separate one for the main code).
newguy



Joined: 24 Jun 2004
Posts: 1517
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 8:13 am     Reply with quote

Now I remember why I'd wrap printf in my own wrapper function: to reduce code size because CCS, by default, tends to inline printf.
Ttelmah



Joined: 11 Mar 2010
Posts: 13528

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 9:20 am     Reply with quote

Yes. Generally the CCS optimisation tends to be for performance, rather than for space. Tricks like this are then a way of switching this type of thing to a form that is slightly more compact. Especially when repeated calls are made using the same format.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group