sdcc-user

[Sdcc-user] Internal registers not found

[Alan C. de A. <ac...@gm...>]

Hi,
I'm compiling the last file from PICos18 RTOS, the prog_man.c file.

I am getting some strange errors:

pro_man.asm:1185: error: Symbol not previously defined (INTCON).
pro_man.asm:1185: error: Symbol not previously defined (INTCON).
pro_man.asm:1188: error: Symbol not previously defined (BSR).
pro_man.asm:1190: error: Symbol not previously defined (FSR2H).
pro_man.asm:1193: error: Symbol not previously defined (TBLPTRU).
pro_man.asm:1194: error: Symbol not previously defined (TBLPTRH).
...

Searching at google I found some "Symbol not previously defined", but
nothing related to theses registers.

Looking at generated asm file (prog_man.asm) I verifyied these
registers are not defined, only STATUS, WREG, FSR0L, FSR0H, FSR1L,
FSR2L, INDF0, POSTDEC1, PREINC1, PLUSW2 and PRODL.

Reading the manual I think I found why it is not happening:

"The compiler does not do any validation of the code within the _asm
... _endasm; keyword pair. Specifically it will not know which
registers are used and thus register pushing/popping has to be done
manually."

Maybe the compiler don't define the registers because they are used
just into asm ... endadm pair.

But I don't know how to instructs the compiler to define they when
generating the asm file. I tested defining theses register manually
inside the generated .asm file and it works.

Cheers,

Alan

Re: [Sdcc-user] Internal registers not found

[Vangelis R. <vr...@ot...>]

Alan Carvalho de Assis wrote:
> pro_man.asm:1185: error: Symbol not previously defined (INTCON).
> pro_man.asm:1185: error: Symbol not previously defined (INTCON).
> pro_man.asm:1188: error: Symbol not previously defined (BSR).
> pro_man.asm:1190: error: Symbol not previously defined (FSR2H).
> pro_man.asm:1193: error: Symbol not previously defined (TBLPTRU).
> pro_man.asm:1194: error: Symbol not previously defined (TBLPTRH).
> ...
>
> Reading the manual I think I found why it is not happening:
>
> "The compiler does not do any validation of the code within the _asm
> ... _endasm; keyword pair. Specifically it will not know which
> registers are used and thus register pushing/popping has to be done
> manually."
>
> Maybe the compiler don't define the registers because they are used
> just into asm ... endadm pair.
>   
You can define externs for each symbol, for example:
    extern INTCON;
    extern BSR;
    extern FSR2H;
    extern TBLPTRU;
    extern TBLPTRH;

this should eliminate your problems.

By the way, I've managed to compile a previous version of FreeRTOS. I 
also have send it to the
FreeRTOS development team, but unfortunately it has been turned down.

regards,
Vangelis Rokas

Re: [Sdcc-user] Internal registers not found

[Alan C. de A. <ac...@gm...>]

Hi Vangelis,

2007/11/7, Vangelis Rokas <vr...@ot...>:
> You can define externs for each symbol, for example:
>     extern INTCON;
>     extern BSR;
>     extern FSR2H;
>     extern TBLPTRU;
>     extern TBLPTRH;
>
> this should eliminate your problems.
>
unhappily it don't eliminated my problem :-(

Placing these externs give errors like this:
pro_man.c:74: extern definition for 'FSR2H' mismatches with declaration.
pic18f2680.h:5902: previously defined here

I tested just copy these definitions from pic18f2680.h:
extern __sfr __at (0xFF2) INTCON;
extern __sfr __at (0xFE0) BSR;
extern __sfr __at (0xFDA) FSR2H;
...

But still getting the old error:
pro_man.asm:1185: error: Symbol not previously defined (INTCON).

Please, some other suggestion?

> By the way, I've managed to compile a previous version of FreeRTOS. I
> also have send it to the
> FreeRTOS development team, but unfortunately it has been turned down.
>

