From repp0017 at tc.umn.edu Thu Nov 1 01:51:21 2001 From: repp0017 at tc.umn.edu (Matthew Reppert) Date: Sat Dec 3 00:52:10 2005 Subject: [info-cscheme] MIT Scheme implementation Message-ID: <3BE0F0E9.9010101@tc.umn.edu> I've been poking about the MIT Scheme sources for a couple days now out of curiosity and desire to add a couple of features. I'm running the latest source distribution on a GNU/Linux system and want to be able to use the SYSTEM primitive. However, the binaries I compile insist that system is an unbound variable, even though looking at the source I can see that it's defined and listed in the table of static primitives in userdef.c. Is there some other sort of master switch for the symbols that get compiled in that I'm missing? This is really what I wanted to know ... I'm also curious as to what you think the best way to add an input function would be. Basically I want to implement some sort of interface to select(2); I have an input routine that sits and waits for input from one of multiple sources. Currently, it's implemented in such a manner that it ends up maxing out my CPU usage, which is unacceptable. (Basically, I sit in a "loop" and read-char? until there's input ready, then process it and start over ... ) Having select(2) would be much nicer ... Well, if anyone's here, thanks in advance, Matt From LaurenceWood at sunyatasystems.com Thu Nov 1 02:56:41 2001 From: LaurenceWood at sunyatasystems.com (Laurence Wood) Date: Sat Dec 3 00:52:10 2005 Subject: [info-cscheme] MIT Scheme implementation In-Reply-To: <3BE0F0E9.9010101@tc.umn.edu> Message-ID: As Chris Hanson might suggest (correct me if I am wrong Chris) check out the scheme add-primitive-procedure method. ============================================ Laurence F. Wood Chief Science Officer Sunyata Systems Corporation 732.701.9746 Direct 732.701.9748 Fax WWW.SUNYATASYSTEMS.COM "Precision Drug Design" -----Original Message----- From: info-cscheme-admin@zurich.ai.mit.edu [mailto:info-cscheme-admin@zurich.ai.mit.edu]On Behalf Of Matthew Reppert Sent: Thursday, November 01, 2001 1:51 AM To: info-cscheme@zurich.ai.mit.edu Subject: [info-cscheme] MIT Scheme implementation I've been poking about the MIT Scheme sources for a couple days now out of curiosity and desire to add a couple of features. I'm running the latest source distribution on a GNU/Linux system and want to be able to use the SYSTEM primitive. However, the binaries I compile insist that system is an unbound variable, even though looking at the source I can see that it's defined and listed in the table of static primitives in userdef.c. Is there some other sort of master switch for the symbols that get compiled in that I'm missing? This is really what I wanted to know ... I'm also curious as to what you think the best way to add an input function would be. Basically I want to implement some sort of interface to select(2); I have an input routine that sits and waits for input from one of multiple sources. Currently, it's implemented in such a manner that it ends up maxing out my CPU usage, which is unacceptable. (Basically, I sit in a "loop" and read-char? until there's input ready, then process it and start over ... ) Having select(2) would be much nicer ... Well, if anyone's here, thanks in advance, Matt _______________________________________________ info-cscheme mailing list info-cscheme@zurich.ai.mit.edu http://zurich.ai.mit.edu/mailman/listinfo/info-cscheme From cph at zurich.ai.mit.edu Thu Nov 1 11:18:10 2001 From: cph at zurich.ai.mit.edu (Chris Hanson) Date: Sat Dec 3 00:52:10 2005 Subject: [info-cscheme] MIT Scheme implementation In-Reply-To: <3BE0F0E9.9010101@tc.umn.edu> (repp0017@tc.umn.edu) Message-ID: Date: Thu, 01 Nov 2001 00:51:21 -0600 From: Matthew Reppert I've been poking about the MIT Scheme sources for a couple days now out of curiosity and desire to add a couple of features. I'm running the latest source distribution on a GNU/Linux system and want to be able to use the SYSTEM primitive. However, the binaries I compile insist that system is an unbound variable, even though looking at the source I can see that it's defined and listed in the table of static primitives in userdef.c. Is there some other sort of master switch for the symbols that get compiled in that I'm missing? This is really what I wanted to know ... You probably don't want to do this. See the section on "Subprocesses" in the reference manual for a way to run synchronous subprocesses. This provides a general mechanism for running a synchronous subprocess, and allows you to do things like redirect the subprocess I/O. If for some reason you _must_ use system, it's called unix/system. Unlike the synchronous-subprocess support, unix/system only works on unix-like operating systems. I'm also curious as to what you think the best way to add an input function would be. Basically I want to implement some sort of interface to select(2); I have an input routine that sits and waits for input from one of multiple sources. Currently, it's implemented in such a manner that it ends up maxing out my CPU usage, which is unacceptable. (Basically, I sit in a "loop" and read-char? until there's input ready, then process it and start over ... ) Having select(2) would be much nicer ... We already have support for the select/poll system calls. It's undocumented, but here's how to use it: 1. Create a "select registry" by calling (make-select-registry). 2. Add input descriptors to the registry: (add-to-select-registry registry (channel-descriptor-for-select (port/input-channel port))) 3. Test the registry, where block? is a boolean specifying whether you want to block if no input is available: (select-registry-test registry block?) 4. Examine the result: * If input is available, the result is a list of descriptors that are ready for input. (You'll have to match the descriptors up with the arguments you passed to add-to-select-registry.) * If no input is available, and block? was #f, the result is #f. * If no input is available, but there is a subprocess that needs attention, the result is the symbol process-status-change. * If no input is available, but an interrupt was delivered, the result is the symbol interrupt. From cph at zurich.ai.mit.edu Tue Nov 27 12:59:31 2001 From: cph at zurich.ai.mit.edu (Chris Hanson) Date: Sat Dec 3 00:52:10 2005 Subject: [info-cscheme] MIT Scheme 7.6.0 Message-ID: MIT Scheme 7.6.0 is released. This release features support for XML, a new sublanguage for writing parsers, and improved variable-reference machinery. See the release notes (on the web page) for full details. The compiled-code representation has been incompatibly changed from that of 7.5.x. YOU MUST RECOMPILE YOUR PROGRAMS TO USE THIS RELEASE. There is a new URL for the web site: http://www.swiss.ai.mit.edu/projects/scheme/mit/ From cph at zurich.ai.mit.edu Thu Nov 29 17:29:01 2001 From: cph at zurich.ai.mit.edu (Chris Hanson) Date: Sat Dec 3 00:52:10 2005 Subject: [info-cscheme] [bug-cscheme] MIT Scheme 7.6.0 on Windows XP professional In-Reply-To: <000001c178a9$3c4203d0$d3c1a818@thunder> (clevcovi@cs.gmu.edu) Message-ID: [Note to info-cscheme readers: I'm CC'ing my reply to this list because this is an issue many of you may need to know about.] Date: Thu, 29 Nov 2001 02:41:18 -0500 From: "Cristian Levcovici" I use the MIT Scheme 7.6.0 on Windows XP professional Athlon 1400MHz / 512 MB DDR / 30GB HDD. I get a consistent inconsistency usually accompanied by crashes when I evaluate (package/parent (pe)). On a fresh image in Edwin, most of the times, first time it evaluates to #[null 11 #x100202] and at the second evaluation it returns #[compiled-procedure 12 #x2800 #x15CDFF2] and it crashes with a message box: This is a known problem. MIT Scheme won't work properly on Athlon machines. I believe that the cache synchronization on the Athlon is broken. Here is the background: Modern processors have very complex cache designs. Most PCs have a two-level cache: level 1 (L1) is a small very fast cache, and L2 is a larger slower cache. In modern PCs the L1 cache is split into two parts: an instruction cache and a data cache (in older PCs the L1 cache was not split this way). This can potentially cause problems if code is written out to memory and then executed, because the instruction cache might have an old copy of the code until the data cache writes it out. On modern architectures other than the PC, there are instructions for managing the cache -- for example, to discard the contents of one of the caches, or to force the contents to be written to memory. The PC architecture has no such instructions, because when it was designed it didn't have a split cache. This means that modern PC chips that _do_ have split caches must provide hardware to synchronize the two caches. Now the problem is that MIT Scheme writes code to memory and then executes it. It does this as a performance hack for implementing fast closures. It also does this whenever compiled code is loaded into the heap from a file, or when it is moved by the garbage collector. On machines with architectural support for split caches, it has some tricks to make sure that the caches are properly managed, without major impacts on performance. On the Intel architecture, since there's no way to manage the cache, it's necessary to rely on the hardware synchronization to make this work. And it's not feasible to avoid this problem by changing MIT Scheme -- we need to be able to load code and then execute it. However, the Athlon synchronization hardware appears not to work properly, because all Athlons on which MIT Scheme has been tried fail in this way. The exact same binaries work perfectly on Intel chips. This is sad, because the AMD chips are superior to the Intel chips in most other respects. I haven't had the time to narrow this problem down to a simpler example, but I am confident that this could be done. I don't know how to fix this. If anyone here has some suggestions, please contact me. From LaurenceWood at sunyatasystems.com Thu Nov 29 18:25:12 2001 From: LaurenceWood at sunyatasystems.com (Laurence Wood) Date: Sat Dec 3 00:52:11 2005 Subject: [info-cscheme] [bug-cscheme] MIT Scheme 7.6.0 on Windows XP professional In-Reply-To: Message-ID: Good catch Chris, we were about to purchase a large number of these chips. Has anyone notified AMD about this? It seems they would be interested to fix this, perhaps it is a problem in the control store of the chip. ============================================ Laurence F. Wood Chief Science Officer Sunyata Systems Corporation 732.701.9746 Direct 732.701.9748 Fax WWW.SUNYATASYSTEMS.COM "Precision Drug Design" -----Original Message----- From: info-cscheme-admin@zurich.ai.mit.edu [mailto:info-cscheme-admin@zurich.ai.mit.edu]On Behalf Of Chris Hanson Sent: Thursday, November 29, 2001 5:29 PM To: clevcovi@cs.gmu.edu Cc: bug-cscheme@zurich.ai.mit.edu; info-cscheme@zurich.ai.mit.edu Subject: [info-cscheme] [bug-cscheme] MIT Scheme 7.6.0 on Windows XP professional [Note to info-cscheme readers: I'm CC'ing my reply to this list because this is an issue many of you may need to know about.] Date: Thu, 29 Nov 2001 02:41:18 -0500 From: "Cristian Levcovici" I use the MIT Scheme 7.6.0 on Windows XP professional Athlon 1400MHz / 512 MB DDR / 30GB HDD. I get a consistent inconsistency usually accompanied by crashes when I evaluate (package/parent (pe)). On a fresh image in Edwin, most of the times, first time it evaluates to #[null 11 #x100202] and at the second evaluation it returns #[compiled-procedure 12 #x2800 #x15CDFF2] and it crashes with a message box: This is a known problem. MIT Scheme won't work properly on Athlon machines. I believe that the cache synchronization on the Athlon is broken. Here is the background: Modern processors have very complex cache designs. Most PCs have a two-level cache: level 1 (L1) is a small very fast cache, and L2 is a larger slower cache. In modern PCs the L1 cache is split into two parts: an instruction cache and a data cache (in older PCs the L1 cache was not split this way). This can potentially cause problems if code is written out to memory and then executed, because the instruction cache might have an old copy of the code until the data cache writes it out. On modern architectures other than the PC, there are instructions for managing the cache -- for example, to discard the contents of one of the caches, or to force the contents to be written to memory. The PC architecture has no such instructions, because when it was designed it didn't have a split cache. This means that modern PC chips that _do_ have split caches must provide hardware to synchronize the two caches. Now the problem is that MIT Scheme writes code to memory and then executes it. It does this as a performance hack for implementing fast closures. It also does this whenever compiled code is loaded into the heap from a file, or when it is moved by the garbage collector. On machines with architectural support for split caches, it has some tricks to make sure that the caches are properly managed, without major impacts on performance. On the Intel architecture, since there's no way to manage the cache, it's necessary to rely on the hardware synchronization to make this work. And it's not feasible to avoid this problem by changing MIT Scheme -- we need to be able to load code and then execute it. However, the Athlon synchronization hardware appears not to work properly, because all Athlons on which MIT Scheme has been tried fail in this way. The exact same binaries work perfectly on Intel chips. This is sad, because the AMD chips are superior to the Intel chips in most other respects. I haven't had the time to narrow this problem down to a simpler example, but I am confident that this could be done. I don't know how to fix this. If anyone here has some suggestions, please contact me. _______________________________________________ info-cscheme mailing list info-cscheme@zurich.ai.mit.edu http://zurich.ai.mit.edu/mailman/listinfo/info-cscheme From LaurenceWood at sunyatasystems.com Fri Nov 30 08:52:27 2001 From: LaurenceWood at sunyatasystems.com (Laurence Wood) Date: Sat Dec 3 00:52:11 2005 Subject: [info-cscheme] [bug-cscheme] MIT Scheme 7.6.0 on Windows XP professional In-Reply-To: Message-ID: Hi Chris, does this problem relate to just the 7.6.0 version of MIT Scheme or are all version affected to your knowledge? Thanks. ============================================ Laurence F. Wood Chief Science Officer Sunyata Systems Corporation 732.701.9746 Direct 732.701.9748 Fax WWW.SUNYATASYSTEMS.COM "Precision Drug Design" -----Original Message----- From: info-cscheme-admin@zurich.ai.mit.edu [mailto:info-cscheme-admin@zurich.ai.mit.edu]On Behalf Of Chris Hanson Sent: Thursday, November 29, 2001 5:29 PM To: clevcovi@cs.gmu.edu Cc: bug-cscheme@zurich.ai.mit.edu; info-cscheme@zurich.ai.mit.edu Subject: [info-cscheme] [bug-cscheme] MIT Scheme 7.6.0 on Windows XP professional [Note to info-cscheme readers: I'm CC'ing my reply to this list because this is an issue many of you may need to know about.] Date: Thu, 29 Nov 2001 02:41:18 -0500 From: "Cristian Levcovici" I use the MIT Scheme 7.6.0 on Windows XP professional Athlon 1400MHz / 512 MB DDR / 30GB HDD. I get a consistent inconsistency usually accompanied by crashes when I evaluate (package/parent (pe)). On a fresh image in Edwin, most of the times, first time it evaluates to #[null 11 #x100202] and at the second evaluation it returns #[compiled-procedure 12 #x2800 #x15CDFF2] and it crashes with a message box: This is a known problem. MIT Scheme won't work properly on Athlon machines. I believe that the cache synchronization on the Athlon is broken. Here is the background: Modern processors have very complex cache designs. Most PCs have a two-level cache: level 1 (L1) is a small very fast cache, and L2 is a larger slower cache. In modern PCs the L1 cache is split into two parts: an instruction cache and a data cache (in older PCs the L1 cache was not split this way). This can potentially cause problems if code is written out to memory and then executed, because the instruction cache might have an old copy of the code until the data cache writes it out. On modern architectures other than the PC, there are instructions for managing the cache -- for example, to discard the contents of one of the caches, or to force the contents to be written to memory. The PC architecture has no such instructions, because when it was designed it didn't have a split cache. This means that modern PC chips that _do_ have split caches must provide hardware to synchronize the two caches. Now the problem is that MIT Scheme writes code to memory and then executes it. It does this as a performance hack for implementing fast closures. It also does this whenever compiled code is loaded into the heap from a file, or when it is moved by the garbage collector. On machines with architectural support for split caches, it has some tricks to make sure that the caches are properly managed, without major impacts on performance. On the Intel architecture, since there's no way to manage the cache, it's necessary to rely on the hardware synchronization to make this work. And it's not feasible to avoid this problem by changing MIT Scheme -- we need to be able to load code and then execute it. However, the Athlon synchronization hardware appears not to work properly, because all Athlons on which MIT Scheme has been tried fail in this way. The exact same binaries work perfectly on Intel chips. This is sad, because the AMD chips are superior to the Intel chips in most other respects. I haven't had the time to narrow this problem down to a simpler example, but I am confident that this could be done. I don't know how to fix this. If anyone here has some suggestions, please contact me. _______________________________________________ info-cscheme mailing list info-cscheme@zurich.ai.mit.edu http://zurich.ai.mit.edu/mailman/listinfo/info-cscheme