There are a large number of PIC related bugs in the bug tracker. I am
willing to tackle them, but I don't seem to understand how to run the PIC
specific regression tests. After building and install gputils and gpsim, I
go back to sdcc/src/regression and run make. This results in
../../bin/sdcc -mpic14 -c -pp16f873 b.c
Processor: p16f873
b.c:2:21: p16f873.h: No such file or directory
Temporary ERROR: at the moment you have to use
an include file create by inc2h.pl. See SDCC source:
support/scripts/inc2h.pl
this is a nuisance bug that will be fixed shortly
After some trial and error, I arrive at the command
../../support/scripts/inc2h.pl 16f873 /usr/local/share/gptuils >p16f873.h
Now make yields
../../bin/sdcc -mpic14 -c -pp16f873 b.c
Processor: p16f873
*** Saved 1 registers ***
No registers saved on this pass
*** Saved 1 registers ***
No registers saved on this pass
gplink --map -c -s 16f873.lkr -o b.o b.o
16f873.lkr: No such file or directory
gplink's usage shows that its default linker script path is
/usr/local/share/gputils/lkr. In this directory, I find a 16f873.lkr file,
so I'm not sure why it can't find it also. In any case, I copy 16f873.lkr
to the current directory and run make again. This time I get
../../bin/sdcc -mpic14 -c -pp16f873 b.c
Processor: p16f873
*** Saved 1 registers ***
No registers saved on this pass
*** Saved 1 registers ***
No registers saved on this pass
gplink --map -c -s 16f873.lkr -o b.o b.o
error: no target memory available for section ".udata"
I am thinking that I do not have gputils installed correctly and/or the
PIC regression Makefile is out of date. Any suggestions would be
appreciated. (My development environment is Red Hat Linux 9 for IA32)
Erik

----- Original Message -----
From: "Erik Petrich" <epetrich@...>
To: <sdcc-devel@...>
Subject: [sdcc-devel] PIC regression tests
> There are a large number of PIC related bugs in the bug tracker. I am
> willing to tackle them, but I don't seem to understand how to run the PIC
> specific regression tests. After building and install gputils and gpsim, I
> go back to sdcc/src/regression and run make. This results in
>
> ../../bin/sdcc -mpic14 -c -pp16f873 b.c
> Processor: p16f873
> b.c:2:21: p16f873.h: No such file or directory
> Temporary ERROR: at the moment you have to use
> an include file create by inc2h.pl. See SDCC source:
> support/scripts/inc2h.pl
> this is a nuisance bug that will be fixed shortly
>
> After some trial and error, I arrive at the command
>
> ../../support/scripts/inc2h.pl 16f873 /usr/local/share/gptuils >p16f873.h
I have been trying to fix this in the PIC16 port for a while and now I
have made the code run properly. It is not so difficult to get rid from the
use of this kind of header files (and the use of the buggy inc2h.pl script)
as far as the programming task is concerned. The difficult part comes next.
We have to write library archives to be linked with the compiled source.
Since now, SDCC treats all symbols defined in the .h file as EQUs (YES,
there is no physical knowledge of the hardware port PORTA for example). The
proper way to do it would be to have a header file like this:
p18f442.h:
extern sfr PORTA;
and a library:
p18f442_lib.c
sfr at 0xf80 PORTA;
>
> Now make yields
>
> ../../bin/sdcc -mpic14 -c -pp16f873 b.c
> Processor: p16f873
> *** Saved 1 registers ***
> No registers saved on this pass
> *** Saved 1 registers ***
> No registers saved on this pass
> gplink --map -c -s 16f873.lkr -o b.o b.o
> 16f873.lkr: No such file or directory
>
> gplink's usage shows that its default linker script path is
> /usr/local/share/gputils/lkr. In this directory, I find a 16f873.lkr file,
> so I'm not sure why it can't find it also. In any case, I copy 16f873.lkr
> to the current directory and run make again. This time I get
>
> ../../bin/sdcc -mpic14 -c -pp16f873 b.c
> Processor: p16f873
> *** Saved 1 registers ***
> No registers saved on this pass
> *** Saved 1 registers ***
> No registers saved on this pass
> gplink --map -c -s 16f873.lkr -o b.o b.o
> error: no target memory available for section ".udata"
>
>
> I am thinking that I do not have gputils installed correctly and/or the
> PIC regression Makefile is out of date. Any suggestions would be
> appreciated. (My development environment is Red Hat Linux 9 for IA32)
As Craig Franklin noticed in another message everything is done
correctly,
except than the fact that the 16F873 device does not have a udata section in
the linker script, so you have to use the udata_shr section. This can be
done
by replacing the name `udata' in the assembly output with `udata_shr'. This
could
be done with command line arguments, like --replace-udata-with=udata_shr
so all unitialized variables will be declared within udata_shr section.
I have been incorporating such changes in the pic16 port (which is my
primary
target), but not in the pic14 port yet. I can commit a temporary CVS fix in
a few
days if you need it urgently.
Regards,
Vangelis

