Raphael,

I am looking for "TRUE" reentrant code. Have a small multi-tasking OS in use. I have not
tried SDCC for a few months and the previous register save/restore used reserved names.

Each task has it's own RAM page for stack and BSR referenced data but the sdcc data
was using the shared page 0 access. I also would adapt my system to fit whatever
scheme sdcc might generate.

George

On Fri, 2005-10-14 at 00:36 +0200, Raphael Neider wrote:
Hi George,

> I am switching from 18f252 to 18f2520 to get the extra instructions that
> support looking into the software stack. Is there support in sdcc for this
> chipset

Well, no. But probably the -mpic16 -p18f252 settings will just work?
(Hmm, this might set off gpasm complain about "invalid/unsupported
mnemonics"...)

Are these two devices really different with respect to the SFRs?

You might also try the AllPics Project by Beau E. Cox, sources available
from his posting here in 22-09-2005 or via email directly from the
developer at <mailto:beaucox@hawaii.rr.com> (there seems to be no
website hosting the project right now, is there?).

If all fails, I might add the 18f2520 manually. Just drop me a line.

> and Is there support for reentrant routines?

Hmmm....
The good news is: Yes, '<TYPE> func(<ARGS>) __reentrant' is supported.
Another good news is that I think the PIC16 backend always generates
reentrant code (according to NOTES it does, ignoring __reentrant).

The bad news is that I'm not sure about this and might have to read a
lot of code in order to check this out :-(.
(I actually did skim through gen.c and did not find non-reentrant code
being emitted; I just cannot guarantee it.)

Another noteworthy point: the PIC16 port's idea of reentrant functions
seems to be restricted to nested function calls, i.e. you can have a
call to f while executing f (either directly through direct/indirect
recursion or by having f interrupted and calling f in the handler
again), but you cannot have f executed in two "threads" and interleave
f's execution like

start f, thread A
interrupt thread A, switch to B
start f, thread B
interrupt thread B, switch to A
finish f, thread A <-- this would use f(B)'s access bank variables
interrupt thread A, switch to thread B
finish f, thread B <-- this would use use access bank values as present
                       just before calling f in thread A

(well, in this approach you might have to save/restore the access bank
anyway during the thread switch I suppose...)

Regards,
	Raphael Neider




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user