Hmm, very interesting. But I need an OSEK compatible RTOS. I contacted
PICos18 author, but he don't have time to help me "port" it to SDCC.
He said me PICos18 uses many MPLAB C18 features and it will not works
easily on SDCC.
But I don't have choice, I don't have Windows and don't like it.

> regards,
> Vangelis Rokas
>

Thank you very much!

Cheers,

Alan

Re: [Sdcc-user] Internal registers not found

[Raphael N. <rn...@we...>]

Hi Alan,

> But still getting the old error:
> pro_man.asm:1185: error: Symbol not previously defined (INTCON).

Your main problem is, that SDCC (currently) does not emit plain
	extern INTCON
but the mangled
	extern _INTCON
(note the leading underscore).
You need to replace all references to C-defined entities
(BSR, INTCON, ...) with an underscore-prefixed variant (_BSR, _INTCON)
throughout the whole project.
Furthermore, C symbols are also declared as _SYMBOL rather than SYMBOL,
thus inline assembler must refer to
  int foobar;
as
  _asm movff _foobar, _STATUS_save _endasm;

I attached a picos18-archive with modifications to make it compile on
SDCC; you may want to diff it against your version to find the numberous
changes throughout the code base.
Be warned: Though I could compile the project, I could not test test it.
There may be subtle conversion errors that you might already have worked
around...

I also changed the device to 18f4520, for different devices, you need to
adjust (a) devices.inc and (b) the ARCH variable in Makefile. It is
probably cleaner to avoid devices.inc altogether...

Regards,
Raphael

Re: [Sdcc-user] Internal registers not found

[Alan C. de A. <ac...@gm...>]

Hi Raphael,

2007/11/8, Raphael Neider <rn...@we...>:
> Hi Alan,
> I attached a picos18-archive with modifications to make it compile on
> SDCC; you may want to diff it against your version to find the numberous
> changes throughout the code base.
> Be warned: Though I could compile the project, I could not test test it.
> There may be subtle conversion errors that you might already have worked
> around...
>

Thank you very much Raphael! I saw your changes are similar the
changes I'm doing here. So it is a bode well for me :-). Unhappily I'm
trying PICos18 v2.10 and the version you compiled is v1.11.

> I also changed the device to 18f4520, for different devices, you need to
> adjust (a) devices.inc and (b) the ARCH variable in Makefile. It is
> probably cleaner to avoid devices.inc altogether...
>

Cool! I was using piklab to make it but will use your Makefile as model soon.

All problems related to internal registers go away, my problem now is
because pro_man.h uses functions defined at kernel.asm (yes native
assembly file, no automatically generated one) and compiler don't
found it:

sdcc -mpic16 -p18f2680 -V -I/home/alan/pic/picos18/ -c pro_man.c
pro_man.c:82: #pragma udata: bad argument(s); pragma ignored
pro_man.c:103: #pragma udata: bad argument(s); pragma ignored
pro_man.c:124: #pragma code: bad argument(s); pragma ignored
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/gen.c:2097
returning register AOP_ACC (null)
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/gen.c:2097
returning register AOP_ACC (null)
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/gen.c:2097
returning register AOP_ACC (null)
pro_man.asm:1228: error: Symbol not previously defined (_parser_organize).
pro_man.asm:1309: error: Symbol not previously defined (_kernel).
pro_man.asm:1398: error: Symbol not previously defined (_sched).
pro_man.asm:1512: error: Symbol not previously defined (_restore_start_adr).

These functions are defined as extern and prefixed by underscore at
the header file, but the compiler is not placing they at "extern
variables in this module" section into generated asm file. I tested
removing the underscore from header declaration with no success.

> Regards,
> Raphael
>

Thank you very much,

Alan

Re: [Sdcc-user] Internal registers not found

[Raphael N. <rn...@we...>]

Hi Alan,

Sorry for having ported the wrong version; I just googled for picos and
found that one...

> These functions are defined as extern and prefixed by underscore at
> the header file, but the compiler is not placing they at "extern
> variables in this module" section into generated asm file. I tested
> removing the underscore from header declaration with no success.

