Just discovered realloc was availible :shock:
only few days ago I was reading 3 year old posts about not holding my breath about realloc........ Its here! amazing
8)
Jorg, you've done that?
Yes, I once needed it to get a lex/yacc-based parser running. A few
bugs have been shaken out now, so I'd expect it to be about as
functional as malloc() itself is.
Obviously, even more than malloc() alone, you should watch out for
possible memory fragmentation issues. I wouldn't want to use it on
devices with only small RAM.
Cool work!
Im using it on a m128 in conjunction with 32kb or more external memory.
how does that lex/yacc hold up on an AVR? Speedwise.
(- Can't wait to test realloc out )
PS: would it be difficult to change the malloc / realloc interface to an user defineable interface. Jesper once added dram to an AVR, and would by quite useable o have a Meg. or more on an AVR sometimes. (Speed efficiency not an issue then)
I can't tell you about the speed of the parser, I never measured it.
It's been just a test.
As for addressing larger memory, you completely miss the point that
all you get is a 16-bit pointer, so you can't do something like bank
switching etc. that way.
I've had a discussion about that in a German forum recently. I think
the most sensible use of large amounts of (banked) external memory is
to use it as a RAM disk, and organize file IO on it. It reminds me my
old CP/M days, when I had 384 KB of RAM on a Z80, quite a huge amount
of memory in those days.
Im aware of the 16 bit pointers and the architecture of the AVR.
Ill cook something myself then 8)
something like this should be doable fairly easy, its not standard C anymore then though.
void* mydata = malloc(4096);
:: do something with mydata. ::
BIGMEMORY* woah = allocate_dram(1024*512); // half meg
woah->memcpy(0x20040, mydata, 4096); // copy to dram at 0x20040
// free sram
free (mydata);
Working with dram can be useful in this way. Ex: for images, wave data, measurements etc.
