Re: [AnyC-devel] AVR and Stack vs Other Memory Management

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

> What are the price differences like between the AVRs and the PICs?
> One of the things I like about the PIC is that they're pretty cheap
> for the feature set they offer.  I can't speak for other
> microcontrollers though, since I haven't really looked that much.

I was looking at the comparison between the PIC 16F877 and the AVR AT90S8=
535.=20
 They are both about $10 and have 8k flash memory.  Other major factors:
=09PIC=09AVR
RAM=09368=09512
EEPROM=09265=09512
IO=0933=0930
A/D=098 chan.=098 chan. (both 10-bit resolution)
SPI=09yes=09yes
UART=09yes=09yes

  I didn't look up everything, but it appears to me that Atmel is trying =
to=20
match the PIC feature for feature. =20

  Another really nice thing about the AVR series is that there are 32 gen=
eral=20
purpose registers, and you can operate on any two for many of the operati=
ons.=20
 For example, you could say:
ADC #$3,#$15

  to add register 3 to register $15 and put the result in register 3.

> I'm sure the page and bank issues can be worked out satisfactorily
> through some creative design and tradeoffs.  They're always somewhat
> on my mind as I've been working.  I'm sure solutions will eventually
> present themselves to any problems we may encounter.
>
> I've been thinking about somehow offering a virtual pseudo-linear
> address space.  This is a rather half baked idea, but perhaps it
> would be possible to take the space requirements for various
> variables, and organize them into chunks of memory within the same
> page.  That way, array and other multi-byte variable accesses could
> be done without switching banks.  This wouldn't lend itself
> particularly well to working within a traditional stack though.
> However, perhaps emulating the traditional stack isn't the best way
> to work with the PICs.

  Hmm...  I think expression parsing might be tougher this way.  Also, wh=
at=20
if you wanted one big array?  Considering how small the RAM is on these=20
things, if they are used for one task, it seems likely this would happen.=
 =20
The solutions I considered before to solve this issue increased code size=
 a=20
good bit. =20

> Instead of implementing a basic system on a stack machine, perhaps
> there could be a more general memory management system that deals
> with either the specifics of the PICs or works with more stack based
> systems like the AVR.  This is going to require a more thought.  Do
> you have any ideas in the area of memory management?  Do you see any
> fatal flaws in the half-baked ideas here?

  I doubt if I am sophisticated enough to come up with a system better th=
an=20
the traditional stack.  Computer science isn't my field, I just picked th=
is=20
stuff up as I went.  I have "the dragon book", but I haven't read very fa=
r=20
yet.  Mostly a shortage of time.