This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
At 05:54 PM 4/27/99 +0700, you wrote: >On Tue, 27 Apr 1999 11:07:53 -0700, Fred Fierling wrote: > >>A TCP stack that doesn't use malloc? Interesting. Do >>you forbid malloc to avoid problems like memory >>leaks, to guarantee response time, or why? > >Perhaps to help in provability? (Ie. guaranteeing the system is valid.) >I expect you could still use buffer pools, instead of a single generic >malloc that handles allocations for all types. In C++ you could use a >class-specific operator new and a private heap for each type. Deterministic response time. Some platforms that we use lack C++ compilers (eg, Analog Devices' SHARC DSP) . In addiion to that, we could be restricted to 544 Kbits of RAM (so the maximum program size would be 8K words of 48-bit instructions (leaving aside 8K 40-bit words for data)). That's a $10 DSP. We just used the non-low-power version where we had the luxury of 1Mbit SRAM inside. Among several other things, we had networking in it (custom, not IP). Fernando D. Mato Mira Real-Time SW Engineering & Networking Advanced Systems Engineering Division CSEM - Centre Suisse d'Electronique et de Microtechnique Jaquet-Droz 1 Email: matomira AT acm DOT org CH-2007 Neuchatel Phone: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720 http://www.csem.ch/ http://www.vrai.com/ http://ligwww.epfl.ch/matomira.html