From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,9292211c2d4756a8 X-Google-Attributes: gidf891f,public X-Google-Thread: 109fba,46882e3fad98420e X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,9292211c2d4756a8 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,48b89668821c1c9f,start X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,9292211c2d4756a8 X-Google-Attributes: gid1014db,public X-Google-Thread: f78e5,9292211c2d4756a8 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1995-01-13 05:30:55 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news1.digex.net!ois.com!ois.com!not-for-mail From: beckwb@ois.com (R. William Beckwith) Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.lang.misc,comp.std.c++,comp.lang.ada Subject: Re: Parallel & RT GC (was Re: Real-Time GC (was Re: Widespread C++...?) Followup-To: comp.lang.c++,comp.lang.c,comp.object,comp.lang.misc,comp.std.c++,comp.lang.ada Date: 13 Jan 1995 08:30:55 -0500 Organization: Objective Interface Systems, Inc. Message-ID: <3f5vaf$r07@gamma.ois.com> References: <787227087snz@wslint.demon.co.uk> <3ckb8g$841@gateway.wiltel.com> <1994Dec21.151952.8902@merlin.h <19941230.201628.350635.NETNEWS@UICVM.UIC.EDU> <3e9f60$8du@jive.cs.utexas.edu> <3epfsi$64d@gamma.ois.com> <3eua1r$4ea@gnat.cs.nyu.edu> NNTP-Posting-Host: gamma.ois.com X-Newsreader: TIN [version 1.2 PL2] Xref: nntp.gmd.de comp.lang.c++:86240 comp.lang.c:74346 comp.object:19495 comp.lang.misc:10335 comp.std.c++:11047 comp.lang.ada:17932 Date: 1995-01-13T08:30:55-05:00 List-Id: Robert Dewar (dewar@cs.nyu.edu) wrote: : "Is there any work-in-progress by the large chip manufacturers to : design GC into their next-generation CPU architectures? It seems : like the next logical step." : I sure hope not, I hope we have seen the end of this kind of incorrect : CISC thinking. At most what you want is some very specific hardware : assist instructions that are consistent with RISC instruction design : philosophy (for an example of this kind of thinking look at the trapped : add in the SPARC design, certainly we do NOT want to put LISP type checking : into the hardware, but this simple RISC consistent instruction is quite a : help for certain approaches to dynamic type checking in LISP interpretors. I'm not looking for a complex solution. I'm looking for the simplest design changes in instruction set, cache, and register files to accommodate transparent memory management. Henry Baker comments that the primary issues are cache management and VM. The fact that GC experts like Henry and Paul Wilson quickly digress to chip level issues leads me to believe that a concerted effort on the part of the CPU designer could lead to a much more elegant and efficient solution to memory management in compiled languages. It seems to me that GC is more than just a process level decision. There are three layers of participation in the effort: 1. CPU 2. O/S kernel 3. system libraries This is all in hopes that the application does not have to participate in the memory management excercise. Why not design the CPU with the GC'tor in mind instead of designing the GC'tor with the CPU in mind. I just seems silly that hardware designers aren't thinking more about relieving us programmers from thinking about what memory we are currently using. ... Bill -------------------------------------------------------------------------- e-mail: Bill.Beckwith@ois.com FAX: 703-264-1721 | Team Ada Objective Interface Systems, Inc. Voice: 703-264-1900 | dist, full O-O 1895 Preston White Drive, Suite 250 | multithreading Reston, VA 22091-5448 U.S.A. | built in