From: wbaguhn@nyx.cs.du.edu (Will Baguhn) Subject: Re: Semiconductor Applications Date: 10 Mar 1996 07:36:30 -0700 Message-ID: <4hupde$q8q@nyx.cs.du.edu> References: <31419D7A.F75@texoma.com> In article <31419D7A.F75@texoma.com>, Fred Meyer wrote: >I learned Friday that AG & Associates have used Forth in their equipment >for the semiconductor industry. I am also aware that Nicolet uses Forth >in their FTIR equipment. > >Does anyone know of other equipment suppliers, especially in the >semiconductor industry, who use Forth in their systems? > >Regards, >Fred Meyer >f3meyer@texoma.com > > Actually, I know a few people from Nicolet (they're a major employer around here). Nicolet used to use Forth a lot more, but they're switching to C and its spawn. And... it seems that their programmers are being forced to use those large OS's to do development now (like NT where they used to use DOS). From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Tcl/Tk Date: 10 Mar 1996 17:23:28 +0100 Message-ID: <4huvm0$qvq@iaehv.IAEhv.nl> Many thanks to Peter Knaggs and Stan Bailes for pointing me to the "real" Tcl/Tk home at http://www.sunlabs.com/research/tcl/ . I've installed the win41b2.exe binary on a '486 with 8 MBytes (Win 3.1). The looks are almost identical to the Xwindows original, that is, very, very nice. Nicer than twine. Unfortunately, this release has too many serious bugs to be of serious use. On a '386 with 4 Mbytes widget stops after a few minutes with a couple of UAE's and leaves Windows with 0% resources free. On the '486 there are no UAE's, but there is a resource leak that eats up 8% of the available resources each time wish starts. Also the color handling works all wrong. There's no stdout or stderr implemented (yet), so use through a simple pipe won't work. I'm gonna take a "mathematician's attitude" here and be content that a solution exists. They'll certainly have fixed the C code by the time I need to use it. Maybe this will save somebody a few frustated hours: I did install twine a week earlier. Twine needs a coupe of environment variables called TCL_LIBRARY and TK_LIBRARY . Remove these before you start up Sun's tcl/tk package. If you don't, the demo's refuse to do anything (I guess there are lots of warning messages on the unimplemented stderr channel). I'm left wondering why no Forth person has thought of developing a platform independent WIMP interpreter in the past few years? Oh, why do I ask. -marcel From: John Dunn Subject: Re: 32-bit Forth for Win 95? Date: 10 Mar 1996 17:42:43 GMT Message-ID: <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) Stephen Pelc wrote: >In article <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> > johndunn@umich.edu "John Dunn" writes: >Re: ProForth for Windows >> How is the speed? Do they use register pointers (two registers) for >> next and all read/writes, such as WinForth32 does, or do they have >> single register, direct addressing such as the (very exceptional) LMI >> UR/Forths do? >ProForth for Windows uses a direct threaded implementation, top of >stack cached in EBX. The speed is fine, in fact its faster than many >DOS Forths. Much of the kernel is in assembler - and you get the source >code. > >Speed in a Windows system often has more to do with how you use Windows >than anything else, but this is *very* application specific. Thanks for your information so far. The implementation issues I am concerned about have to do with whether direct or indirect addressing is used for memory access, and for next. Win32Forth uses the following for ! (store): pop eax \ fetch value (address is tos, EBX) mov [ebx] [edi] , eax \ store value to [ebx] inderect [edi] pop ebx \ update top of stack ..and next is also register indirect, and not very efficient even for direct threaded code: mov eax , 0 [esi] \ get rp add esi , # 4 \ bump mov ecx , [eax] [edi] \ double register indirect addressing add ecx , edi \ set up for register jump jmp ecx \ jump to next ..whereas LMI is far more efficient and elegant (i.e. *lots* faster). i.e., ! (store) is: pop [TOS] \ move value into address pop TOS \ update top of stack ..and next is lightening fast as: lodsd \ incrememt rp & put into EAX jmp eax \ jump to next ..so my question about ProForth implementation: is it single register direct as LMI UR/Forth, or is it double inderect as Win32Forth? ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: "William H. Stewart" Subject: Re: Semiconductor Applications Date: 10 Mar 1996 17:57:28 GMT Message-ID: <4hv568$f20@news.computek.net> References: <31419D7A.F75@texoma.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; U; 32bit) FRED: MICROSEMI, 2830 SO. FAIRVIEW ST., SAN ANNA, CA 92704 Contact: Paul O Lloyd Uses New Micros F68HC11 in there manufacturing and inspection process. The last time I worked with them they were using the Floating Point package from Motorola, that I modified for the F68HC11 VER 3.3, but I suspect they have probably changed to the Ver 3.5 which has floating point in the kernel. Floating point was needed to achieve the accuracy to measure the small values of capacity in a line of diodes. Contact Paul for details. I can't find a telephone number at this time. Question for you - Is the Dallas Forth Interest Group still meeting? If so come details please. Regards -- Bill Stewart bill@koyote.com DBA BEN FRANKLIN SERVICES 903-325-4356 VOICE AND FAX From: frodes@psyk.uit.no Subject: Re: Any ASYST users out there? Date: 10 Mar 1996 19:54:18 GMT Message-ID: <4hvc1a$5k0@news.uit.no> References: <4gidhl$3mj@alecto.METC.DOE.GOV> <3131D2F4.7E68@nist.gov> Reply-To: frodes@psyk.uit.no >Bill Chisholm wrote: > > Are there any ASYST users, newsgroups, bulletin boards, > etc. out there? ASYST is a version of FORTH with lots of > data acquisition, graphics, communications capability, etc. > included. Its still sold by Keithly-Metrabyte, but they > don't give much in the way of support. I still use it in > my lab, and would like to communicate with other users. I have been using ASYST since 1987 for experimental control and data analysis (experimental psychology). I think this package is just GREAT - fast, powerful, flexible. Yes, you must write some code, but the modules you develop for specific purposes may be reused later, often with only minor changes. Frode Svartdal, frodes@psyk.uit.no http://www.isv.uit.no/seksjon/psyk/index.htm From: mhill@cinternet.net (Mike) Subject: Engineering Positions Available Date: Sun, 10 Mar 1996 00:55:51 GMT Message-ID: <4ht8vl$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: mhill@cinternet.net (Mike) Subject: Engineering Positions. Date: Sun, 10 Mar 1996 00:55:25 GMT Message-ID: <4ht8us$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: mhill@cinternet.net (Mike) Subject: Engineering Positions Available Date: Sun, 10 Mar 1996 00:55:53 GMT Message-ID: <4ht8vn$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: mhill@cinternet.net (Mike) Subject: Engineering Positions Available Date: Sun, 10 Mar 1996 00:55:55 GMT Message-ID: <4ht8vp$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and \ manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: mhill@cinternet.net (Mike) Subject: Engineering Positions Available Date: Sun, 10 Mar 1996 00:56:01 GMT Message-ID: <4ht8vv$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and \ manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: mhill@cinternet.net (Mike) Subject: Engineering Positions Available Date: Sun, 10 Mar 1996 00:56:07 GMT Message-ID: <4ht904$9qd@news.cinternet.net> Engineering Opportunities At Tekmar-Dohrmann, we attribute our preeminent position in analytical instrumentation to advanced technology and to our organization's impressive capacity to respond to customer needs. A wholly owned subsidiary of Rosemount, Inc. ( a division of Emerson Electric), we are ISO 9001 registered, setting the pace in the development and \ manufacture of laboratory sampling and analysis equipment. Currently, we are seeking talented professionals at our Corporate Headquarters in Cincinnati, OH to join our Product Development Team. Hardware Electronics Engineer: This position is responsible for the design of embedded control systems. The ideal candidate will have a BSEE, 2-3 years' experience in design of PCB based products using FPGA and analog components, embedded processor experience with Intel 8032/8052 family, and Motoroloa 68xx/68xxx family, and experience in specifying, planning documenting, prototyping and verifying designs using PC based and advanced lab equipment. Good analytical and interpersonal skills are essential; understanding of analog circ and familiarity with electronic CAD are pluses. We will consider a recent MSEE or BSEE graduate with relevant lab and project experience. Firmware Engineer: We will rely on you to design and develop software for embedded systems. To qualify, you should have a strong background in Forth and C programming on Intel Embedded systems, and a BS in Software Engineering or Computer Science and 1-4 years' experience. Knowledge of Motorola 68xxx family and C/C++ Windows programming preferred. We offer a challenging and creative environment with a competitive salary. New grads welcome. For consideration send you resume to: Tekmar-Dohrmann P.O. Box 429576 Cincinnati, OH 45242-9576 Attn: Human Resources Dept. Or fax to 513-247-7021 Or email to mhill@cinternet.net -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-Mike Hill-=-=-=-=-=- =-=-=mhill@cinternet.net=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=- From: Elizabeth Rather Subject: Re: Semiconductor Applications Date: 10 Mar 1996 21:44:44 GMT Message-ID: <4hvigc$fo7@chile.it.earthlink.net> References: <31419D7A.F75@texoma.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:31419D7A.F75@texoma.com Varian Ion Implant Systems in Gloucester, MA, is an interesting example. This company was started a few years ago (10?) based on some innovative engineering & Forth-based control systems. They prospered and were bought. As they grew they encountered problems hiring Forth programmers in the Boston area, and are now considering re-writing their next generation systems in C++ because of this. Given that Boston is the home of one of the larger & more active FIG chapters (whose members frequently complain that there are no Forth jobs available) this seems particularly sad, but so far as I know the systems have been technically a great success. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: 32-bit Forth for Win 95? Date: 10 Mar 1996 21:55:04 GMT Message-ID: <4hvj3o$fo7@chile.it.earthlink.net> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:4hv4aj$4nb@lastactionhero.rs.itd.umich.edu John Dunn wrote: >Thanks for your information so far. The implementation issues >I am concerned about have to do with whether direct or indirect >addressing is used for memory access, and for next... You can get more specific information about ProForth for Windows, including some timings, by calling us at 1-800-55FORTH tomorrow during business hours; ask for Steve. There's also more information regarding features, etc., in our web page (address below), but it doesn't cover the exact information you're asking for. We sell and support this system in the US. We have found it to be quite fast, in addition to being very full-functioned and well-documented. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: John Dunn Subject: Re: 32-bit Forth for Win 95? Date: 10 Mar 1996 23:03:52 GMT Message-ID: <4hvn4o$ak9@lastactionhero.rs.itd.umich.edu> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <4hvj3o$fo7@chile.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) Elizabeth Rather wrote: >You can get more specific information about ProForth for Windows, >including some timings, by calling us at 1-800-55FORTH tomorrow during >business hours; ask for Steve. > >There's also more information regarding features, etc., in our web page >(address below), but it doesn't cover the exact information you're >asking for. > Thanks for jumping in. I actually started at the web site, thanks to a posting you had provided on a different thread. And I also talked to Steve, and have sent several email messages, and have received your sales documentation. In all that, I have been unable to get the low level information that really impacts performance. Steve tells me he is not a "technical" person, and in any event has to wait for a reply to my questions from the UK, and that right now you all have some project going on, and everyone is tied up. If the package sold for $300 or less, I would just buy it and check it out...if it didn't meet my requirements I would consider it a lesson and go on. But at $1600, I really need to know that it will do the job beforehand. ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: regnirps@aol.com (Regnirps) Subject: Re: Emb. Syst. Programming rediscovers Forth? Date: 10 Mar 1996 22:26:54 -0500 Message-ID: <4i06hu$pg0@newsbf02.news.aol.com> References: <826447241snz@mpeltd.demon.co.uk> Reply-To: regnirps@aol.com (Regnirps) I guess my definition of a 'Forth variant' allows more variation than yours! Cheers Charlie Springer From: john.r.strohm@BIX.com (John Strohm) Subject: Re: Anyone interested in writing an operating system? Date: 11 Mar 1996 05:22:28 GMT Message-ID: <4i0dak$m4d@news1.delphi.com> References: Paul Koch wrote: >Have you not heard of FreeBSD/NetBSD/Linux ?? They are >all x86 free unix clones. Visit www.freebsd.org. Paul, I think his point was that he wanted to do something DIFFERENT, not Yet Another Bug-Compatible Unix Clone. You maybe should read Reiser _The Oberon System: User Guide and Programmer's Manual_. Oberon is a beautiful workstation-class operating system AND window system that requires all of 150 kbytes or so to run. Compare with workstation Unix clones that require multiple megabytes to crawl. From: jlblue@nickel.ucs.indiana.edu (john blue) Subject: Forth for Geos, already exist? Date: 11 Mar 1996 17:17:27 GMT Message-ID: <4i1n77$mi8@usenet.ucs.indiana.edu> NNTP-Posting-User: jlblue Hi , I am interested in finding if someone has already created a Geos V2.00 operating system (by GeoWorks) compatible Forth. Thanks, John Blue -- John Blue, jlblue@indiana.edu, jlblue@aol.com Poplars Room 730 Computing Technology Assistance Center 400 East 7th Street office: 812-855-7530, FAX:812-855-9320 Bloomington, Indiana 47405 See the CTAC Web page for more information http://www.indiana.edu/~ctac/ From: Andrew McKewan Subject: Re: 32-bit Forth for Win 95? Content-Type: text/plain; charset=us-ascii Message-ID: <314457B3.7C3A@netcom.com> Content-Transfer-Encoding: 7bit References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Date: Mon, 11 Mar 1996 16:41:23 GMT X-Mailer: Mozilla 2.0 (WinNT; I) John Dunn wrote: > > >> How is the speed? Do they use register pointers (two registers) for > >> next and all read/writes, such as WinForth32 does, or do they have > >> single register, direct addressing such as the (very exceptional) LMI > >> UR/Forths do? > > Thanks for your information so far. The implementation issues > I am concerned about have to do with whether direct or indirect > addressing is used for memory access, and for next. > > Win32Forth uses the following for ! (store): > > pop eax \ fetch value (address is tos, EBX) > mov [ebx] [edi] , eax \ store value to [ebx] inderect [edi] > pop ebx \ update top of stack > > ..and next is also register indirect, and not very efficient even for > direct threaded code: > > mov eax , 0 [esi] \ get rp > add esi , # 4 \ bump > mov ecx , [eax] [edi] \ double register indirect addressing > add ecx , edi \ set up for register jump > jmp ecx \ jump to next > > ..whereas LMI is far more efficient and elegant (i.e. *lots* faster). > i.e., ! (store) is: > > pop [TOS] \ move value into address > pop TOS \ update top of stack > > ..and next is lightening fast as: > > lodsd \ incrememt rp & put into EAX > jmp eax \ jump to next > > ..so my question about ProForth implementation: is it single register > direct as LMI UR/Forth, or is it double inderect as Win32Forth? The "double register" instructions in Win32Forth allow the Forth dictionary to be relocatable. The addresses are all relative to the base of the dictionary stored in EDI. In the 486 and above, there is no extra runtime penalty for using two index registers. All the address calculation is done in hardware in parallel with the instruction decode. The real penalty is the loss of a register in an already register-poor architecture (only 8). The difference between direct and indirect threading is more subtle. If you look at NEXT, it certainly seems as though dircect threading is faster. Here is an indirect NEXT comarable to your example from LMI (absolute addresses): lodsd jmp [eax] ( Actually, this code is faster: mov eax, [esi] add esi, 4 jmp [eax] ) The indirect threaded code requires an extra memory reference during the jump. This makes primatives that much faster. But for nesting (:) and defining words (CONSTANT, VARIABLE, etc.) the direct threaded code has a JMP or CALL instruction in the code field, whereas the indirect threaded does not. This JMP or CALL is quite expensive, because it stops the prefetch queue that gives the 486+ it's one-cycle instruction execution. Here's an example for docol, the runtime for colon: --- Direct threaded (cfa contains "call docol") --- call docol docol: sub ebp, 4 mov [ebp], esi pop esi next --- Indirect threaded (cfa contains address of docol) --- docol: sub ebp, 4 mov [ebp], esi lea esi, 4 [eax] next In addition (we're picking nits here) indirect threaded code allows us to keep all of the addresses (cfa, pfa, runtime routines) aligned to 4-byte boundries more easily. With a 32-bit data bus, aligned fetches are faster. If you really want speed, then subroutine-threading and native code generation is the way to go. It makes for a more complicated system, but I have observed a 4-5 times speedup for simple benchmarks. But really, it is wrong (and I do it all the time) to judge a system's performance based on the source code of next and fetch. What really matters is how your application runs. As Steven pointed out, whenever you make a call to Windows, whatever time you spend threading is insignificant. Andrew From: Andrew McKewan Subject: Re: Semiconductor Applications Content-Type: text/plain; charset=us-ascii Message-ID: <31445A08.4DF7@netcom.com> Content-Transfer-Encoding: 7bit References: <31419D7A.F75@texoma.com> <4hv568$f20@news.computek.net> Mime-Version: 1.0 Date: Mon, 11 Mar 1996 16:51:20 GMT X-Mailer: Mozilla 2.0 (WinNT; I) William H. Stewart wrote: > > Floating point was needed to achieve > the accuracy to measure the small values of capacity in > a line of diodes. My opinion: Floating point does not give accuracy. Floating point has two features: 1. Large dynamic range 2. Programmer convenience Accuracy (or precision) is determined by how many bits you use to store a number (magnitude). In this regard, a 32-bit integer is more accurate than a 32-bit floating point number. Andrew (BTW, try representing 0.1 in IEEE floating point. Suprise, it can't be done.) From: ouversonm@aol.com (OuversonM) Subject: Forth Dimensions magazine (vol. XVII, #6) Date: 11 Mar 1996 13:48:05 -0500 Message-ID: <4i1sh5$en9@newsbf02.news.aol.com> Reply-To: ouversonm@aol.com (OuversonM) The March-April 1996 issue of Forth Dimensions is being mailed. It features the following: ============================================================== Coordinating Pygmy and C by Frank Sergeant --How to wrap Pygmy Forth inside a C program: --C can pass string to Forth to be interpreted, and --Forth can call C functions. Have it both ways! Diffrential File Comparison by Wil Baden --Every programmer should have a reliable file-comparison --utility. As the author notes, "The obvious algorithm will --sooner than later fail miserably." His own program has been --evolving since 1976. Using Forth to Manipulate the Real World: Getting to the Hardware from Linux by Skip Carter --Moving to Linux without previous experience with workstations --and minicomputers can be a shock. Skip covers the essentials: --accessing the parallel port, adding device drivers, which Forth --to use, and how to control stepper motors (see previous issue). Success Stories Sought by Mike Elola --Saying farewell to his duties as "Fast Forthward" columnist, --Mike divulges his current work projects and offers a challenge... ...and more! ========================================================================== == If you are not already a reader of Forth Dimensions, we invite you to read it regularly. (The owner of a popular Silicon Valley computer bookstore called FD the best specal-interest technical magazine ever.) Software, Forth texts and tutorials, conference proceedings, and other Forth resources are also available, with a discount to current FIG members. Contact: Forth Interest Group P.O. Box 2154 Oakland, California 94621 USA telephone: 510-893-6784 fax: 510-535-1295 e-mail: johnhall@aol.com Forth Interest Group home page: http://www.forth.org/fig.html From: regnirps@aol.com (Regnirps) Subject: Re: Semiconductor Applications Date: 11 Mar 1996 13:03:20 -0500 Message-ID: <4i1pt8$dlt@newsbf02.news.aol.com> References: <31445A08.4DF7@netcom.com> Reply-To: regnirps@aol.com (Regnirps) Andrew McKewan wrote: "Accuracy (or precision) is determined by how many bits you use to store a number (magnitude). In this regard, a 32-bit integer is more accurate than a 32-bit floating point number. " I think of accuracy as how close you come to the target. Precision is how well your shots group, regardless of the target. In this sense there are integer targets you can not hit with floating point and vice versa. How far away are the shots that miss and how close are the members of a group? Charlie Springer From: John Dunn Subject: Re: 32-bit Forth for Win 95? Date: 11 Mar 1996 20:48:50 GMT Message-ID: <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) Andrew McKewan wrote: > >The "double register" instructions in Win32Forth allow the Forth dictionary >to be relocatable. The addresses are all relative to the base of the >dictionary stored in EDI. In the 486 and above, there is no extra runtime >penalty for using two index registers. All the address calculation is done >in hardware in parallel with the instruction decode. The real penalty is >the loss of a register in an already register-poor architecture (only 8). > >The difference between direct and indirect threading is more subtle. If you >look at NEXT, it certainly seems as though dircect threading is faster. >Here is an indirect NEXT comarable to your example from LMI (absolute >addresses): > (snip) Thanks for your input on this. I must admit that it has been some time since I looked at cycle times. Since the 386, they have been so situation-dependent that I more or less gave up and just continued to write code that "seemed" tight. Anyway, I have run some benchmarks on Win32Forth and LMI's Protected mode (32 bit) UR/Forth. All were run under Windows 95, with no other programs in the background. UR/Forth is DOS based, using PharLap's TNT, which is DPMI compliant; so I ran it in a DOS window in Win95. The actual code follows at the end of this message and if some one has a copy of ProForth I'd love to see the benchmarks. Results of benchmarks (min:sec.hundreds): Pentium 133 DX4/100 Win32 UR/Forth Win32 UR/Forth Eratosthenes: 59.43 18.01 1:03.60 37.90 Interface Age: 1:21.61 27.96 1:32.71 46.80 Two things stand out: (1) UR/Forth is about 3 times as fast as Win32; and (2) UR/Forth is substantially faster when running on a Pentium, but Win32 is not. BTW, I also ran the benchmark on LMI's 16 bit real mode UR/Forth, and got essentially the same timings as with the 32 bit version --------------------------------------------------------------------- \ Eratosthenes sieve benchmark program \ j 14:08 03-11-96 FORTH DEFINITIONS DECIMAL 8190 CONSTANT SIZE CREATE FLAGS SIZE ALLOT : DO-PRIME FLAGS SIZE 1 FILL 0 SIZE 0 DO FLAGS I + C@ IF I DUP + 3 + DUP I + BEGIN DUP SIZE < WHILE 0 OVER FLAGS + C! OVER + REPEAT DROP DROP 1+ THEN LOOP DROP ; : PRIMES 1000 0 DO DO-PRIME LOOP ; \ : PRIMX !TIMER PRIMES .TIMER ; : PRIMX time-reset primes .elapsed ; \ Interface Age benchmark FORTH Dimens \ j 14:10 03-11-96 ( enter: 1000 BENCH ) : BENCH DUP 2 / 1+ SWAP 1 DO DUP I 1 ROT 2 DO DROP DUP I /MOD DUP 0= IF DROP DROP 1 LEAVE ELSE 1 = IF DROP 1 ELSE DUP 0 > IF DROP 1 ELSE 0= IF 0 LEAVE THEN THEN THEN THEN LOOP 2DROP LOOP DROP ; \ : BENCHX !TIMER 20000 BENCH .TIMER ; : benchx time-reset 20000 bench .elapsed ; : TEST CR ." Eratosthenes sieve benchmark: " PRIMX CR ." Interface Age benchmark: " BENCHX CR ; ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: mlosh@tir.com Subject: Re: What is Tyler Sperry's point about Harris RTX? Date: Mon, 11 Mar 1996 17:52:08 -0500 Message-ID: <3144AE98.3020@tir.com> References: <313FC25C.2A79@tir.com> <4hq14v$4k7@chile.it.earthlink.net> <314198bb.26635878@ixnews3.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Phil Koopman wrote: > By all means send him some e-mail. He's a pretty reasonable fellow.... > > BTW, I first met Tyler at the Rochester Forth conference, so he can't > be all bad. > > -- Phil I did not mean to imply that he was bad at all... I just thought his point was a little fuzzy. Maybe I'll send him a copy of my post. :) -- Mike Losh From: mlosh@tir.com Subject: Re: Emb. Syst. Programming rediscovers Forth? Date: Mon, 11 Mar 1996 17:58:30 -0500 Message-ID: <3144B016.7524@tir.com> References: <313FC200.64CA@tir.com> <4hq0vd$4k7@chile.it.earthlink.net> <19960309.053415.85@hasle.sn.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Are Leistad wrote: > Wow - there is actually such a magazine! > Please, can you give some details, like the publisher, perhaps > an e-mail address or something. > > Are > --_Embedded Systems Programming_, A Miller Freeman Publication. 1-800-829-5537. Published monthy. US subscription $49.95/Year. http://www.embedded.com. I've tried to get a "complimentary" subscription multiple times with no success. :) It's still a great mag, though. The Editor's opinions on Forth are hard to pin down, at least from my somewhat spotty reading of the magazine. He'll praise it and damn it in the same essay. -- Mike Losh From: MABS85B@prodigy.com (Leo Wong) Subject: @! , Anyone? Date: 11 Mar 1996 21:08:50 GMT Message-ID: <4i24p2$1r4u@usenetw1.news.prodigy.com> In my Sokoban Contest entry I wrote: : MOVE-SOKO ( a1) where's-soko DUP @ DUP AT-MAZE C@ EMIT ! ; I should have written: : MOVE-SOKO ( a1) where's-soko @ DUP AT-MAZE C@ EMIT where's-soko ! ; This still bothers me. The a1 waits a long time to be stored. Maybe I want a word whose colon definition might be: : @! ( newvalue address - oldvalue) DUP @ ROT ROT ! ; but which would probably be CODEd. Then I could write: : MOVE-SOKO ( a1) where's-soko @! DUP AT-MAZE C@ EMIT ; I've never felt the need for @! before. Is it a useful word? Is it well-named? - LEO WONG MABS85B@prodigy.com New York State Department of Civil Service Albany, NY 12239 From: lglisle@aol.com (LgLisle) Subject: Re: floating vs. fixed point Date: 13 Mar 1996 21:38:31 -0500 Message-ID: <4i80r7$1s1@newsbf02.news.aol.com> References: <883@purr.demon.co.uk> In article <883@purr.demon.co.uk>, jack@purr.demon.co.uk (Jack Campin) writes: >Speed, though, is something else; since Moore started advocating fixed >point for reasons like those I've given, hardware floating point has >become much cheaper. There aren't going to be many occasions when a >hand-coded fixed-point numerical algorithm running on sequential hardware >can beat an FPU. This will depend highly on the environment you're working in. FPU's are still rather rare for 8 and 16 bit single chip computers. When one is dealing with a cost sensitive, embedded project, fixed point is still much prefered. L. Greg Lisle, PE Forth Toolsmith | L.G.Lisle@ieee.org From: japs@netcom.com (Jim Schneider) Subject: Re: 32-bit Forth for Win 95? Message-ID: References: <4i46j5$juf@nadine.teleport.com> <4i4cko$h07@lastactionhero.rs.itd.umich.edu> Date: Thu, 14 Mar 1996 01:59:41 GMT In article japs@netcom.com (Jim Schneider) writes: >In article <4i4cko$h07@lastactionhero.rs.itd.umich.edu> John Dunn writes: >>znmeb@teleport.com () wrote: >>>John Dunn (johndunn@umich.edu) wrote: >>>: I don't understand how the overhead is in Windows on these benchmarks. >>>: No i/o is used within the test loop, so what is it that Windows might >>>: be doing to slow it down? >>>Windows *must* be servicing interrupts. The time it spends doing so is >>>time unavailable to your benchmark. >>> >>Since I ran the DOS program in a Win95 window, and since there is no i/o >>in the benchmarks, it would seem to me that the background tasking would >>be about the same in both systems... >-- > >It ain't necessarily so. In particular, Windows 3.1 was much more cavilier >about interupting a Windows app than it was about interrupting WinOldAp >(which, in turn, ran the DOS box). I think this is because WinOldAp wasn't >terribly reentrant. I don't know what that particular situation is on Win95, >but I do know that the default DOS box (the one used if you don't take the >trouble to create a PIF for your DOS app) on Win95 has a very low idle >sensitivity, and usually a fairly high priority. This means that Windows 95 >would have a harder time interrupting the DOS box than is necessary. And yes, >Windows will ignore interrupts if it feels that the foreground task is >important enough (this doesn't happen often for Windows apps, but it does >happen fairly frequently for DOS apps). Oops -- one more thing: Win32Forth attempts to load every single DLL in the standard Windows distribution. This means that if you only run Win32Forth for benchmarks, and you only run a DOS box for the DOS based FORTH benchmarks, Win32Forth is *still* saddled with a lot of Windows overhead that won't be present in the DOS box case. From: Elizabeth Rather Subject: Re: 32-bit Forth for Win 95? Date: 14 Mar 1996 01:29:24 GMT Message-ID: <4i7spk$e55@bolivia.it.earthlink.net> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: johndunn@umich.edu,sagarwal@forth.com,sfp@mpeltd.demon.co.uk,druffer@forth.com X-URL: news:4i23ji$kcs@lastactionhero.rs.itd.umich.edu Dennis Ruffer and the folks at FORTH, Inc. have a standard set of benchmarks that we use to compare Forths. The results of the benchmarks on ProForth for Windows are as follows: Win95 Win95 WinNT 486-80 486-66 486-66 Testing DO LOOP 0.756 0.865 0.952 us Testing * 1.539 1.483 1.822 us Testing / 1.895 2.184 2.233 us Testing + 1.250 1.387 1.482 us Testing M* 1.594 1.538 1.873 us Testing M/ 3.227 3.859 3.815 us Testing M+ 3.063 3.447 3.495 us Testing /MOD 2.060 2.513 2.484 us Testing */ 4.587 5.411 5.498 us Testing Erathosthenes sieve 1899 Primes 15.140 16.727 18.315 us Testing Hoare's quick sort (reverse order) 164.000 205.000 210.000 us To run all tests 20.806 23.759 24.666 sec Source for the tests follow. \ FORTH, Inc. 32 Bit Benchmark Source \ BENCHMARKS Loads system performance analysis tools." \ These blocks contain benchmarks for 32-bit polyFORTH systems. \ Modify the load blocks to suit your environmental needs. CR .( Loading pMSD compatability routines) CELL NEGATE CONSTANT -CELL : ALIGN CELL HERE OVER 1- AND - ALLOT ; : [ASCII] [COMPILE] ASCII ; IMMEDIATE : COUNTER ( - n) [FORTH] WinGetTickCount ; : D< ( d d - t) D- 0< NIP ; : MU/ ( d n - d) MU/MOD ROT DROP ; : M/ ( d n - n) M/MOD NIP ; : M+ ( d n - d) 0 D+ ; : PAGE CLS ; CR .( Loading benchmark routines) ( Benchmark support words) : .### ( n) <# # # # [ASCII] . HOLD #S #> 7 OVER - SPACES TYPE SPACE ; \ TIMER is redefined to format the elapsed time better. : TIMER ( n n) >R COUNTER SWAP - 1000000 M* R> MU/ 2DUP 1000000 S>D D< IF .### ." us " ELSE 1000 MU/ 2DUP 1000000 S>D D< IF .### ." ms " ELSE 1000 MU/ .### ." sec " THEN THEN ; \ [$ is the prefix to a testing word. It returns the ticks \ timer value before the test starts. : [$ ( - n) CR ." Testing " COUNTER ; \ $] is the suffix to a testing word. It takes the fast ticks \ timer value and calculates the elapsed time. It does do \ some display words before calculating the time, but it is \ assumed that this will take minimal time to execute. : $] ( n) ." = " TIMER ; \ CARRAY creates a byte size array. : CARRAY ( n) CREATE ALLOT DOES> ( n - a) + ; \ ARRAY creates a word size array. : ARRAY ( n) CREATE CELLS ALLOT DOES> ( n - a) SWAP CELLS + ; \ 2ARRAY creates a double word size array. : 2ARRAY ( n) CREATE CELLS CELLS ALLOT DOES> ( n - a) SWAP CELLS CELLS + ; ( Basic FORTH, Inc. Benchmarks) \ This series of tests analyze the Forth primatives. : $DO$ [$ ." DO LOOP" 1000000 DUP 0 DO I DROP LOOP $] ; : $*$ [$ ." *" 1000000 DUP 0 DO I I * DROP LOOP $] ; : $/$ [$ ." /" 1000000 DUP 1+ 1 DO 1000 I / DROP LOOP $] ; : $+$ [$ ." +" 1000000 DUP 1+ 1 DO 1000 I + DROP LOOP $] ; : $M*$ [$ ." M*" 1000000 DUP 0 DO I I M* 2DROP LOOP $] ; : $M/$ [$ ." M/" 1000000 DUP 1+ 1 DO 1000 0 I M/ DROP LOOP $] ; : $M+$ [$ ." M+" 1000000 DUP 1+ 1 DO 1000 0 I M+ 2DROP LOOP $] ; : $/MOD$ [$ ." /MOD" 1000000 DUP 1+ 1 DO 1000 I /MOD 2DROP LOOP $] ; \ $*/$ tests the math primative */ . This may or may not tell \ you how the other math primatives perform depending on \ how */ has been coded. : $*/$ [$ ." */" 1000000 DUP 1+ 1 DO I I I */ DROP LOOP $] ; \ $PAUSE$ tests the multitasker loop with PAUSE . It is assumed \ that each system tested has the same number of tasks \ defined in the round robin and that they are doing the \ same things (i.e. nothing). \ : $PAUSE$ [$ ." PAUSE" 1000000 DUP 0 DO PAUSE LOOP $] ; ( Eratosthenes sieve benchmark program ) \ This is the original BYTE benchmark. 8190 CONSTANT SIZE SIZE CARRAY FLAGS : DO-PRIME 0 FLAGS SIZE -1 FILL 0 SIZE 0 DO I FLAGS C@ IF I 2* 3 + DUP I + BEGIN DUP SIZE < WHILE DUP FLAGS 0 SWAP C! OVER + REPEAT 2DROP 1+ THEN LOOP . ." Primes" ; : $SIEVE$ [$ ." Eratosthenes sieve " DO-PRIME SIZE $] ; ( Fibonacci Benchmark) \ FIB produces a fibonacci sequence from the given number using \ recursion. \ : FIB ( n - n') DUP 1 > IF DUP 1- RECURSE SWAP 2- \ RECURSE + THEN ; \ : $FIB$ [$ ." Fibonacci recursion ( " 24 DUP . ." -> " \ DUP FIB DUP U. ." )" SWAP - $] ; \ : $DATE$ [$ ." Date access ( " DATE 1000 DUP 1- 0 DO \ @DATE DROP LOOP ." )" $] ; \ : $TIME$ [$ ." Time access ( " TIME 10000 DUP 1- 0 DO \ @TIME DROP LOOP ." )" $] ; ( EDN Benchmark) \ This is EDN's benchmark which does a string comparison. \ CREATE DST ( the following line is too long to be on this line) \ ," 00000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000THERE IS A MATCH000000000000000" \ CREATE SRC ," HERE IS A MATCH" \ : $MATCH$ [$ ." EDN's string comparison" 10000 DUP 0 DO \ DST COUNT SRC COUNT -MATCH 2DROP LOOP $] ; ( QuickSort from Hoare & Wil Baden) 7 CELLS CONSTANT THRESHOLD : Precedes ( n1 n2 - f) U< ; : Exchange ( a1 a2) 2DUP @ SWAP @ ROT ! SWAP ! ; : Both-Ends ( f l pivot - f l ) >R BEGIN OVER @ R@ Precedes WHILE CELL 0 D+ REPEAT BEGIN R@ OVER @ Precedes WHILE CELL - REPEAT R> DROP ; : Order3 ( f l - f l pivot) 2DUP OVER - 2/ -CELL AND + >R DUP @ R@ @ Precedes IF DUP R@ Exchange THEN OVER @ R@ @ SWAP Precedes IF OVER R@ Exchange DUP @ R@ @ Precedes IF DUP R@ Exchange THEN THEN R> ; : Partition ( f l - f l' f' l) Order3 @ >R 2DUP CELL -CELL D+ BEGIN R@ Both-Ends 2DUP 1+ U< IF 2DUP Exchange CELL -CELL D+ THEN 2DUP SWAP U< UNTIL R> DROP SWAP ROT ; : Sink ( f key where - f) ROT >R BEGIN CELL - 2DUP @ Precedes WHILE DUP @ OVER CELL + ! DUP R@ = IF ! R> EXIT THEN ( key where) REPEAT CELL + ! R> ; : Insertion ( f l) 2DUP U< IF CELL + OVER CELL + DO I @ I Sink CELL +LOOP DROP ELSE ( f l) 2DROP THEN ; : Hoarify ( f l - ...) BEGIN 2DUP THRESHOLD 0 D+ U< WHILE Partition 2DUP - >R 2OVER - R> > IF 2SWAP THEN REPEAT Insertion ; : QUICK ( f l) DEPTH >R BEGIN Hoarify DEPTH R@ < UNTIL R> DROP ; : SORT ( a n) DUP 0= ABORT" Nothing to sort " 1- CELLS OVER + QUICK ; ALIGN 30000 ARRAY POINTERS : fill 30000 0 DO 30000 ( I') I - I POINTERS ! LOOP ; : $SORT$ [$ ." Hoare's quick sort (reverse order)" fill 0 POINTERS 1000 SORT 1000 $] ; : Z ( n) PAGE 0 DO I POINTERS @ 8 U.R LOOP ; : BENCHMARK PAGE [$ ." the " .cold ." system" CR $DO$ ( $LOAD$ ) $*$ $/$ $+$ $M*$ $M/$ $M+$ $/MOD$ $*/$ ( $PAUSE$ ) $SIEVE$ ( $FIB$ $MATCH$ ) $SORT$ ( $DATE$ $TIME$ ) CR CR ." To run all tests" 1 $] ; BENCHMARK Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: japs@netcom.com (Jim Schneider) Subject: Re: 32-bit Forth for Win 95? Message-ID: References: <4i3252$657@lastactionhero.rs.itd.umich.edu> <4i46j5$juf@nadine.teleport.com> <4i4cko$h07@lastactionhero.rs.itd.umich.edu> Date: Thu, 14 Mar 1996 01:28:08 GMT In article <4i4cko$h07@lastactionhero.rs.itd.umich.edu> John Dunn writes: >znmeb@teleport.com () wrote: >>John Dunn (johndunn@umich.edu) wrote: >>: I don't understand how the overhead is in Windows on these benchmarks. >>: No i/o is used within the test loop, so what is it that Windows might >>: be doing to slow it down? >>Windows *must* be servicing interrupts. The time it spends doing so is >>time unavailable to your benchmark. >> >Since I ran the DOS program in a Win95 window, and since there is no i/o >in the benchmarks, it would seem to me that the background tasking would >be about the same in both systems... -- It ain't necessarily so. In particular, Windows 3.1 was much more cavilier about interupting a Windows app than it was about interrupting WinOldAp (which, in turn, ran the DOS box). I think this is because WinOldAp wasn't terribly reentrant. I don't know what that particular situation is on Win95, but I do know that the default DOS box (the one used if you don't take the trouble to create a PIF for your DOS app) on Win95 has a very low idle sensitivity, and usually a fairly high priority. This means that Windows 95 would have a harder time interrupting the DOS box than is necessary. And yes, Windows will ignore interrupts if it feels that the foreground task is important enough (this doesn't happen often for Windows apps, but it does happen fairly frequently for DOS apps). From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: What is Tyler Sperry's point about Harris RTX? Date: 13 Mar 1996 21:41:07 GMT Message-ID: References: <313FC25C.2A79@tir.com> In-reply-to: mlosh@tir.com's message of Fri, 08 Mar 1996 00:15:08 -0500 CPUs (or any other product, for that matter) do not live or die based on technical considerations; they live or die based on business considerations! Unless, perhaps you have a Gnu CPU in your pocket :-) -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: petersen@nicmad.nicolet.com (Joel V Petersen) Subject: Re: Semiconductor Applications Message-ID: References: <31419D7A.F75@texoma.com> <4hupde$q8q@nyx.cs.du.edu> Date: Tue, 12 Mar 1996 18:29:16 GMT In article <4hupde$q8q@nyx.cs.du.edu>, wbaguhn@nyx.cs.du.edu (Will Baguhn) wrote: > In article <31419D7A.F75@texoma.com>, Fred Meyer wrote: > >I learned Friday that AG & Associates have used Forth in their equipment > >for the semiconductor industry. I am also aware that Nicolet uses Forth > >in their FTIR equipment. > > > >Does anyone know of other equipment suppliers, especially in the > >semiconductor industry, who use Forth in their systems? > > > >Regards, > >Fred Meyer > >f3meyer@texoma.com > > > > > > Actually, I know a few people from Nicolet (they're a major employer around > here). Nicolet used to use Forth a lot more, but they're switching to C and > its spawn. And... it seems that their programmers are being forced to use > those large OS's to do development now (like NT where they used to use DOS). Thanks for the recognition. I'm still programming FTIRs at Nicolet (16 years) and continue to sneak Forth into them, just not as visible as before. I've been doing DSP56000 based bench controller work and have found text interpreters impractical on them (tiny address space and 24-bit words). Much of the code is still Forth "under the hood," but no way for users to get at it since it's headless. The wafer handler on our Semiconductor analyzer (ECO-1000) has a full Forth (68332 cpu). It is really only a service diagnostic tool since _untrained_ use can lead to breakage of a whole cassette of silicon wafers ($$$$). (ECO-1000 users, do NOT try using it!) By the way, is it really true that PCI Macs have Open Boot Forth? How do I get at it? Joel Petersen, Nicolet Instrument Corp. petersen@nicmad.nicolet.com FTIR (Forth is Truly Incredible, Really) From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: @! , Anyone? Date: Wed, 13 Mar 1996 09:19:39 -0500 Message-ID: <4i8i77$ene@sdcc12.ucsd.edu> References: <4i24p2$1r4u@usenetw1.news.prodigy.com> MABS85B@prodigy.com (Leo Wong) wrote to us all: >In my Sokoban Contest entry I wrote: >: @! ( newvalue address - oldvalue) DUP @ ROT ROT ! ; >Then I could write: >: MOVE-SOKO ( a1) where's-soko @! DUP AT-MAZE C@ EMIT ; >I've never felt the need for @! before. Is it a useful word? Is it >well-named? Hmm. It's clearly useful, and it certainly makes things clearer to me. If you're proposing it as a standard idiom (well, I certainly plan to use it), then that's a great name; although it doesn't say exactly what happens. Hmm. If you're only going to use it once in that application, perhaps it should have a name more specific to that use. I doubt it, though. How about ""? Less functional meaning than yours, but is read as "bracketed store" since the storing is done within a protection bracket so that the previous value is saved. : DUP @ >R ! R> ; Maybe >!> would look and seem better. An application-specific name might be "update" or "renew", or even "refresh". I think I would use one of these if I were writing the above. Now if I were considering it for inclusion in The Standard, I would probably pick something like "!@" or (less likely) ">!>". > LEO WONG MABS85B@prodigy.com -Billy From: Allan Rae Subject: C-to-Forth Translater or Compiler Date: Thu, 14 Mar 1996 14:20:59 +1000 Message-ID: <31479EAB.2781E494@s1.elec.uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Is anybody aware of a (preferably shareware) C to Forth translator or compiler? I've seen mention of one in an article about the Novix NC4016 in Byte magazine (1987) but no details of who was actually writing it or where to get it. Thanks From: rastle@ix.netcom.com(RICHARD ASTLE) Subject: Re: @! , Anyone? Date: 14 Mar 1996 08:53:22 GMT Message-ID: <4i8mq2$eql@cloner3.netcom.com> References: <4i24p2$1r4u@usenetw1.news.prodigy.com> <879@purr.demon.co.uk> X-NETCOM-Date: Thu Mar 14 12:53:28 AM PST 1996 The @! I have in my system, which I inherited from, I think, Guy Kelly and/or Pierre Moreton, has the stack picture ( addr1 addr2 --- ) acts like addr1 @ addr2 ! and could be coded in "high level" as : @! SWAP @ SWAP ! ; This semantics for the token " @! " is useful to me at least and is, I think, aptly named. Perhaps the word being discussed in this thread could be more aptly named !@ : !@ ( newvalue address - oldvalue) DUP @ ROT ROT ! ; Richard Astle From: rrt1001@cus.cam.ac.uk (Reuben Thomas) Subject: Re: Immediacy in the ANSI standard Date: 14 Mar 1996 12:03:26 GMT Message-ID: <4i91ue$esh@lyra.csx.cam.ac.uk> References: <4hemvm$8ma@lyra.csx.cam.ac.uk> <4hko6a$36h@dfw-ixnews1.ix.netcom.com> <4hua1i$h2h@lyra.csx.cam.ac.uk> <4i60mg$cr8@cloner4.netcom.com> In article <4i60mg$cr8@cloner4.netcom.com>, Jonah Thomas wrote: >In <4hua1i$h2h@lyra.csx.cam.ac.uk> rrt1001@cus.cam.ac.uk (Reuben Thomas) >writes: [snip] >From dpANS-6 we have the definition of "immediate" in section 2.1: > > immediate word: a Forth word whose compilation semantics are to > perform its execution semantics. Would you believe I couldn't actually find this anywhere? That eases my mind somewhat. -- Web page: http://www.cl.cam.ac.uk/users/rrt1001/ From: Marc de Groot Subject: Re: Forth in a PLD? Date: Thu, 14 Mar 1996 04:30:15 -0800 Message-ID: <31481157.5D25@immersive.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Years ago, I had a roommate who rewrote his fig-Forth implementation (for the PDP-11). The code was in Forth and Forth-style postfix assembly language, and was read by a metacompiler. He rewrote the code words in a platform-independent register-transfer language of his own devising. The register-transfer language described the code words in terms of operations on IP, SP, RP, and UP. He then created PDP-11-specific code templates, essentially assembler macros, that generated PDP-11 code from the register transfer language. It occurred to him that the code templates could be written to generate Altera logic equations, and that the code words could be compiled into hardware. I don't know that he ever actually burned any chips to try out the idea. Seemed like a great thing to try. -- ---- Marc de Groot | Immersive Systems, Inc. | http://www.immersive.com | Real VR for the net! "Remember, there's a big difference between kneeling down and bending over." -- Frank Zappa From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Anyone interested in writing an operating system? Message-ID: References: Date: Thu, 14 Mar 1996 12:45:53 GMT nq8140700-Davison (jwd@ihnns792.ATT.COM) wrote: > >Even though you don't want another "*unix* clone", is it really useful to >pick yet another separator for directories? /CODE/MOV would be preferable >to ~CODE~MOV in my opinion. > What about CODE MOV and we are back to old fashiened Forth. ;-) (I mean space as separator.) Andras From: John Dunn Subject: Forth Benchmarks Date: 14 Mar 1996 14:27:38 GMT Message-ID: <4i9acq$km1@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) Thanks to contributions from Forth, Inc. and LMI, I have a good start on a Forth benchmark package. I plan to put these and such others as I come across into a reasonably universal Forth Benchmark Suite. I will make the source available to anyone who wants it, either through my own web site, or some of the Forth sites (if anyone cares to do it); and I will also put the benchmarks into several execution-only turnkey'd Forths, which will also be available to anyone who wants to run the benches on various Forths on their own computer. Before putting this project to bed, I will invite all others to contribute code or suggestions or objections or whatever to what will become the Forth Benchmark Suite. By virtue of the fact that none currently exists, this will most likely become a de facto standard, so if you have benchmarks of any kind to contribute, please send them to me (johndunn@umich.edu). The intent here is not just to have a benchmark suite to run, but to compile the benchmarks into various versions of Forth, turnkey them into a run-only executable that can be freely distributed, and make these executable available for anyone to download and try out on their own machines. So much is dependent on the platform, it seems to me that this is the only way to get a handle on what kind of speed a particular version gets on a particular platform. I'm doing this because I need it, and it seems to me it would be valuable to other Forth programmers. Please help with your comments, suggestions, criticisms, and most of all, your benchmark code. Thanks. ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: Elizabeth Rather Subject: Re: C-to-Forth Translater or Compiler Date: 14 Mar 1996 13:03:56 GMT Message-ID: <4i95fs$61h@ecuador.it.earthlink.net> References: <31479EAB.2781E494@s1.elec.uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:31479EAB.2781E494@s1.elec.uq.edu.au Allan Rae wrote: >Is anybody aware of a (preferably shareware) C to Forth translator >or compiler? > >I've seen mention of one in an article about the Novix NC4016 in >Byte magazine (1987) but no details of who was actually writing it >or where to get it. Not exactly. Harris offered a limited C compiler to the native RTX2000 instruction set, which supported the "Forth virtual machine" but was not exactly what we know as Forth. The difficulty with a "Forth to C" translator is that the architecture and assumptions of the two languages are quite disimilar. The effort would be comparable to carving up steel beams into bricks to build a house -- not a good use of either steel or bricks. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: floating vs. fixed point Date: 14 Mar 1996 16:00:10 GMT Message-ID: References: <883@purr.demon.co.uk> <4i80r7$1s1@newsbf02.news.aol.com> In-reply-to: lglisle@aol.com's message of 13 Mar 1996 21:38:31 -0500 >>>>> "LgLisle" == LgLisle writes: LgLisle> In article <883@purr.demon.co.uk>, jack@purr.demon.co.uk LgLisle> (Jack Campin) writes: >> Speed, though, is something else; since Moore started >> advocating fixed point for reasons like those I've given, >> hardware floating point has become much cheaper. There aren't >> going to be many occasions when a hand-coded fixed-point >> numerical algorithm running on sequential hardware can beat an >> FPU. LgLisle> This will depend highly on the environment you're LgLisle> working in. FPU's are still rather rare for 8 and 16 bit LgLisle> single chip computers. When one is dealing with a cost LgLisle> sensitive, embedded project, fixed point is still much LgLisle> prefered. Also, certain specialized applications, such as MPEG-2 video and audio decoding (like the project I am currently working on), require *VERY* demanding real-time speed, and cheap cost. We are using fixed point because it uses substantially fewer transistors, and hence less chip real-estate. We have multiple signal processor type pre barrel-shift then multiply and add, then post barrel-shift hardware units on a single chip, so to keep cost down and yeild up, we want to minimize total chip area used. Floating point would be prohibitive in an application such as this. LgLisle> L. Greg Lisle, PE Forth Toolsmith | L.G.Lisle@ieee.org -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: utsl@one.net (Nathan Hawkins) Subject: Re: Anyone interested in writing an operating system? Date: 14 Mar 1996 17:16:04 GMT Message-ID: <4i9k8k$47s@news.one.net> References: Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: : nq8140700-Davison (jwd@ihnns792.ATT.COM) wrote: : >Even though you don't want another "*unix* clone", is it really useful to : >pick yet another separator for directories? /CODE/MOV would be preferable : >to ~CODE~MOV in my opinion. : What about CODE MOV and we are back to old fashiened Forth. ;-) : (I mean space as separator.) Well, that one of the simplest possible examples I could think of. What I want to do would allow for relatively easy access to nested vocabularies. Basically, the root vocabulary would be called ~ and subvocabularies of ~ could be referred to as ~FORTH, for example. However, if I am three levels deep in vocabularies, in ~SYSTEM~KERNEL~IMPLEMENTATION, and I want to access something else, the standard Forth syntax, while it certainly can be made to work, will become a little overworked. Not to mention obscured. Also, I want to be able to access words in a vocabulary, without executing the vocabulary word, and possibly changing CURRENT. Using space as a separator is easier to do, but not as clear. And clear is important for a system that relies on complex vocabulary structures. In the example above: CODE MOV ENDCODE makes sense, because of the context. When switching to an assembler, it is probably useful. But what if what we want is ' MOV ? CODE ' MOV ENDCODE may well not work. But something like ' ~CODE~MOV could be guarranteed to work. What I want to do is make it easy to refer to words in different vocabularies, in order to encourage a more hierarchical approach to Forth. More and smaller vocabularies, with an easier way to use them. *utsl* From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: Anyone interested in writing an operating system? Date: 14 Mar 1996 16:41:15 GMT Message-ID: References: <826181227.26001@abwillms.demon.co.uk> <4i7bde$4rs@news.one.net> In-reply-to: utsl@one.net's message of 13 Mar 1996 20:32:46 GMT >>>>> "Nathan" == Nathan Hawkins writes: Nathan> opinion. I was thinking of an extension to Forth, which Nathan> would allow a hierarchical vocabulary structure. This has Nathan> been done before, but what has not been done, is Nathan> convenient access to words that aren't in the current Nathan> vocabulary. That's the main difference between most Nathan> implementations of vocabularies in Forth, and unix-style Nathan> directories. In unix, you can access a file in a different Nathan> directory by specifying the path. In Forth, this is harder Nathan> to do. Hence my idea. I chose ~ because, to the best of Nathan> my knowledge, it is not currently used in the names of any Nathan> Standard Forth words. / is. Well, because the synatx of Forth is basically a sequence of tokens delimited by whitespace, you can't use tilde as a vocabulary delimiter without putting whitespace on either side of it. I already wrote your ~ word, only I called it v' for symetry with my x' d' o' and b' prefix words to switch bases. v' switches vocabularies. If you put a vocabulary in another vocabulary, then you have the hierarchical structure that you want. Here is the ANS Forth code (at least it works in PFE) for these prefix words: \ This word is used by the override words for bases and \ vocabularies. It takes the address of a variable and a \ new value for that variable, and returns the old value \ of that variable and its address so that the old value \ may be restored with a simple ! operation. : XCHG DUP >R @ SWAP R@ ! R> ; ( new addr -- old addr ) \ These words will evaluate one word from a text string, and \ one word from the input stream. They are useful for \ overriding things like the BASE or the VOCABULARY that is \ normally in effect, and then restoring it after that one \ word has been evaluated. : eval_str FIND CASE ( str -- ; evaluate the word in str ) 0 OF NUMBER? 0= ABORT" is undefined! " DROP ( number ) STATE @ IF [COMPILE] LITERAL THEN ENDOF -1 OF STATE @ IF , ELSE EXECUTE THEN ENDOF ( word ) 1 OF EXECUTE ENDOF ENDCASE ; ( immediate word ) : EVAL BL WORD eval_str ; ( -- ; read and evaluate a word ) \ These words allow the current base to be overridden for \ the execution/interpretation/compilation of the next word \ from the input stream. They restore the original base when \ the overridden word is finished executing. : base' ( n -- ; causes next word to operate in base n ) BASE XCHG >R >R EVAL R> R> ! ; \ ( compact forms for the most popular bases... ) : X' 16 base' ; IMMEDIATE ( force hexadecimal ) : D' 10 base' ; IMMEDIATE ( force decimal ) : O' 8 base' ; IMMEDIATE ( force octal ) : B' 2 base' ; IMMEDIATE ( force binary ) \ These words work in a fashion analogous to the base \ overriding words, only they override the vocabulary instead \ of the base, restoring it after the next word has been \ executed. : v' ( " " v' ) CONTEXT @ >R ( save orig vocab ) eval_str ( execute temp vocab ) EVAL ( read and execute overridden word ) R> CONTEXT ! VOCORDR ; ( restore orig vocab ) : V' BL WORD v' ; IMMEDIATE ( V' ) Enjoy! -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: rj@eli.wariat.org (Robert J. Brown) Subject: Thread model in the spirit of Forth (was Re: Anyone interested in writing an operating system?) Date: 14 Mar 1996 16:27:01 GMT Message-ID: References: <826181227.26001@abwillms.demon.co.uk> <4i4bmv$qmo@texas.nwlink.com> <4i4hi6$2cf@news.one.net> <884@purr.demon.co.uk> In-reply-to: jack@purr.demon.co.uk's message of 13 Mar 1996 13:30:24 GMT >>>>> "Jack" == Jack Campin writes: Jack> But this is just (part of) the storage system. There's more Jack> to an OS than that. Alaric, what else did you have in mind? Jack> What would a process or thread model "in the spirit of Jack> Forth" look like? I have already presented (Roch Conf 1990 poster session) a tree structured stack implementation that permits *EVERY* subroutine call (every word called) to potentially be the spawning of an independent thread of execution. The parameters passed on the stack may be viewed as a message. Instead of a normal call, execute subroutine, return from subroutine, resume initial calling routine model of execution, the model becomes pass message to newly spawned thread, either continue or wait for a reply message containing the results (or continue for a while, then wait for the reply, or never wait because you know there will be no reply other than a possible THROW, which is also handled across thread boundries in a uniform manner). The conventional execution model is implemented by waiting for the reply immediatly after passing the initial message and spawning the new thread. The tree structured stack permits the new thread to inherit the spawning thread's parameter and return stacks, and to modify them as needed, without affecting the spawing thread's view of those same stacks -- the stack, as a tree, just sprouts a new branch at that point. The return can pass new values for the stack pointers, so the calling routine sees the callee's stacks after the "return" is made (via a wait for reply message). The table driven token threaded dynamic binding for objects permits a fast duplication of the binding environment so the new thread can modify bindings without affecting the caller until a return is made. All the memory allocation and freeing, along with the reference count maintenance and freedom from garbage collection, and handling the linking of the tree structure, is capable of being handled by hardware, as I outlined in my poster session. In my "Dreams" paper, also presented at the same conference in platform session, and published in JFAR summer 1994, and available at: http://eli.wariat.org/~rj/dreams/dreams-rep.html I discussed the possibility of "migrant worker" tasks. These are tasks that can travel over a network (or be written to *ANY* I/O channel and then be read in [later] into the same or a different machine), moving between machines as needed, executing different portions of their code on different networked nodes, going where they can best acquire the resources they need at the moment. Shades of Java! (Note that I presented this in 1990.) The MOOSE project (Machine for Object Oriented Software Execution) is an attempt to design a virtual machine (one that should be practical to realize in either software simulation, or actual hardware) that implements provisions for these ideas. With my present involvement in custom ASIC design, I may get a chance to actually build a hardware MOOSE chip someday. Jack> ----------------------------------------------------------------------------- Jack> Jack Campin jack@purr.demon.co.uk jack@tardis.ed.ac.uk T/L, Jack> 2 Haddington Place, Edinburgh EH7 4AE, Scotland (+44) 131 Jack> 556 5272 -------------------- FERMAN PADiSAHIN, DAGLAR Jack> BiZiMDiR -------------------- -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: regnirps@aol.com (Regnirps) Subject: Re: Semiconductor Applications Date: 14 Mar 1996 13:29:55 -0500 Message-ID: <4i9oj3$i0k@newsbf02.news.aol.com> References: Reply-To: regnirps@aol.com (Regnirps) >By the way, is it really true that PCI Macs have Open Boot Forth? How do I get at it? Hold down Command, O, and B keys during startup. You can then talk Forth through the modem port at 38Kbaud. Charlie Springer From: flacy@crchha99.nortel.com (Mark Flacy) Subject: Re: Anyone interested in writing an operating system? Date: 14 Mar 1996 14:00:15 -0600 Message-ID: References: <4i9k8k$47s@news.one.net> In-reply-to: utsl@one.net's message of 14 Mar 1996 17:16:04 GMT In article <4i9k8k$47s@news.one.net> utsl@one.net (Nathan Hawkins) writes: >Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: >: nq8140700-Davison (jwd@ihnns792.ATT.COM) wrote: >: >Even though you don't want another "*unix* clone", is it really useful to >: >pick yet another separator for directories? /CODE/MOV would be preferable >: >to ~CODE~MOV in my opinion. >: What about CODE MOV and we are back to old fashiened Forth. ;-) >: (I mean space as separator.) >Well, that one of the simplest possible examples I could think of. What I >want to do would allow for relatively easy access to nested vocabularies. >Basically, the root vocabulary would be called ~ and subvocabularies of ~ >could be referred to as ~FORTH, for example. However, if I am three >levels deep in vocabularies, in ~SYSTEM~KERNEL~IMPLEMENTATION, and I want >to access something else, the standard Forth syntax, while it certainly >can be made to work, will become a little overworked. Not to mention >obscured. > >Also, I want to be able to access words in a vocabulary, without >executing the vocabulary word, and possibly changing CURRENT. Using space >as a separator is easier to do, but not as clear. And clear is important >for a system that relies on complex vocabulary structures. You could do something along the lines of: Where restores it. That could be implemented with a couple of hidden variables or even your own stack. Depends upon if you need reentrant behavior or not. I've worked with a Forth-83 system that had the words NEWBASIS and OLDBASIS that did just that and saved BASE at the same time. It was pretty useful when you included files. [rest deleted] -- \ ---------------------------------------------------------------------- \ Mark A. Flacy | flacy@nortel.com | ESN 445-8347 \ | (214) 685-8347 | Department 2B51 \ ---------------------------------------------------------------------- \ Someday I may speak for Nortel. \ Someday pigs may howl at a full moon. \ Expect the latter to occur first. \ ---------------------------------------------------------------------- From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: 32-bit Forth for Win 95? Date: 14 Mar 1996 23:45:45 +0100 Message-ID: <4ia7ip$37m@iaehv.IAEhv.nl> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <4i3252$657@lastactionhero.rs.itd.umich.edu> <4i46j5$juf@nadine.teleport.com> <4i4cko$h07@lastactionhero.rs.itd.umich.edu> johndunn@umich.edu (John Dunn) writes Re: Forth Benchmarks [..] > Having good, standard, and verifiable benchmarks would be very > helpful in resolving the speed issue, at least. > > If we, the Forth community at large, could agree on a > reasonably fair benchmark suite, What is wrong with the four programs Anton Ertl supplies? It would be nice to have a floating-point benchmark suite, and one that tests I/O speed and memory allocation. > perhaps each Forth vendor, or > anyone else who has a copy of a particular Forth, could build > a turnkey system that runs the standard bench, reports > timings, and exits. Why do you need this? Just ask for timings, most Forthers will be glad to oblige. The problem with your proposal is that I wouldn't be able to test binaries for Win95, NT, OS/2, Linux, FreeBSD, OS/9 etc. etc. on all of the CPU types these OS's support. And naturally, I'm most interested in the run-time of benchmarks on systems I do not run myself -- like OS9 on a PowerPC (because I might be considering to switch if it's worthwhile). It certainly is easier to consult a list with timings than it is to gather all the binaries and hardware to generate the figures myself. Some UN*X Forths can be very hard to install, no binaries :-) > This would go a long way toward resolving the issue that > everyone has a different speed CPU, different memory, etc. > You simply download the versions that you might be interested > in, and run them on your own computer. The list should not simply state the run-time, but the run-time of Forth-X compared to on the same hardware. For I propose a non-optimized sequence of 1000 push / pop paired assembler instructions. This program is looped for 300,000 times (about 600 million instructions executed). The asm text of the actual push/pop pair used (e.g push eax; pop eax; on intel) shall be stated in the documentation of the benchmark figures. I thought of using F83 instead of the asm loop, but unfortunately I know too many machines that don't run F83 (transputer, TMS320c30, RTXEB). There may be some CPU's that don't have a hardware stack to push or pop. We'll see? To kick off, here are my results for iForth on a '486/66 DX2 Intel PC. is the code granule "eax push, eax pop,". I tested under DOS, Windows 3.1 full-screen DOS-box, Windows 3.1 windowed DOS box, Linux 1.3.30 straight and Linux 1.3.30 X-windows. The Windows 3.1 timings are not shown (full-screen is same as DOS, windowed is 10% slower). OS time sieve bubble matmul fib -- ---------------- ----- ------ ------ --- DOS 27.92 sec 0.397 0.498 0.340 0.376 Linux 27.96 sec 0.400 0.397 0.315 0.376 X-win 27.98 sec 0.400 0.397 0.315 0.376 Note: Some time ago Andras Zsoter led me to believe that the Intel databook is wrong and a '486 takes only one cycle for both push and pop reg. The experiment shows this is not so: 5 cycles are actually used (4 pop, 1 push). This means iForth will really FLY on a Pentium... -marcel From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble) Subject: Re: @! , Anyone? X-Nntp-Posting-Host: fermi.clas.virginia.edu Message-ID: References: <879@purr.demon.co.uk> Date: Thu, 14 Mar 1996 23:30:32 GMT jack@purr.demon.co.uk writes: > > MABS85B@prodigy.com (Leo Wong) writes: > > Maybe I want a word whose colon definition might be: > > > : @! ( newvalue address - oldvalue) DUP @ ROT ROT ! ; > > > but which would probably be CODEd. > > > I've never felt the need for @! before. Is it a useful word? Is it > > well-named? > > If it was done atomically, maybe this could be useful for inter-process > communication in a concurrent system? Like, where the values were the > addresses of messages, and the protocol captured an incoming message in > "oldvalue" while returning a free buffer for a new one in "newvalue"? > I don't recall seeing exactly this primitive in the concurrency literature, > though. > > Leo's name sounds fine. I think of it as acting like those little carousels > British Rail uses at ticket counters: you put your money on one side of > a wheel with a barrier in the middle continuous with the glass partition. > The ticket seller puts the ticket and your change on the other side, then > gives it a 180-degree flip so your money and the ticket exchange places. > I can imagine Brodie's drawing, but I can't think of a neat word to capture > this metaphor. Perhaps MEX ( "memory exchange"), since that's what you are doing. (I also though of S&M "stack & memory", but thought better of it.) -- Julian V. Noble jvn@virginia.edu From: John Dunn Subject: Re: 32-bit Forth for Win 95? Date: 15 Mar 1996 00:44:38 GMT Message-ID: <4iaehm$353@lastactionhero.rs.itd.umich.edu> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <4i3252$657@lastactionhero.rs.itd.umich.edu> <4i46j5$juf@nadine.teleport.com> <4i4cko$h07@lastactionhero.rs.itd.umich.edu> <4ia7ip$37m@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) mhx@IAEhv.nl (Marcel Hendrix) wrote: > >What is wrong with the four programs Anton Ertl supplies? > Probably nothing, could you send them, or tell me where to find them in text form? I can't un-tar if those are the ones I tried to get last week. >It would be nice to have a floating-point benchmark suite, and >one that tests I/O speed and memory allocation. > Specific suggestions that would be more or less universal to implement would be great. >> perhaps each Forth vendor, or >> anyone else who has a copy of a particular Forth, could build >> a turnkey system that runs the standard bench, reports >> timings, and exits. > >Why do you need this? Just ask for timings, most Forthers will be >glad to oblige. > >The problem with your proposal is that I wouldn't be able to test >binaries for Win95, NT, OS/2, Linux, FreeBSD, OS/9 etc. etc. on all of >the CPU types these OS's support. And naturally, I'm most interested >in the run-time of benchmarks on systems I do not run myself -- like >OS9 on a PowerPC (because I might be considering to switch if it's >worthwhile). It certainly is easier to consult a list with timings than >it is to gather all the binaries and hardware to generate the figures >myself. Some UN*X Forths can be very hard to install, no binaries :-) > This is a valid point, however it doesn't have to be either/or. If there were a standard benchmark suite, then the data would naturally start to accumulate on various processors. However for developers who need to know how a particular implementation works on a particular platform, there is nothing like running it yourself. >The list should not simply state the run-time, but the run-time of >Forth-X compared to on the same hardware. > >For I propose a non-optimized sequence of 1000 push / pop >paired assembler instructions. This program is looped for 300,000 times >(about 600 million instructions executed). >The asm text of the actual push/pop pair used (e.g push eax; pop eax; on >intel) shall be stated in the documentation of the benchmark figures. > Good idea, but I wonder if the push/pop loop would be distorted by various cach implementations? Perhaps this should be just a register to register transfer, with another register holding the loop count. Something like: mov ecx, 300000 lp: mov eax, ebx mov ebx, eax loop lp ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: japs@netcom.com (Jim Schneider) Subject: Re: @! , Anyone? Message-ID: Keywords: semaphores names standard ANS References: <4i24p2$1r4u@usenetw1.news.prodigy.com> <879@purr.demon.co.uk> <4i8mq2$eql@cloner3.netcom.com> Date: Fri, 15 Mar 1996 00:45:40 GMT In article <4i8mq2$eql@cloner3.netcom.com> rastle@ix.netcom.com(RICHARD ASTLE) writes: >The @! I have in my system, which I inherited from, I think, Guy Kelly >and/or Pierre Moreton, has the stack picture > ( addr1 addr2 --- ) >acts like > addr1 @ addr2 ! >and could be coded in "high level" as > : @! SWAP @ SWAP ! ; >This semantics for the token " @! " is useful to me at least and is, I >think, aptly named. Perhaps the word being discussed in this thread >could be more aptly named !@ > > : !@ ( newvalue address - oldvalue) DUP @ ROT ROT ! ; > > >Richard Astle Why not the name EXCHANGE (or EXCH if EXCHANGE is too long)? It EXCHANGEs the value at the address with a new value. I don't know if the Standard has a name that is too similar, but I don't think so. If the operation is atomic (ie. nothing can interrupt it once it starts), it would be useful in implementing mutual exclusion or semaphore protocols. For example: VARIABLE SEMAPHORE 0 CONSTANT RESOURCE-FREE 1 CONSTANT RESOURCE-INUSE : GET-RESOURCE ( -- flag ) \ returns TRUE if ok to use the resource RESOURCE-INUSE SEMAPHORE EXCHANGE RESOURCE-FREE = ; : RELEASE-RESOURCE ( -- ) \ frees the resource for use by other threads RESOURCE-FREE SEMAPHORE ! ; RELEASE-RESOURCE This could be generalized by creating an array of semaphores, and having GET-RESOURCE and RELEASE-RESOURCE require a semaphore index. These indices could be given symbolic names, like this: 0 CONSTANT NO-RESOURCE 1 CONSTANT SERIAL1 2 CONSTANT DISK1 3 CONSTANT DISK2 4 CONSTANT DISK3 5 CONSTANT CDROM ( etc...) x CONSTANT #OF-RESOURCES 0 CONSTANT RESOURCE-FREE 1 CONSTANT RESOURCE-INUSE CREATE SEM-ARRAY #OF-RESOURCES CELLS ALLOT SEM-ARRAY 0 #OF-RESOURCES CELLS FILL RESOURCE-INUSE SEM-ARRAY ! ( NO-RESOURCE is always "In use" ) 1 0= CONSTANT FALSE 0 0= CONSTANT TRUE : >SEMADDR ( resource-index -- addr-of-semaphore | -- 0 ) DUP 0 #OF-RESOURCES WITHIN IF CELLS SEM-ARRAY + ELSE DROP 0 THEN ; : GET-RESOURCE ( resource-index -- flag ) \ flag is TRUE if ok to use >SEMADDR ?DUP IF RESOURCE-INUSE SWAP EXCHANGE RESOURCE-FREE = ELSE FALSE THEN ; : RELEASE-RESOURCE ( resource-index -- ) \ release lock on the resource >SEMADDR ?DUP IF RESOURCE-FREE SWAP ! THEN ; This could be used like this: : SERIAL-SEND ( byte -- flag ) \ flag is TRUE if byte sent SERIAL1 GET-RESOURCE IF SERIAL1 (SEND-BYTE) SERIAL1 RELEASE-RESOURCE TRUE ELSE DROP FALSE THEN ; This would be most appropriate in a multithreaded FORTH, but something like this could also be used in an event-driven system. Of course, this all depends on EXCHANGE being an atomic operation. On a 486 (which is the system with which I am most familiar), this is possible only if the top two stack items are cached in registers (or at least I can't come up with a way to do it atomically with only one or no stack items in registers). It would be done "pseudo-atomically", in that the update of the memory location and the read of the memory location would happen without interruption, but the primative itself would still be subject to interruption, in this way (assuming that EBX caches the TOS): CODE EXCHANGE ( newvalue \ address -- old value ) POP EAX XCHG EAX, [EBX] MOV EBX, EAX NEXT, END-CODE The critical portion of the above code (XCHG EAX, [EBX]) not only updates and reads the memory location in one uninteruptible operation, but it also does it in a locked bus cycle, so no other processor on the bus can access the memory at the same time. Fortunately, even though the primative can be interrupted before or after the XCHG instruction, this doesn't really affect resource exclusion. If the interrupting process needs the resource, it will either grab it before the XCHG instruction executes, or it won't be able to get it. Of course, this is not a rigorous treatment mutual exclusion, and the semaphore example I just used could be easily circumvented, it does (hopefully) illustrate a few points. From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: Speed of interpretive Forth systems on the 486 (Was: 32-bit Forth for Win 95?) Date: 14 Mar 1996 19:40:07 GMT Message-ID: References: <4i51qc$dl0@iaehv.IAEhv.nl> In-reply-to: h9290246@hkuxa.hku.hk's message of Wed, 13 Mar 1996 17:33:39 GMT >>>>> "Zsoter" == Zsoter Andras writes: Zsoter> I have just compared the forth systems on my machine (486 Zsoter> DX2-66) under Linux. The tests are those that came with Zsoter> gforth, except that I executed sieve 300 times. The Zsoter> numbers are the times which appear on the output of Zsoter> Linux's time command in the user column: The question that immediatly comes to my mind is does this figure include the time to read the Forth system image off the disk and initialize the Forth system itself, instead of just the time to run the benchmark? It would seem to me that you need to time 2 different numbers of runs, like maybe 300x and 600x, to allow the effect of loading and initializing and maybe even compiling the benchmark program to concel out so only the true execution time survives and gets reported. If you subtract 2 different numbers of iterations of the same program, then these overhead effects will get subtracted away and disappear, leaving the real figure you are looking for. -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: Tom Zimmer Subject: Re: 32-bit Forth for Win 95? Date: Thu, 14 Mar 1996 22:06:30 +0000 Message-ID: <31489866.DD4@ix.netcom.com> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> <4i7spk$e55@bolivia.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Thu Mar 14 7:59:07 PM PST 1996 X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) Here are the results of the FORTH, Inc. benchmarks as modified for Win32Forth Testing the Win32Forth system WinNT P5-66 Testing DO LOOP = 0.911 us Testing * = 1.963 us Testing / = 3.826 us Testing + = 1.452 us Testing M* = 2.003 us Testing M/ = 3.034 us Testing M+ = 2.844 us Testing /MOD = 2.324 us Testing */ = 4.045 us Testing Eratosthenes sieve 1899 Primes = 14.770 us Testing Hoare's quick sort (reverse order) = 170.000 us To run all tests = 22.77 sec ok Tom Zimmer And here is the source for the benchmarks as modified for Win32Forth, including the header from Elizabeth Rather; ------------------------------------------------------------------------------------ Dennis Ruffer and the folks at FORTH, Inc. have a standard set of benchmarks that we use to compare Forths. The results of the benchmarks on ProForth for Windows are as follows: Win95 Win95 WinNT 486-80 486-66 486-66 Testing DO LOOP 0.756 0.865 0.952 us Testing * 1.539 1.483 1.822 us Testing / 1.895 2.184 2.233 us Testing + 1.250 1.387 1.482 us Testing M* 1.594 1.538 1.873 us Testing M/ 3.227 3.859 3.815 us Testing M+ 3.063 3.447 3.495 us Testing /MOD 2.060 2.513 2.484 us Testing */ 4.587 5.411 5.498 us Testing Erathosthenes sieve 1899 Primes 15.140 16.727 18.315 us Testing Hoare's quick sort (reverse order) 164.000 205.000 210.000 us To run all tests 20.806 23.759 24.666 sec Source for the tests follow. \ FORTH, Inc. 32 Bit Benchmark Source \ March 14th, 1996 - 21:40 tjz added floating point support for easy time calculations. fload float 4 set-precision \ BENCHMARKS Loads system performance analysis tools." \ These blocks contain benchmarks for 32-bit polyFORTH systems. \ Modify the load blocks to suit your environmental needs. CR .( Loading pMSD compatability routines) CELL NEGATE CONSTANT -CELL : ALIGN CELL HERE OVER 1- AND - ALLOT ; : [ASCII] [COMPILE] ASCII ; IMMEDIATE \ March 14th, 1996 - 21:42 tjz changed to use the Milli-second fetch of Win32Forth : COUNTER ( - n) ms@ ( [FORTH] WinGetTickCount ) ; \ March 14th, 1996 - 21:40 tjz don't need this \ : D< ( d d - t) D- 0< NIP ; \ March 14th, 1996 - 21:40 tjz don't need this \ : MU/ ( d n - d) ( MU/MOD ROT DROP ) ; \ March 14th, 1996 - 21:41 tjz don't have M/MOD, switched to UM/MOD : M/ ( d n - n) um/mod ( M/MOD ) NIP ; : M+ ( d n - d) 0 D+ ; : PAGE CLS ; CR .( Loading benchmark routines) ( Benchmark support words) : .### ( n) <# # # # [ASCII] . HOLD #S #> 7 OVER - SPACES TYPE SPACE ; \ TIMER is redefined to format the elapsed time better. : TIMER ( n n) s>d d>f counter swap - s>d d>f f# 1000e0 f* fswap f/ fdup f# 1.0e3 f< if f. ." us" else fdup 1.0e6 f< if 1.0e3 f/ f. ." ms" else 1.0e6 f/ f. ." sec" then then ; \ March 14th, 1996 - 21:41 tjz modified TIMER to use floating point \ >R COUNTER SWAP - 1000000 M* \ R> MU/ 2DUP 1000000 S>D D< IF .### ." us " \ ELSE 1000 MU/ 2DUP 1000000 S>D D< IF .### ." ms " \ ELSE 1000 MU/ .### ." sec " THEN THEN ; \ [$ is the prefix to a testing word. It returns the ticks \ timer value before the test starts. : [$ ( - n) CR ." Testing " COUNTER ; \ $] is the suffix to a testing word. It takes the fast ticks \ timer value and calculates the elapsed time. It does do \ some display words before calculating the time, but it is \ assumed that this will take minimal time to execute. : $] ( n) ." = " TIMER ; \ CARRAY creates a byte size array. : CARRAY ( n) CREATE ALLOT DOES> ( n - a) + ; \ ARRAY creates a word size array. : ARRAY ( n) CREATE CELLS ALLOT DOES> ( n - a) SWAP CELLS + ; \ 2ARRAY creates a double word size array. : 2ARRAY ( n) CREATE CELLS CELLS ALLOT DOES> ( n - a) SWAP CELLS CELLS + ; ( Basic FORTH, Inc. Benchmarks) \ This series of tests analyze the Forth primatives. : $DO$ [$ ." DO LOOP" 1000000 DUP 0 DO I DROP LOOP $] ; : $*$ [$ ." *" 1000000 DUP 0 DO I I * DROP LOOP $] ; : $/$ [$ ." /" 1000000 DUP 1+ 1 DO 1000 I / DROP LOOP $] ; : $+$ [$ ." +" 1000000 DUP 1+ 1 DO 1000 I + DROP LOOP $] ; : $M*$ [$ ." M*" 1000000 DUP 0 DO I I M* 2DROP LOOP $] ; : $M/$ [$ ." M/" 1000000 DUP 1+ 1 DO 1000 0 I M/ DROP LOOP $] ; : $M+$ [$ ." M+" 1000000 DUP 1+ 1 DO 1000 0 I M+ 2DROP LOOP $] ; : $/MOD$ [$ ." /MOD" 1000000 DUP 1+ 1 DO 1000 I /MOD 2DROP LOOP $] ; \ $*/$ tests the math primative */ . This may or may not tell \ you how the other math primatives perform depending on \ how */ has been coded. : $*/$ [$ ." */" 1000000 DUP 1+ 1 DO I I I */ DROP LOOP $] ; \ $PAUSE$ tests the multitasker loop with PAUSE . It is assumed \ that each system tested has the same number of tasks \ defined in the round robin and that they are doing the \ same things (i.e. nothing). \ : $PAUSE$ [$ ." PAUSE" 1000000 DUP 0 DO PAUSE LOOP $] ; ( Eratosthenes sieve benchmark program ) \ This is the original BYTE benchmark. 8190 CONSTANT SIZE SIZE CARRAY FLAGS : DO-PRIME 0 FLAGS SIZE -1 FILL 0 SIZE 0 DO I FLAGS C@ IF I 2* 3 + DUP I + BEGIN DUP SIZE < WHILE DUP FLAGS 0 SWAP C! OVER + REPEAT 2DROP 1+ THEN LOOP . ." Primes" ; : $SIEVE$ [$ ." Eratosthenes sieve " DO-PRIME SIZE $] ; ( Fibonacci Benchmark) \ FIB produces a fibonacci sequence from the given number using \ recursion. \ : FIB ( n - n') DUP 1 > IF DUP 1- RECURSE SWAP 2- \ RECURSE + THEN ; \ : $FIB$ [$ ." Fibonacci recursion ( " 24 DUP . ." -> " \ DUP FIB DUP U. ." )" SWAP - $] ; \ : $DATE$ [$ ." Date access ( " DATE 1000 DUP 1- 0 DO \ @DATE DROP LOOP ." )" $] ; \ : $TIME$ [$ ." Time access ( " TIME 10000 DUP 1- 0 DO \ @TIME DROP LOOP ." )" $] ; ( EDN Benchmark) \ This is EDN's benchmark which does a string comparison. \ March 14th, 1996 - 21:43 tjz but is isn't too long for Win32Forth \ CREATE DST ( the following line is too long to be on this line) \ ," 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000THERE IS A MATCH000000000000000" \ CREATE SRC ," HERE IS A MATCH" \ : $MATCH$ [$ ." EDN's string comparison" 10000 DUP 0 DO \ DST COUNT SRC COUNT -MATCH 2DROP LOOP $] ; ( QuickSort from Hoare & Wil Baden) 7 CELLS CONSTANT THRESHOLD : Precedes ( n1 n2 - f) U< ; : Exchange ( a1 a2) 2DUP @ SWAP @ ROT ! SWAP ! ; : Both-Ends ( f l pivot - f l ) >R BEGIN OVER @ R@ Precedes WHILE CELL 0 D+ REPEAT BEGIN R@ OVER @ Precedes WHILE CELL - REPEAT R> DROP ; : Order3 ( f l - f l pivot) 2DUP OVER - 2/ -CELL AND + >R DUP @ R@ @ Precedes IF DUP R@ Exchange THEN OVER @ R@ @ SWAP Precedes IF OVER R@ Exchange DUP @ R@ @ Precedes IF DUP R@ Exchange THEN THEN R> ; : Partition ( f l - f l' f' l) Order3 @ >R 2DUP CELL -CELL D+ BEGIN R@ Both-Ends 2DUP 1+ U< IF 2DUP Exchange CELL -CELL D+ THEN 2DUP SWAP U< UNTIL R> DROP SWAP ROT ; : Sink ( f key where - f) ROT >R BEGIN CELL - 2DUP @ Precedes WHILE DUP @ OVER CELL + ! DUP R@ = IF ! R> EXIT THEN ( key where) REPEAT CELL + ! R> ; : Insertion ( f l) 2DUP U< IF CELL + OVER CELL + DO I @ I Sink CELL +LOOP DROP ELSE ( f l) 2DROP THEN ; : Hoarify ( f l - ...) BEGIN 2DUP THRESHOLD 0 D+ U< WHILE Partition 2DUP - >R 2OVER - R> > IF 2SWAP THEN REPEAT Insertion ; : QUICK ( f l) DEPTH >R BEGIN Hoarify DEPTH R@ < UNTIL R> DROP ; : SORT ( a n) DUP 0= ABORT" Nothing to sort " 1- CELLS OVER + QUICK ; ALIGN 30000 ARRAY POINTERS : fill 30000 0 DO 30000 ( I') I - I POINTERS ! LOOP ; : $SORT$ [$ ." Hoare's quick sort (reverse order)" fill 0 POINTERS 1000 SORT 1000 $] ; : Z ( n) PAGE 0 DO I POINTERS @ 8 U.R LOOP ; : BENCHMARK PAGE [$ ." the " ." Win32Forth" ( .cold ) ." system" CR $DO$ ( $LOAD$ ) $*$ $/$ $+$ $M*$ $M/$ $M+$ $/MOD$ $*/$ ( $PAUSE$ ) $SIEVE$ ( $FIB$ $MATCH$ ) $SORT$ ( $DATE$ $TIME$ ) CR CR ." To run all tests" 1 $] ; BENCHMARK \s Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: japs@netcom.com (Jim Schneider) Subject: Re: Anyone interested in writing an operating system? Message-ID: References: Date: Fri, 15 Mar 1996 01:04:54 GMT In article h9290246@hkuxa.hku.hk (Zsoter Andras) writes: >nq8140700-Davison (jwd@ihnns792.ATT.COM) wrote: >> >>Even though you don't want another "*unix* clone", is it really useful to >>pick yet another separator for directories? /CODE/MOV would be preferable >>to ~CODE~MOV in my opinion. >> > >What about CODE MOV and we are back to old fashiened Forth. ;-) >(I mean space as separator.) > >Andras > There are some problems with using spaces as directory separtors. For example, if you have scripts that depend on a certain directory structure, and that structure is changed, the script could fail in rather hard to debug ways (assuming that arguments to programs are also separated by spaces). For a concrete example, consider this (original executable is "my programs fileedit", which is moved to "my programs fileedit editor"): my programs fileedit editor In the original script, "my programs fileedit" would presumably open and edit the file "editor", while, after the change, the program would be started without arguments, which may or may not cause an obvious error. An even bigger problem would occur if subdirectories had directory structures that mirrored the root directory to some extent. For example, if your system had this directory structure (using the *NIX convention of separating directory names with slashes): /programs /my/programs the command: programs fileedit could conceivably have two different effects, depending on your current directory. Finally, how would you distinguish the root directory? You could use a special keyword, like "root:", but this is far uglier than any other alternative. I think that any proposed directory separator would have to be a single character that generally wouldn't be missed in file names, and won't cause problems in interpretation by either man or machine. (This leaves out both ~ and $, because I use both of them extensively in file names, and I would miss them dearly.) From: mj@isy.liu.se (Michael Josefsson) Subject: DSP-forth anyone? Date: Fri, 15 Mar 1996 13:52:10 EST Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit As a research engineer here at the University of Linkoping I have been contacted by an undergraduate student wanting to do a MIDI-interface with 'options', sampling, some filtering etc. He is planning on using a DSP for the 'options'. As I am always trying to encourage the use of Forth I have one question: Does there exist a Forth compiler for the DSP56xxx or TMS320C30? Free or not does not matter as he is willing to invest both time and money in his project. Any pointer would be appreciated. Regards, Micke Micke Josefsson University of Linkoping Sweden From: John Jones Subject: Software Audit Tool Written in Forth Date: Fri, 15 Mar 1996 13:09:42 +0000 Message-ID: X-NNTP-Posting-Host: pathfind.demon.co.uk MIME-Version: 1.0 Picking up on a few threads about "what commercial software is written in FORTH?" You may be interested in looking at our software audit tool, The Barefoot Auditor. A review copy can be taken from our web site, I'll email you the access code to unzip it. We sell this tool all around the world to professional Internal Audit teams and it gets great crits. Most of the unique features are only really practical in Forth At some point, nearly every organisation will need to conduct a software audit. If you are at this point you may like to try a restricted version of The Barefoot Auditor. Just to see how simple it can be to gather the data you need to produce your reports. As far as we know, it is still the only software audit tool that doesn't have an external reference database of products - it builds its own as it runs, including version numbers. Point your web browser at http://www.u-net.com/pathfinder/ If you organisation has someone who has the job of validating software license use, they will be very interested in this tool. --------------------------------------------------------------------- John Jones Voice +44 (0)161-406-7399 Fax +44 (0)161-406-7410 Meet The Barefoot Auditor at http://www.u-net.com/pathfinder/ -------------------johnj@pathfind.demon.co.uk------------------------ From: stamps@usa.pipeline.com(virgil stamps) Subject: Re: DSP-forth anyone? Date: 15 Mar 1996 20:35:22 GMT Message-ID: <4ickaa$928@news1.h1.usa.pipeline.com> References: X-PipeUser: stamps X-PipeHub: usa.pipeline.com X-PipeGCOS: (virgil stamps) Contact Steve at FORTH, INC. They can help you. -- virgil stamps Date: 15 Mar 1996 21:41:00 +0100 From: All@business.forth-ev.de (Wolfgang Allinger) Message-ID: <64u1JMmb7QB@business.forth-ev.de> References: <4i24p2$1r4u@usenetw1.news.prodigy.com> <4i8i77$ene@sdcc12.ucsd.edu> Subject: Re: @! , Anyone? X-Charset: ISO-8859-1 On 13 Mar 96 in article <4i8i77$ene@sdcc12.ucsd.edu> (William Tanksley) wrote: >MABS85B@prodigy.com (Leo Wong) wrote to us all: >>In my Sokoban Contest entry I wrote: > >>: @! ( newvalue address - oldvalue) DUP @ ROT ROT ! ; > >>I've never felt the need for @! before. Is it a useful word? Is >>it well-named? > >Hmm. It's clearly useful, and it certainly makes things clearer to >me. > >An application-specific name might be "update" or "renew", or even >"refresh". I think I would use one of these if I were writing the >above. Now if I were considering it for inclusion in The Standard, I >would probably pick something like "!@" or (less likely) ">!>". > Hi why not call it BARTER or TRADE ? SWOP is a also a good name, but I fear it sounds to similar to SWAP and might be confused, especially with my (bad) german pronouciation :-( I think BARTER describes it best, TRADE would be the best name for non english natives, because TRADEing will be understood, BARTERing is a special word, not necessarily known to all people. bye bye by Wolfgang -- FORTHing @ work Cheap Fast Good ...pick any two of them Dipl.-Ing. Wolfgang Allinger Brander Weg 6 Voice/FAX [+49] [0] 212 / 66 8 11 D-42699 SOLINGEN eMail: all@business.forth-ev.de GERMANY ## CrossPoint v3.02 R ## From: Elizabeth Rather Subject: Re: 32-bit Forth for Win 95? Date: 15 Mar 1996 12:51:29 GMT Message-ID: <4ibp4h$jv4@ecuador.it.earthlink.net> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> <4i7spk$e55@bolivia.it.earthlink.net> <31489866.DD4@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:31489866.DD4@ix.netcom.com Tom Zimmer wrote: >Here are the results of the FORTH, Inc. benchmarks as modified for Win32Forth... Tom, unless I missed something you didn't tell us what machine (e.g., 486/66) you were running them on, so it makes it a little hard to compare. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: bouma@cs.purdue.edu (Bill Bouma) Subject: Re: Anyone interested in writing an operating system? Date: 15 Mar 1996 20:34:31 -0500 Message-ID: <4id5r7$dcb@deneb.cs.purdue.edu> References: <826181227.26001@abwillms.demon.co.uk> <4i7bde$4rs@news.one.net> In article <4i7bde$4rs@news.one.net>, utsl@one.net (Nathan Hawkins) writes: |> nq8140700-Davison (jwd@ihnns792.ATT.COM) wrote: |> : Even though you don't want another "*unix* clone", is it really useful to |> : pick yet another separator for directories? /CODE/MOV would be preferable |> : to ~CODE~MOV in my opinion. |> I was thinking of an extension to Forth, which would allow a hierarchical |> vocabulary structure. This has been done before, but what has not been |> done, is convenient access to words that aren't in the current |> vocabulary. That's the main difference between most implementations of |> vocabularies in Forth, and unix-style directories. In unix, you can |> access a file in a different directory by specifying the path. In Forth, |> this is harder to do. Hence my idea. |> I chose ~ because, to the best of my knowledge, it is not currently used |> in the names of any Standard Forth words. / is. My system even allows this ok, : subtract : plus + ; : minus : negate 0 swap - ; negate plus ; minus . ; ok, 5 8 subtract -3 ok, 12 subtract:minus:negate . -12 Of course you can use the same syntax to reference words in nested vocabularies. Things are made easier by allowing every (yes!) word have a sub-vocabulary. It is a simple modification to the code that searches for a word. There are organizational and information hiding benefits to having word sub-definitions. Note that ANS Forth disallows this, however. 8^( |> : I'm a unixWeenie, in the sense that unix is the OS on the machine I spend |> : most of my time on (a SUN). I bought SunForth from Mitch Bradley and |> : started using it. I liked having the power of the forth interpreter at my |> : disposal, even though it didn't integrate quite as well with the rest of my |> : work and my colleagues' work as the Korn shell, Ksh, did. It was nice to |> : be able to create new words for common tasks without having to pay for |> : shell files, etc... Then I realized Ksh functions provided essentially the |> : same benefits and integrated better with my environment. |> I, too, use unix (Linux) almost exclusively. But, I think many elements |> of the design are hopelessly archaic. And I agree, Forth isn't integrated |> into the environment of unix. But I hope to create a system where it is. A few years back I was writing a Forth Unix shell, fsh. I got about 80% done and then realized that Forth and Unix just aren't very compatible. (I could make it work, it just wouldn't be a nice as I first anticipated.) That was the first time I made use of the tree dictionary structure. I needed the dictionary in some sense to parallel the Unix file structure. That seems to be what you [Nathan] are thinking about here? That part of my shell works pretty good. The points where I was having trouble were in arguments, piping, wildcard expansion... Basically I didn't know how to make it transparent as to whether you were calling a Unix program or a Forth function, which was the point of the excercise in the first place. |> But regardless of the pros/cons of an OS written in Forth, is the vocabulary |> structuring I've described useful to anyone else? It seems that such a |> design would make object-oriented extensions easier, as well as generally |> making vocabularies easier to use. (Anyone who has worked with Dos or |> unix could figure it out.) Exactly. I added object oriented capabilities to my system as a simple modification of the basic word look up strategy. In fact, my whole scheme of using vocabularies is more consistent, simple, and powerful than in any other Forth system I have seen. ;^) -- Bill http://www.cs.purdue.edu/people/bouma -- The worm gets the late bird. From: wilbaden@netcom.com (W.Baden) Subject: Definition of BL Message-ID: Date: Sat, 16 Mar 1996 03:08:35 GMT The Rationale to the Standard says: A.6.1.0770 BL Because space is used throughout Forth as the standard delimiter, this word is the only way a program has to find and use the system value of "space". The value of a space character cannot be obtained with CHAR, for instance. How about? -- [ CHAR " WORD " CHAR+ C@ ] LITERAL From: John Dunn Subject: Bencmarks now available Date: 16 Mar 1996 09:26:55 GMT Message-ID: <4ie1gv$870@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) My first pass at making a general benchmark suite available for Forth is now available at: http://www-personal.umich.edu/~johndunn/ The benchmarks were taken from the LMI and Forth, Inc. benchmarks, plus a few of my own. As of now, only 3 Forths are represented: Win32Forth, and LMI 16 bit and 32 bit UR/Forths. The LMI Forths include turnkey compiled executables that run the benchmarks, so you can test them on your own platform. All benchmark code is available as well. The benchmarks are as nearly plain vanilla Forth as possible, to make them easy to port to various environments. The benchmark code should run with little additional porting code in both 16 & 32 bit Forth. I hope others will add to this list, especially Forth vendors. The web site has directions on how to upload your contributions. Any additions to the benchmarks, or suggestions, corrections, etc., would be very welcome. ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: Elizabeth Rather Subject: Re: DSP-forth anyone? Date: 15 Mar 1996 23:06:46 GMT Message-ID: <4ict66$8pj@ecuador.it.earthlink.net> References: <826909559snz@tcontec.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: ,mj@isy.liu.se,"Michael,Josefsson",sagarwal@forth.com X-URL: news:826909559snz@tcontec.demon.co.uk "Paul E. Bennett" wrote: >In article mj@isy.liu.se "Michael Josefsson" writes: > >> As a research engineer here at the University of Linkoping I have been >> contacted by an undergraduate student wanting to do a MIDI-interface with >> 'options', sampling, some filtering etc. He is planning on using a DSP for the >> 'options'. As I am always trying to encourage the use of Forth I have one >> question: >> >> Does there exist a Forth compiler for the DSP56xxx or TMS320C30? Free or not >> does not matter as he is willing to invest both time and money in his project. > >I understand that MPE do one for the TMS320C50 (which may cover other devices >in the family) and I am sure that Steve will be putting his own message here to >that effect. We support the TMS320C30 with a board and cross-development software. Michael, if you will send your smail address and fax# to us: sales@forth.com we will send you more information at once. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: DSP-forth anyone? Date: 15 Mar 1996 23:07:01 GMT Message-ID: <4ict6l$8pj@ecuador.it.earthlink.net> References: <826909559snz@tcontec.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: ,mj@isy.liu.se,"Michael,Josefsson",sagarwal@forth.com X-URL: news:826909559snz@tcontec.demon.co.uk "Paul E. Bennett" wrote: >In article mj@isy.liu.se "Michael Josefsson" writes: > >> As a research engineer here at the University of Linkoping I have been >> contacted by an undergraduate student wanting to do a MIDI-interface with >> 'options', sampling, some filtering etc. He is planning on using a DSP for the >> 'options'. As I am always trying to encourage the use of Forth I have one >> question: >> >> Does there exist a Forth compiler for the DSP56xxx or TMS320C30? Free or not >> does not matter as he is willing to invest both time and money in his project. > >I understand that MPE do one for the TMS320C50 (which may cover other devices >in the family) and I am sure that Steve will be putting his own message here to >that effect. We support the TMS320C30 with a board and cross-development software. Michael, if you will send your smail address and fax# to us: sales@forth.com we will send you more information at once. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: DSP-forth anyone? Date: 15 Mar 1996 23:07:47 GMT Message-ID: <4ict83$8pj@ecuador.it.earthlink.net> References: <826909559snz@tcontec.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: sagarwal@forth.com X-URL: news:826909559snz@tcontec.demon.co.uk "Paul E. Bennett" wrote: >In article mj@isy.liu.se "Michael Josefsson" writes: > >> As a research engineer here at the University of Linkoping I have been >> contacted by an undergraduate student wanting to do a MIDI-interface with >> 'options', sampling, some filtering etc. He is planning on using a DSP for the >> 'options'. As I am always trying to encourage the use of Forth I have one >> question: >> >> Does there exist a Forth compiler for the DSP56xxx or TMS320C30? Free or not >> does not matter as he is willing to invest both time and money in his project. > >I understand that MPE do one for the TMS320C50 (which may cover other devices >in the family) and I am sure that Steve will be putting his own message here to >that effect. We support the TMS320C30 with a board and cross-development software. Michael, if you will send your smail address and fax# to us: sales@forth.com we will send you more information at once. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Svartalf Subject: Re: 32-bit Forth for Win 95? Date: Sat, 16 Mar 1996 10:23:22 -0600 Message-ID: References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> On 11 Mar 1996, John Dunn wrote: > Pentium 133 DX4/100 > Win32 UR/Forth Win32 UR/Forth > Eratosthenes: 59.43 18.01 1:03.60 37.90 > Interface Age: 1:21.61 27.96 1:32.71 46.80 > > Two things stand out: (1) UR/Forth is about 3 times as fast as Win32; > and (2) UR/Forth is substantially faster when running on a Pentium, > but Win32 is not. BTW, I also ran the benchmark on LMI's 16 bit real > mode UR/Forth, and got essentially the same timings as with the 32 > bit version Well, this may well be due to the fact that Win32Forth is going through Windows for all of it's services- and UR/Forth is not. All UR/Forth is doing is going through the DPMI layer in a DOS box and getting a chunk of RAM to play in. This makes a *BIG* difference in performance. And it might also account for the apparent lack of speed increase when going from a 486 to a Pentium. Frank Earl Earl Consulting Services ------------------------------------------------------------------------- Pursuant to USC 47, unsolicited commercial E-mail sent to this address is subject to a $500 archival fee per copy. E-mail recieved after any reciept of this notice implys acceptance of these terms. A copy of USC 47 may be found online at http://www.law.cornell.edu/uscode/47/ ------------------------------------------------------------------------- From: Svartalf Subject: Re: 32-bit Forth for Win 95? Date: Sat, 16 Mar 1996 10:28:24 -0600 Message-ID: References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> <314472D1.45AC@ix.netcom.com> <4i3252$657@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <4i3252$657@lastactionhero.rs.itd.umich.edu> On 12 Mar 1996, John Dunn wrote: > I don't understand how the overhead is in Windows on these benchmarks. > No i/o is used within the test loop, so what is it that Windows might > be doing to slow it down? There's the fact that you're running UR/Forth in a _DOS_ box. It will get time slices over every other app running except certain critical services in Win95. Win32Forth gets to compete with all the system services, and applications (Explorer is an app.) so there's more than meets the eye to this speed issue in the case of Win32Forth. Frank Earl Earl Consulting Services ------------------------------------------------------------------------- Pursuant to USC 47, unsolicited commercial E-mail sent to this address is subject to a $500 archival fee per copy. E-mail recieved after any reciept of this notice implys acceptance of these terms. A copy of USC 47 may be found online at http://www.law.cornell.edu/uscode/47/ ------------------------------------------------------------------------- From: John Dunn Subject: Re: 32-bit Forth for Win 95? Date: 16 Mar 1996 21:20:11 GMT Message-ID: <4ifbab$gi2@lastactionhero.rs.itd.umich.edu> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) Svartalf wrote: > > >On 11 Mar 1996, John Dunn wrote: > >> Pentium 133 DX4/100 >> Win32 UR/Forth Win32 UR/Forth >> Eratosthenes: 59.43 18.01 1:03.60 37.90 >> Interface Age: 1:21.61 27.96 1:32.71 46.80 >> > >Well, this may well be due to the fact that Win32Forth is going through >Windows for all of it's services- and UR/Forth is not. All UR/Forth is >doing is going through the DPMI layer in a DOS box and getting a chunk of >RAM to play in. This makes a *BIG* difference in performance. And it >might also account for the apparent lack of speed increase when going >from a 486 to a Pentium. > Yes. This has been quite a learning experience for me. It also appears that Win32Forth does substantially better when a full suite of benchmarks is run. On my 486/100 the entire suite runs about 32 sec on UR/Forth, and 37 sec on Win32Forth. You can run them yourself by downloading the full (to date) suite from: http://www.umich.edu/~johndunn/ ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: 100647.3306@compuserve.com (PETREMANN Marc) Subject: Re: Tiny DOS Forth compiler with access to DOS ints? Date: Sat, 16 Mar 1996 22:38:19 GMT Message-ID: <4ifg8n$20h@dub-news-svc-4.compuserve.com> References: <4gi3ff$2nb@mulga.cs.mu.OZ.AU> <64XAJuOFrbB@uni-upn.forth-ev.de> wfuehrer@uni-upn.forth-ev.de (Wolfgang Fuehrer) wrote: >In the moment i use Tom Zimmers ZF-FORTH, a F83. I ported it to the >Portfolio. I thing it's a littel bit better than UniFORTH - quellcode is >available too. ZF-FORTH also works with textfiles. In CSI-FORTH FORUM on COMPUSERVE, You can find TURBO-Forth, a special version for PORTFOLIO is available. This version is given with a fully disassembler and graphical function (YES, completly incredible, is'nt?) If you can't accessing to compuserve, you can have a version in disk support. Give your address via E-mail to 100647.3306@compuserve.com With best regards. Marc PETREMANN http://ourworld.compuserve.com/homepages/mp7 From: Andrew McKewan Subject: Re: 32-bit Forth for Win 95? Content-Type: text/plain; charset=us-ascii Message-ID: <314B3B4F.10C3@netcom.com> Content-Transfer-Encoding: 7bit References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> Mime-Version: 1.0 Date: Sat, 16 Mar 1996 22:06:07 GMT X-Mailer: Mozilla 2.0 (WinNT; I) To illustrate what native code can do for a Forth system, here are the results of two benchmarks I ran recently. These were from Tom Almay's ForthCMP package. I was trying to see how much slower a threaded Forth written in C was that Win32Forth for primative operations. All the following are Win32 programs: CFORTH Threaded Forth written in C. WIN32FOR Tom's Win32Forth system. FORTH32 A subroutine threaded Forth. TOY Subroutine threaded with inline code and pinhole optimizer. Benchmarks on a P5-90 under Windows NT 3.51. Times in seconds. BENCHMARK TESTS RUN ON 12/17/95 1. BYTEBNCH.4TH Implementation Iterations Time -------------- ---------- ---- CFORTH 200 15.6 WIN32FOR 200 10.4 FORTH32 200 3.4 TOY 200 2.0 2. IAGEBNCH.4TH Implementation Iterations Time -------------- ---------- ---- CFORTH 10000 25.0 WIN32FOR 10000 23.3 FORTH32 10000 5.0 TOY 10000 3.7 Andrew From: Andrew McKewan Subject: Re: Definition of BL Content-Type: text/plain; charset=us-ascii Message-ID: <314B3DEF.5CC4@netcom.com> Content-Transfer-Encoding: 7bit References: Mime-Version: 1.0 Date: Sat, 16 Mar 1996 22:17:19 GMT X-Mailer: Mozilla 2.0 (WinNT; I) W.Baden wrote: > > The Rationale to the Standard says: > > A.6.1.0770 BL > > Because space is used throughout Forth as the standard > delimiter, this word is the only way a program has to find and > use the system value of "space". The value of a space character > cannot be obtained with CHAR, for instance. > > How about? -- > > [ CHAR " WORD " CHAR+ C@ ] LITERAL That certainly won't work on any of my systems (returns 67). It is true that when WORD executes, the second characters of the buffer contains the code for BL, but by the time that C@ executes, the buffer contains 2, 'C', '@' and so I get the code for 'C'. How about this: : BL" [CHAR] " WORD CHAR+ C@ ; [ BL" " ] LITERAL ( two spaces between BL" and " ) ( or) BL" " CONSTANT BL Oh, silly me, it's even simpler than that: S" " DROP C@ Which will work interpretively if the file wordset is present. Andrew From: wilbaden@netcom.com (W.Baden) Subject: Re: Definition of BL Message-ID: References: <314B3DEF.5CC4@netcom.com> Date: Sun, 17 Mar 1996 01:10:33 GMT Andrew McKewan (mckewan@netcom.com) wrote: > W.Baden wrote: > > How about? -- > > > > [ CHAR " WORD " CHAR+ C@ ] LITERAL > > That certainly won't work on any of my systems (returns 67). It is true > that when WORD executes, the second characters of the buffer contains the > code for BL, but by the time that C@ executes, the buffer contains 2, 'C', > '@' and so I get the code for 'C'. This is the second time in recent memory that I've forgotten that. I'll have to cripple my system so I can't get away with it any more. > Oh, silly me, it's even simpler than that: > > S" " DROP C@ > > Which will work interpretively if the file wordset is present. I would like to see something that is the same as BL, so I'd re-write this as [ S" " DROP C@ ] LITERAL Now can we do this with the Core words only? With source from a textfile, how about? -- [ SOURCE DROP C@ ] LITERAL To define BL, how about? SOURCE DROP C@ CONSTANT BL From: Elizabeth Rather Subject: Re: 32-bit Forth for Win 95? Date: 16 Mar 1996 12:37:45 GMT Message-ID: <4iecmp$793@ecuador.it.earthlink.net> References: <4GaSx0un5yOQ084yn@axiom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: druffer@forth.com X-URL: news:4GaSx0un5yOQ084yn@axiom.net sergeant@axiom.net (Frank Sergeant) wrote: > > \ 2ARRAY creates a double word size array. > > > > : 2ARRAY ( n) CREATE CELLS CELLS ALLOT DOES> ( n - a) > > SWAP CELLS CELLS + ; >[...] > (It is functionally correct, as long as the CELL size >is at least 2 bytes, but suffers from a readability problem. >If the CELL size is only 1 byte, it has a serious problem. >If the CELL size is greater than 2 bytes, it wastes space, >which could affect the cache, and thus performance.) In the first place, ANS Forth has a min. cell size of 16 bits, so the first objection doesn't apply. As to the second, use of cells as a standard unit can waste space but buys portability; that was the design objective. However, I suspect that in this case the phrase "CELLS CELLS" in both the compile-time and run-time parts is an over-zealous generalization of an original "2* 2*" which really should be "CELLS 2*". Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: DSP-forth anyone? Date: 16 Mar 1996 12:44:07 GMT Message-ID: <4ied2n$7hs@ecuador.it.earthlink.net> References: <4ickaa$928@news1.h1.usa.pipeline.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: stamps@usa.pipeline.com X-URL: news:4ickaa$928@news1.h1.usa.pipeline.com stamps@usa.pipeline.com(virgil stamps) wrote: >Contact Steve at FORTH, INC. They can help you. We support the TMS320C30 with a board and cross-development software. "Steve" is sagarwal@forth.com. If you will send your smail address and fax# to us, he will send you more information at once. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Peter Knaggs Subject: Searchable Forth Bibliography Date: Sun, 17 Mar 1996 16:31:23 +0000 Message-ID: <314C3E5B.60EF@paisley.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win95; I) On Friday evening we changed WWW server (moving from a small Sun system to a very large NT system). You should not have noticed this, however the move did break the search software for the "Searchable Forth Bibliography" I run at the site. This has just (Sunday afternoon) been fixed. -- Peter J Knaggs pjk@paisley.ac.uk http://www.paisley.ac.uk/~cis/forth/index.html From: dharkhig@aol.com (Dharkhig) Subject: Starting in Win32Forth Date: 17 Mar 1996 14:31:04 -0500 Message-ID: <4ihp9p$95b@newsbf02.news.aol.com> I've been programming in F-PC for several years now, but I need to start programming Windows applications. I've downloaded Win32Forth v3 (by the same authors as F-PC), but I'm having trouble getting started as there's no documentation to speak of (not even a word glossary), and I've absolutely no idea what to do! Can anyone point me in the right direction? I'm new to this group, so apologies if this has been covered before. Garry Lancaster Dharkhig@aol.com Z88 Links Page: http://members.aol.com/Z88forever/z88home.htm From: Lars.Malmheden@mailbox.swipnet.se (Lars Malmheden) Subject: DLL's and Win32Forth Date: 17 Mar 1996 21:23:33 GMT Message-ID: <4ihvsl$ci5@mn5.swip.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII NNTP-Posting-User: edc4c285cf16ab5c2a083c4f4bdd69ae I have been trying to use the WinDirect DLL's from SciTech Software with Win32Forth. No success. Has anybody information on the correct way to use DLL's with Win32Forth or perhaps even tried WinDirect. Bye Lars Malmeden From: John Dunn Subject: Re: Starting in Win32Forth Date: 17 Mar 1996 22:40:00 GMT Message-ID: <4ii4c0$h9f@lastactionhero.rs.itd.umich.edu> References: <4ihp9p$95b@newsbf02.news.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 32bit) dharkhig@aol.com (Dharkhig) wrote: >I've been programming in F-PC for several years now, but I need to start >programming Windows applications. I've downloaded Win32Forth v3 >(by the same authors as F-PC), but I'm having trouble getting started as >there's no documentation to speak of (not even a word glossary), and I've >absolutely no idea what to do! > >Can anyone point me in the right direction? > After you have read the initial "F1" file, try using VIEW. It takes you right to the source code of a word, which is documented reasonably well. There is a considerable problem of not seeing the forest for the trees, but if you mosey around the source code, using VIEW and that great cross-file text search facility, it slowly starts coming into focus. ------------------------------------------------------------ John Dunn, Research Fellow University of Michigan School of Art e-mail: johndunn@umich.edu Software Tools for Artists e-mail: stfa@webcom.com home page: http://www.webcom.com/~stfa/ From: Marc de Groot Subject: Another Win32 execution speed comparison Date: Sun, 17 Mar 1996 15:20:58 -0800 Message-ID: <314C9E5A.57B2@immersive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) CC: wmb@firmworks.com, perry@firmworks.com I ran the Byte benchmark on Tom Zimmer's Win32 Forth and my own C-coded Forth system. The results surprised me. By the way, my system is called "Meme" (pronounced "meem"). Meme is an acronym for "Multitasking Extensible Messaging Environment". The system is designed for multi-user virtual reality on the Internet...but that's a story for another time... check out my home page for more info (see my .sig). Here's the benchmark code I used: ------------------------- \ Uncomment for Meme caps on \ CARRAY creates a byte size array. : CARRAY ( n) CREATE ALLOT DOES> ( n - a) + ; 8190 CONSTANT SIZE SIZE CARRAY FLAGS : DO-PRIME 0 FLAGS SIZE -1 FILL 0 SIZE 0 DO I FLAGS C@ IF I 2* 3 + DUP I + BEGIN DUP SIZE < WHILE DUP FLAGS 0 SWAP C! OVER + REPEAT 2DROP 1+ THEN LOOP DROP ( . ." Primes" ) ; \ Uncomment for Meme CAPS OFF : do-it fGetTime 50 0 do do-prime loop fGetTime fswap f- 50e f/ 1000e f* f. ." ms" ; \ Uncomment for Win32 Forth \ : do-it ms@ 50 0 do do-prime loop ms@ swap - 50 / . ." ms" ; ---------------------- Note that I have removed the bit that prints the word "primes" at the end of the sieve loop. Never did care for timing console I/O as part of the benchmark. Now, for the results. Win32 Forth: cd /meme32 Current directory: C:\meme32 ok fload sieve.m ok do-it 91 ms ok do-it 90 ms ok do-it 90 ms ok do-it 91 ms ok do-it 91 ms ok My system: ok cd /meme32 ok fload sieve.m ok do-it 59.100 ms ok do-it 58.880 ms ok do-it 58.880 ms ok do-it 59.080 ms ok do-it 59.100 ms ok Hmm. I would have expected my code to run at a fraction of the speed of Win32 Forth, considering that it's written in C, and it's token-threaded. Meme is based on Mitch Bradley's C-Forth 83, which is a hybrid token-threaded and double indirect-threaded system. It uses 32-bit constants to refer to the primitives, and 32-bit absolute addresses to refer to the compiled definitions. The inner interpreter is a huge C-language switch statement. Each case in the switch contains the code for one primitive. I use Microsoft Visual C++ 4.0 to compile Meme. I have maximum optimization turned on, and I generate Pentium op-codes. The test machine is a Pentium 90 running NT 3.51. -- ---- Marc de Groot | Immersive Systems, Inc. | http://www.immersive.com | Real VR for the net! "Does 'anal retentive' have a hyphen?" -- seen on the net From: ecbm@cc.newcastle.edu.au Subject: Re: Anyone interested in writing an operating system? Date: 18 Mar 96 11:51:44 +1100 Message-ID: <1996Mar18.115144.1@cc.newcastle.edu.au> References: <826181227.26001@abwillms.demon.co.uk> In article , jwd@ihnns792.ATT.COM > (nq8140700-Davison) writes: Nathan Hawkins writes: ... > There's some attraction to the idea of a > set of vocabularies and the ability to extend them, but I'm not sure how it > would seem different from the facilities that exist in Unix/Dos to have > multiple directories on a path, coupled with the ability to create scripts > and/or functions. -- Or perhaps the point is that a Forth OS would make > that kind of flexibility available on much smaller machines? This last point is an attraction. Does it -- or could it -- tie into the idea of a 'subcomputer', sometimes called an 'Internet computer'? Or is it more likely to link in with OpenBOOT as a processor independent platform? Or both? (or neither?) On the question of explicit access to a specific namespace in a vocabulary hierarchy, in addition to current norms which can be seen as opening multiple default namespaces, I prefer the /vocab/subvocab/word or vocab.subvocab.word to ~vocab~subvocab~word, and provided a vocabulary-style word that provides one-off access to the namespace, I think I prefer the space as a seperator even more. What I'm unclear on is the wisdom of conflating vocabulary and workspace namespaces. I like the idea of a persistent workspace containing named data, perhaps organized as tuples, but the names and hierarchy should be in the workspace, in part to evade the 'How do I forget whole vocabularies' problem. Virtually, Bruce McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: chaos@wiloyee.shnet.org Subject: Re: Anyone interested in writing an operating system? Message-ID: References: <4i9k8k$47s@news.one.net> Date: Sun, 17 Mar 1996 17:34:18 GMT i like the idea of a completely forth based operating system. having a tree of forth-words instead of a tree of files is an interesting idea, exspecially for distributed systems. but it looks more like an operating system that pleases people who want to create a stunning powerfull kernel than a system that pleases people who want stunning powerfull applications. for a stunning powerfull kernel you need multiuser and memory protection. any SIMPLE ideas about how to integrate this into your system? if you have one, then writing such an OS might be worth the effort. dierk "chaos" ohlerich From: 100647.3306@compuserve.com (PETREMANN Marc) Subject: Re: Tiny DOS Forth compiler with access to DOS ints? Date: Mon, 18 Mar 1996 05:01:10 GMT Message-ID: <4iir3u$7pk@arl-news-svc-3.compuserve.com> References: <4gi3ff$2nb@mulga.cs.mu.OZ.AU> aet@mundook.cs.mu.OZ.AU (Bert Thompson) wrote: >I want to do some programming on my palmtop computer (HP95LX), >but most environments are too big to fit into the 50K or so >that I can spare. (Even assemblers are generally too big.) >Hence Forth is the best alternative... You will found here the version of FORTH adapted to PORTFOLIO ATARI. It's run on a HP95LX. The program is named TF83.COM and follow here in UUENCODE format. Use UUDECODE to convert it in .ZIP format. Use PKUNZIP to decompress it. If you will have the complete system, give your complete adress. I will send you the disk by S-mail. begin 644 tf83.zip M4$L#!`H````&`$!#:QC"YX:BEE```(IV```(````5$8X,RY#3TT/`!(#)!4V M)S@Y:GM,G6X?"08!$S3E]I;WTT^\F5[A3:E06R_&_O_DT*%-FR:V"W#Q_/7P M#[.W(KP7Z*>N+T>LX(A??'!]MF)=?%7@^F?(/APH4*B+CP:D#7"]L&;_T)_3 M6MCH4ZE4D8-62=XNX+OV[?[T0C9MN*I3IT6G4G<;@X*K01P8T"L"8'316_4:#K]JH^57OY/ MGT)-;3\@KKL/:!1@7.>#BQO@=@'H4#"*(D^32VB M^2U4>C'%Q%8!I!]X.$!`8;(JGQ*;L0%]>N3^T,\H`*I_I#N3=,\YO*ZTHCR6 MM0>[RI_<>:+3R0KJ]BSL^U#26*FC#(A`SRZ([I8O.K0JU>*) MR..R"A5X&&I1*4/TYIJ@>S,]S4L??8Y:0-X#?!/53L`:.FV!Z:,D[8Z2'FK0 MJE.+#W->B+/W%1@XN7.!BZ9ZH!'H84#[*NB5?X-V`]`C\'/0'@KZY?"@G0'T M#M,[@/9<;/>DBP:U6C05&$/2!+;`T]OOA_U^@8BB7#8=+` MP,!C#CBK*ARMV9$Y?>@?S3\^F'Y8LZL7*'@H<"?.IP2N"/I8T'YT`/2AOT"/ M%='SHIY]Q?-,0[\=R!C[U@_R.\:>WM&TH[%[)N03HCX;=>?N.'MZ/-7.)]V! M9Z)F:C?M9*9=4KH"=T7-8XAMUL[$VK$.+!0[/[5:_/A`_HN]:;UCX%F_>I5/ MRG<"4MS>>Z`A;BWJN_S`?MUD$N\#/@_H/,BX\D^_@-RU8?U4J,`/\'GBZ??S M<_Z?LX:V2)!K>G?-GEW@(,P:.`GNBZ?WYNP<"3A[Z)D$N_RY9C<]D#!1*4U8 M*$&LZ84Y>P[NB1CV4)J'FEZ6LSLD2'CJU:#0P1+4XGVH9[_RG%(N'_O;$I=B/-83G[VK>F5W]4^EBGCW!\YZ>76+!P5B@GP/M,:!O!.TGH(/LJ1,N MB/4^]/1]GGT-V5.56K5XY8*X__]/SP;:^19XU(,R&>U/19E MCHMH^_OT2:+]=0'37VJ1:6/>Q!@CK]?JG9'\L`4;T++^:7:L!@/'AM1<$OO] MFIU$\[(]-2^@^3'-SJ;YV:R:']!\E6;'=/0R5>_2^NC@TQMQ=EK._EJ9L^/S MY9Q=4=Y7>5[;LZ-/?^+9^7B/4W6Z=@G6]!2D79KT,5?SDQZ(=:?ITS3[P`/>M3S2;\]J<7>+!P3&&_,V#6PY1H5TE\C<^?W2WP`PO_IB\L M8^)ZXE.L_Y[M3'>?+BO<_-%2=O@^]N#@7N+/E")2M?\>G7/ MB\MJF+UG'^ALM;Y>V_.LMAHF[V'/BM?X>F7/\WIVW].>]:_M];H`Q_`>)D_? MY*"U;NGUJ:#G!M[S]**F-:^7U+86.-LY65^5]T($UBH']`\$W68'O6\.T(I= MSBW\CU!L1,KBE%S'-2.%^%AH46I7FGUG;&&NB4`]UX)EBMVL`62 MIDT;-'S%9X^$Z;R_>'`[`FF-1M0R@2],`/,^P++\8OKX]X+D":0/[4'Z1](F M"ARA<=2+/:[FDT^^*]AWB9LMZ-6&64M&H MZ4U1>Q-JVV5E0\W2L_9'UAX?(>$9_2ZHW[=.J?;T>JC]$O4TJ$VKU28(3BL5 M,[;5LD&?.V!!@"X+%%/8Z@BLB:[^Q:]9`RJ/\)GSZ'?<"0\3P0P:6UYG4;A= M[BF59]`^A+;G38CXQS9!1NT>D']":V#S\PEBP3Z$N$*LF5AG_/9FS^">"&YX M1@5IG5`ZWMSIS4T[1`6;(-BEGU9H4R$P0_N:#R`)&Q/+,\U;.7:N8)U,#[`&WPSMG`($SS!P7NR(1>@??0 M%3XF0'2'\!7D_!6Y^R*_:D):97/J"J1\D]?7R@FS*XC?O@+L9>R9C\,6P`U; MTL/^X0)L_!,7@XVLD^JX!01WKP:X:O@KK<#E<7/>"`L%.OM^.@'Z^2Y(^(V7 M3@5_44'';WV\!V17>]Q;<6M4O`M;&FBK8XG=OCOK)MFLYM,R%QIN6L5IRG_` M!KSC3SOOECL6<*VX,+"J[?S.G08@5^RX007@ZUSP9B;^J^AM+WPDS@$O'!3. MGI.G0R\LK&(>U[A@'A>_0,S1NSIZDK]"PTP4&I?(0*&90?L@8^U>/YAT=<3Y MCZ?W_4&&AYDT-'HFPW[@/$FX-#24>0_M7>=^DN$@F_?T16E)*8;W19U`G+,U M+Z#9GS(DQ#)WNHQY`LQ.;*Q.VK"6-[#L^):7LJP(ECTM@SP,37D%RF[G_1$_ M?FK,,V#VS`P+C^CW8LT[:';'#`TC45D39>+L$)Q=4/I"@TYA=@G,3@NHD3(E MMCR%98?.$#%4*?53$?X8]!:@?4MZ+6ZDSYC'P.SMF,WRIAXJ5F)V;F"G;AVS M`_F549/FIU)1+1]Q9%ZQX:%)7ZJ3HNWY?ZGL!QO4SE"9+=,S&U2YO:?&O.`[ MS(_`CF.F(-P=1G(F]%V8I6#,G5*3FL;:(,A;?3ITNMR&N-`:G[LG@09@)1&V)$,V;5]V:CT[^F3#7>QHUP92+\*(S,[S<4+(2C M[!`W"*VF+\]Y@PZG!NW=KGYH4*C3A$23 MZ-YHDNZ7.N0WXA2+YBVO90V+W-71E8+H"D:Z6?9)'9"N"G586$B;JJOH%SJ( MIFM$/X2$=^J('>1HUJ?3U\GWGPT8IZT^\N8_.YB$#,!;M6LY.]`1_F&M&EG< M@6+&D^+UDQU[\0%.SS,L7H,\][2T68)@X5VU`Y\WU.'@'6)%?X[D#,+?L:D= M=!SC_0GO#A M("166P[Q02UFYB<:>$MN^!.WB.R#)MFC'\O>"6RXDAKF!T[57:;/=$"5DY4_ M#DB>?D"B#]I?+`\5C#K>_'ZP;LPWA;[VX6)K'M+'HRN3SC=-%WR>1I"?7C^` MZW:HJ:$"?YA(BCZUA;I:4B=[*R:(/N5_HXK!*RZ(/N3_HSB)UUW6UNG61_P@ M][P)5[75PW*'+P@;4GOZ!!/[2HEE_I@)YNA#@]H?B3"'WMV[65NW!!1Z$ MX/4?(72/H-L>A4.HH:M,ULT@KL9_")IAC7L>$X+33;9/38T5HI:*V-B.&M[/ M<8B)J)F/OH@\MPK!'1?C;H)A2>MY!D;6RQ"D^`YO-WK0+01P=4&E"J,WGE3( M7;$NR1>"!IDT16^?3'>&:"S:#HQ!YZQL'1*[P69*C)D6MIT`:I8_,VN.-:-B!=Y\WW`A[T>VV5&$,1:J'7$SNY7%=.()S!1T!29TKIG,2:,1"E>Y# MQGW!OQD4EG316G2:M"J.(*U^(RHZI(9_J/V?;%$1+9^2Z-/I"<7: M4\(S3E)",2(8`0$8ZF:*[?I#J259Z)8TRD"C%F9!6N?$#ETVHUY!J0YR0@0Q M9`E4SJTQ"VC2-B=<)_G_!9#2E.:$):1WTTI50O'Z):CTMD!KE3AH%"WK/S=\ M021NZ?FA+YEKG="A\LQ/MWN^G)N/6J5TSQ8^THE8)[J7\'?GDQO*E3<`*Z8D(WQ:7%"A"]CVGES`6R'F!Z MNGN"4O0J^D:],Z?K8TL[P+@'8`Q5[@`&3D%`[[JI1WG$19\Z(05+D9VXUH^T?]@[X^&.M^G3Y6A8_T?N4'3-79`C@9!# M`R-WDA0R(P34$#NPMTI!?-H\^D:+ZO:D%+)*[XLN32V7(A:@G;:0;I?B30_R M]K,4PL[A>FK(%+]J&5MI6_FNFR[3[88I)N*WQ*UQAYE:UM;JI/LY$K#T4@*, M"A%W4GV;.)V:.D7:3[ZA17S[L;\-YMA6RZ?@OPWOHTR\%UC[N:SMJ$[@),%- M4S.L\'.9!3GM)7SCZ%H0]Y?U1++^:).$X2["[>GQ,Y MG63N=_TBB[J^]%CA/0!UN@][(,SS$H0-$G'!Q?G_%USO:RGE\K5KE*#H$_%( MVZZ`"5P+6?@0;)F/&&QNJAK&/;Y#M!$=&U#1*LJR#@L7 M;EFV(,X=9%JW=L.R34NV+"=MW&S:L6C3EI4+TNU;MR#IRGU;UZY@5=HD!.S+ MMGE/WL>^E2NW[%BZN0*":=,DTATNB*('T4_.!8%OQM,Y'@YR2\^VS-H2\L6= MMAAV[%C%<]@QJ)U.\633/.T&P,F':,.Z)5-O76'9'\@F.=(-*P;;R9ZXGNW; ML6'IIC$KI"N&;2?\W3>FL`;&SK^00BM M=061#:_@*[R,=/QEO9LWESP="; MC$C&:A=<1ALY9_L'56-#>F[<.G6&A9!-CI0K&(X3+OGU$@NZ'S7M"JQ*UZPH.*@NBZ,L,3AK*^>% M.+LC9W(D!D:0LW-R)IMT3\3953F3.KHOXFR**]!T4HR%!LEL[B@,>(X5H^$1 MSLQK?8QA>)`"C6-@OT,'NH!+.-,!#U&*G,W+M!>.0>+ERZL2FE<2^A^\;!;/ M/6.8K\R:DLKG`"J5#UE*C^0U^=-%\Z]V,7SH"EH?FE28<1!S%<,C9HQG,KBR MJ*($8:P<[C(SX@8RFS\_-ROV7BB\JO$AT`L-```'[8?&>]ZHT:+2L"P1U$$S M]N+8]M6E%S8Y!5QGQD*8IJ.ZIYJANH1?A*/59D1DM2-U`BA=`I>;$<%,MP1] M^C=..Z#WB28]`L)..J.6G3M+F'+1\TSHY\,<42YXE@=Q0I^K73%T++BF1-)= MJD984]L-[!JM)QBZ M&:V@UN)+U@IL:LA>ZF(:KT1R5+>&V&\N_%&]V]8053?I@@-F?]`:FB>N4::& MJ&J&4CC8@K&0 M]L`;K+7A!@#DHM@$5PQM94:1D3>`?K]YTJ9!F5VK@FNTWHV%$/"I5-,(JM&E MNAIE51=GX!(W_MTXPFI^('BGY5(DK)D9'Y['(B6#LIH="P M.1(B-Z`Y*:#!<](>Q3__2_"B`B1#=J,[HY6/RX[NLD M_=2E2:'#["`2']_^*V/MCH7/=TU78-"G5[PGYNTG.W@W(';^Q%N=>?/%V>6[ MK@-.CP)WHQT/OYQBPYH-_MR.6S;B.8?[%;@86Q-.\=`>U.T).Q8BX/,0+$5' MF:7IV`X>)U*DSW;8Q30]BW*QV]F18@ZP<$=%-H0UPEM>T=`36TM1=]#RRF3= MXW9$6-!EA[K:;Z^;=K3W%_>T;(.?H@6[+3=>'FE7:1O07FR?RJ?J(>);;KYX MC;/:_%/\)]K6E1XP8"W3EH?T2,AO>G?'E!X;#9M\K1'9)7I&9YCTH#OL`\52 M7$5;55]\0+%(@:;J4;A+5*^C*0'>[]B`%6^(@->LJ+SKN^">+PR1((OIN7H8 MJN#BHM]W#/:..HRB-;1'1`.@6;(9>>`>&(`#+E,`)@FXS@O]\O7V*L(VQ8$_ MVT,N=BR+A^(?!*=*6.&>!7R7K50A`8=/R/8S:/CQP MNL2D<&K0,_61"6D$T'SAQT(Q?Z)9?8'C+9[S]B+/9G/V[:&#H3E^,`6Z9%P_ M%OT0K3VB]V'OV8K&QSQ;U10.E2Q)?CT,JS:^Z;T?*=SS1-%N-6G1:]'R=G'3 M43_@RD&G(L?]XGB)_FW+L:O0Z=PBYX<*!T5?0`53=X'1_WB M"_YNS-_5@ZOZ&6QZA)JR$$YT.DN0N%KFZ:M1^R:B2MN)A9HRJ0&]4N>G1?/% MX39`F1H91.Y,N($MS(!*\K)C()@V!E%<>,N[*;;)3X'2/^/VOK)LVUVU_6%[ MZ1_&_V`)3,-6?:AN8T,WJ\9KA]S1%/E'D(I_5H6R,3JL@^B.P"'X=H:#N%T! M,8%K\@^@9%-Y46(NM.KT*!OD3A"*Q$$:_M$"^I`J>D&"?!FO,X;QPCHGPKH99R@%WD9/EYT%"!['57D,>ZL%=;4CX&B)6)U62@[-R]Y`\ MU!`S!`\!P''J@$,N]I@XX.#A"K%X_-/O_;:2'&1@UI5#AIJ^`&L&:O^_.?B@ MP*V/M`>C[3-#1*19@=V%B#2KTGZ,YG9#%C,ZA,LJD8S'28Z5"EV(.$V/]3DCOW0M M+`*%N6G2J5,0T=@#>NHB>K7!VQ4J-'P],,+*XE\'75^+#'PJO"6$L0+H=$^1 MQHMBP9_J+VI1:!IPA'QB>.`(FTYC%SEXZ\GN#T>V3D^_6_,'1R;?TB>Z:+?W MN8L@$FUB?)0B4SE1,BCI[.V%0KYRQ,C;A35$*M-!1PIF*1UP?X]JXFO0(?BI<('0@.@&T@U\L MG?U+\UKHCN%Y,_E5@IA-/3\"[_0;7B,"UM7M(Y;C?_G(1X_`7C/V*.M?(\UYW\YXD1**=#!+U2$-N MLR.-[O'[9D9D0LZ(-&Z2A:B5VN'2`*3UDG29-E2JR``-@=;(*)4C)GDH[IUP MK(]L.SK:_2"/)#D(3`,BVS"_CM9/HE&R;/.MJ29]TIHN2&VW.`6"9.?1VPQ9 M$R^C/IO\!(5W`6H?.'&IRW)#UE#BTF%+(O;1:F&,F5HM9JU>5`X)3GT>ZMBS M,C*?ASDJGYY9PDPY38CYM"52FY=,_*-IQ-(#+0GHF@M3=Q[J."5IKDW=HD:H MZZEKSKEDL=0^R+0L\0)*\?8EC?^01G^0YG7(^]$]L,79Q]'S@B:)9?Q<59TY MF7/^$ONT5I/%5V3C M$@5DPS8G6;P*H)Z$4=CJGF^:?VH_Z-$@2,GTRJ9)E2:-73F0?Q#=]ZH)=YL, M:H):9TEU4F/Y%%`T-Z!"0)Y:#)^2+CVRZ4)0?Q5)*O%P]YS@26(HCY;".JX3 MA;12/"G\B=),,AM.X"2U]+'B2"+=[C_$G<@W=7778;$@T$1/'KLVI:EU"9RE M/%2VO]\3X:7/]J04BT@>-WE8Y)"298]01KO>#P.6U`[6@CVQ/:IX(^M6?(M1 MX]Q/[BAYCOTD)Q)KT\47JR7J#4&6Q6-*TPD<55M(8-EUJTEY)%GN-/=,@$#* MT&(SM=6VMT8`*;+V@`$03"]P+-L=5LFM]8B!QT^>-$05YALTY!/6RO4DX1`] M?6B1*7_A'%$2_B&-$K-(U@VAN):#;/J&4NN!%G1;G*V)G7I2(DQ;RY.AIOBA M,60LJFC:T-NY75,46OXVRJPI*Z.L5OF\U=.BZ(%:3[.F M8\R4@DF&TBZM+PP(&XYR$]TDMSC<".9RGBIP MT63NTO0E(=Q8Q-1:A#-5I6(K-&AK7P6&66HV;A$XM&05=HNEK5@%$H-YLIS( M$S".OJYU0J1+9E6YB"2P6U0GC6_7F2]FFXRK,K$,+4.\K2XT4[*MRQ!H2YCQ ML2D)D?)/ARG/KF)Y1Y6$9I_:HIB6T%9=5[8:7'%<[U,VWR3=6YA3UBF!XB+- M<&7A$:;KTI:>@[G_6SIF29Q?KVR[$O/*ORN_H^@7FT!EJJ_HH"C:-M'$Z(ZZ M.PM6+T*;J@N)>`6J7W?%.U5%?/0*]$-%>WB5@WTFG>8P)+8D<>+/4_9*(%E# M);,N#&:B^_V5:US3#\U`9JG-DC5;T[J*K%$FG1*R&/;'R.SE3CRC`/E*856+ M1*5?LLC<+LCNK\EB(6U=BNU<,;(D M'+5J$CE;S])/;3+/&5&RQT@`#ZEVXD\6]#AD%H&<"?[3)?C396&O.>Q+&*6I MV+L0%ESIBA@L)MW,8M`1+.1M0M9RPY[IU$SYL6C#UB63(MA[5)B)C_#/+-$` MS9&S//3'J;8DVC380%2-`&E78(5TO[N:]OPL:;]L'L(%_R"UZ..E-P&G<`K[ M;*=,.6*DX`FE9PX(/K!%_%*MKVQ).T/\*,FGGSX-8#C+PDV7`/2,X`U;<'T. MKCUZ!77%=+W4)M=H'=?H;-I1MML26C%3I64:$Z0 MH$LC6`6]V1:W83&RS9X(M8,$V)=F#R;[;IKA6RZF8=8*ZDF5-`M/>9@S909I MZ@1^(SS62C!JRA38NP0P`C03CY6KWM#EYA8V7R<:2#V!_6,[+.?R+7*:ECU# MEFZ!5[`3P-%>=/!IN^(U7[H\ MM.JW,+(7F_,4%M9)I?K8O(7:O,^"\27I'FSG8>#NDO!3*`-5I6-@4GYO?8*2 M.DNB7'$H1YH\8I=RV+9I+3?-L%;?+@=)6%8M3=*%+SM"N+%&VE>DFM'1.C]( M4=RUG[@^`]LW!+`MU]V@>O-%^$Q&C&033:NU,.WB!C0@.F72">2"RWS9?ZR4$E-1*?2`J"&T?S@%_3!:"Z%WN!___(\@S.'0,MPJ*D4 M"2!-GW\I^T5RV2-UB>8W//Z+`Y[6I$6VE8Z85%[_Q;.$SD&E/=.XGD>QMD"E M*#2:%R0;UHV!#@QYH2[7$8?=,JB*LU59V/YZ0_<+"W5H$2$_ZR8REIOA4/3_ MBS.?ET.7"^^X_Y4M#/X0QG(LM3KM%0">1A$F7A#FL;KCO:LHHA9W<0=J7?I` MC^GO9QNH-:>.K)EAGG19KMM['#Y\T!>!TNXKB%1HO=_/BX07RDNBY'LU[Y@" M9=&J7Q(*.$[:A959\-]A(AX1:E![I8*7O&V.:A[&F.\9T MU`7^+[PS4N&V,Y5MC(93=HTTJEQYY+!CLV"[Q]'&2*.\21%8BC-JDI]`NHRH M`T^"U)D?AO;#H.85AIJ$IZ,\32]XMB>CGY[DV'-'5<*YY@@ M2M22)$Q4?,6W6+8AM:66-WK@60I;M\=X"OL*2Q-5)[Q9.)'OA6GH2D.I*FIV]OYCK-KN)5YOD%NRQ1J-WB7>GCZ*1%Q8<^$(S',9 MH;<8]?QPRN4XD=^/6>>8AN MCN3.]K74[WO&_$AI@*X'A%)L[6DD25RG3GM; M3"=;E7[MU)^[-I'Y2D.,.RC<'6@W:-6X(J&"J#@,CAVW/8*>:).@<6&@9+GC MN0)H5@/-))MFKJ"9G0>DFA5!,TM6!LD\YDB`I&G4K;)ID/0([2-FF=W]+(#[ MIN[C?^#+H2"X:CS1^TY0YLHJED#)F]K10`]D]K"4#*BP[0!\)W'SP).B?JP0]*P M5I+F6I)F1U;+-0D;&847VTV%3['TPJL'J!5ES<(HG/94%U%DL,>S5';)/&6+ MX1I>9JU/;Z:3>UG:VL9SS7MWP)'%KUEB!$$G-OJ(]W>ZZA%&RW M:)=.0J(@;?9GP/R#M^.L8&G.T?@N%BY98RS M4VE'V5;RR+DV!^%$5I!H)S^9_[S!VG&^JW2I#R=G^OU"G^T"<@ET$NJ,GL3A*&<[3$JL$>IJ')7?J+_W(^@#1A*N;XX#B\)$]01%_L%WS.V5"HR80[?T M3[/5?K$KE*T',@?FJO,<"IFJV%4'F<[8YDOQ!D"@ZUU."('ME M1G$%V=Q0-N7EQV0C(61S4-DTVK)XLK&K(_(2-_CN_36,G\*'7:/4#<$E/R+9 MBD=1;-DZ7>,,"R@I*`$@[_,>9A) MHBSU:%)G5J9CXSPLY1D'\>S2AOZ'CJ5T2UPKRL1QZICS`):MTVF+.@?_'"J- MT]6CCF>U5[41[45LKKHE0,"IIX?!`>LH^,WW<56OCHHG(EZ^TT-NW*P."I+F MJ9/PCRHN3(831O6@6/R21.=!D?AFYH`I7=6"3+72K!CM:I# MZK7G6/4R7^LM>\D/JJ2-=3HY/!18WVH]F_H>/=*#ZRC0-!.Z&W-KB8,4CB3' M1>P0K/`X<3H<)SJP6MQY8IK3^R)I4.=Q*3W1IX8&"V8 MCT@H)Q-$GSE3<--I6I+?_>Y.J3O,2]:Y.^3\FV$ONP->1^LT/))JDATF!6M$ MT'UFKIG13W@'A6\X^5?$R5GOF)@M9Y?"WD'@90/D.PD9/&M!S?/[9$V&C5:$ M/8K-.;7UG5BU2H6J&#[,_[0%1*S3CRQVD'VGX"!I=NH[71790269;+Z#L4.R M#'"6,=]%;C\+DO^.`GXC*,L*^$_RS+I5\7K:`9AV:]B^=ZXRQKWH3P)$UF\E\D]4QYRUU5R%Q9]3B_#-^M[\ACJ MKSRDE2:/EG+1(V7OE*JOIT]:QC7D@*5:;]0#"$MT6 MU9;-:(B'XN>"UO_I8H#W1X;+)]'M59M"<^XQ)'6_O-%+S>;P_P%>+5#J= MJPI'D;A>V@/J,N9_E%M3.K_G\!XBGQVAAO)3ZJ!5;O_* MT"?+GP6GIEUQ:$K(`7CJ,\#Q!@G*#\)MH,$7FH_KBFG[4Z=,9-<(N/WW(.`" MC_L+W';IBW5@DM4?U?RD3T(AW@"RX28_K850A&9FJT)P=;_/FA]J?H\6 MH.AZ'UV('U2_G:QBD.GP+P:+QDXU%/;EK3X=XK?M=.[+`F&$(JS2./4L'EU] M_JAD^GH/R3^HT")0\I(HJZ.(5JX_"Q-]\DG_\KFJVD``+Z"BZ"HAX=@^=)?V M.E\JZ4)Z+L$I2]G_)" ME'V#LKL$LCXRY4DH6\!M/65OH>Q$E">B[#:4_8GR0I3]A[)K67=L5YNC>IEU M4_8$R@YGW91=@K+O63=EWZ#LD92?"NUJ4_93U:;L+91=5K4GN]J4G9.]*?L/ M94<.]/!6H5A73DW:C6L+]`%Z>Z:)/&N"9W?WK%"^:0G/[N^9^N8;GMUA4,); MN#D)9O?`;-F\!;.O8+;TF-T&L^-@5BS,_H/9`JNAFW_%,YM;I3P[D6=B;A7S M34*9FY3S34*9FS3D5P0_?3?@>!YD22E[`F7OI/P499>@[-.^;,J^0=E1!PT\ M2MT>=8"^OA^92MV4'7G0P5.65<*R]UI?2IC(:62YE+AP2>XGA>8F6MVU)X4R M9E*@T,#7S$@_%#IXZQ4ID_?:;TJLL&7R:-0_#Z9$W]W7PQ)H=Q#+^<[B`)M_ MRWNI.'_C%/)YVE3(YA[3!K,P[268$\6;,$O3GH$Y631F";+/%7)7RK*69XFW M:^.PC&HK=@(!.ZSI1=H+3:*M7F*$`W($9DV;BG>F3Z_%ZP%<-&GM)>U-/KQ( MCT.:!/2V)]7"<@W"QCRTI#TK%8#KZH6H*CWNS+'D63V'VGO^\:P!APJ^XJQ" M;E;^'QPBK1&'%@+:BU0;?73N&CDK3[,`(;(V6<_2HE(B\ZA#AJ;A3;U4*==^ M74B8)BXDZY8:.`!YFN<0D5P!=I(.8&8XB:XZQ*E?,L&RMQ::=\A+$W(UTR;V M;R3YYD$HO-X>DG0LE`R=872V+B3RO)NL&'+)/MTK'/L'-,7+\2V8]L& M03_QG8\$2P68H2;RKG/WB&-WP);U[[AP\G"T,:MPU>]:U,DZ&^ M*,06^)@===LRO&"0:-_*D<"U;9J"%]+TVZ&#:2`-SWT7TE(D6M78U]"&#Z;M M+.J,'L:]#6YX4MSNA8NFK>*TOZ$-GTC;FMH^P*1$N'5ET<$XN.'9W+/+H<$\ M%!>F>5QY$>Y87Z47:1.E%FU$_QSZ\#'TW8V^N1=C:WWQE][[0!C\P+/[>YNT M7I1P3!CU\/MUU0O(SFR=:?31FER:Q#O@C7B'%D\N-!+?%%#S_+BNV<%WQ=M_ MBD\O-D*7'']GW]4-[7N.79,7K*@BI^!`7Z:_;:2Y*F@)BVX6K7:$'1L M(YO;9%/E%7>'#ENS&TG[;&GS96G;W.6V_IO:-""53%3%5[S'5Z9YJ+#(DKH, MFSYXQ(E2)#KED?JJUU/M'ZIMNNNO71,G*9$IIH]W>]H$#S9[KNUBVQ+3WI+* MU*E'40&!MSR27NVBUGGK7$MO;VDS]7L.*"WZ()*DZ,E'RQ-H34F[V=(!U?9] MFZ'LB`+`:JQO^W/)7R32K8^Z+:S6UFC7=F$ENW[I_(?TDX:'K+X,L:CJM(Y( M%7%.M,<*C:JS1(H\]U]S]3H4J6<"4]$9D4QWMD0/E,"CR]([Z2=68*JRF[KP M(ETNO^F'C#9ZT^Y-Y89@1M.^M$S"16(_80!<1NKB,FA&X4QNU:5E>%+5CNJ> M76]KV>TM0ZN(DED46-];"Q*EJQ%6VD M1[-'.HA2I@;SM3F`-1$L9BI8^)&:]#/\%%F\4V M_D"PXI#0#:CC)G5S3:Y-^N@:*GE#MV7)]TUB5\L4`<23#AXZ55?5BP[*,R+/B>B8%/%_D62\]DX&>G_*LK9[)4,]%4%NK2GY'NY7MCHSL*L[VVTK2 MHJLJF0S:#1?98^I!)>6#!D`H\O#HJ$IZF^ZHI#"5T;^Q0:J%5.FC2K2@8!H. M=_/#L,:E80/X/2J]Y16)@=U-64&>UK5*FJ8W#VF*:II>K$0,:DP,4-]2%MA6 M_2ZJ++CPGD=4-B'Y>+`^'S1H<-Q$;\@PKD39B4F_9G2P[")3JL9,2VI@S9>[4*+IR?[A$"PN] MMC\FY3DH.]-ARN,K84Q9B2G/3P8P94VFO#Y5-65O`N[UE$>BK-">'L?6/G7) MTS>%.FVS-K7\EVN_@N^9!HR1OMFE)Y2W4ST1L/2%YINR%QU.OLA"=D;*GM0Z MXZ(PE+^D/%*FU,"GI_R`ID]BS;3V5LO>M"JSY5$LGWM)0]AYZJ+DDB_&WN4D MM.GMS\"-9?T,?V?+:UNVC131_FSYL44%*PT.G^B=Y.6QKS1H,>7GK``6]$J% M)2\G^8-,J!="[79NBC,EK'0H5FW+CP.2,P&OVNDDCR+9CR7_Q\^F[D>HO<]% M,6IGECP?TS)J9T+M?I2/HFQ(:HFG!Y'#V+([L?8ZRJ-1UF?*Q^D)IJS3E,\C MFQ:T43N<"<2H'8JZZX$`3%FJ?8_RGKXMW?$D+XK)65`C-<;D/PE$`Z\&?GK. MHL5^WY2]:##E&_V^*4NU$_M]&W(PZ:'+V(<'>+8L[<=)"-6Z+>M3:%`O;GG\ M3`LMF]P:CGF"30TQRUH*KGES:]>96_F#DUK^8]-!<&1-]E1@[^334AZ#Z?E]2Q[U:G(LH=J8\2ZX::%FBW,RHD$L?FEH%!K-$*UAU)6:#:NU'D>':;\-F5_0K19GIM3%J*- M=%T,^U.0R#T!GEFWG+5EKB-THKQ087QEM@.U(8>W(]XZ\8,AKS6 M*J15.U4!CZ@1C%X88(Q>Y`5"&SR7 M[%0PS%XY3*KC`"D^'0R3IZ_E;MO^_!/K>2FW.K94UNY#W!K'@/330-4V6`XP M?E-!U$)8#E#(^CR4C;1,27T'M/M!5;GZ*NKFF@Z0#=!761?8=(!WEHU=(L,! MJ%[BM1MO&FS7WB5(N=)R@(^J3VJLK+Z:&%_\ZA.6-=*BSJ"WYLQ+.5^4Z=1B M`4?7-:G5/>'N)]8J]FEA(0[423P)%&B14 M0I$UEG*_*Z`0+):)M/)3^AB5+=,R$ZO&D4(M+*,:+U&-?LN3>!`"[FW4*V?@ M\"?<8'B(#V`8G6AP3U,%3#78T^E4HE:<.N M]>]A;\/Y-_P9;WZ_YV"A58^#5ED?*W^HZ;%RQXK0QRI0PR=",6L#8.^/Q5E8 M::B^&%BZ/11.6$%OF0J^L!$F2_.P6XM&D#!?C'UTPH##KCF1:[J5]/]VH;., M>LAIDZ9WVFR-TVZ(X@E&O;L1-,2H_H&+(IZGP+H/42`K^MK_K2[VB!\*_>LF MQ7M&^?3HU6]4V.F^5I]0OO;T?%]EKQO*&.PKQQ3_X/_IU42[VY^'44(-\J:+ MIF8=U6J5H4\<,/&)F>5#!WX8_M\E].Q0#Q6V4^'LJ3./BIO__RUGG6CTY\0VAU'0?@Z&@5`,.9![=TC>9#"\\,!RMAL/V&#XO"J!\J$/-!R MN`Q,9M=5CP`$XN.N#W&-1==><5[L6LGWB(`+Q0"EW%/(Z?CX6(;XHV33-J54 MNB]A'-X<$#8L5"F&IM#NIESCX`*H-:U40SUYIT=<5QN.D'[MAV)YISU*+=2* M,QG41TO=E>>FG/6[P#QC[%!3`G>,G3'RT0(%2*>1Q[)\NDQ1@U(N\:'`FTO5 MRAXE.=9_1K07ERH8*G!OT%G^Z4DX^S5P#>WN>:SNTU-X=G/>'KJ?L[]/7\#9 M>?N@[1*WC%]1K]:QMP*/*EB'2'*Y*#!W>RK5;,U#ZD1AN2,L>%@`CWG2D$@_ M8'7$KM"YXT^17GJ,A.PI)D+ MN"[X@@/I<7`]6])J;\VC4'.#<]$`-UU-4C4D:A/)[9UUYCCOCJW*7BM_K>FA M>)82TIR-!AM,G+`+C_.T"RNB$>HJ<@-%4H%N\>U5%#\(L!$:.5:JA5WDT8F9 M"WE!DMNE_5(][.+RREW#/#=,95OJRZ8M9;M0*2GOH@Z@AB"I]E31>P2Y,*JQR=:>SDA6%U^TX0V`,R3$X#VXUX M?=(I7+%J[!<:JU]T:!4B_-1IBQ>?%)X>?ZJ#F7@`'M`#B'$)0%B`*&=TCO^! M6_&8(Y4*O-6Q3;>'[((>G"CX06],55\%>P>!=I;CFKU89,WVYRAV- M"-V10ITB,RX/2A(=HH[A>5R.SZ_ZA4Z\;E5509[`B5I[#@)2QVG9^!5ZU<0N M@+031W4G"@3K/P_L>@)IDBH(,,BY-K1ROA59[7(7DAMR+IBC":3)(HYMC$TK M'/K6#>/LMB[(GB"4%GVM:56P2UV=)H)WL,=3'>SD]2K="M<*'7JC^L*BY)'( MK+9IQU8=NS@DE]HB;XBPU*'=L'+3AA6#F`8N?@-_?(7?M"JPM:C1HM+`5@6/ M(;1UVKF"Y-$'X20]B#_T;F/:!13Y.UR8W90].D/;$$2CRQ0-F"&O*G8I0XN0 M"1/VT\L55&-=1)Z]BLATZ*.DTJGAF0X`HQZHID%Z,9M,".)0"S-5::XCH!39 MHXV0+$3KY"MH_DE)=VE"B[O4OKIAVDQ=(V)Y_="?X&O"W]!.1J_;AI&4#O6R M?A"#[;:&Q'K92GG/`5KI5TA7LB=4U>GFA;/>>78;W6TV#>E*)MO&V3`:+KIK M>2'UX@"O=NB`+@/>0'?L5R.[2`<3V2<$6-=JAL??ZFZK^*V^O$KWJN>KX:]8 MK3^QU)Q@55,HAMG:3E:%2\7*%PN22U*Z-U``'K@BQQ(D$Z!O6I3()WN1>M4Y MI08TRW/N(NA((\`YE=R?7H,4FF*4!NW3EFDZ%J*0!(D=K\H% MHE[4MC5IT8\7#W!L&9W'8]E><,&($4Y+&6=I?J#!=\.F]P7X>`O.N6-$[P[N M'U*!VA4U:Y9VJO@>9KF1:G)NEB.N=N)/%O=MU_S9+-E'R6:Q/D,C2AP$'YVN MG#Y>AGR^40B535(CE1U90')*=?GU63!VVS&MHK,Z-NA`8KF`85^-8[AYNN*4 MDF@9ZB91MK++@+O5K&G)6<[<&5_RFEX2954&#&_B4=)Z`MZ:X)<2KLS!#A%R&YIV[]L/R-@V]5E.[4_Z___"2Z-W_)K(U.* M3@<55M@G[DJYJ^:NH[O"[EJ[*^^NQ;M4MB[OBK[K_JX4O21_TNM,+P23SMXU M?A>$>H=F(AC0@VI-]&IRRB\MFJW),4[1KVIR;[/7*(3W#H5A2KW#YCJ1(X;P MG"B79FWB45PLEVREDNUQLKF7;%>235;D`J@1Y&MOP;T"[^D$MN?-I69)X>XFV;P%,6C87I][S;1&UJ;?-E4JRV>PI MX!$LHY.]HTC/<[?+XJ)#*Y+P71R#'.)0L`I2417$ZE M=!5%&R0##+">>,NI67K!19N")*"VES0X%(FQ@T3X%`HCZA3XY/:?)1LT5A_? MS60K09!&8X(P7L(I+;4LW34W@VLVLG M:[1[B/:)II5#,'B>JZ\C;B)G.C"Z4= M44[B*+>V/&J=*D=5&^JJ4H4^;4&=D*,0+N=(E%;!_=,I;=*F6POQFC-1@-Q% M03C@1)^Y5?9FL/%F6;$QCT0H+F2(MY1ZDL(.S#"2BJ@<<,L(KAJ0C89;Z<;A%L5JS3T:=7#\IYAV"@5SG] M!+2"3Y\=U(5@3V?(V?BQ8DZ?[-D_@BV4\R)9#\-8FK3*MPJF"LSW'8Q'V9/5 M?FF'H(J>ZI!J>%;5'"98P4.A04QZ+UA$I"VXX*G%H%=P`BI8PD\P]VD]0R.# M?6$!L!A&/*UJGW+S.!"\>T2G*DQ\0."^%DSQ-4!XGNN:OG9-5P5S&!T?YT#R MZ&")NVSZ-!GV1AM@KU$$CX*FT[BL;_57#29LJTP+"%?_C)H5DJ;>"G M#^9XU09!01RKT2WTAJO"1<-.#&-55WALF&8I[EP/:%1K5U#1;._"A6Q=5U43 MH3-M3`[BMT!@X<$U?T)N*-IA6$$28+Y@Q&'R;,J.3?E)RK:`?WBK4*PK.OEN MSWMZ]DC:!924=Z7LG)0?`N^YE/V6LL$[,647!D\3@==GS]Y,V^#]F[*78>-$ MX%V=LJ.KG@B\UU/V;O`*)6P:P,QV?]I/@7<(RL9;4:S@?8.R9_A8!N\FE-VA M&'@6-H_Q[/.6-G@/HNRL\#*!XTR4_05\>$KY*\I>Q>:\Q6LNAMG!B@T\*ODW MR=XF_"'LGD?9271M[$Y(V>^PF];\$;,WNGYD*N4Y*?N/BF'M?DK9-6EM(,-E M*3NL=ENJ=N_%[+O%[(3<5=FR"WKHP")S5RSNSH[9J5TOA6[/I^SJKEV*T4J` M9[F2ZY-<>P1E%SCF^B37RH'9-8X-?"WY%,E^J?<:RQQQC.V?AS!B^ M_;:9S*#O`8T/I8ZB\`QZIV,/05.@ZP@>.L`%=$74['F:E]%,/72LF2;5[)2: M\T$TEI"LV;^++0R%-W\2EP-K=E%L_Z-MSLQT:ZV1CG%Q:I!LUC$52XYW_M M-TB,)Y(9<7M)-L@?\%C'8SF/53T6]UAC1'-F1$>/H78_-@H5:E=,N;:OYB05 M?9?,"!ANXQG):*ZK)1N8C!;U*9DP,.<=D^FB,MI.]6.^,YDFZ&8RA\N<5TWF M"?KGWJ$QGYM,X"NJ>X6R[<;)#+[>)J/#'--&I7S,!*,@([.V'/9X6'RB.UFM M8GF3!4V6O!B]=3H9R1A'.?3BL+S#M@_K4>Q3L7S%JA:;K9SKVSK<,'+;]0*M MX*MFD/ZS&*YV;"9;@66SXA)\V2,V M&[^,)V%R;SKL];`(Q>84^YHL9;'+R4XF$Z_*G(R6:28@606?9$_9#(BVJ+XB MTR;&?"AFEY2W#=Y:>J0[THMG-FO:3+Q^NDX,49PLM$&\9O!'-K>T-&FB$>M&L]0 MTQC/V/_"G@%%?SS+#RC>XKJ>>#"R/GIF^2++(DD^9=D5DATZK3+A5V"`WQV[)F46M0:]0RF_W(*&3'NQHN;GGEV6]S\ MTK<,O;)OD/_\\UMM#_,(F$D"+C"?B-9)X)+[S[R^!^Q_EJ+9N&*BZ89H0*OH M'Z)=5.POT08'HVISNN8GT>HTNVW=6Z(-&>:XY64FV%KK)-F)2,%KHEE^)IIE M'P;P;=FO78_%1K=\DV6G;L81+E38\EF6_(N_^<[UD^8#CHOF2]$:AL&`"Y-Y]S-NDL/%-NX:B.DCZZK0\4^:T:C3!R,]G?WV)LS9K2+3\B)@$8L(GQ(3< M:?:9M3Z]9ZD$Y,,9INV89GEHRR7(ECW%LI],HWF,^1K,/C--XLKR0I8=:)K* M1>+H;8Y@<_G=-$X>08Z=#81UMBP"L2>>-PT.4-AZCZV(,K:8X2%#IFV95F=: M*>#\,=K`S]@TJ*V];UK!3I1=E;*C3@.J#7`'"2VOU>RSFG?B7+,.:_8-0EWT MI;;EHRU[L&QCWDFS=VOV;?76;(WCZYH]7;TXU^SYFMUSVD"9XP?51&5FF[)' M4'8F9O:74*YV#LS^4,U[S1:4IVAV#ELBN]:=M1G(!?KO:03_R M:453]0`JKOIC>"YXU960NT`R6AB3NE&A+CUR+2$-XJG4UZXUO,9#&?-80LB/ M,3^)V2.O'=2GR."@ECW+'D$6-A+WF:;4E=-U. M#%M^0ZPQL#=D[5-]-L-6-W;R1IW#';(A5])KJ+12-M7ZJ)J;J+;EG:8)JVOA M>0I&9ABFX4*Z#8^?0*(C97,LS8D=I]&>U]"QL@T+'+D!,.'CU:9RYM-/-H3![,F9GQ5P#5[9:8_9CS#-A MYN.8?5U727IK;`/P[&!J-X?O.D$@1[/J$F>;*&UGXDW:9VN:3;6ZZS\GTJ33 M1CJR,=O,;"NVGS14?.PRE5DOUH,%I%A&FR;20Q1#TPFS!E@R7K MA;([\:I'YA_;#LX)0]91M9!FVM9DFVV-VP8/\IO^N(T&9,RITE"8G1.S-\JF M[,/=*:ES3=T4M(:"YFY29N!-N8$[D_"`FH)6&-`\#=44 MM/:`YN+4=%`8B0N^?9O@7;?]W7:I6[AN`[N5=,XYNPDSI5.9$!2!$/BYHNSO M6K*V2XK%Y,9,ZW53`[5KP&-E>[>M:+?/I.;SW>"F?=DSOEG^XIOE\*PEEIW8 M6(6>&9+'8/:7;Y@#C-CD/IA]Y-M#\0U5NMTFE:10YR2@457GCG-]!N!`08!/1QWX@:S:/KQ.PC3`)K9-AC_?;E MD[^Y%*IZ6HB!/E57:4V-\:CSW[^I[_SX;])<:U?UVZHFL[]-U&1_^C+)5"PM MVN;;(6GQ16D]A(]@,O&Z;Z>^C?WF6+^_30CG7/N_N2ARRM#"(7D(@3NDZ*!P MP+WY5+ADX2PO9EF)+0]GV=_@9S'*=.>S['JNEZ+3%=&R&UJV#40I+;ND9;EV M4,N>$8X"-1+0?@H*K*R>7=5VSVT[KV77M>Q!EAW9LAN'(\`F&QNE.JVUD>GA M8(BFH(\)U$)8P'`9P\4,ES1^C\H4,H^^)%`ZJ,(UL>AZ8/!S5% M.:'[53G'+8\@V?-TH^-TV^?(MU0W:51X>:M#N85F4=(`'UO.H.*KY=0%DW]K MN?88T7?+S99D<*=PD'*"Y6DU*0<-PVB:J'1\?-P792_WQ3?7D+R15*$"$YEP M3F#JPCF!20,)3'L5NMW2R<*4Y!OGZ*[/6;Y(RO43R][L^J95!,=G+'O,.8`6 M,__![-M:WY-\3&>R[#VPC9EC8?82_7UF2/0RRSYV;J'E]-!*]CC-KL2\,#QT M&?-_F+V/>9X=W,YH6;5SSG5JY!F>]F8>BWLB/3-N43G0IW;=4Z)9.5M::HOG?`T:6<]C_I!)\AF'#7K'0'&RVB2V0FO`FH:?AS^4'- M$=--;*3U]$7EF-T2+JR'5Z?K7,PL$8O_=3H/)Z"KE?RIS"MAT*KI['X1!#5! M(P_6HBU/E#.CG7=%N1CO&M<)XRM(L4+,(#RVO?B#8"_3I^E&&FI*W_-[J. M,.:/UZD!>F[Z.#V`#^@!T+[B=J)5R(_62!C@B66ON<`L*I;CF=9H<0IHJ$>&[^`'&9T M;%^OG,';1QKWRQLGDFFN*6G1HXP(O\Z);EE@XZ8&085;6&.PNB0Z<3O;+6_! MA*G8HF^L,Z==[3GN^QX,YKMF.T>7W-,M'5'ZU>Z@H=C Subject: Re: Another Win32 execution speed comparison Date: Sun, 17 Mar 1996 20:58:08 +0000 Message-ID: <314C7CE0.990@ix.netcom.com> References: <314C9E5A.57B2@immersive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sun Mar 17 8:48:20 PM CST 1996 X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) Marc de Groot wrote: > > I ran the Byte benchmark on Tom Zimmer's Win32 Forth and > my own C-coded Forth system. The results surprised me. Marc, I am glad that comp.lang.forth has gotten all this interest in performance all of a sudden, cause it made Andrew rerun some benchmarks (similar to yours) on the current version of Win32Forth. What he discovered was that the dictoinary wasn't cell aligned, and was getting a 50% performance hit. I had forgotten to add cell alignment to the application dictionary when I modified Win32Forth to use a dual dictionary. You can check yourself to see if the Win32Forth you are running has this problem, by ticking several kernel code words, and checking to see if they are on cell boundries. If not then its a slow one. If it is, then your comparison is probably valid. I will be releasing a fixed version (3.1) shortly when I have ironed out a couple of additional bugs that have been reported. Tom Zimmer From: Tom Zimmer Subject: Re: 32-bit Forth for Win 95? Date: Sun, 17 Mar 1996 20:49:01 +0000 Message-ID: <314C7ABD.10AE@ix.netcom.com> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314457B3.7C3A@netcom.com> <4i23ji$kcs@lastactionhero.rs.itd.umich.edu> <4i7spk$e55@bolivia.it.earthlink.net> <31489866.DD4@ix.netcom.com> <4ibp4h$jv4@ecuador.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sun Mar 17 8:39:13 PM CST 1996 X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) Elizabeth Rather wrote: > > Tom Zimmer wrote: > >Here are the results of the FORTH, Inc. benchmarks as modified for Win32Forth... > > Tom, unless I missed something you didn't tell us what machine (e.g., 486/66) > you were running them on, so it makes it a little hard to compare. Sorry Elizabeth, it was Pentium 66. But, don't compare things too closely yet, Andrew discovered that when I recently changed Win32Forth to a dual dictionary, I forgot to align the application dictionary to long word boundries, so things are running about half the speed they should be. Other changes I have made in the last couple of months have alwo slowed things down a bit, so I am working on getting it up to at least where it was in december. Long term however, I don't see Win32Forth being any faster than ProForth unless there is a basic architecture change to subroutine threading, which probably won't ever happen, and probably isn't needed anyway. Algorithms are always more important than absolute system performance. Tom Zimmer From: Tom Zimmer Subject: Re: DLL's and Win32Forth Date: Sun, 17 Mar 1996 21:05:32 +0000 Message-ID: <314C7E9C.1828@ix.netcom.com> References: <4ihvsl$ci5@mn5.swip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sun Mar 17 8:55:43 PM CST 1996 X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) Lars Malmheden wrote: > > I have been trying to use the WinDirect DLL's from SciTech Software > with Win32Forth. No success. Has anybody information on the correct > way to use DLL's with Win32Forth or perhaps even tried WinDirect. > > Bye Lars Malmeden If you are running Win32Forth 3.0 or higher, then you should be able to simply add the name of your dll to the WINLIB.F file along with the other dll's mentioned there. Then you just call the dll functions with something like; CALL MyDllFunction Be sure to put all its arguments on the stack in reverse order, that is the argument nearest the word CALL is the argument that appears first in the C call description. Also you need to use REL>ABS and ABS>REL to convert addresses back and forth between things sent to a DLL and things received deom a DLL. Note that Win32Forth searches all the DLL's for a particular function name, and compiles a reference to which ever library it first finds the function in. So if you have conflicting function names, you will have a problem. I hope this helps. Tom Zimmer From: Marc de Groot Subject: Re: Another Win32 execution speed comparison Date: Sun, 17 Mar 1996 23:30:31 -0800 Message-ID: <314D1117.5F8D@immersive.com> References: <314C9E5A.57B2@immersive.com> <314C7CE0.990@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Tom Zimmer wrote: > > Marc de Groot wrote: > > > > I ran the Byte benchmark on Tom Zimmer's Win32 Forth and > > my own C-coded Forth system. The results surprised me. > What he discovered was that the dictoinary wasn't cell aligned, and was > getting a 50% performance hit. I had forgotten to add cell alignment > to the application dictionary when I modified Win32Forth to use > a dual dictionary. You can check yourself to see if the Win32Forth you > are running has this problem, by ticking several kernel code words, > and checking to see if they are on cell boundries. If not then > its a slow one. If it is, then your comparison is probably valid. Dup, swap, over and drop all have odd addresses. Gee, just when I was starting to believe in the supernatural. ;-) ^M From: John.Peters <104212.3543@CompuServe.COM> Subject: Phone DTMF Forth Code available? Date: 18 Mar 1996 10:05:25 GMT Message-ID: <4ijch5$ccj$1@mhafc.production.compuserve.com> I am looking for a way to dial the phone as well as wait for a response in the form of a DTMF tone. One use is to dial the phone from phone numbers I have in some of my Forth files. As I am new to this system you might do me a favor and fax a note to tell me to look here for a response FAX 415 585-1245 Thanks John A. Peters 415 239-5393 voice if you like, I will return your call if I am out. From: cgra@btmaa.bel.alcatel.be (Chris Gray) Subject: Re: What is Tyler Sperry's point about Harris RTX? Date: 18 Mar 1996 08:39:56 GMT Message-ID: <4ij7gs$or0@btmpjg.god.bel.alcatel.be> References: <313FC25C.2A79@tir.com> Reply-To: grayc@btmaa.bel.alcatel.be > In article , rj@eli.wariat.org (Robert J. Brown) writes: > CPUs (or any other product, for that matter) do not live or die based > on technical considerations; they live or die based on business > considerations! Unless, perhaps you have a Gnu CPU in your pocket :-) You mean you haven't heard about the Free Hardware Foundation's design for an open processor architecture based around an ARM core? It runs native elisp code, and the aim is to make emacs the standard user i/f for the "network computer". Expect to see an official announcement in the gnu.* newsgroups on or around, um 1 April ... ;> -- __________________________________________________________________________ Chris Gray Chris_Gray@bcs.org.uk Compuserve: 100065,2102 __________________________________________________________________________ From: Andrew McKewan Subject: Re: Definition of BL Content-Type: text/plain; charset=us-ascii Message-ID: <314D7AFC.53CF@netcom.com> Content-Transfer-Encoding: 7bit References: <314B3DEF.5CC4@netcom.com> Mime-Version: 1.0 Date: Mon, 18 Mar 1996 15:02:20 GMT X-Mailer: Mozilla 2.0 (WinNT; I) W.Baden wrote: > > I would like to see something that is the same as BL, so I'd > re-write this as > > [ S" " DROP C@ ] LITERAL > > Now can we do this with the Core words only? > > With source from a textfile, how about? -- > > [ SOURCE DROP C@ ] LITERAL > > To define BL, how about? > > SOURCE DROP C@ CONSTANT BL That's clever. Also: : BL S" " DROP C@ ; From: Andrew McKewan Subject: Re: Tiny DOS Forth compiler with access to DOS ints? Content-Type: text/plain; charset=us-ascii Message-ID: <314D7B66.58F9@netcom.com> Content-Transfer-Encoding: 7bit References: <4gi3ff$2nb@mulga.cs.mu.OZ.AU> <4iir3u$7pk@arl-news-svc-3.compuserve.com> Mime-Version: 1.0 Date: Mon, 18 Mar 1996 15:04:06 GMT X-Mailer: Mozilla 2.0 (WinNT; I) Uh, oh, the binary police are gonna' catch us on this one! Andrew From: Marc de Groot Subject: Re: Tiny DOS Forth compiler with access to DOS ints? Date: Mon, 18 Mar 1996 08:02:34 -0800 Message-ID: <314D891A.9C0@immersive.com> References: <4gi3ff$2nb@mulga.cs.mu.OZ.AU> <4iir3u$7pk@arl-news-svc-3.compuserve.com> <314D7B66.58F9@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Andrew McKewan wrote: > > Uh, oh, the binary police are gonna' catch us on this one! Don't you mean, "compiler security"? :-) I see you're at Finnigan MAT. Are they still using Forth for their mass spec system? -- ---- Marc de Groot | Immersive Systems, Inc. | http://www.immersive.com | Real VR for the net! "Does 'anal retentive' have a hyphen?" -- seen on the net From: claird@Starbase.NeoSoft.COM (Cameron Laird) Subject: Re: Anyone interested in writing an operating system? Date: 18 Mar 1996 09:34:14 -0600 Message-ID: <4ijvpm$t8r@Starbase.NeoSoft.COM> References: <4i0dak$m4d@news1.delphi.com> In article <4i0dak$m4d@news1.delphi.com>, John Strohm wrote: . . . >Paul, I think his point was that he wanted to do something DIFFERENT, not >Yet Another Bug-Compatible Unix Clone. > >You maybe should read Reiser _The Oberon System: User Guide and >Programmer's Manual_. Oberon is a beautiful workstation-class operating >system AND window system that requires all of 150 kbytes or so to run. >Compare with workstation Unix clones that require multiple megabytes to >crawl. Indeed. The other canonical reference, I would think, would be to comp.lang.oberon, which I have e-mailed to the original questioner. -- Cameron Laird http://starbase.neosoft.com/~claird/home.html claird@NeoSoft.com +1 713 623 8000 #227 +1 713 996 8546 FAX From: wilbaden@netcom.com (W.Baden) Subject: Re: Definition of BL Message-ID: References: <314B3DEF.5CC4@netcom.com> <314D7AFC.53CF@netcom.com> Date: Mon, 18 Mar 1996 16:43:48 GMT Andrew McKewan (mckewan@netcom.com) wrote: : : BL S" " DROP C@ ; Please, no execution-time overhead. I looked to see how I do it in the current RTH It uses Core Extension though. CHAR " PARSE " DROP C@ CONSTANT BL From: lefebvre@medcor.mcgill.ca (Luc Lefebvre) Subject: Re: CIS of Creative Solutions Inc.' Date: Mon, 18 Mar 1996 12:06:24 -0500 Message-ID: References: <4ic1ln$jr6@h20-hrze.uni-duisburg.de> In article <4ic1ln$jr6@h20-hrze.uni-duisburg.de>, hg946ha@rs1-hrz.uni-duisburg.de (Hansen) wrote: "> Can somebody tell me the Compuserve number of Creative Solutions Inc. "> I tried to contact them by fax but I didn*t suceeded. "> "> Thanks "> "> Rainer "> "> E-Mail: rhasb96@tufvan.hv.se Hi Rainer, You could try GO FORTH. I know they have user group there, one of the sysops may be able to give you more info. They are usually pretty good at helping out... Good luck. -- Luc Lefebvre |rm -r bozos project engineer | Aerospace Medical Research Unit | McGill University | Montreal, Canada | |PGP public key availble upon |request. From: Tom Zimmer Subject: Re: Another Win32 execution speed comparison Date: Mon, 18 Mar 1996 11:43:03 -0600 Message-ID: <314DA0A7.6428@ix.netcom.com> References: <314C9E5A.57B2@immersive.com> <314C7CE0.990@ix.netcom.com> <314D1117.5F8D@immersive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Mon Mar 18 11:41:32 AM CST 1996 X-Mailer: Mozilla 2.0 (WinNT; I) Marc de Groot wrote: > > Tom Zimmer wrote: > > > > Marc de Groot wrote: > > > > > > I ran the Byte benchmark on Tom Zimmer's Win32 Forth and > > > my own C-coded Forth system. The results surprised me. > > > What he discovered was that the dictoinary wasn't cell aligned, and was > > getting a 50% performance hit. I had forgotten to add cell alignment > > to the application dictionary when I modified Win32Forth to use > > a dual dictionary. You can check yourself to see if the Win32Forth you > > are running has this problem, by ticking several kernel code words, > > and checking to see if they are on cell boundries. If not then > > its a slow one. If it is, then your comparison is probably valid. > > Dup, swap, over and drop all have odd addresses. > > Gee, just when I was starting to believe in the supernatural. ;-) > Actually I spent the whole day yesterday looking at the performance issues related to lodsd, short and long version of immediate instructions, and short and long versions of branchs. The results I observed on my 90mhz Pentium are very hard to understand. On some instruction sequences, it seems to make a big difference whether you use the short versions of instructions, and in others it seems to make no difference at all. I compared the December version of Win32Forth with the current version, and saw differences which could not be explained by looking at the generated code (they were using exactly the same instructions donw to the hex cde). While the results were completely reproducable, I could find no reason for the differences. I can only deduce that the architecture change to Win32Forth splitting the dictionary into two parts, has somehow effected the way WindowsNT runs Win32Forth. I am baffled, but I have given up trying to explain it. Tom Zimmer From: rrt1001@cus.cam.ac.uk (Reuben Thomas) Subject: Re: Anyone interested in writing an operating system? Date: 18 Mar 1996 17:43:31 GMT Message-ID: <4ik7c3$d0e@lyra.csx.cam.ac.uk> References: <826181227.26001@abwillms.demon.co.uk> <1996Mar18.115144.1@cc.newcastle.edu.au> In article <1996Mar18.115144.1@cc.newcastle.edu.au>, wrote: [quote snipped] > This last point is an attraction. Does it -- or could it -- tie into >the idea of a 'subcomputer', sometimes called an 'Internet computer'? Or pronit; see http://www.cl.cam.ac.uk/users/rrt1001/melt/melt.html -- Web page: http://www.cl.cam.ac.uk/users/rrt1001/ From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: 32-bit Forth for Win 95? Date: 18 Mar 1996 18:36:25 GMT Message-ID: <4ikaf9$9e4@news.tuwien.ac.at> References: <4hibv2$gkj@lastactionhero.rs.itd.umich.edu> <313EFA9A.3B@netcom.com> <826382540snz@mpeltd.demon.co.uk> <4hs86j$d7q@lastactionhero.rs.itd.umich.edu> <826448056snz@mpeltd.demon.co.uk> <4hv4aj$4nb@lastactionhero.rs.itd.umich.edu> <314B3B4F.10C3@netcom.com> In article <314B3B4F.10C3@netcom.com>, Andrew McKewan writes: |> WIN32FOR Tom's Win32Forth system. |> FORTH32 A subroutine threaded Forth. ... |> 1. BYTEBNCH.4TH |> |> Implementation Iterations Time |> -------------- ---------- ---- |> WIN32FOR 200 10.4 |> FORTH32 200 3.4 |> |> 2. IAGEBNCH.4TH |> |> Implementation Iterations Time |> -------------- ---------- ---- |> WIN32FOR 10000 23.3 |> FORTH32 10000 5.0 The factor between the Win32Forth and subroutine threading looks funny to me. Here's the latest results of my threading microbenchmark (see http://www.complang.tuwien.ac.at/forth/threading/): gcc sub- Machine Processor version routine direct indir. switch DECStation 5000/125 R3000 25MHz 2.2.2 19.8s 17.7s 25.8s 46.5s HP/Apollo 425 68040 25MHz 2.2.2 38.3s+ 22.3s 30.1s 63.5s HP/Apollo 720 HP-PA 50MHz 2.3.2 15.54s 10.99s 15.05s 19.74s SPARCStation 1 Cypress 20MHz 2.2.2 31.2s 33.2s 47.9s 73.6s 486 486DX2 50Mhz 2.2.2d 20.3s 14.4s 14.6s 21.5s Alpha 21064A 300MHz 2.7.1 2.2s 3.1s 4.1s 5.7s Pentium PB Cache Pentium 133MHz 2.6.3 6.7s 2.8s 3.55s 13.14s So, the Pentium is faster on indirect threading than on subroutine threading, the rest is the same, yet you report a factor of three in favour of the subroutine threaded system. On the other hand, inlining and peephole optimization have less impact than I would expect. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: hoz@telescan.com (Rick Hoselton) Subject: Re: @! , Anyone? Date: 17 Mar 1996 23:45:45 GMT Message-ID: <4ii879$504@globe.plus.com> References: <879@purr.demon.co.uk> Mime-Version: 1.0 > : @! ( newvalue address - oldvalue) DUP @ ROT ROT ! ; > I've never felt the need for @! before. Is it a useful word? Is it > well-named? I pronounce it "fetch-store". I've been doing it so long that it sounds well named to me, hehe. I use it a lot when working with linked lists, such as: VARIABLE TOPLINK : BUILD-LINK HERE TOPLINK @! , REST-OF-LINK ; -- Rick F. Hoselton