Re: [AnyC-devel] Recursion

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

> I would be interested in making it possible to work with both
> situations.  I imagine it would be possible to do with some sort of
> generic variable request system.  If you need a variable, you ask it
> for code to get to that variable.  It decides if it's going to be
> local or global in scope based on if the processor supports local
> variables/recursion.  I haven't thought about it that much yet.

  I think you may be getting two different things confused, or else I don=
't=20
understand what you're saying.  Since the PICs have separate data and cod=
e=20
memory, there are separate data and code stacks.  You can still implement=
 a=20
data stack (up to 256 bytes) with the PICs.  In fact, I really don't see =
any=20
other way to make a proper C compiler except to use a data stack.  The re=
ason=20
is: the compiler has no way to know what way the independent functions wi=
ll=20
be called.  Maybe function A will call function B, or C will call A, whic=
h=20
will then call B.  Because of this, there are only two options I see for=20
local variables:
1) Use a data stack for all local variables
2) Allocate space for all local variables on the heap at run-time.  This=20
means you will be using data space for every local variable in every func=
tion=20
all the time, whether that function is running or not.  I think I had a=20
routine that would implement a data stack on the PICs in the code, althou=
gh=20
I'm not sure.

  So that data stack is not the problem.  The problem is that the code st=
ack=20
is either limited to the hardware stack, or you have to do an incredible=20
amount of work to get around it and implement it in software.  With the P=
ICs,=20
this is very difficult, which is why no one has done it.  With the AVRs, =
it=20
looks much, much easier.

  All the work I did on the original version was centered around the PIC=20
line, but seeing the AVR datasheets makes the PICs seem very old-fashione=
d. =20
I would still like to support the PICs, I'm just not sure they will ever =
be=20
able to do what the AVRs can.

  Where do you get your chips?  The major sources for amateur electronics=
 I=20
have found are Digikey, Mouser, and Jameco.  Digikey now sells several of=
 the=20
AVR (two pages worth), including some with no RAM or EEPROM for $2.  Thos=
e=20
might be interesting to implement a virtual machine on eventually...

> The AVR line sounds pretty good for compilers.  I wonder if they had
> compilers in mind when they were designed.  Perhaps to act more like
> regular computers.  I don't want to only support the AVR line though,
> especially since I don't even know if I can easily aquire them
> locally without special ordering them.  The PIC is a popular chip,
> and having a free compiler for it couldn't hurt at all. :)  I didn't
> look at the datasheets for the AVR chips.  I suppose they support
> 20MHz as well?  That was the only question I had about them.  Perhaps
> I should take a look when thinking about these memory allocation
> issues.

  I think I read on the Atmel site that the AVRs were designed with C=20
compilers in mind... that's why they have 32 general-purpose registers.  =
I=20
have not done optimization work, but I can see how 32 GP registers would =
make=20
optimization much more efficient.  They are rated at 4 or 8 Mhz, but they=
 are=20
designed like the Scenix chips, which means many of the instructions are =
1=20
instruction per clock cycle.  The PICs use the traditional method which=20
requires 4 clock cycles per instruction.  So actually the AVRs should be=20
faster than the PICs at top speed.  If you count the reduction in overhea=
d=20
for the data stack and the 32 GP registers, I guess the AVRs should be 2-=
5=20
times faster for C code.

  Did you say you are in Canada?  I'm not sure where Digikey sells to, bu=
t I=20
imagine you can get them through Digikey.  They are a little high priced,=
 but=20
the service is excellent (fast delivery and phone help if you need it).

Digikey is www.digikey.com and Atmel is www.atmel.com.