Hi,
Thanks for the clarification, I understand the problem.
writing "extern isr_name;" is perfectly fine for me, just had to know it!
Would that make its way into the documentation as a tip?
could this be implemented as a #pragma symbol USED or another declarator
attribute one day or another?
Regards
Sebastien
On Tue, Jul 20, 2010 at 11:38 AM, Raphael Neider <rnei...@web.de> wrote:
> Hi,
>
> C is a bit lax with types -- if there is none given, it often assumes int,
> as in ''extern portb_isr'', which is (correctly) interpreted as
> ''extern int portb_isr;''.
>
> >> For a SIGHANDLER that is defined in the SAME file, I have to forward
> >> declare it using: SIGHANDLER(portb_isr); ; extern portb_isr fails with:
> >> main.c:162: error 98: conflict with previous definition of 'portb_isr'
> >> for attribute 'type'
> >> from type 'int fixed'
> >> to type 'void function ( ) fixed'
>
> This is to be expected -- mismatches in the type of the declared object
> and the type of its implementation should at least be warned about.
>
> >> for a SIGHANDLER that is defined in ANOTHER file, I have to extern
> >> declare it using : extern i2c_slave_isr; extern
> >> SIGHANDLER(i2c_slave_isr); fails with:
> >> main.asm:247:Error [113] Symbol not previously defined (_i2c_slave_isr).
> >> main.asm:247:Error [113] Symbol not previously defined (_i2c_slave_isr).
>
> This is a bug in the PIC16 target of SDCC. As sdcc does not see a reference
> to the declared function, it drops it from the list of symbols to pull in
> from other modules. This is often useful, preventing the .asm files from
> EXTERN declaring each and every symbol that occurs in any of the
> (transitively) included header files.
> In this case, however, the assumption that unreferenced symbols are not
> required is plain wrong.
>
> I have no precise idea why 'extern foo' works -- probably (global)
> variables are treated different from functions; if I had time, I would
> look into this, but right now, we will have to remember that extern foo
> works or implement interrupt handlers in the main .c file.
>
> >> The errors are different!
> >> And the messages are even formatted differently :-)
>
> The first error message originates from SDCC (who can and does find a
> type mismatch as declaration and definition are visible at the same
> time/in the same file in this case), the second one is from the
> assembler (from the gputils project), who stumbles upon the lacking
> 'extern' declaration that sdcc/pic16 so conveniently decided not to
> emit.
>
> The error output is to be expected and perfectly fine for me.
>
> > Well, this is AFAIK, but the SIGHANDLER is a macro, not a C language
> > construct. Your 'forward declaration' probly does something, but not
> > what you want.
>
> If the PIC16 target code was right, the macro would work just fine.
>
>
> Best regards
>
> Raphael
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
