Re: [AnyC-devel] Recursion

[Daniel W. <dan...@ro...>]

> With the PIC16F877, the data memory is fragmented.  It you look on
> page 13 of the pdf for it, you can see that the largest unfragmented
> section is 112 bytes.  Using the FSR and INDF alone, you can access
> 176 actual bytes of data memory.  The full amount of memory is 386
> bytes and can be accessed with the FSR and the IRP bit of the STATUS
> register.  The stack will have to know when it's going to hit a
> boundary in order to jump to the next section.  Alternatively,
> variables could be pre-allocated in order that you don't have to
> worry about hitting the end of the stack space.  It's probably
> possible to build some sort of psuedo-stack-machine in the compiler
> that will deal with this fragmented data memory issue.

  Oh, ok.  I didn't realize it was over 256 bytes.  That explains why the=
=20
data stack would also have some overhead.  I still think that pre-allocat=
ing=20
memory for local variables is a bad idea, unless the program doesn't use =
much=20
of the available memory (in which case, you should be buying a cheaper mo=
del=20
of PIC, right?).  Also, the easy way to parse expressions is on the stack=
=2E =20
I'm not really sure how I would do expression parsing without a stack. =20

> Limited recursion using the hardware stack is possible on the 877,
> since it has 8 levels of stack.  I'm more worried about the data
> issues than the difficulties with the hardware stack.

  Now I see what you mean... I don't think the original PIC architecture =
was=20
ever designed with the idea of having more than 256 bytes of memory. =20
Obviously they have just taken the old core and tacked new things on top.=
 =20
Kind of like the 8086 processor line.

> I get my chips at Active Components.  It's a division of the company
> that runs www.future-active.com.  It's a local store... I generally
> just drive over and pick up the parts I want.  They happen to stock
> the 877 and the 84, so it makes it easy for me to acquire them.  I
> could always special order things, but that's another step.

  There is a nice electronics store down the street from me, but I'm not =
sure=20
what microcontrollers they carry.  I used to live in Fayetteville, Arkans=
as,=20
which has about zero chance of anyone carrying microcontrollers locally.

> One issue is that I just got my PIC programmer to work under Linux.
> It took me a while to find something that would work to program the
> PIC16F877 under Linux.  I spent more than a week unsucessfully trying
> to program the PIC, until I finally had success with the NOPPP
> programmer and the 16F84, which then required some hardware and
> software adjustments to work with the 877.  If you want, you can read
> about what I did at http://patearl.net/pic_html
>
> I'm not in much of a hurry to build another programmer and buy more
> chips.  I don't have a lot of money at the moment, as I'm saving up
> to buy a welder with my friend.

  Yikes.  So far I haven't even programmed any chips, despite the fact th=
at I=20
built a programmer from a kit several years ago.  I worked with the 68HC1=
1=20
when I was doing microcontroller stuff at Los Alamos for my research, and=
 it=20
was an evaluation board that was pretty much ready to go.  I suspected th=
at=20
actually getting PIC programming to work might be difficult, which is why=
 I=20
put it off.

> That said, the AVR chips sound quite delightful, and under other
> circumstances, I'd probably jump at the opportunity to use them.  As
> for now though, getting the PIC to work nicely is, to me, a fun
> challenge.  I enjoy taking limited resources and making them work
> well.

  That was the main reason I started the project in the first place.  It =
is=20
definetly a challenge to get such a simple processor to run C code with=20
floating-point and all.  There are a lot of cool things I would like to d=
o=20
with it too.

> I've been studying the output from the compiler.  It's pretty icky in
> terms of speed.  I don't even understand parts of it.  I still need
> to read more of it, but I'll probably have some questions for you, if
> you think you can answer them.

  You mean the compiler is slow or the generated code would run slow on t=
he=20
PIC?  The compiler if for sure slow... my symbol table isn't even a hash=20
table, it's a linked list that has to search the whole thing for each sym=
bol=20
lookup!  Obviously this will need to be changed eventually.  I didn't do =
that=20
originally because I didn't want to write a hash table.  Now that I have=20
learned about glib this will be much easier.

  I am going on vacation starting Saturday morning until next Saturday or=
=20
Sunday.  Since my girlfriend isn't going with me, I will print out the co=
de=20
and look at it when I'm recovering from the hikes.  Hopefully then I will=
 be=20
up to speed again about how it works, so I can start a developers documen=
t=20
with Lyx and be able to answer question better.