Life without malloc

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Life without malloc

Post by Folknology »

I still consider myself a bit of a newbie with XC and such still dealing with the new world I live in when coding with it. My latest mental barrier I would like to ask for your humble feedback on is given XC's lack of pointers how do you deal with larger memory requirements. Obviously the XC way is to use channels as pipelines and inter thread communications perhaps mixed with smaller arrays. But there must be many times when such mechanisms are not performant enough and a good old memory buffer of some sort may be needed between threads or even within a thread for data manipulation sets. So my questions is how do folks live their life without malloc in what situations have you had to deal with these kind of hurdles and what was the result. Did you have to resort to C or ASM, are their any guidelines or official recommendations of which way to go or what to use from XC. If you have any examples I would love for you to share them.

So what are your experiences and have you done to deal with these issues in your projects, what strategies have you eveloved in XC to deal with memory, I would love some feedback on this as its not really covered in the documentation..


User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

In a recent project in XC I just used arrays any time I needed a large buffer (8K+). There was one instance where I needed to store variable sized data structures in the buffer. I came to the simple solution of storing the size in the buffer just before the data and having a read and write 'pointer' keep track where I was in the array. In this sense it was more of a queue, but it was easy to wrap round and reuse space as long as you checked the read and write indices didn't overlap.

Of course, there's nothing stopping you using C and pointers to implement more complicated data structures but if you are just looking for linear storage of some data, you can't go wrong with arrays.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

I need large arrays in my FIR filters, and I usually check the disasm that I didn't code something a very stupid way.

If I pass an array or struct as a reference from main() to a function, no mem-copy will be addressed.
Inside that function I can address that array as I want without any performance penalty and without taking care of/casting pointers all the time.
For me it's almost like MATLAB, which I find easier to read compared to all pointer syntax in classic C.
Probably not the most confused programmer anymore on the XCORE forum.
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

"Life with out malloc"

I remember it well. I don't think I used or needed a malloc for the first ten years of my professional embedded work.

Mostly that's because the embedded systems I worked on:
a) Had such little memory that a malloc made no sense.
b) Had such timing constraints that you had better have everything allocated statically at start up as there is no time to go looking for it later.

In such systems can you be sure malloc will find the space you need all the time every time. Better that every task/thread has all the RAM it could ever need from the get go.

I see the XMOS devices as in this same boat still.

Mostly you have a few data types in an application, various stucts, and you can manage them in arrays, fifos etc easily enough.
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Post by shawn »

Technically the amount of Ram one should have should be addressable to the bit width of the CPU minus the memory in the IOT, of said bit width words not bytes. Page it as you wish I choose it to be for example 1/2 the bit width of the CPU for zero page. and in the IOT (1/2 the bit width minus 2bits) of 1/2 width words (great for macros or Stash) leaving the rest of IOT for SPI's or UNIx's then bus dma ect ect ect . this is somewhat how It worked in TOPS10 w/16 Fast Accumulators and 16 registers with the regX's on ZERO page. I am just recalling bits of how this raptor ran, circa 1972-3 era DEC SYSTEMS PDP10 KA, zero cache and all main ram was NV ferrite core and the IOT may have been T-ram like some early TX PDP LINC incantations,,,, "I am just not sure?". And for sure it didn't have anthing like 2^36 addressable 36bit words. I would guess had DEC's super secret project Jupiter ever realized , they may have addressed that much by now. That's about a third Terra byte of wonderful Ram.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Post by Folknology »

One Idea I thought of was to make a large multi dimensional array and handing out row or rows as required by different parts of the program (A bit like Andy's solution). I guess one could even right an xmalloc in C that returned dimensioned arrays on demand also. But really I would like to see standard dimensioned structures such as Fifos, Queues and Stacks that are designed for the job, just like you see standard collections in higher level languages. These elements could be written in low level ASM with a bit of C perhaps to make them as efficient as possible.

An by the way heater, I completely understand what you are saying, in many applications one doesn't even notice the lack of malloc because of the lower memory requirements and or static nature of the problem. However often a more structured alternative would be useful in XC to handle those more dynamic memory requirements in DSP type applications for example.

Keep up the feedback folks this is a fascinating thread.