Yes, this is a bug... Unused (or ones used only in inline assembly
fragment and thus effectively hidden from the compiler) extern
declarations are discarded; as a consequence, they do not appear in the
.asm file as EXTERN SYMBOL nor EXTERN _SYMBOL and hence cannot be
resolved by the assembler. Sigh...

The really bad workaround is to effectively access the symbols in c:
    extern void _kernel(void);
with _kernel being only referenced in _asm ... _endasm; blocks such as
    _asm goto _kernel _endasm;
should (for now) be rewritten as
    extern kernel; // Note: SDCC mangles this into _kernel
    static void *k = &kernel; // WORKAROUND SDCC BUG

As I said, the workaround is really bad: It is both a maintenance
nightmare and even costs memory space at runtime! I really need to look
into a way of emitting even unused externs...

Assembler symbols with no leading underscore need to be rewritten in the
defining .asm (or better .S) file to have a leading underscore if they
are to be accessed from C (which includes all symbols that need the
above workaround):

	global tsk_1_stack
tsk_1_stack res 15
	global great_function
great_function:
	return

becomes
	global _tsk_1_stack
_tsk_1_stack res 15
	global _great_function
_great_function:

Alternatively one might introduce an option for SDCC not to add a
leading underscore to user-defined symbols, probably risking name
clashes with compiler-defined symbols...

Regards,
Raphael

Re: [Sdcc-user] Internal registers not found

[Alan C. de A. <ac...@gm...>]

Hi Raphael,

2007/11/8, Raphael Neider <rn...@we...>:
> Hi Alan,
>
> Sorry for having ported the wrong version; I just googled for picos and
> found that one...
>

Don't worry, your port help me too.

> Yes, this is a bug... Unused (or ones used only in inline assembly
> fragment and thus effectively hidden from the compiler) extern
> declarations are discarded; as a consequence, they do not appear in the
> .asm file as EXTERN SYMBOL nor EXTERN _SYMBOL and hence cannot be
> resolved by the assembler. Sigh...
>

Sure, before using your workaround I tested just placing this symbols
at generated .asm and it was assembled fine. Also placing the internal
registers at "Equates to used internal registers" solve the internal
register problem.
Maybe if the preprocessor start analyzing the used symbols (extern
functions and internal registers) into _asm/_endasm; block this
problem can be solved. Just my 2cts, I don't understand about compiler
internals.

> The really bad workaround is to effectively access the symbols in c:
>     extern void _kernel(void);
> with _kernel being only referenced in _asm ... _endasm; blocks such as
>     _asm goto _kernel _endasm;
> should (for now) be rewritten as
>     extern kernel; // Note: SDCC mangles this into _kernel
>     static void *k = &kernel; // WORKAROUND SDCC BUG
>

Work fine now! ;-)

> As I said, the workaround is really bad: It is both a maintenance
> nightmare and even costs memory space at runtime! I really need to look
> into a way of emitting even unused externs...
>

Yes, I verified SDCC only declares symbols used in pure C, if this
symbols are used in assembly code only it is discarded.

> Assembler symbols with no leading underscore need to be rewritten in the
> defining .asm (or better .S) file to have a leading underscore if they
> are to be accessed from C (which includes all symbols that need the
> above workaround):
>
>         global tsk_1_stack
> tsk_1_stack res 15
>         global great_function
> great_function:
>         return
>
> becomes
>         global _tsk_1_stack
> _tsk_1_stack res 15
>         global _great_function
> _great_function:
>

All right, really these functions are defined prefixed by underscore
at kernel.S (formally kernel.asm)

> Alternatively one might introduce an option for SDCC not to add a
> leading underscore to user-defined symbols, probably risking name
> clashes with compiler-defined symbols...
>

I think it is not a big problem, but solving it make possible the
portability among MPLAB C18 and SDCC codes.

> Regards,

Thanks for you useful help and explanation!

> Raphael
>

Alan