From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17907 invoked by alias); 13 Oct 2005 14:01:19 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 17861 invoked by uid 22791); 13 Oct 2005 14:01:14 -0000 Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 13 Oct 2005 14:01:14 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1EQ3dv-0001sv-00; Thu, 13 Oct 2005 16:01:11 +0200 Date: Thu, 13 Oct 2005 14:01:00 -0000 To: Stefan Sommerfeld Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20051013140111.GE6114@lunn.ch> Mail-Followup-To: Stefan Sommerfeld , ecos-discuss@ecos.sourceware.org References: <001e01c5cff3$a4129150$8262fea9@nullnullsix> <20051013130155.GB6114@lunn.ch> <003801c5cff9$5daf8f00$8262fea9@nullnullsix> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003801c5cff9$5daf8f00$8262fea9@nullnullsix> User-Agent: Mutt/1.5.11 From: Andrew Lunn Subject: Re: [ECOS] ISR to DSR delay? X-SW-Source: 2005-10/txt/msg00085.txt.bz2 On Thu, Oct 13, 2005 at 03:23:57PM +0200, Stefan Sommerfeld wrote: > Hi, > > >On Thu, Oct 13, 2005 at 02:42:58PM +0200, Stefan Sommerfeld wrote: > >>BTW: Why is "c++ empty delete function" a default option? I took me a > >>day > >>to find out why my system consumes a lot memory. > > > >Its a philisophical thing. > > > >Small footprint embedded systems, which is what eCos is targeted to, > >tend to use static allocated memory. That way they know they have > >enough memory either at compile time, or just after the system has > >started running when it allocates all the memory it needs for the rest > >of its life. This also makes the code simpler and smaller. You don't > >need to worry about running out of memory if you survive the startup > >phase. It is not normal to free memory since objects live until the > >system crashes/reboots. In such systems delete() is just a waste of > >space, but the linker is unlikely to be able to throw it away. So an > >empty implementation is used. > > Of course, i agree it's an important function for embedded system, but i > would suggest that it's not by default enabled. > > >Now i guess you are not using eCos for what its primarily targeted > >to. If you are using C++ with dynamically allocated objects you are > >probably on a big fat footprint embedded system. > > I'm using eCos as a RTOS ... XScale 520MHz with 64MB RAM :) So a very very fat footprint system. I expect most systems running eCos are around 1MB-2MBs of RAM. > > > >What i suppose we could do to help people in your situation is that if > >INFRA_DEBUG is enabled add a counter to count the number of times > >delete() is called. If it exceeds 100 throw an assert. When the assert > >goes off and you start investigating it, it will quickly become > >obvious what you need to do.... > > That would be an option .... I will add it to my ToDo list. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss