Hi Raphael,
thanks for the patch. I will try it over the weekend, right now I do not
want to take any risks that might screw up my environment, no matter how
small the risk is.
The '(mandatory!) __asm return __endasm;' (LOL) workaround fixed the
immediate issue for me.
>
> Currently, the compiler assumes all local/temporary variables to reside in
> the access bank; moving them to arbitrary memory locations is not that
> easy (on first sight), as this assumption also holds during register
> allocation and I do not readily know how to change that (nor if there is a
> single place to do so...)
Actually I would be happy with just being able to tell the compiler not to
emit (for a given filen):
;Internal registers
registers udata_ovr 0x0000
but to emit:
;Internal registers
registers udata 0x0000
so that the registers in that file would not be overlaid with register in
an other file. I'm quite happy to leave all the internal registers in
the access bank, actually, that is ideal, but when they are overlaid with
registers in an other file it makes it necessary to save/restore them.
Also forcing all variables defined in a single file to some given bank
would allow be a useful option as it would allow easier use of the
--pno-banksel option, but of course I can force the addresses of
variables so this is no big deal.
Ok - any way, thanks again for the excellent support of SDCC/PIC.
br Kusti
> From: Raphael Neider <rnei...@web.de>
> Reply-To: <sdcc-user@lists.sourceforge.net>
> Date: Mon, 9 Mar 2009 23:24:02 +0200
> To: <sdcc-user@lists.sourceforge.net>
> Conversation: [Sdcc-user] PIC port, __naked not working, Bus error, signal 11:
> SIGSEGV
> Subject: Re: [Sdcc-user] PIC port, __naked not working, Bus error, signal 11:
> SIGSEGV
>
> Hi Kusti,
>
>> After a lot of pruning I got the code down to:
>>
>> unsigned char x;
>>
>> void test() __naked {
>> if (x) {
>> x = 1;
>> }
>> }
>
> Very good work; this helped a lot!
>
>> which when compiled with parameters:
>>
>> SDCCFLAGS = "-Wl,-m,-s 18f4550.lkr" -mpic16 -p18f4550 \
>> --disable-warning 85 --std-sdcc99 --obanksel=3 --pno-banksel
>>
>> produces SIGSEGV .
>>
>> If I remove the __naked the problem disappears, but I'm back in square
>> one.
>>
>> So this appears to be compiler bug. I tried to look for this in the list
>> archives but I could not find anything related to that.
>>
>> Now I have specific questions:
>>
>> 1) Should I file a bug?
>
> No need: please find a patch attached.
>
> The bug removes an invalid cast of a pCodeLabel into a pCodeInstruction
> and stays safe in that no (new) NULL pointer dereferences can occur. Code
> triggering this bug is likely to be buggy (a label with no instruction
> following is probably not a good thing to have; and I think this is the
> only circumstance at which this particular bug is triggered), so the risk
> of fixing this is low. The benefit would be one less obstacle for those
> experimenting with the __naked keyword using the pic16 target.
>
> @Borut: Shall I include this into 2.9.0 (would be my vote) or wait till
> after its release?
>
> Kusti, can you apply the attached patch locally and check if your
> originally failing code compiles with the patch?
>
>> 2) How can I circumvent this?
>
> Adding the (mandatory!) __asm return __endasm; to return to the calling
> function worked around the issue for me.
>
>> My actual problem is that the compilers emits a lot of code like:
>>
>> 002C C000 FFE5 01503 MOVFF r0x00, POSTDEC1
>> 0030 C000 FFE5 01504 MOVFF r0x01, POSTDEC1
>> 0034 C000 FFE5 01505 MOVFF r0x02, POSTDEC1
>> 0038 C000 FFE5 01506 MOVFF r0x03, POSTDEC1
>> 003C C000 FFE5 01507 MOVFF r0x04, POSTDEC1
>> 0040 C000 FFE5 01508 MOVFF r0x05, POSTDEC1
>>
>> that I would like to avoid, all I want is for the compiler to allocate
>> these are global variables used solely by the interrupt so that there
>> is no need to save/restore them...I know 'naked' alone would not do this
>> but it seems like a necessary step in getting there...?
>
> Currently, the compiler assumes all local/temporary variables to reside in
> the access bank; moving them to arbitrary memory locations is not that
> easy (on first sight), as this assumption also holds during register
> allocation and I do not readily know how to change that (nor if there is a
> single place to do so...). You might file a feature request for this so
> that it is not lost.
>
>> 3) I seem to recall some list discussion relating to PIC / inline
>> assembly and that it does not work or something but I cannot
>> find that discussion. Is there a problem there?
>
> Ummm, well, I am not aware of problems in conjunction with inline
> assembly, except that accessing local variables/parameters passed into a
> function is not easily possible (inspection of the .asm to map locals to
> r0xYYs and hoping the assignment survives the next compilation is not
> really suitable, but the best I have to offer right now).
>
> Best regards,
> Raphael
------------------------------------------------------------------------------
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