On Sun, 14 Dec 2003, Vangelis Rokas wrote:
> As Craig Franklin noticed in another message everything is done
> correctly, except than the fact that the 16F873 device does not have a
> udata section in the linker script, so you have to use the udata_shr
> section. This can be done by replacing the name `udata' in the
> assembly output with `udata_shr'. This could be done with command line
> arguments, like --replace-udata-with=udata_shr so all unitialized
> variables will be declared within udata_shr section.
Ah. I eventually modified a local copy of SDCC to emit `udata_shr' instead
of `udata' and was able to at least get a few of the regression tests to
run. I hadn't committed any changes because it was unclear to me whether
this change was needed because of the new relocation support or if it was
just specific to the 16F873 chip the regression tests was using.
> I have been incorporating such changes in the pic16 port (which is my
> primary target), but not in the pic14 port yet. I can commit a
> temporary CVS fix in a few days if you need it urgently.
It is not urgent for me; I have no current PIC projects. I simply noted
that approximately half of the open bug reports are PIC related, the code
generators looked incomplete, and development seemed to have stalled. I am
happy to help, but I would like to be able to run the regression tests to
verify that I haven't obviously broken something. I'll take a look at your
recent commits for pic16 to see what's useful to back-port.
Thanks for the reply,
Erik

----- Original Message -----
From: "Erik Petrich" <epetrich@...>
To: <sdcc-devel@...>
Subject: Re: [sdcc-devel] PIC regression tests
> Ah. I eventually modified a local copy of SDCC to emit `udata_shr' instead
> of `udata' and was able to at least get a few of the regression tests to
> run. I hadn't committed any changes because it was unclear to me whether
> this change was needed because of the new relocation support or if it was
> just specific to the 16F873 chip the regression tests was using.
I understand, but eventually, we should add some support for the poor
users that cannot rebuild SDCC!!!;-)
> It is not urgent for me; I have no current PIC projects. I simply noted
> that approximately half of the open bug reports are PIC related, the code
> generators looked incomplete, and development seemed to have stalled. I am
> happy to help, but I would like to be able to run the regression tests to
> verify that I haven't obviously broken something. I'll take a look at your
> recent commits for pic16 to see what's useful to back-port.
Well, since this is not urgent, there is not problem. I had similar
problems with the regression tests (especially with the processor include
files) that I had to stop repairing the code generator and figure out a way
to make the sources independent of these ad hoc solutions.
So far so good, but this needs a fair amount of work, that is not yet
complete, so I haven't updated yet the CVS sources. I work on two local
copies of the SDCC distribution, one in sync with the CVS and one where all
the development is done.
I think its time to bring these two in sync...!
ANW, you are doing a very good job with SDCC and seem to know much about
compilers, I'll surely need your advices in the near future!:-)
Regards,
Vangelis

On Tue, 16 Dec 2003, Erik Petrich wrote:
> It is not urgent for me; I have no current PIC projects. I simply noted
> that approximately half of the open bug reports are PIC related, the code
> generators looked incomplete, and development seemed to have stalled.
And that's my fault.
While I'm listening and sympathizing, there's not much more I can do other
than offer support. At the moment all of my free time is devoted to gpsim.
Sorry,
Scott