X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Message-ID: <4161837F.F5E01C1F@yahoo.com> Date: Mon, 04 Oct 2004 13:08:15 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: 2.04 References: <200409301704 DOT i8UH4nUu020036 AT speedy DOT ludd DOT ltu DOT se> <200410011034 DOT 32461 DOT pavenis AT latnet DOT lv> <200410011308 DOT i91D8m2r015237 AT envy DOT delorie DOT com> <200410011711 DOT 21422 DOT pavenis AT latnet DOT lv> <415E7065 DOT BC389773 AT yahoo DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com CBFalconer wrote: > Andris Pavenis wrote: > > On Friday 01 October 2004 16:08, DJ Delorie wrote: > > > ... snip ... > >> > >> Can we PLEASE release 2.04 now? > > > > It will also require to rebuild large number of packages. > > Otherwise mixing packages built using 2.03 and 2.04 is expected > > to cause problems. For example if gcc is not built using DJGPP > > v2.04, it will fail encountering symbolic links. Maybe it's even > > could be better to put stuff in new directories like v204, > > v204gnu, etc. > > > > Anyway waiting will not make situation easier. So I think that > > 2.04 must be released reasonable soon. > > I expect I will be able to get to rebuilding the memalign() > portion of nmalloc within the next month. Things have been out of > kilter here due to various personal problems. I do not expect to > modify the other portions in the least. Virtually the whole > existing memalign stuff will be thrown out. > > I do expect to name the routine _memalign, so that stdlib.h can > have suitable provisions to conditionally redefine memalign and > avoid namespace pollution. Further to the above, the following is the simplified plot for memalign. If anybody sees any logical holes in it please let me know. The system will divert to pure malloc if alignment is <= ALIGN (which is 8 for this system). I have case B wrong already, since what is written does not allow a minimum assignment to free space. I have to consider the 1 high and 2 high conditions. /* The remaining code is an attempt to graft on the memalign function. It can do with improvement. The idea is to do this without disturbing the already checked and debugged package. In units of ALIGN (== 8 here) bytes: Initial malloc block (alignment > ALIGN): ____________________________________________________ | | | | | | 2 | size | xtra for | | | control | | realignment | | |__________|____________|______________|_____________| ^ ^ A) Worst case when this is 1 above an alignment point. becomes: ____________________________________________________ |alignment+| | | 0 | | 2-1 | 2 | size | nothing | |to freespc| control | | needed BUT: | |________ _|____________|______________|_____________| ^ ^ ^ ^ Now this point is suitably aligned ^ ^ For the intermediate cases make sure this block to be moved to free space is at least 3 units long. Easiest is to set the initial extra value so that this worst case is 3, not 0 This makes the initial extra size alignment+4. B) Alternatively, the initial alignment point is 1 low ____________________________________________________ | 3 | | | | |control+1 | 2 | size | xtra-3 | |to freespc| control | |to freespc | |__________|____________|______________|_____________| ^ ^ ^ ^ This point is aligned --^ This goes to freespace The minimum of 3 units to freespace is because 2 are required for control, and without further space the block is useless. In fact it needs the further space to implement the free block linking mechanism. */ -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!