Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.scheme Subject: Re: on the portability of SIOD Message-ID: Date: 22 Aug 90 19:40:07 GMT References: <9008211348.AA16999@cebaf4.cebaf.gov> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 17 I said: > > Another problem in SIOD comes from the heap management. All the RAM for the > > heap is allocated at startup. On a machine with 64K segments that leaves > > a 5000-element heap, which isn't enough to run the factorial test. If I > > continue to go with SIOD (I'm currently waiting for PSI so I can do a 3-way > > comparison with TCL, SIOD, and PSI) I'll be sure to fix that. In article <9008211348.AA16999@cebaf4.cebaf.gov> thompson@CEBAF4.CEBAF.GOV (Al Thompson) writes: > Pardon my ignorance, but how do you intend to do that? Off the top of my head: if I can't get a cell, allocate a new pair of arrays and treat them as part of the heap. When I get back to bottom, do a GC and compress the heap, freeing any arrays that are no longer needed. All pointers are already 32 bits, so that's not a problem. It's a little harder to operate with a non-contiguous heap, but it should be no slower. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com