Xref: utzoo comp.arch:16549 comp.lang.functional:223 Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!linus!carlton From: carlton@mitre.org (David Carlton) Newsgroups: comp.arch,comp.lang.functional Subject: Re: Processor architecture to support functional languages Keywords: hardware, stack, garbage Message-ID: Date: 15 Jun 90 20:24:16 GMT References: <5439@midway.cs.glasgow.ac.uk> Sender: carlton@linus.mitre.org Followup-To: comp.arch Organization: Mitre Corporation, Bedford, MA. Lines: 24 In-reply-to: simonpj@cs.glasgow.ac.uk's message of 8 Jun 90 12:10:45 GMT What about having hardware/OS support for multiple stacks per thread? It seems to me that it would be easier and faster (or at least not slower) to let somebody else take care of making sure that your stack doesn't run out of space unless you actually run out of memory. It would mean that you wouldn't have to write code which has to deal with the fact that the stack might move at a moment's notice (though, if the garbage collector were written properly, I suppose that there would be no way for the program to tell that the stack had moved), might reduce fragmentation, and so forth. Also, what work has been done on putting garbage collection in hardware? I was just reading ad (old) MIT AI lab report by Guy L. Steele, Jr. proposing that you get rid of (some of the) math operations in the microprocessor and replace them by garbage-collection operations. And I could well believe that in many circumstances it would be more desirable to have garbage collection done in hardware rather than, e.g., floating point. Of course, this too would cause problems - the cpu would have to be able to identify pointers, for example, and so it would probably only be feasible on architectures with tagged data. But for them it might be a good idea. What do people think? david carlton carlton@linus.mitre.org