From: echapin@interlog.com Subject: Sept. Dr. Dobbs Date: 16 Aug 1996 02:17:52 GMT Message-ID: <4v0log$3rj@news.interlog.com> Reply-To: echapin@interlog.com See pp. 88 - 91 :) Elliott Chapin echapin@interlog.com From: echapin@interlog.com Subject: comp.parallel Date: 16 Aug 1996 02:15:23 GMT Message-ID: <4v0ljr$3rj@news.interlog.com> Reply-To: echapin@interlog.com I cross-posted a couple of articles from our recent thread on Forth in parallel computing. Perhaps the specialists here would have fun visiting comp.parallel. Elliott Chapin echapin@interlog.com From: mikeh@zeta.org.au (Michael Hore) Subject: Re: Objects for ANS Forth Date: 16 Aug 1996 13:57:40 +1000 Message-ID: <4v0rjk$3sb@godzilla.zeta.org.au> mhx@IAEhv.nl (Marcel Hendrix) writes: >It is interesting to check how efficient the code will be that >uses Andrew McKewan's CLASS.FTH straight out of the box. >... [without classes] >test \ Output: 0.727 seconds elapsed. >120000000 ok [with classes] >test2 \ Output: >20.896 seconds elapsed. >120000000 ok > >The (speed) difference is quite unacceptable. (for other Forth >implementations the results might be less extreme). FYI, in Mops itself the second test would be almost as fast as the first. Although I still haven't had time to check out Andrew's stuff, I think he'd agree we're more at a "proof of concept" stage at present. On a particular platform, once the bottlenecks are determined, things could easily be speeded up dramatically. Certainly on code like this, I wouldn't expect more than a 10% slowdown for using objects. Late binding would be a bit slower, but not by all that much for "normal" code. (Of course if you do a late-bind in a tight loop for a timing test, it won't look so good). >Also, I hope there is a terser way to address arrays. What I've >done above is not very readable :-) Well it looks fine to me :-) :-) >This doesn't mean I don't like the object model presented by Andrew. >In fact, it has some *very* good points! It allows objects and 'normal' >Forth code to be mixed: the objects don't try to "take over" Forth. >You can use them as just another toolkit. >I was also very pleasantly surprised when it proved possible to "re-use" >the method names To: and At: in my own classes, although they are globally >visible in the dictionary (I always assumed method names would have to be in >a 'class vocabulary' for this to be possible). I wonder how records >(or structures) are implemented in this object model (or Mops). Can name >space clutter be avoided in this case too? In Mops, names of classes and methods are hashed to 32-bit values and chained together appropriately - and this is completely separate to the normal dictionary links. So there's no name space clutter to speak of. >... Cheers, Mike. ---------------------------------------------------------- Mike Hore mikeh@zeta.org.au ---------------------------------------------------------- From: "Douglas Beattie Jr." Subject: Re: Stack Computer book back in print Date: 16 Aug 1996 05:40:34 GMT Message-ID: <4v11ki$td@news.whidbey.com> References: <3212fd02.78487@usenet.interramp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) koopman@cs.cmu.edu (Phil Koopman) wrote: > >Mountain View Press now has hard-copy reprints of my Stack Computers >book available. { ... } >Contact Glen Haydon: (415) 747-0760 >ghaydon@forsythe.stanford.edu >http://www.taygeta.com/jfar/mvp.html > I believe the correct URL is http://www.taygeta.com/jfar/%2Cmvp.html a.k.a URL http://www.taygeta.com/jfar/,mvp.html (it's a comma ",") -- Douglas Beattie Jr. From: mikeh@zeta.org.au (Michael Hore) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 16 Aug 1996 16:18:24 +1000 Message-ID: <4v13rg$8s3@godzilla.zeta.org.au> Andy Civil writes: >... >I have been considering the various arguments about which language is >better, and thinking about the structure of my Forth (the only one I >know, although I will try Holon soon) which does not make use of many of >the registers that my processor has. It uses only the accumulator for >actually doing calculations, and the registers that give you >"interesting" addressing modes. But the general purpose registers remain >unused. This is really a matter of implementation, not language. These days there are plenty of Forths that can generate native code which use all the registers effectively, for most common processors. These implementations will run pretty nearly as fast as C will. >... >This problem must be exacerbated on a processor like the 68000 series >where the large number of general purpose registers is one of its >greatest benefits. Mops (Mac) is one Forth which generates native code, and uses all the regs of the 68k quite effectively. So it's not really a language issue at all. Maybe you should look at some other Forths? Cheers, Mike. ---------------------------------------------------------- Mike Hore mikeh@zeta.org.au ---------------------------------------------------------- From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multiple values Date: 16 Aug 1996 07:25:18 GMT Message-ID: <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> X-NETCOM-Date: Fri Aug 16 2:25:18 AM CDT 1996 In <321383F0.58FB@inlink.com> Bill Zimmerly writes: >Hans Bezemer wrote: >> Bill Zimmerly wrote: >> [snip] >> >*Every* word should remove only the input arguments documented in >> >it's stack effect diagram, and should only put back what it's stack >> >effect diagram documents. If this rule is not followed, no wonder a >> >disaster follows. >> [snip] >I'm 'kinda lost on this one, Hans...I don't quite understand what your >problem with it is. What is confusing about returning "booleans and >something (or nothing)"??? Can you perhaps post an example of a word's >definition that confuses you and then (we) can critique it? Here's a made-up example. Say you're doing genetic algorithms. You have a problem where it's hard to find a good solution, but easy to test how good a given guess is. So your program makes guesses and tests them and improves on them. OK, now you have a whole series of examples of the problem coming in, and you have a dozen techniques that are each good at some versions of the problem and bad at others. And you have rules of thumb about when each is likely to be good. So when a problem comes in, you give it to the first method, and it checks its rule-of-thumb, and either it returns an attempted solution, or it passes. So what it returns if it tries to solve the problem, is the address that it left its solution, and then the error function that says how good the solution is, and then a true flag. And what it returns if it punts, is only a false flag. If it found a solution, you want to do something with the solution. If it didn't, you definitely aren't going to respond the same way, you're going to do something entire different, namely you're going to try the next method and not look back. It might make sense to leave two pieces of garbage on the stack under the false flag, so you can 2DROP them later. That way the routine leaves the same number of items either way, and people can't get confused by expecting the wrong number. On the other hand, people could get just as confused if they have 2 pieces of garbage to keep the stack depth happy. If they don't notice which branch they're in then they can expect problems. But then, it's easier to write automatic stack-checkers if each word leaves the same number of items no matter what. And even if it turns out that sometimes it's easier to read and write and understand a word that has two separate stack results, probably the majority of the times that people think so, they're wrong. I figure the rule that you don't make routines with varying numbers of stack results won't usually cause a lot of trouble, and it can save some. From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Multiple line text input within a compiling word X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: Date: Fri, 2 Aug 1996 14:57:19 GMT Is there an _obvious_ Standard way to input multiple lines of text? That is, I would like to define a Standard word : multi" \ put everything after space, up to \ a trailing " , across cr/lf's, \ in a buffer or string in some Standard place. YOUR CODE HERE ; There is no reason except custom why the stop character has to be a " . That is, the word should operate like the phrase char " word except the latter reads up to a cr/lf and gives no Standard way to find out what was the last character read (except by playing with TIB and >IN --supposedly obsolescent words, and ones that by their very nature lead to environmental dependen- cies). I can do what I want on the systems I work with--that is not the point. I am trying to discover a Standard, completely portable method that will work within a word being compiled, as in my FORmula TRANslator (so I can finish the port to ANS Forth with as few environmental dependencies as possible): : f" multi" buffer swap $! FORTRAN ; immediate : test f" A=B+C*D -ACOSH(U/PI)" ; see test PI F@ U F@ FR/ FACOSH FNEGATE D F@ C F@ F* F+ B F@ F+ A F! ok Thanks for any help. -- Julian V. Noble jvn@virginia.edu From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 16 Aug 1996 09:13:18 GMT Message-ID: <4v1e3e$fnd@hkusuc.hku.hk> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> Andy Civil (Andy@civil.demon.co.uk) wrote: >If I wanted to speed up my Forth, I could re-write some of the words in >assembler, and make use of the registers for temporary storage, but then >I would be writing assembler, not Forth. However, if I was writing a >true compiler, then I would be free to use the registers to their full ^^^^^^^^^^^^^^^ >extent. Is this not better? Is there a way to use registers in Forth ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >that I have not thought of? I suppose I could "cheat" and write a word >that copied the top of stack into a register or performed some operation >on it, but this does not "feel" right. Do you mean it is impossible to write a "true compiler" for the Forth language????? Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 16 Aug 1996 09:16:13 GMT Message-ID: <4v1e8t$fnd@hkusuc.hku.hk> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> Andy Civil (Andy@civil.demon.co.uk) wrote: >This problem must be exacerbated on a processor like the 68000 series >where the large number of general purpose registers is one of its >greatest benefits. As a matter of fact, on the i80x86 (still one of the most wildly used processor in PC-s) I had to few registers to implement OOF comfortably (I mean I had to make trade-offs because the processor does not have enough registers :-( ). Probably the 68000 series would be better. Andras From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Rampant Misconceptions [Was: Re: multiple values] Date: 16 Aug 1996 11:28:49 GMT Message-ID: <4v1m1h$h60@news.tuwien.ac.at> References: <40.10697.1617@channel1.com> <839842549snz@tcontec.demon.co.uk> <4usi07$s1j@news.tuwien.ac.at> In article <4usi07$s1j@news.tuwien.ac.at>, anton@a0.complang.tuwien.ac.at (Anton Ertl) writes: |> This kind of error would be easy to catch statically, if we restrict |> the legal programs such that all words (functions for you Schemers) |> take and return a statically determined number of values on the stack |> (a restriction satisfied by ~99% of the Forth words written, but most |> applications contain a few words that do not satisfy it). Silly me, I forgot EXECUTE (i.e., indirect calls). I should not post when I am tired. Anyway, EXECUTE is somewhat more frequent than words that break the restrictions above. To make words using it statically checkable, we would need unrealistically good data flow analysis to ensure that all words executed by a specific EXECUTE have the same stack effect. We could also use declarations at the places where the data flow analysis would have problems. - anton |> Posted to comp.lang.forth and comp.lang.scheme. Set followup as |> appropriate. -- 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: "Michael A. Losh" Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: Fri, 16 Aug 1996 07:50:23 -0400 Message-ID: <3214607F.2436@tir.com> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Andy Civil wrote: > If I wanted to speed up my Forth, I could re-write some of the words in > assembler, and make use of the registers for temporary storage, but then > I would be writing assembler, not Forth. > ... > I suppose I could "cheat" and write a word > that copied the top of stack into a register or performed some operation > on it, but this does not "feel" right. > ... > Andy Civil In fact, all Forth systems implemented with a virtual machine have at least a few "CODE" words that execute native machine language. And such routines make use of CPU registers freely, or at least use them where appropriate. If you look at the source for different Forth systems, you can see this for yourself. Some systems only have a couple dozen CODE routines, other systems have hundreds. It is true that most Forth virtual machines tend to not utilize many CPU registers as they thread through high-level code, which is nice when you _do_ want to use the registers in a special CODE word. By the way, many Forth systems have a built-in assembler, so it is easy to add your own CODE words that fully take advantage of your CPU hardware. This is not cheating, but it does make a trade-off between speed and possibly functionality versus portability and easy maintainance. -- Mike Losh mlosh@tir.com From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Fri, 16 Aug 1996 10:12:04 -0500 Message-ID: <32148FC4.77FC@austin.finnigan.com> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <3211F4C7.5E2C@austin.finnigan.com> <4v0017$fbm@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Marcel Hendrix wrote: > It is interesting to check how efficient the code will be that > uses Andrew McKewan's CLASS.FTH straight out of the box. I don't think this is a fair test at this point. I have presented a completely high-level and portable implementation. Arrays, for instance, include all index calculations, plus range checking, in high-level Forth. An optimized implementation would do all this in low-level Forth (code or C). (Range checking on a 80386 or 68020 is a single instruction.) > (BTW: I can report that the only ANS problem iForth found was > the use of BOUNDS .) Thanks, I missed that one. > Also, I hope there is a terser way to address arrays. What I've > done above is not very readable :-) That's a matter of taste, but I think it reads quite well. > This doesn't mean I don't like the object model presented by Andrew. I didn't invent it, Chuck Duff did in Neon (back in 1984). > In fact, it has some *very* good points! It allows objects and 'normal' > Forth code to be mixed: the objects don't try to "take over" Forth. > You can use them as just another toolkit. > I was also very pleasantly surprised when it proved possible to "re-use" > the method names To: and At: in my own classes, although they are globally > visible in the dictionary (I always assumed method names would have to be in > a 'class vocabulary' for this to be possible). This is a key point. Selectors (To: and At:) send messages to objects. The object itself decides which method to execute. The same selector can invoke different methods for different objects. > I wonder how records > (or structures) are implemented in this object model (or Mops). Can name > space clutter be avoided in this case too? Mops has a special sytax for records, but you can think of a class as a record with methods. If you allow the instance variables to be public (they are now private, but Mops allows public ivars) then you can have records without any methods. > It will be easy to optimize CLASS.FTH (very easy, and very implementation > dependent), but for that to be successful I'd like a glossary that > describes *only* the words that are to be externally available. Skip Carter > has written a simple wordset to emulate beheading or hiding in the FSL, it > will benefit CLASSes as well! I agree. I will try to start a glossary of the externally-visible words. Off the top of my head, this is about the size of the list: :Class ;Class Release self super [ ] ( not really words, but part of the syntax ) -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Fri, 16 Aug 1996 10:17:52 -0500 Message-ID: <32149120.2FFA@austin.finnigan.com> References: <4v0rjk$3sb@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Michael Hore wrote: > In Mops, names of classes and methods are hashed to 32-bit values and > chained together appropriately - and this is completely separate to the > normal dictionary links. So there's no name space clutter to speak of. This was one area I had to depart from the Yerk/Mops tradition. Since I could not patch FIND to automatically recognize selectors, I had to make them into Forth words. :M automatically creates a new selector if it doesn't already exist. Each selector is only created once. Since selectors are words, I use the pfa address as the selector value instead of a hash code. This prevents any possibilty of a hash collision. (Ivar names are still hashed, but the compiler will not allow two names with the same hash value.) Also, as an optimization for late binding, I used an 8-way hashed list for the methods. This cuts down on the search time in (FINDM). -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: blaak@mda.ca (Ray Blaak) Subject: Re: interfaces (was Re: multiple values) Date: 16 Aug 1996 08:36:11 -0700 Message-ID: <4v24hb$3ei@map.mda.ca> References: <40.10697.1617@channel1.com> <4ul0uo$10mg@news.goodnet.com> <4ulm8c$bi7@nadine.teleport.com> <4uq5c8$fog@map.mda.ca> <3210ACD4.5B56@austin.finnigan.com> <4us274$hoa@dfw-ixnews5.ix.netcom.com> <4uuijg$jt3@ephor.tusc.com.au> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JEThomas@ix.netcom.com (Jonah Thomas) writes: >It looks to me like type systems don't really speed up that process. They >take time to set up, they can be set up wrong, and those times might balance >out the errors they catch faster than you'd catch otherwise. But that's >just my impression, I don't have any measurements on it. It surely depends >a whole lot on the language, too. My experience with strong typing is that it immensely speeds up the process. They don't take much time to set up, since usually each structure, list, whatever is a distinct type directly in my language of choice (Ada). I imagine ML is the same. A whole slew of bugs that don't show up until run-time instead show up at compile time when strong (and static) typing is in effect. Cheers, Ray Blaak blaak@mda.ca From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Manipulating Return Addresses Date: 16 Aug 1996 15:43:37 GMT Message-ID: <4v24v9$ck@news.tuwien.ac.at> References: <4ud4bb$8v@news.tuwien.ac.at> <4uo9at$8oa@news.tuwien.ac.at> <79eBCOA0oMEyEwUY@apvpeter.demon.co.uk> In article <79eBCOA0oMEyEwUY@apvpeter.demon.co.uk>, Chris Jakeman writes: |> >: RADrop |> > r> r> drop >r ; |> That's it exactly. You might consider the more efficient: |> |> : RADrop S" R> DROP" EVALUATE ; IMMEDIATE I would never consider such an abomination. If you want to know why I consider such uses of EVALUATE bad, read http://www.complang.tuwien.ac.at/forth/why-evaluate-is-bad (it contains the postings I made the last time this came up). A much better way to get the time efficiency you want is : RADrop POSTPONE R> POSTPONE DROP ; IMMEDIATE It's also better for the compile time. - 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: matt@access5.digex.net (Matt Lawrence) Subject: Re: multiple values Date: 16 Aug 1996 16:10:52 GMT Message-ID: <4v26ic$gq5@news3.digex.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> Paul E. Bennett (peb@transcontech.co.uk) wrote: : In article <4uqv9c$b8g@news.NL.net> hbezemer@vsngroep.nl "Hans Bezemer" writes: : : > I don't know any C- : > functions that sometimes return a value and sometimes not. And if they do : > they are BAD news. : : In C they are but in Forth, with consideration, they are not. Well, I thought about it a bit before writing this. There are a number of C functions that return more than one value. Look at many of the I/O routines, they return the number of bytes transferred and an error code in "errno". If there wasn't an error, the value of errno may be undefined. In Forth, you can just leave the extra value on the stack to do further processing with, while in C you have to save it away to prevent any further code from stomping on it. -- Matt From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: multiple entries Date: 16 Aug 1996 16:47:50 GMT Message-ID: <4v28nm$ck@news.tuwien.ac.at> References: <4ud5e1$1so@news.tuwien.ac.at> <4udtm5$t99@unlisys.unlisys.net> <4uo5ae$8oa@news.tuwien.ac.at> <4usigc$fkr@ns2.ryerson.ca> In article <4usigc$fkr@ns2.ryerson.ca>, jverne@acs.ryerson.ca (John Verne - CNED/F94) writes: |> Wonyong Koh states in the hForth docs: |> optiCOMPILE, is used in place of Standard word COMPILE, which |> removes one level of EXIT if possible... Sounds like tail call optimization, but not like jump optimization. |> My understanding of the inner workings, and differences between, various |> compilers is limited, to say the least. I do understand that one of the |> most attractive things about this, is that there is no (little?) penalty |> for "empty" words. i.e. CHARS and CELLS (instead of 2*) can be used with no |> interpretation penalty. With tail call optimization this works only if the CHARS or CELLS is at the end of a definition. You may be thinking of inlining; with inlining, however, you don't get two entry points to the same code, but two code sequences (Paul Shirley would not like that). - 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 16 Aug 1996 17:18:49 GMT Message-ID: <4v2ahp$ck@news.tuwien.ac.at> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> To: Andy Civil In article <2YVV4GAXP4EyEw31@civil.demon.co.uk>, Andy Civil writes: |> "How can Forth be efficient when it does not use registers much?" *If* it does not use registers much, it will suffer. |> I have been considering the various arguments about which language is |> better, and thinking about the structure of my Forth (the only one I |> know, although I will try Holon soon) which does not make use of many of |> the registers that my processor has. It uses only the accumulator for |> actually doing calculations, and the registers that give you |> "interesting" addressing modes. But the general purpose registers remain |> unused. The 8086 has no general-purpose registers. The 80386 is much better: All registers have the interesting addressing modes. But it does not have enough registers for Forth (at least not for Gforth). |> Is there a way to use registers in Forth |> that I have not thought of? In my thesis you can find some ideas on how to make it use registers, for interpreters, for native code, and for translation to C. @PhdThesis{ertl96diss, author = {M. Anton Ertl}, title = {Implementation of Stack-Based Languages on Register Machines}, school = {{Technische Universit\"{a}t Wien}}, year = {1996}, address = {Austria}, url = {http://www.complang.tuwien.ac.at/papers/ertl96diss.ps.gz}, abstract = {Languages with programmer-visible stacks (stack-based languages) are used widely, as intermediate languages (e.g., JavaVM, FCode), and as languages for human programmers (e.g., Forth, PostScript). However, the prevalent computer architecture is the register machine. This poses the problem of efficiently implementing stack-based languages on register machines. A straight-forward implementation of the stack consists of a memory area that contains the stack items, and a pointer to the top-of-stack item.\par The basic optimizations explored in this thesis are: Caching the frequently-accessed top-of-stack items in registers reduces stack access overhead, and combining stack-pointer updates eliminates most of them.\par This thesis examines these optimizations in the context of three basic implementation techniques: \begin{itemize} \item For (virtual machine) \textbf{interpreters}, I regard the stack cache in the registers as finite state machine, where the execution of a virtual machine instruction performs a state transition; there are specialized implementations of the virtual machine instructions for each state. \item My \textbf{native-code compilation} technique transforms the programs into standard compiler data structures; then state-of-the-art compiler technology can be applied for optimization and code generation. In particular, stack items are represented by pseudo-registers, which register allocation will (usually) put into machine registers; stack pointer updates are executed symbolically, i.e., at compile time. \item For \textbf{translation to C}, I emphasize simplicity; the optimizer of the C compiler takes care of the complex problems. The translator just has to represent stack items as local C variables, and the C compiler will keep them in registers. As with native-code compilers, (usually) no stack pointer updates at run-time are necessary. \end{itemize} For interpreters, the optimizations eliminate about two real machine instructions per virtual machine instruction, resulting in speedups of 17\%--31\% (for Forth on a DecStation~3100). The techniques presented here for native-code compilation and translation to C achieve a speedup factor of 1.3--3 over traditional native code compilers and more than 3 over a straight-forward translator to C (for Forth on a 486DX2/66).} } |> This problem must be exacerbated on a processor like the 68000 series |> where the large number of general purpose registers is one of its |> greatest benefits. The 68k has no general-purpose registers, and certainly not a large number. The sentence above should rather read: These opportunities should be even greater on RISC chips, which usually have an adequate number of registers. - 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 16 Aug 1996 17:55:14 GMT Message-ID: <4v2cm2$ck@news.tuwien.ac.at> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> In article <3211CD2B.2878@headwaters.com>, Brad Rodriguez writes: |> Yes, let us PLEASE at least standardize a syntax for object-oriented |> Forth. |> But let's distinguish between syntax and implementation. (Architecture |> vs. organization?) (It's architecture vs. implementation/realization, at least in the computer architecture field.) This may not be completely possible (I have not looked closely on the Neon syntax in this respect, though). The syntax and semantics of such a wordset would prescribe certain implementation decisions; e.g., I think the Neon syntax makes it necessary to use FIND (or generally, half of a text interpreter) in the implementation, which I find ugly. My general position has been to write those bits of object-orientation that an application needs, when it is needed. E.g., in the Gray parser generator I used a simple implementation of OO that was tailored to the task. Yesterday I sat down and wrote an OO package, for the fun of it (it does not need FIND and it has constant-time late binding). But what is it good for? It has no classes to go with it. Without classes, it is pretty useless. Without classes, it's better to write the things that are needed, when they are needed. So, I think the way to get a standard OO syntax for Forth is to write a class library for it. The 17 other syntaxes will fall into disuse. No need for a standards committe for that one. - 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: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: multiple values Date: Fri, 16 Aug 1996 18:03:46 GMT Message-ID: <4v2d69$84p@news.NL.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> "Paul E. Bennett" wrote: >In article <4uqv9c$b8g@news.NL.net> hbezemer@vsngroep.nl "Hans Bezemer" writes: [snip] > >This implies if the string is not available there is nothing you can do >about it except perhaps do something else you were going to do anyway and >return to this item later. >A little local thought is all that is required for such situations. It is not >as if we have to save the flag for much later use. [snip] Why not embed such words in compilerwords like IFSTRING something ELSE something Then you force programmers to treat it like a conditional. >I agree that they should be as few as is practicable. They are not really a >problem. I usually have a clear view in my mind about the words I am using >because I always have a glossary reference by my side when programming (or on >screen if I haven't printed the latest yet). > [snip] if (x > 0) do_something(); is not much of a problem either. However, when deadlines have to be made, it easy to write code like this: if (x > 0) do_something(); do_another(); Oops, forgot the curly (Sue) braces. MultiReturn IF something THEN will result in code like: MultiReturn IF something ELSE another THEN >If you do not document Fort properly the I agree it can become very >un-maintainable. However, that comes down to programmer discipline (these >words do not sit well together for some). If you document as you write then >even the most complex of words you can create will be maintainable. This will >apply no matter which language you use, I just maintain that this is easier >in Forth. That is not my point. Documenting is always very important. >> If you expand >> the range, you might have to use the unsigned or double wordset, which means >> rewriting lots of code. >Why should you need to?. You would have obviously done some form of analysis >of the problem domain. You should know the sort of range for numbers you are >dealing with long before you start coding. The only time I find this is not >the case is when I write a few definitions to explore the problem domain a >little, in which case, this is throw away code. Yes, I even document that well >enough to follow it many months later. That's the point of maintenance! If we could plan all ahead we wouldn't need any maintenance! Not every maintenance run is due to programming errors! Circumstances change in the real world and programs have to be adapted to that. A small business with less than 32767 customers can boom! >> I don't know any C- >> functions that sometimes return a value and sometimes not. And if they do >> they are BAD news. >In C they are but in Forth, with consideration, they are not. Considering everyting, every program should work right away. ;) Unfortunately, they don't.. Hans. From: Elizabeth Rather Subject: Re: interfaces (was Re: multiple values) Date: Fri, 16 Aug 1996 10:28:24 +0000 Message-ID: <32144D48.5CAD@forth.com> References: <40.10697.1617@channel1.com> <4ul0uo$10mg@news.goodnet.com> <4ulm8c$bi7@nadine.teleport.com> <4uq5c8$fog@map.mda.ca> <3210ACD4.5B56@austin.finnigan.com> <4us274$hoa@dfw-ixnews5.ix.netcom.com> <4uuijg$jt3@ephor.tusc.com.au> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> Reply-To: erather@forth.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Macintosh; U; PPC) Ray Blaak wrote: > My experience with strong typing is that it immensely speeds up the process. > They don't take much time to set up, since usually each structure, list, > whatever is a distinct type directly in my language of choice (Ada). I imagine > ML is the same. My experience is that there are a lot of legitimate things I want to do that "strong typing" would prevent. Examples: fetch a keystroke, subtract an offset (( char n -), clearly illegal!) and use the result to index into an array; drop the high-order part of a double number that I know (from application-domain knowledge) is irrelevant and deal with the low-order part as a single; etc. It's possible that some limited checking (e.g., don't 2! into a VARIABLE) may be useful in some contexts, but in general I think how I handle values is none of the compiler's business. -- 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://www.forth.com From: Elizabeth Rather Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: Fri, 16 Aug 1996 10:48:00 +0000 Message-ID: <321451E0.1198@forth.com> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> <3214607F.2436@tir.com> Reply-To: erather@forth.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Macintosh; U; PPC) Michael A. Losh wrote: > > Andy Civil wrote: > > If I wanted to speed up my Forth, I could re-write some of the words in > > assembler, and make use of the registers for temporary storage, but then > > I would be writing assembler, not Forth. > > ... > > I suppose I could "cheat" and write a word > > that copied the top of stack into a register or performed some operation > > on it, but this does not "feel" right. > > ... > > Andy Civil > > In fact, all Forth systems implemented with a virtual machine have at > least a few "CODE" words that execute native machine language. And such > routines make use of CPU registers freely, or at least use them where > appropriate. If you look at the source for different Forth systems, you > can see this for yourself. Some systems only have a couple dozen CODE > routines, other systems have hundreds. It is true that most Forth > virtual machines tend to not utilize many CPU registers as they thread > through high-level code, which is nice when you _do_ want to use the > registers in a special CODE word. > > By the way, many Forth systems have a built-in assembler, so it is easy > to add your own CODE words that fully take advantage of your CPU > hardware. This is not cheating, but it does make a trade-off between > speed and possibly functionality versus portability and easy > maintainance. In fact, most Forths that I'm familiar with have carefully allocated registers to certain functions in order to optimize performance of the "virtual machine", and knowledge of these allocations can be useful when you write code routines. For example, the stack pointer is almost always kept in a register, and often the top-of-stack is. In addition, our implementations specify that certain registers are _always_ scratch, meaning you are free to use them in code w/o saving & restoring, a factor that provides additional performance improvements over environments where one routinely saves & restores all registers. Remembering that Forth was designed for high-speed real-time control applications, it certainly is within these design objectives that you can and should be able to make full use of your machine's features without any sense of "cheating". And, of course, since Forth lets you interactively test your code words and interfaces to them transparently, it's particularly easy to develop & test hybrid code/high-level solutions -- much easier than conventional environments where you run your compiler, assembler, linker & debugger as separate entities. -- 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://www.forth.com From: matt@access5.digex.net (Matt Lawrence) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 16 Aug 1996 21:05:36 GMT Message-ID: <4v2nr0$cq4@news4.digex.net> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> <3214607F.2436@tir.com> <321451E0.1198@forth.com> Elizabeth Rather (erather@forth.com) wrote: : : In fact, most Forths that I'm familiar with have carefully allocated registers : to certain functions in order to optimize performance of the "virtual : machine", and knowledge of these allocations can be useful when you write code : routines. For example, the stack pointer is almost always kept in a register, : and often the top-of-stack is. Also, many of today's CPUs are optimized to run C. Some of the machines in the past were optimized for Fortran, even other for Lisp or Smalltalk. None of these are perfect models for running Forth. Some are ok, some are pretty dreadful. Some examples: The 8051 is a terrible architecture to run a traditional Forth system on but the gains in productivity and the reduction in development time can make it well worth using. The 6502 is a pretty bad CPU to run Forth on, but it's still my language of choice when working with an Apple ][. The Motorola 6809 is a fairly good CPU for Forth. The TI 9900 is probably the best CPU I've ever used to run Forth. If I remember corrctly, the inner interpreter is 1 instruction and lots of other core functions are only a couple of instructions. : In addition, our implementations specify that certain registers are _always_ : scratch, meaning you are free to use them in code w/o saving & restoring, a : factor that provides additional performance improvements over environments : where one routinely saves & restores all registers. Always a good idea. : Remembering that Forth was designed for high-speed real-time control : applications, it certainly is within these design objectives that you can and : should be able to make full use of your machine's features without any sense : of "cheating". And, of course, since Forth lets you interactively test your : code words and interfaces to them transparently, it's particularly easy to : develop & test hybrid code/high-level solutions -- much easier than : conventional environments where you run your compiler, assembler, linker & : debugger as separate entities. Also, Forth was originally developed on an IBM 1130 so much of the language is more closely matched to that type of archetecture - 16 bit integers, shared code and data space, 4K (or more) memory, disk drive, etc. It's a tribute to Forth's versatility that it can be adapted so effectively to so many different environments. However, when you use low end mocrocontrollers, such as the 87C750 (1K ROM, 64 bytes RAM), you can't use a "traditional" Forth system and have to go to cross development and target compilers. In my opinion, this is still a very productive environment, but not as good as native development (and I don't know of any "native" development environments for the 87C750). -- Matt From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Fifth (was: Win32Forth and some OOP questions) Date: 16 Aug 1996 17:01:10 GMT Message-ID: <4v29gm$ck@news.tuwien.ac.at> References: <4uiv0k$2ki@helka.iif.hu> <4usv01$6vu@ite127.inf.tu-dresden.de> <1996Aug15.082335.32230@kbbs.org> In article <1996Aug15.082335.32230@kbbs.org>, hp@kbbs.org (Holger Petersen) writes: |> PS: there might be other things with the same name... Yes, you can find the description of a system called Fifth in JFAR (sorry, I don't remember the issue). It took some ideas of Modula to Forth. One of the Authors was Cliff Click, but he no longer does Forth. - 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Hang on, isn't Forth out of date now? Date: 16 Aug 1996 16:57:18 GMT Message-ID: <4v299e$ck@news.tuwien.ac.at> References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> In article <4uu272$9t5@ns2.borg.com>, falvosa@borg.com (Samuel A. Falvo II) writes: |> It should be noted that under NO circumstances can FORTH code run |> "faster" than assembler code. A statement which you promptly contradict: |> Some FORTH code may be faster than some assembly language routines |> because those who wrote the assembly language routine didn't know how |> to properly optimize his/her code for speed (the author was probably |> concentrating on getting it to WORK rather than work and be fast). That's what I meant. So, while this assembly programmer is still trying to get it to work, the Forth programmer may already be done with that and can continue with some refinements that annihilate the speed advantage of the assembly program. What's even more effective is when you give some thoughts to efficiency from the start (but remember that it has to work in order to work fast), giving several orders of magnitude of speedup (whereas rewriting threaded code in assembly barely gives one). The question is, does Forth encourage such a design for speed more than assembly? - 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: pai1@ix.netcom.com(Lloyd Prentice ) Subject: Re: Objects for ANS Forth Date: 16 Aug 1996 15:44:43 GMT Message-ID: <4v251b$4a2@dfw-ixnews3.ix.netcom.com> X-NETCOM-Date: Fri Aug 16 10:44:43 AM CDT 1996 David N. Williams wrote... > What I'm adovcating is that a Forth standard should maximize the > possibilities for interacting with mainline class/object resources. Yes! Yes! Yes! Who will show the way? From: Jack McPeck Subject: Forth Contractors / Temps Date: 16 Aug 1996 16:16:44 GMT Message-ID: <4v26tc$355@gate.itron.com> May have an opportunity for several agency or independent MTFORTH programmers to work 3-6 months. Please respond via e-mail with experience and availablity. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Jack McPeck Itron, Inc. Spokane, WA USA www.itron.com jack.mcpeck@itron.com From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Objects for ANS Forth Date: 16 Aug 1996 23:26:49 +0200 Message-ID: <4v2p2p$nmt@iaehv.IAEhv.nl> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> Trying out TEST.FTH and TESTER.FTH (ftp-ed from the site Andrew McKewan mentioned) presented some unexpected problems with CLASS.FTH. All but one of them have to do with the fact that the files have lines wrapped at unconvenient locations (changing their meaning to a Forth interpreter). I give the corrections below. The original "->" overwrote every cell available to iForth. The serious problem is that when a method name is chosen that is already the name of an existing Forth word, the code for the new method is not generated (or not findable). Instead, the original Forth word executes whenever you try to use the presumed method. In my Forth the word Exec: already exists, that's how I found out. Try : Put: CR ." Oeps." ; and load class.fth to see what will happen. I think this is a problem that should be removed, or at least flagged with an error message. -marcel --------------------------------------------------------------- Comparing files TEST.FTH and test.old ****** TEST.FTH \ ====================================================================== TESTING LATE BINDING ****** test.old \ =============================================================== ======= TESTING LATE BINDING ****** ****** TEST.FTH :M To: ( value index -- ) To: a1 ;M :M Fill: Fill: a1 ;M ****** test.old :M To: ( value index -- ) To: a1 ;M :M Fil l: Fill: a1 ;M ****** ****** TEST.FTH { : T14 5 At: [ POBJ ] ; T14 -> 99 } { : T15 5 POBJ At: Array ; T15 -> 99 } ( class binding ) { : T16 POBJ RELEASE ; T16 -> } ****** test.old { : T14 5 At: [ POBJ ] ; T14 -> 99 } { : T15 5 POBJ At: Array ; T15 -> 99 } ( class binding ) { : T16 POBJ RELEASE ; T16 -> } ****** Comparing files TESTER.FTH and tester.old ****** TESTER.FTH : -> \ ( ... -- ) RECORD DEPTH AND CONTENT OF STACK. \ kills Forth when stack did underflow! DEPTH DUP ACTUAL-DEPTH ! \ RECORD DEPTH ****** tester.old : -> \ ( ... -- ) RECORD DEPTH AND CONTENT OF STACK . DEPTH DUP ACTUAL-DEPTH ! \ RECORD DEPTH ****** From: tyan@cs.cornell.edu (Thomas Yan) Subject: Re: interfaces (was Re: multiple values) Date: 16 Aug 1996 19:06:32 -0400 Message-ID: <4v2utp$jvh@gerd.cs.cornell.edu> References: <40.10697.1617@channel1.com> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> <32144D48.5CAD@forth.com> In article <32144D48.5CAD@forth.com>, Elizabeth Rather wrote: >My experience is that there are a lot of legitimate things I want to >do that "strong typing" would prevent. Examples: fetch a keystroke, >subtract an offset (( char n -), clearly illegal!) and use the result >to index into an array; drop the high-order part of a double number >that I know (from application-domain knowledge) is irrelevant and >deal with the low-order part as a single; etc. It's possible that >some limited checking (e.g., don't 2! into a VARIABLE) may be useful >in some contexts, but in general I think how I handle values is none >of the compiler's business. a good type system would not prevent you from doing this, although it would probably make it more tedious. presumably there would be functions that map a keystroke into an integer (probably a nop), and a function that converts an integer to a keystroke. (perhaps two flavors, one that does rangechecking, and one that doesn't). having to use such conversions can help document code, but i agree that it can be quite a pain! i like this approach because i can always use an unsafe conversion to manipulate data when i know it safe (e.g. drop high order part of a double), but otherwise there are automatic sanity checks. also, i find one of the major benefit's of ML's type system is that when modifying a program, the type inference engine alerts me to type mismatches. it makes propagating changes much easier and much more reliable. the other thing to note is that type inference means that only a few type declarations must be given -- useful documentation in any case -- and then the remaining types are inferred. - t -- Thomas Yan I don't speak for Cornell. Computer Science Department \\ Cornell University \\ Ithaca, NY 14853 From: phpr@berlin.snafu.de (H.-Peter Recktenwald) Subject: oop(?) Date: Fri, 16 Aug 1996 00:48:42 GMT Message-ID: <4v38b2$pks@unlisys.unlisys.net> Reply-To: phpr@berlin.snafu.de I'd try the following on inheritage of a words defining rules in my f.i.g.-style forth system (where the f83 vocabulary stack also exists): 0 variable DDS \ for current entry : NEST >r ;s ; \ for nested execution : \ (f.i.g.-"does>" is not immediate) here swap ! [compile] literal \ the inherited defining word compile [ ' nest cfa , ] \ compile its nested execution 4 csp +! ; immediate \ "" \ initialize ' task dds ! \ and test it : defn0 References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> X-NETCOM-Date: Fri Aug 16 10:09:24 PM PDT 1996 Anton Ertl wrote: [ in reply to the question: can Forth be faster than ] [ assembly language programs? ] >So, while this assembly programmer is still trying to >get (his program) to work, the Forth programmer may >already be done with that and can continue with some >refinements that annihilate the speed advantage of the >assembly program. >The question is, does Forth encourage such a design for >speed more than assembly? Consider Forth to be a development system. The Forth (outer) interpreter is your interface to your program. Write your program in high-level Forth to get it working. Forth will be your console I/O, your debugger, your mass storage controller, your code library. Forth is especially good for working with strange new hardware setups. Once your program runs, you can see where your timing bottlenecks are. You can replace the crucial portions of your program with FORTH ASSEMBLER. You still use Forth as your development system, but now you're optimizing for speed. You don't need to write the whole program in assembler! Your Forth may have a "native code compiler", which gives a run speed about one-half of assembler, but without writing ANY assembly code. You can "target compile" the system (see Leo Brodie's book, STARTING FORTH for info), to reduce the size of the binary image for embedded systems; or you can "seal" the system (ie: lockout the outer interpreter from the end-user if necessary) for disk-based systems you want to distribute. Will the final Forth code run faster than assembler? Well, the parts written in Forth's assembler will be _about_ as fast. If you are good at hand optimization, and the "other" assembler makes a lot of unfortunate assumptions for you (ie: only uses long jumps, not short jumps, etc.), then the Forth program CAN run faster ... in those critical areas. Will the Forth programmer get his project done first? NO CONTEST. From: Chris Jakeman Subject: Re: Manipulating Return Addresses Date: Fri, 16 Aug 1996 19:51:22 +0100 Message-ID: References: <320B3C25.6E4C@austin.finnigan.com> <320F1536.38E8@forth.com> <320FD2B3.522A@ix.netcom.com> <32132C17.5EAA@ix.netcom.com> X-NNTP-Posting-Host: apvpeter.demon.co.uk MIME-Version: 1.0 In article <32132C17.5EAA@ix.netcom.com>, Tom Zimmer writes >Chris Jakeman wrote: >> >> In article <320FD2B3.522A@ix.netcom.com>, Tom Zimmer >> >> Surely there's a better way. >> > >> >How about using CATCH and THROW, nothing says they can only be used for >errors. >> >At least that is a known "standard" way of manipulating the return stack. >> >> Thanks for the idea, Tom, but I don't think it will work. Yes, you >> could use THROW to back out of a pattern when a mis-match was found, but >> after the mis-match, you will want to resume from the most recent point >> where there was an alternative and try that. In other words, you are >> jumping back into a pattern at a point where you've been before. I >> can't see how to do that with the standard CATCH and THROW. > >I suppose if you are are not returning up to the same caller, it could be >more complex, you would have to pass back a code to tell all the CATCHes >above, which one was to actuall catch the THROW. Your ideas are much appreciated, but I still don't think it will work because we need to jump back _into_ a pattern. For example, the 3 patterns: << ABA A { B } A >> matches "AA" and "ABA" << ACA A { C } A >> matches "AA" and "ACA" << Pattern ABA ACA >> will match only "AAAA", "ABAAA", "AAACA" and "ABAACA" If we try to match the string "ABACA", then pattern ABA will match "ABA.. and save the token for the possible alternative match "AA... on the Data Stack on top of a Return Address. The next pattern ACA will try to match ...CA" and fail. All failures backtrack by executing the token on the Data Stack. There will be one left by << which unnests out of ACA. Then there will be another left by >> which re-nests back into ABA. Finally there is one left by {. This last token pulls a Return Address off the Data Stack and uses it to resume from part-way through ABA. I hope this hasn't muddied the waters still further. CATCH isn't enough because it one way only - un-nesting words. Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter From: wykoh@pado.krict.re.kr (Wonyong Koh) Subject: Re: multiple entries Date: Sun, 18 Aug 1996 03:16:56 GMT Message-ID: <4v484f$adk@nis.dacom.co.kr> References: <4ud5e1$1so@news.tuwien.ac.at> <4udtm5$t99@unlisys.unlisys.net> <4uo5ae$8oa@news.tuwien.ac.at> <4usigc$fkr@ns2.ryerson.ca> <4v28nm$ck@news.tuwien.ac.at> Reply-To: wykoh@pado.krict.re.kr 'optiCOMPILE,' in hForth does not do tail call optimization. 'optiCOMPILE,' removes one level of EXIT if the 'xt' being compiled is null definition or synonym of other definition. See the following examples: : TEST1 ; SEE TEST1 call-doLIST EXIT ok : TEST2 TEST1 ; SEE TEST2 call-doLIST EXIT ok : TEST3 DUP ; SEE TEST3 call-doLIST DUP EXIT ok : TEST4 TEST3 ; SEE TEST4 call-doLIST DUP EXIT ok 'optiCOMPILE,' is defined as: : optiCOMPILE, DUP ?call ['] doLIST = IF DUP @ ['] EXIT = IF \ if first word is EXIT 2DROP EXIT THEN DUP CELL+ @ ['] EXIT = IF \ if second word is EXIT @ DUP ['] doLIT XOR \ make sure it is not literal value IF SWAP THEN THEN THEN THEN DROP COMPILE, ; where '?call' is defined as: ?call ( xt1 -- xt1 0 | a-addr xt2 ) Return xt of the CALLed run-time word if xt starts with machine CALL instruction and leaves the next cell address after the CALL instruction. Otherwise leaves the original xt1 and zero. Wonyong Koh, Ph.D. wykoh@pado.krict.re.kr anton@a0.complang.tuwien.ac.at (Anton Ertl) wrote: >In article <4usigc$fkr@ns2.ryerson.ca>, jverne@acs.ryerson.ca (John Verne - CNED/F94) writes: >|> Wonyong Koh states in the hForth docs: >|> optiCOMPILE, is used in place of Standard word COMPILE, which >|> removes one level of EXIT if possible... >Sounds like tail call optimization, but not like jump optimization. >|> My understanding of the inner workings, and differences between, various >|> compilers is limited, to say the least. I do understand that one of the >|> most attractive things about this, is that there is no (little?) penalty >|> for "empty" words. i.e. CHARS and CELLS (instead of 2*) can be used with no >|> interpretation penalty. >With tail call optimization this works only if the CHARS or CELLS is >at the end of a definition. You may be thinking of inlining; with >inlining, however, you don't get two entry points to the same code, >but two code sequences (Paul Shirley would not like that). >- 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: Brad Rodriguez Subject: Re: Hang on, isn't Forth out of date now? Date: Sat, 17 Aug 1996 06:26:58 -0700 Message-ID: <3215C8A2.BED@headwaters.com> References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Anton Ertl wrote: > What's even more effective is when you give some thoughts to > efficiency from the start (but remember that it has to work in order > to work fast), giving several orders of magnitude of speedup (whereas > rewriting threaded code in assembly barely gives one). The question > is, does Forth encourage such a design for speed more than assembly? A case in point: a Quicksort in Forth will run faster than a bubble sort in assembly. I think Forth programmers are more likely to try a recursive solution (like Quicksort) than assembly programmers. -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: mikc@gnu.ai.mit.edu (Mike Coughlin) Subject: Re: I threw a stone into a pool, and the ripples are still going... Date: 17 Aug 1996 13:19:07 GMT Message-ID: <4v4gsb$6ev@life.ai.mit.edu> References: <2YVV4GAXP4EyEw31@civil.demon.co.uk> In article <2YVV4GAXP4EyEw31@civil.demon.co.uk>, Andy Civil wrote: >"How can Forth be efficient when it does not use registers much?" >I have been considering the various arguments about which language is >better, and thinking about the structure of my Forth (the only one I >know, although I will try Holon soon) which does not make use of many of >the registers that my processor has. It uses only the accumulator for >actually doing calculations, and the registers that give you >"interesting" addressing modes. But the general purpose registers remain >unused. >If I wanted to speed up my Forth, I could re-write some of the words in >assembler, and make use of the registers for temporary storage, but then >I would be writing assembler, not Forth. However, if I was writing a >true compiler, then I would be free to use the registers to their full >extent. Is this not better? Is there a way to use registers in Forth >that I have not thought of? I suppose I could "cheat" and write a word >that copied the top of stack into a register or performed some operation >on it, but this does not "feel" right. >This problem must be exacerbated on a processor like the 68000 series >where the large number of general purpose registers is one of its >greatest benefits. Everyone who uses Forth uses it in a different way and thinks about the computer in a different way. Using stacks is better than using registers. Once you see this, then you see that registers just get in the way of good programming, and you want a CPU that has more stacks instead of more registers. You can simulate a stack machine in software if you have to. Of course, if you disagree with the above, and think many registers are an advantage, then you can still use Forth. You just woun't do things the same way. It is perfectly fine to use Forth as an assembler. In fact I don't understand why assemblers are still in use after Forth has been invented. The power of Forth is used to write many different but related languages and use them in many different styles. This causes endless problems with documentation, standards, and training. But this is because there are problems with documentation, standards and computer language training with any method of computer programming. Using Forth makes these problems worse only because Forth programmers care very little about solving them. So don't worry about "cheating". If the program works, then it must be OK. Develop your own style and if its not the same as anybody else's, then you are following in the Forth tradition. If you publish your programs so others can understand them, then your way of doing things could be examples that others will follow. -- Michael Coughlin mikc@gnu.ai.mit.edu Cambridge, MA USA From: "David N. Williams" Subject: Re: Objects for ANS Forth Date: Sat, 17 Aug 1996 10:54:31 +0000 Message-ID: <3215A4E7.7FAB@umich.edu> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) Marcel Hendrix wrote: > > Trying out TEST.FTH and TESTER.FTH (ftp-ed from the site > Andrew McKewan mentioned) presented some unexpected problems > with CLASS.FTH. > > All but one of them have to do with the fact that the files have > lines wrapped at unconvenient locations (changing their > meaning to a Forth interpreter). I give the corrections below. > The original "->" overwrote every cell available to iForth. There was nothing like this in the files I got from ftp.netcom.com/pub/mc/mckewan. Have they been fixed? The file test.4th works fine on my system in ANS compatibility mode. I haven't yet checked the name conflict problem Marcel brings up. By the way I never succeeded in getting a directory listing for this site with NetScape, much less a download, with tries on several different days. I finally did ftp the old way from a UNIX machine. --David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: Greg Morrisett Subject: Re: interfaces (was Re: multiple values) Date: Sat, 17 Aug 1996 13:43:20 -0400 Message-ID: <321604B8.3DB2@cs.cornell.edu> References: <40.10697.1617@channel1.com> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> <32144D48.5CAD@forth.com> <4v2utp$jvh@gerd.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (WinNT; I) Elizabeth Rather wrote: >My experience is that there are a lot of legitimate things I want to >do that "strong typing" would prevent. Examples: fetch a keystroke, >subtract an offset (( char n -), clearly illegal!) and use the result >to index into an array; Works great until you move to an NT system which uses unicode instead of ASCII. In general, confusing abstractions just because the representations "happen" to match leads to many problems porting code. (Witness all the problems with people assuming int is 16 or 32 bits now that we have 64 bit machines.) And of course, providing a char2int conversion is no great difficulty. On machines where char and int have the same representation, you pay no performance cost and get the added benefit of not accidentally treating char and int as the same. -Greg Morrisett jgm@cs.cornell.edu From: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Subject: Re: interfaces (was Re: multiple values) Date: 17 Aug 1996 14:20:54 -0400 Message-ID: <8gwwyxc1o9.fsf@galapagos.cse.psu.edu> References: <40.10697.1617@channel1.com> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> <32144D48.5CAD@forth.com> <4v2utp$jvh@gerd.cs.cornell.edu> <321604B8.3DB2@cs.cornell.edu> In-reply-to: Greg Morrisett's message of Sat, 17 Aug 1996 13:43:20 -0400 To: Greg Morrisett Greg Morrisett writes: | Elizabeth Rather wrote: | >My experience is that there are a lot of legitimate things I want to | >do that "strong typing" would prevent. Examples: fetch a keystroke, | >subtract an offset (( char n -), clearly illegal!) and use the result | >to index into an array; | | Works great until you move to an NT system which uses unicode instead | of ASCII. In general, confusing abstractions just because the | representations "happen" to match leads to many problems porting | code. (Witness all the problems with people assuming int is 16 | or 32 bits now that we have 64 bit machines.) Not that standard Scheme does any better here. It only has character handling functions (e.g. read-char), so it cannot handle ordinary bytes. From: "Paul E. Bennett" Subject: Re: Hang on, isn't Forth out of date now? Date: Sat, 17 Aug 96 11:06:46 GMT Message-ID: <840280006snz@tcontec.demon.co.uk> References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4uu272$9t5@ns2.borg.com> falvosa@borg.com "Samuel A. Falvo II" writes: > It's like designing a circuit using discreet TTL > components (the BASIC route), I never ever would have thought of BASIC in those terms. It's very wide of such an analogy. > ..............................then using PAL/PLA chips (the FORTH > route), The analogy for FORTH in chip terms is: TTL -- Vendor written components (the usually useful stuff they stick in the give-away files with their Forth products. PAL/FPGA -- What you write yourself and implement. > .........and finally, to your very own custom ECL ASIC chip with > built-in, bidirectional level shifters for use with MOS and TTL LS > chips running at 250MHz without pipelines (the assembly language > route). This was the most correct. Especially when you take the time to analyse and optimise as much as practicable. It is a lot of hard work though. > The analogy isn't all that fake either, as software is the > logical equivalent of hardware. I've always said that. It becomes a new view of software when you can realise the similarities. Forth is also very like a plug-board (bread-board) on which you can just plug the chips in and wire up the signal interconnections (knowing the power-lines are already done for you) and try things out. When you are happy with the results of the try-outs you then do the PCB (re-write with full documentation) and asemble the final product. What do you do with the bread-board afterwards?. Dismantle it and keep it handy for the next time you need to try something out. For those who are interested in such a view that is graphically easy to understand Gordon Charlton's article in the December 1993 edition of Forthwrite (the FigUK magazine). I cannot recall at present whether Gordon submitted this to FD. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: "David N. Williams" Subject: Environment Variables Date: Sat, 17 Aug 1996 16:53:45 +0000 Message-ID: <3215F919.7102@umich.edu> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) The recent discussion of NEEDS in this group inspired me to stop putting off implementing it, so I did. That led to the need for a library path variable, so I figured I might as well go ahead and try to do UNIX-style environment variables, which I did. Feedback on the general setup and the specification of the basic words would be appreciated. I didn't look very hard for existing implementations, so maybe this is reinvention. Here's the rationale. UNIX and other rational systems provide at program startup not only the argc and argv information familiar from the C main() function but an array of environment strings as well. There's no standard way of doing that, but it's common to include all of these things just below the user's stack. The environment strings are C strings with forms like LIBPATH=/usr/local/lib/forth/ with the name of the environment variable to the left of the "=" and the string value to the right. There is a POSIX variable for the array of environment strings extern char **environ and a POSIX function char *getenv(const char *name) which returns the pointer to the string value associated with name, or the null pointer if name does not exist. I thought it might as well be opened up a bit to allow the user to add variables not provided by the system, and to set the values as well as read them. I give them a private name space, not in the search order; but they are otherwise normal Forth variables with two-cell data fields that hold the length and address of the string value. I use an ENVIRONMENT wordlist, but that detail doesn't have to be part of the specification. In the stack comments below, the notation "s" or ".s" indicates Forth string parameters, e.g., s=[c-addr len]. The basic words I'm experimenting with are the following. MAKE-ENV ( name.s -- dfa ) Enter a word named by the input string in the ENVIRONMENT wordlist. Reserve a two-cell data field. The word can then be found by name.s ENVIRONMENT SEARCH-WORDLIST and behaves as a normal variable when executed, leaving its dfa. It's name.s on the parameter stack, rather than "name" in the input stream, to accommodate the variables provided by the system. This word can be implemented portably, with something like Will Baden's PLEASE mechanism, but I think the natural implementation will be system dependent. There's another word for user creation of environment variables: CREATE-ENV ( "name" -- ) which does an analogous thing from the input stream, and which is easy to implement portably. ENV-DFA ( name.s -- dfa|0 ) Leave the data field address of the environment variable named by name.s, or zero if it doesn't exist. There is an unlikely implementation dependence in the assumption that zero is not a possible dfa. ENV-DFA is a direct analog of the POSIX getenv(), but it also enables changing the value. Maybe >ENV would be a better name? Finally, a penultimately implementation-dependent word: COLLECT-ENVS ( -- ) Parse each of the environment strings provided by the system and make an environment variable in the ENVIRONMENT wordlist, named by the part of the string to the left of the equals sign, whose value is the part of the string to the right of the equals sign. This is long-winded enough, so I'll quit. Anybody who's interested can look in ftp://ftp.williams.physics.lsa.umich.edu/pub/forth/env/ for an implementation of the above, and a little bit more, including a couple of defining words for accessors. There's really, really nonportable stuff at the end, probably incomprehensible outside of my system, but it's marked, and might suggest the flavor. Thanks for any comments. --David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: "David N. Williams" Subject: Re: Environment Variables Date: Sat, 17 Aug 1996 17:05:36 +0000 Message-ID: <3215FBE0.1C53@umich.edu> References: <3215F919.7102@umich.edu> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) David N. Williams wrote: > > ftp://ftp.williams.physics.lsa.umich.edu/pub/forth/env/ Oops! Wrong URL. Here's the right one: ftp://williams.physics.lsa.umich.edu/pub/forth/env/ --David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: Tom Zimmer Subject: Re: Manipulating Return Addresses Date: Sat, 17 Aug 1996 16:13:38 -0600 Message-ID: <32164412.199D@ix.netcom.com> References: <320B3C25.6E4C@austin.finnigan.com> <320F1536.38E8@forth.com> <320FD2B3.522A@ix.netcom.com> <32132C17.5EAA@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sat Aug 17 2:11:43 PM PDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Chris Jakeman wrote: > > In article <32132C17.5EAA@ix.netcom.com>, Tom Zimmer > writes > > > >I suppose if you are are not returning up to the same caller, it could be > >more complex, you would have to pass back a code to tell all the CATCHes > >above, which one was to actuall catch the THROW. > > > Your ideas are much appreciated, but I still don't think it will work > because we need to jump back _into_ a pattern. For example, the 3 > patterns: > << ABA A { B } A >> matches "AA" and "ABA" > << ACA A { C } A >> matches "AA" and "ACA" > << Pattern ABA ACA >> > will match only "AAAA", "ABAAA", "AAACA" and "ABAACA" > > If we try to match the string "ABACA", then pattern ABA will match > "ABA.. and save the token for the possible alternative match "AA... on > the Data Stack on top of a Return Address. The next pattern ACA will > try to match ...CA" and fail. > > All failures backtrack by executing the token on the Data Stack. There > will be one left by << which unnests out of ACA. Then there will be > another left by >> which re-nests back into ABA. Finally there is one > left by {. This last token pulls a Return Address off the Data Stack > and uses it to resume from part-way through ABA. > > I hope this hasn't muddied the waters still further. CATCH isn't enough > because it one way only - un-nesting words. I'm slowly getting a clearer picture, and it does appear that there may not be a good standard way to handle this kind of problem. It sounds to me like what is needed is a state machine, and a bunch of gotos. Thanks for all the explaination :-) Tom Zimmer From: Tom Zimmer Subject: Re: Objects for ANS Forth Date: Sat, 17 Aug 1996 16:18:29 -0600 Message-ID: <32164535.33E0@ix.netcom.com> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <3215A4E7.7FAB@umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sat Aug 17 2:16:33 PM PDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) David N. Williams wrote: > > By the way I never succeeded in getting a directory listing for this > site with NetScape, much less a download, with tries on several > different days. I finally did ftp the old way from a UNIX machine. There is some peculiar problem with Netcom's ftp, I don't think any version of Netscape works with it. I blame it on Netcom, because Netscape seems to work with everyone else. I use Fetch on my Mac which works fine for Netcom. "bounce, bounce, who has the bouncing ball" Tom Zimmer From: Peter J Knaggs Subject: Re: Objects for ANS Forth Date: Sat, 17 Aug 1996 15:37:12 +0100 Message-ID: <3215D918.3C79@paisley.ac.uk> References: <4v0b2g$p1r@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b7a (Win95; I) CC: lenz@acm.org >> I would like to promote this model as a standard for object-oriented >> programming in Forth. I believe it to be quite a complete model with >> a clean syntax and good performance. > >Yes, let us PLEASE at least standardize a syntax for object-oriented >Forth. I recently did a survey of 17 OOFs and couldn't find any >agreement at all, and we'll need this to be competitive. Well, we had a working group at euroFORTH '95 on just this topic. Len Zettel has the notes. -- Peter J Knaggs pjk@paisley.ac.uk From: Georg_Bauer@ms3.maus.westfalen.de (Georg Bauer) Message-ID: <199608162308.a16455@ms3.maus.de> Subject: Forth for SUN 3/50 X-Software: Erwinsgate gb0.9o (c) es@do2.maus.ruhr.de, gb@ms3.maus.westfalen.de Date: Fri, 16 Aug 96 23:08:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Does anyone have a Forth system that can be installed on an old 68K Sun as the prime system instead of Sun OS? I don't really like to use a full Unix on the system because it is awfull slow (it's only a 4M RAM system). But since the system has nice hardware, it would be fun to reactivate it with a Forth system and use it again (especially the 19" monitor is worth the try). bye, Georg From: Bill Zimmerly Subject: Re: multiple values Date: Sat, 17 Aug 1996 17:50:07 -0500 Message-ID: <32164C9F.179F@inlink.com> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com Jonah Thomas wrote: > > In <321383F0.58FB@inlink.com> Bill Zimmerly writes: > >Hans Bezemer wrote: > >> Bill Zimmerly wrote: > > >> [snip] > > >> >*Every* word should remove only the input arguments documented in > >> >it's stack effect diagram, and should only put back what it's stack > >> >effect diagram documents. If this rule is not followed, no wonder a > >> >disaster follows. > > >> [snip] > > >I'm 'kinda lost on this one, Hans...I don't quite understand what your > >problem with it is. What is confusing about returning "booleans and > >something (or nothing)"??? Can you perhaps post an example of a word's > >definition that confuses you and then (we) can critique it? > > Here's a made-up example. Say you're doing genetic algorithms. You > have a problem where it's hard to find a good solution, but easy to test > how good a given guess is. So your program makes guesses and tests them > and improves on them. OK, now you have a whole series of examples > of the problem coming in, and you have a dozen techniques that are each > good at some versions of the problem and bad at others. And you have > rules of thumb about when each is likely to be good. So when a problem > comes in, you give it to the first method, and it checks its > rule-of-thumb, and either it returns an attempted solution, or it > passes. > > So what it returns if it tries to solve the problem, is the address that > it left its solution, and then the error function that says how good the > solution is, and then a true flag. And what it returns if it punts, is > only a false flag. > > If it found a solution, you want to do something with the solution. If > it didn't, you definitely aren't going to respond the same way, you're > going to do something entire different, namely you're going to try the > next method and not look back. > > It might make sense to leave two pieces of garbage on the stack under > the false flag, so you can 2DROP them later. That way the routine > leaves the same number of items either way, and people can't get > confused by expecting the wrong number. On the other hand, people could > get just as confused if they have 2 pieces of garbage to keep the stack > depth happy. If they don't notice which branch they're in then they can > expect problems. > > But then, it's easier to write automatic stack-checkers if each word > leaves the same number of items no matter what. And even if it turns > out that sometimes it's easier to read and write and understand a word > that has two separate stack results, probably the majority of the times > that people think so, they're wrong. I figure the rule that you don't > make routines with varying numbers of stack results won't usually cause > a lot of trouble, and it can save some. Thanks, Jonah, but I think I already figured out what Han's beef was near the bottom of my reply to him... After further consideration of Han's posting, I came to realize that what was bugging him seemed to be words *like* ?DUP, that return 2 elements if the original was non zero and one element if the original was zero...to be immediately be eaten up by the ?BRANCH word. (Or whatever the child of IF is called these days! ) ...and I agree with Han's...I don't like *that* style! As a matter of principle, I avoid using words that exhibit this behavior (like ?DUP) since I abhor words that express what I like to call "funny" stacks. I see them as being the functional equivalent of multiple entry points since they leave it up to subsequent branches to clean up the mess that they've introduced. I prefer that the cleanup be done WITHIN the appropriate followup branch RATHER than before the branch occurs and unnecessarily forces the stack diagram to report it's alternate behaviors. I just don't like diagrams like this... ( n -- d | 0 false | 1 a l true -- ) \ etc. ...instead prefering nothing more complicated than a before and after effect... ( a -- a+1 len ) But still...what's a "SED"? Aha!!!! (Alarm bells ringing!!!!! *** (S)tack (E)ffect (D)iagram!!!!! ***) Life is good again! - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Objects for ANS Forth Date: 18 Aug 1996 12:03:55 +0200 Message-ID: <4v6pqb$nlg@iaehv.IAEhv.nl> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> Anton Ertl writes Re: Objects for ANS Forth [ I presume "this" refers to making the architecture independent of the implementation? ] > This may not be completely possible (I have not looked closely on the > Neon syntax in this respect, though). The syntax and semantics of such > a wordset would prescribe certain implementation decisions; e.g., I > think the Neon syntax makes it necessary to use FIND (or generally, > half of a text interpreter) in the implementation, which I find ugly. Do you dislike the Neon syntax as such, or the fact that the interpreter must be modified to accommodate it? Personally I think Forth would benefit from some sort of on-the-fly "interpreter manipulation" now and then. Trivial examples are the ability to parse matrix, record and string operations: a[2] +TO warehouse.apples.1stquality, $name+$extensions TO $filename). The obvious disadvantage of these abilities is that they make user extensibility very difficult. The idea of virtual methods in an OOF might point to a solution. [ .. ] > Yesterday I sat down and wrote an OO package, for the fun of it (it > does not need FIND and it has constant-time late binding). But what is > it good for? It has no classes to go with it. Without classes, it is > pretty useless. Without classes, it's better to write the things that > are needed, when they are needed. The same reasoning applies to writing new Forth interpreters. A lot of people do, and then stop. For the Duff/McKewan/Hore implementation I expect some interesting classes are, or will become, available. > My general position has been to write those bits of object-orientation > that an application needs, when it is needed. E.g., in the Gray parser > generator I used a simple implementation of OO that was tailored to > the task. With this approach you will never find a need to do OOP, or will never realize you're doing it. You must be willing to use somebody else's libraries. Or is there more to OOP than this? -marcel From: Brad Rodriguez Subject: Re: Objects for ANS Forth Date: Sun, 18 Aug 1996 06:45:53 -0700 Message-ID: <32171E91.1009@headwaters.com> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Anton Ertl wrote: > |> But let's distinguish between syntax and implementation. (Architecture > |> vs. organization?) > > (It's architecture vs. implementation/realization, at least in the > computer architecture field.) We obviously had different profs for computer architecture. :-) -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Brad Rodriguez Subject: Re: Manipulating Return Addresses Date: Sun, 18 Aug 1996 06:47:41 -0700 Message-ID: <32171EFD.1776@headwaters.com> References: <4ud4bb$8v@news.tuwien.ac.at> <4uo9at$8oa@news.tuwien.ac.at> <79eBCOA0oMEyEwUY@apvpeter.demon.co.uk> <4v24v9$ck@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) > |> That's it exactly. You might consider the more efficient: > |> > |> : RADrop S" R> DROP" EVALUATE ; IMMEDIATE Is EVALUATE guaranteed to leave nothing on the return stack while it executes? -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Paul Shirley Subject: Re: Hang on, isn't Forth out of date now? Date: Sun, 18 Aug 1996 02:33:31 +0100 Message-ID: References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> Mime-Version: 1.0 In article <4v3k64$d95@sjx-ixn6.ix.netcom.com>, pfrenger@ix.netcom.com writes >Will the Forth programmer get his project done first? NO CONTEST. This was *not* my experience in the mid 80's, for the simple reason that the dominant delay was rebooting the system after a fatal crash (about 2-4 minutes!) The editor/assembler/debugger I used was pretty good at catching fatal memory writes before they did any damage. The Forth system in contrast was quite easy to crash even before running the app! -- Paul Shirley From: "Jerry Kreps" Subject: Where is Lee Brodie? Date: 18 Aug 1996 18:13:06 GMT Message-ID: <01bb8d31$04904be0$63c3dece@dialin.inetnebr.com> Way back in 1981 I picked up Forth because I became associated with SAVVY, a natural language programming system that was written in PolyForth. Later, while in a "get cheap" mode, they changed to a lessor know version. I installed a DB & development package written in Forth called "DataAce" at an automotive parts house and taught the owner how to program in Forth. I had previously taught myself using the book from Forth Inc., "Starting Forth" by Lee Brodie. I remained in computer programming and now use VB3, Delphi, and PowerBuilder 5.0, but when I saw WinForth32 I downloaded a copy and my interest in Forth has been rekindled. Brodie's book was, perhaps, the best introduction to a computer language that I ever read! As I re-read it now, to bring myself back up to speed, I recall reading that a more recent version is available. Is that true? And, what is Brodie doing these days? -- Jerry Kreps jlkreps@inetnebr.com From: Bernd Paysan Subject: Re: multiple values Date: Sat, 17 Aug 1996 15:40:33 +0200 Message-ID: <3215CBD1.3B8B9340@informatik.tu-muenchen.de> References: <40.10697.1617@channel1.com> <320F15C8.749D@forth.com> <4upa55$c5i@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Zsoter Andras wrote: > > Elizabeth Rather (erather@forth.com) wrote: > > >I'm sorry you found your experience with Forth so unfortunate. You don't > >mention what version you used or -- more importantly, in this case -- how > >you learned Forth (e.g., from some of the good books on the subject, from > >user documentation with your system, from experienced Forth programmers, > >or on your own without help). > > Well, I have learned Forth on my own (with a book with some not quite > well written examples) and it really took longer than to learn almost > any other language. Looks more like a fault of the book than yours. I learned Forth with _the_ book (Brodie), and I learned it faster than my first langugae (which was Logo, the toy language for children). I guess it would have been harder, if my first language was BASIC. To some extent, Logo is just polish notated Forth, except that it hasn't swoperators, but local variables. > You have to admit that Forth is hard to learn, and some people might > never get a grasp what is it all about. Many people never get a grasp what it is all about, because they never have a close look. There are only few good Forth books around, one is Starting Forth. But this is the case for other languages, too. Most people learn C with K&R and Pascal with Wirth. > On the other hand once you have learned it everything else looks > a bit unnatural. ;-) It looks like the language designer did a lot of unnecessary work. > >There are a few simple recommended practices for good Forth programming: > >1. Keep your definitions short (most should be only a few lines long). > >2. Each definition should destroy its arguments and leave only explicit > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I know about this rule and it bothers me a lot. > Sometimes ideas do not seem to fit into the "destroy the arguments" > scheme. So I sometimes violate this rule. No styling rule is "always", all are "most the time". There is one important rule: "If all other rules seems inappropriate, do whatever suits the problem best" > > results. Document its stack effect at the beginning of the definition. > >3. Test each definition individually before using it in higher level > > definitions (bottom-up testing), ensure that its stack behavior > > is appropriate as well as ensuring that its behavior is otherwise correct. > > About the original question: > > I think Forth words with the explicit stack handling, > stack diagrams, and a few lines of description are a lot > easier to understand than say, a five page long C function with all > that named variables and the like. Especially, if the names of the variables are "f, g, i, j, k, p, q, r, n, m, tmp;". > Just don't think about the items left on the stack as "return value(s)", > but rather as a change in the environment caused by the word. > That makes things psychologically more confortable. I feel comfortable with the "return value" idea. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: Hang on, isn't Forth out of date now? Date: Sat, 17 Aug 1996 16:03:47 +0200 Message-ID: <3215D143.21C99DA2@informatik.tu-muenchen.de> References: <320a20a0.0@news.cranfield.ac.uk> <32108D62.3E5@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Andrew McKewan wrote: > > Finally, if anyone knows how to add microcode to a Pentium, I'd sure like to > > add about four instructions to it to make it an almost perfect FORTH > > processor... > > And about 4 more registers... There's a "2" missing. Start with the PPro, and add 24 registers, formed as a first-level stack cache (the PPro has enough register renaming capabilities). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: Hang on, isn't Forth out of date now? Date: Sat, 17 Aug 1996 16:12:32 +0200 Message-ID: <3215D350.2344BDFE@informatik.tu-muenchen.de> References: <320a20a0.0@news.cranfield.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Jim Schneider wrote: > Although I don't know much about ARM instructions, I can post a comparison > on the x86 chip. First, the FORTH, which is from a (not yet released) > Linux FORTH system: > > subr: nest \ nest a colon definition, eg., call it > sub ebp, # 4 > mov 0 [ebp], esi This takes 3 cycles since you have a one cycle penalty for modifying a register before using it as addess. Use mov -4 [ebx], esi sub ebp, # 4 instead (one cycle on the Pentium, since it can be done in u and v pipeline) > mov esi, 8 [eax] > mov eax, [esi] \ This is the "next" macro > add esi, # 8 > jmp [eax] > end-code If you can, mix "next" macro with the part above. The code might be longer, but it will be faster on the Pentium (no difference on PPro). This is especially of value for non-control flow operations, since they don't use IP or W (eax in your case). So you can fill the three penalties above with other useful instructions. [...] > FORTH nest: 7 FORTH nest, corrected: 5 > FORTH unnest: 6 > C entry: 5 > C exit: 6 -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: indirect vs. subroutine threading (Was: Hang on, isn't Forth out of date now?) Date: Sat, 17 Aug 1996 19:01:45 +0200 Message-ID: <3215FAF9.52FD6C0@informatik.tu-muenchen.de> References: <320a20a0.0@news.cranfield.ac.uk> <4uo7i3$8oa@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Stephen J Bevan wrote: > It may sound wierd but I'm more interested in the actual (generated) > assembly code than the timings. For example, the ARM doesn't appear > to have any load delay or branch delay (otherwise the two instructions > for NEXT that Simon posted would need at least two nops) whereas the > chips I'm mainly interested in (MIPS/SPARC/ALPHA) have either one or > both features. MIPS has load and branch delay slot (in fact, only R3000 requires a nop in the load delay slot). SPARC has branch delay slots, and ALPHA has neither load nor branch delay slot (in the sense that it requires nops there). However, Alpha certainly has load delays, so you can (and should) insert instructions between the load instruction and that instruction that makes use of the loaded value. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: Objects for ANS Forth Date: Sat, 17 Aug 1996 21:25:56 +0200 Message-ID: <32161CC4.513B399F@informatik.tu-muenchen.de> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Brad Rodriguez wrote: > > Andrew McKewan wrote: > > I would like to promote this model as a standard for object-oriented > > programming in Forth. I believe it to be quite a complete model with > > a clean syntax and good performance. > > Yes, let us PLEASE at least standardize a syntax for object-oriented > Forth. I recently did a survey of 17 OOFs and couldn't find any > agreement at all, and we'll need this to be competitive. Yep. The main difference I find between OOFs is the order of method passing. Some use "method object", others use "object method". I prefer the second, because it allows (enforces) active parsing of the method. To preserve the implementation freedom, we should agree that all object-parsing must happen in the same line (thus either FIND patching, or BL WORD FIND in the class word works). Because variables and words are handled equal in Forth, they should be handled equal in OOF objects, too. Thus both shall be available through the same method passing mechanism. Inheritance: the only standard way should be single inheritance. This is easy enough to implement and fastest, anyway. Whoever wants to implement multiple inheritence can do it however he wants. Method types: I found at least three different method types important: Variables: they are private storage space for each class instantiation. A variable should return the address of storage place. Declaration can be handled with one standard word, taking the size of the variable space. Fixed size variables can be always implemented using this standard variable declaration word. Object pointers: a variable that contains another object. This method itself parses the input string and applies the next method to the object it points to. Object pointer can be set with BIND , addresses can be optained with LINK (or whatever you find appropriate). (virtual) Methods: a pice of code that executes in the context of the object. All methods can be referred without a leading object, or as "self" reference (whatever you like, we can discuss this). These three method types I find essential. The two further types I use are early bound methods that can't be changed through inheritance, and object instance variables, thus objects that are part of another object. The latter isn't really important, since object pointers can do the same. A nice thing to have is a deferred method, thus a method that is executed through a pointer in the instance data, not in the class-wide data. It's not necessary, though. Declaration and implementation: Many object oriented languages I know separate declaration and implementation of methods. Because methods can be implemented more than one time (due to inheritance and overriding), I think this is good for a OOF, too. I think it's good to restrict the syntax so that it's only possible to first declare things of a new class, and then (immediately following) implement methods. I use class how: class; and each class is some sort of object, too (so "class" is a method). IMHO this is elegant, because it allows all sorts of object handling (thus instance generation, object accesses and other things) to be handled by methods. Thus all classes inherits basic handling form one class, I call it "object". Initialization/destruction: Objects may be created dynamically. I think it's good to have a method for this, called "new". The destruction happens with "dispose". In my system, new calls "init" for the object itself and every embedded object in declaration order. The second class of objects are persistent objects, which have a name. I create them with the method ":", but other names are welcome, too. I have creation of array objects (with new[] or [] ) and object pointers (with ptr ), too. Private/protected/public: This distinction should be optional. Thus everything is public (accessible through the method passing system, inheritable and changeable through inheritance) by default. I think we can find a common syntax with this approach. One thing we never can do is to unify the "method object" and the "object method" approach - this is impossible. The main rationale I have for "object method" in a standardized approach is that it is always possible to turn the "method object" approach round with just adding the parser to "object", while the other way round is very difficult. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: subroutines that return variable #'s of results Date: Sat, 17 Aug 1996 21:30:19 +0200 Message-ID: <32161DCB.6E47C02A@informatik.tu-muenchen.de> References: <4usvuk$1tu@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.12 i486) Anton Ertl wrote: > > In article , jvn@faraday.clas.Virginia.EDU (Julian V. Noble) writes: > |> The difficulties arising from variable numbers of return > |> values are not restricted to Forth. If memory serves, C > |> permits functions that return variable numbers of results. > > No. It permits functions with a variable number of arguments. Typical > C calling conventions ensure that passing more arguments than > necessary does not cause trouble. As C returns additional values through pointers in the calling arguments (uh, uh), it's possible to give a variable number of pointers. scanf uses this approach. If you don't specify enough addresses, the program will crash horrible (GCC has -Wall, the others could use lint). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: ehp@ear.co.at (Ewald Pfau) Subject: Objects for ANS Forth Message-ID: <840414075.AA00428@ear.co.at> Date: Mon, 19 Aug 1996 01:27:15 +0100 X-FTN-To: Bernd Paysan Bernd Paysan wrote: BP> Yep. The main difference I find between OOFs is the order of method BP> passing. Some use "method object", others use "object method". This is not just swapping the sequence. A bit more extended wording shows the more versatile scope, if Forth meets syntax: Add a stack comment after each nomination of a name. For "Message Object" this is not possible, since "Object" has to be parsed at compile time. For "Object Message", you may have a parameter in between. So it may as well read: "Object [ -- parameter ] .. .. [ parameter -- ] Message". (Did I miss something that I'd be wrong and it really should read "Method" here? - 'the method' is just only the special instance which is applied; by reading a source text, you will find the name of 'the message'.) BP> prefer the second, because it allows (enforces) active parsing of BP> the method. To preserve the implementation freedom, we should agree BP> that all object-parsing must happen in the same line (thus either BP> FIND patching, or BL WORD FIND in the class word works). The 'inline' approach expects a reading like "count the apples". With RPN reading, it is legitimate to underline the action involved: "Here are apples. Let's count them" (many non-Forthers and some Forthers sometimes as well, have a problem here, with reading the abbreviation of this: "Apples Count" :) ). But now we are back at very common Forth level handling. Why should the object be on the same line? If the inline syntax reading is gone, so there is no need for it. As I could see, the ported Yerk approach uses names ending in colons to indicate the message, as "Count: Apples". If swapped, there is no such syntactical writing needed (it cuts down to cosmetics for reading: "Apples Is-Counted"). We are either more back on a common Forth level. Say, if a parameter describes a record containg fields to be derived from that parameter, so we have exactly the same without ever needing to mention the doubled "oh" :). The game should be such one about encapsulating data. But we have already this perfect encapsulation, by dynamic and anonymous stack handling: A-Data B-Data C-Data C-Action B-Action A-Action. It is RPN, and this is its strength here. If someone can read RPN, so the binding of objects to methods, A, B, C, is straight-on and clear. I would much more underline the "classes building technique" instead of the "object orientation". Since _this_ is what seems to me to come in nice into the Forth environment. Both meet at the point, where messages are bound to methods by reference to classes. To apply bound messages to data, to objects, is straight-on trivial in this context. References to data float around all the time anyway. What comes in as being new, is as well an ambiguity of "the message" regarding the data it is related to. Now this is stack parameters being references: to arrays and records, and, now as well, to data groups holding binding information (if not binding information is as well stack data). I think, to have the latter one as well, were useful to the full bandwidth of Forth programming, preferrably if not just a new playground came along. The strength of both comes in, if they are combinable: introduce data structures as before. Write methods for them as well with a fixed meaning (as before), as well methods with the mechanical behaviour being floating. An example as I had it in use (and combined both approaches): - Have a descriptor block for records file handling. - Have inside of it each a "classes" cell for each field of the records. - Introduce messages, to apply for the fields. - Bind methods to the messages, by use of the descriptor block. - Write the fields access partly in terms of messages. The data structure of the descriptor block itself has nothing to do with double-plussed programming. But it is used to introduce classes binding for a partial aspect of its use. By this, another descriptor block still may be used in parallel, re-using as well the methods, even if representing a quite different use of the file-records. I would never have introduced a "full OO package" for this. This would have urged me to use that technique were it is not of adavantage. Only by tight combination, the benefit was there. From: jwillard44@aol.com (JWillard44) Subject: Re: x Date: 5 Aug 1996 14:27:15 -0400 Message-ID: <4u5ee3$671@newsbf02.news.aol.com> References: Reply-To: jwillard44@aol.com (JWillard44) wrote: > x y? From: mikeh@zeta.org.au (Michael Hore) Subject: Re: Objects for ANS Forth Date: 19 Aug 1996 13:57:18 +1000 Message-ID: <4v8omu$ou7@godzilla.zeta.org.au> pai1@ix.netcom.com(Lloyd Prentice ) writes: >David N. Williams wrote... > >> What I'm adovcating is that a Forth standard should maximize the >> possibilities for interacting with mainline class/object resources. > >Yes! Yes! Yes! > >Who will show the way? Ummm... I don't know if I can... I have here a copy of the SOM/CORBA spec - it's almost 500 pages, and rather daunting. I find myself wondering, is anybody actually going to use this stuff? But I suppose they will, indirectly. That is, they'll use OpenDoc or whatever, which is based on SOM. So they'll write to an API that uses SOM behind the scenes. Anyway over the next couple of weeks I'll see if I can get my mind around some of this, and maybe then I'll be able to come up with some words of wisdom (?) Cheers, Mike. ---------------------------------------------------------- Mike Hore mikeh@zeta.org.au ---------------------------------------------------------- From: mikeh@zeta.org.au (Michael Hore) Subject: Re: Objects for ANS Forth Date: 19 Aug 1996 13:58:09 +1000 Message-ID: <4v8ooh$ovo@godzilla.zeta.org.au> anton@a0.complang.tuwien.ac.at (Anton Ertl) writes: >In article <3211CD2B.2878@headwaters.com>, Brad Rodriguez > writes: >|> Yes, let us PLEASE at least standardize a syntax for object-oriented >|> Forth. > >|> But let's distinguish between syntax and implementation. (Architecture >|> vs. organization?) > >(It's architecture vs. implementation/realization, at least in the >computer architecture field.) > >This may not be completely possible (I have not looked closely on the >Neon syntax in this respect, though). The syntax and semantics of such >a wordset would prescribe certain implementation decisions; e.g., I >think the Neon syntax makes it necessary to use FIND (or generally, >half of a text interpreter) in the implementation, which I find ugly. Not really - or not quite... In Neon and Mops, selectors and instance variable names are hashed to 32-bit (cell) values. The regular FIND isn't used for these, since the lookup process is a lot simpler, basically just a loop which follows a link and compares two cells. There's no text string handling involved. So none of the text interpreter is needed at run time - just this special lookup word. >... >So, I think the way to get a standard OO syntax for Forth is to write >a class library for it. The 17 other syntaxes will fall into disuse. >No need for a standards committe for that one. Agreed. After all, it works for Micro$oft. :-) Cheers, Mike. ---------------------------------------------------------- Mike Hore mikeh@zeta.org.au ---------------------------------------------------------- From: kb7nmu@olywa.net (J Christopher Kennedy) Subject: Wanted: Forth for OS/2 Message-ID: Date: Mon, 19 Aug 1996 07:00:23 GMT Reply-To: kb7nmu@olywa.net I am very interested in finding a Forth for use under OS/2. I already have PFE, and Forth/2. Both appear to be stagnant. I am willing to pay for a profesional solution, if one exists. What I want is a Forth system that can run ANS standard programs (but perhaps it itself is not ANS standard), takes full advantage of OS/2 (eg. multi-threading, sytem API calls, etc), and ideally, have the potential to create Presentation Manager programs (PM is the GUI method used by OS/2). Also, I should be able to generate SOM compliant objects, as SOM is the standard object model for OS/2. The ability to compile stand-alone executables would also be appreciated. A fancy developement environment (IDE, resource editors, etc.) is not required, but would be appreciated. IF you know of such a system, or am willing to make one available (preferably in the under $300USD range), please either post to this newsgroup, or respond via email. I want this for my own personal use. As any language for OS/2 will cost in the under $300USD range, no matter whether it is C, C++, or Modula-2 I am willing to pay up to $300USD for such a Forth system. Thank you for your time. J Christopher Kennedy kb7nmu@olywa.net From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: multiple values Date: Mon, 19 Aug 1996 07:31:54 GMT Message-ID: <4v95bj$pbn@news.NL.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> <4v26ic$gq5@news3.digex.net> Reply-To: hbezemer@vsngroep.nl matt@access5.digex.net (Matt Lawrence) wrote: >Paul E. Bennett (peb@transcontech.co.uk) wrote: >: In article <4uqv9c$b8g@news.NL.net> hbezemer@vsngroep.nl "Hans Bezemer" writes: >: >: > I don't know any C- >: > functions that sometimes return a value and sometimes not. And if they do >: > they are BAD news. >: >: In C they are but in Forth, with consideration, they are not. >Well, I thought about it a bit before writing this. There are a number of >C functions that return more than one value. Look at many of the I/O >routines, they return the number of bytes transferred and an error code in >"errno". If there wasn't an error, the value of errno may be undefined. >In Forth, you can just leave the extra value on the stack to do further >processing with, while in C you have to save it away to prevent any >further code from stomping on it. We're talking about stack effects. If in fact, a Forth word returned the (optional) parameters in variables, I would not put up an argument, sice the stack effects would be the same -- just a flag. In fact, most error-situations in C can be evaluated without errno. In the I/O routines you just have to compare the number of bytes actually written or read against the number you wanted to read or write. errno is just there for additional information. That means: in C the stack is always balanced. I would have found the va_ routines a much better example. There you can have multiple input parameters. I do not know many Forth words that allow this. Hans. From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: interfaces (was Re: multiple values) Date: 19 Aug 1996 08:33:31 GMT Message-ID: <4v98sr$ipc@dfw-ixnews6.ix.netcom.com> References: <40.10697.1617@channel1.com> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> <32144D48.5CAD@forth.com> <4v2utp$jvh@gerd.cs.cornell.edu> <321604B8.3DB2@cs.cornell.edu> X-NETCOM-Date: Mon Aug 19 3:33:31 AM CDT 1996 In <321604B8.3DB2@cs.cornell.edu> Greg Morrisett writes: >Elizabeth Rather wrote: >>My experience is that there are a lot of legitimate things I want to >>do that "strong typing" would prevent. Examples: fetch a keystroke, >>subtract an offset (( char n -), clearly illegal!) and use the result >>to index into an array; >Works great until you move to an NT system which uses unicode instead >of ASCII. In general, confusing abstractions just because the >representations "happen" to match leads to many problems porting >code. (Witness all the problems with people assuming int is 16 >or 32 bits now that we have 64 bit machines.) Sometimes it makes sense to get it running now, and handle the porting problems when you need to port it. If you never need to port this particular code to a particular system, then all the time you put into dealing with that level of portability is wasted. It's a tradeoff. If you save an hour now, and it costs you an hour 3 years from now when you have to port it, you do better to spend the hour later. This year's hours are more valuable than later years' hours -- not least because you might die this year. But also you get paid for this year's project this year, and work done now on year-2002 projects won't get paid for some time. But what if an hour now saves 10 hours next year? Somehow you have to guess at the payoffs and work to fit them. And you need to factor in how much the customer values maintainability. Suppose you could say, "Here's one way we can do it, it will port to any architecture unchanged and benefit from whatever capabilities the new system provides, and programmers with minimal training will be able to maintain it forever. It will cost $X over i months. Here's another way we can do it, we'll be able to keep patching it for 5 years on this list ( ... ) of systems, and by that time you'll need a major rewrite. It will cost $Y over j months." At what ratio of X:Y would they switch? It's an academic question since we're going out on a limb on all guarantees. Anyway, when you design for one system you can test it and see what you get. When you design to be maximally portable, you can't. You can port to a few representative systems. Beyond that you follow rules; you hope you're following the rules correctly; you hope the rule-checkers you use work correctly; you hope the rules are correct; and you hope the later systems will follow the rules. When you design to be maximally maintainable, it's even worse. Instead of writing for unknown computer systems, you're writing for unknown programmers. How do you tell how well you're doing? If your product is wildly successful, the code might wind up being maintained by people who haven't been born yet. How can you know what they'll understand easily? Then there's the opposite possibility; the product might bomb. Your careful work could be wasted. "If it isn't worth doing at all, then it isn't worth doing well." Sometimes, to some extent, it makes great sense to program for today. When and how much is an unsolved question. >And of course, providing a char2int conversion is no great difficulty. >On machines where char and int have the same representation, you pay >no performance cost and get the added benefit of not accidentally >treating char and int as the same. The limiting resource is always your ability to think and put it all together, in the available time. When extra rules help you, they're good. When they slow you down they're bad. It's a hard thing to predict. To really test it, you need to take the same problem and solve it both ways, and see which is faster. Ideally you should do it the first time with each method, instead of first one and then the other. 8-) From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: multiple values Date: 19 Aug 1996 10:39:25 GMT Message-ID: <4v9g8t$m6p@hkusuc.hku.hk> References: <40.10697.1617@channel1.com> <320F15C8.749D@forth.com> <4upa55$c5i@hkusuc.hku.hk> <3215CBD1.3B8B9340@informatik.tu-muenchen.de> Bernd Paysan (paysan@informatik.tu-muenchen.de) wrote: >Zsoter Andras wrote: >> >> Elizabeth Rather (erather@forth.com) wrote: >> >> >I'm sorry you found your experience with Forth so unfortunate. You don't >> >mention what version you used or -- more importantly, in this case -- how >> >you learned Forth (e.g., from some of the good books on the subject, from >> >user documentation with your system, from experienced Forth programmers, >> >or on your own without help). >> >> Well, I have learned Forth on my own (with a book with some not quite >> well written examples) and it really took longer than to learn almost >> any other language. >Looks more like a fault of the book than yours. I learned Forth with >_the_ book (Brodie), and I learned it faster than my first langugae ^^^^^^^^^^^^^^^^^^^ A bit of mystification. ;-) >(which was Logo, the toy language for children). I guess it would have >been harder, if my first language was BASIC. To some extent, Logo is >just polish notated Forth, except that it hasn't swoperators, but local >variables. Well, I played with Logo, but I have found it unnatural (really a toy, not a serious language). First I have learned BASIC, which took me some time, but after that most languages looked the same. [Well, if you think about it C and Pascal are just fancy versions of FORTRAN (a kind of FORTRAN++ ;-) and BASIC is like FORTRAN so I could grasp that immediately. Forth, on the other hand, is an entirely different thing.] Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Objects for ANS Forth Date: 19 Aug 1996 11:07:18 GMT Message-ID: <4v9ht6$m6p@hkusuc.hku.hk> Well, this thread is interesting. ;-) As for the "object method" and "method object" cathegories, there is my (Dyn)OOF (the new release is on taygeta and it is called dynoof for the sake of German speakers) which is in fact a third cathegory. Here the "object" has to be activated by a word (I like to refer to it as a case-ending, although in Forth, of course, it is written as a separate word) "{". So it is not the position, it is the "case" which determines the object, anything after that (methods, and fields [ = variable-methods by Brend Paysan] are related to the object such activated. So the following lines are all valid: Object1 2 3 + SWAP { Method1 . Object1 { 4 5 * Method1 . : BAR Method1 ; : FOO Object1 O! ; ( Cannot be "{", see below. ) FOO BAR : Jack { Method1 } ; Object1 Jack ObjectPtr1 @ Jack (Of course because "{" saves the previously active object to the return stack the first two lines should end in a "}" to remove that object.) The other important point is, that if someone likes late binding via FIND (I don't, it is way toooo slooooow), in (Dyn)OOF there is a way to have as many interpreters in the same time as one wishes. In fact every vocabulary (and wordlist) is an object of the class hierachy Vocabularies, and they have a method for interpreting a number and another one for interpreting a "word". The interpreter automatically uses those methods once a vocabulary is active (~~at the top of the search order), so one can have vocabularies with different rules [e.g. different rules for case sensitivity, or some expression evaluation can be added]. Andras From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multiple values Date: 19 Aug 1996 08:53:38 GMT Message-ID: <4v9a2i$av@dfw-ixnews5.ix.netcom.com> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> X-NETCOM-Date: Mon Aug 19 3:53:38 AM CDT 1996 In <32164C9F.179F@inlink.com> Bill Zimmerly writes: >As a matter of principle, I avoid using words that exhibit >this behavior (like ?DUP) since I abhor words that express >what I like to call "funny" stacks. I see them as being the >functional equivalent of multiple entry points since they >leave it up to subsequent branches to clean up the mess that >they've introduced. I prefer that the cleanup be done WITHIN >the appropriate followup branch RATHER than before the branch >occurs and unnecessarily forces the stack diagram to report >it's alternate behaviors. I just don't like diagrams like >this... > ( n -- d | 0 false | 1 a l true -- ) \ etc. >...instead prefering nothing more complicated than a before >and after effect... > ( a -- a+1 len ) OK. Right off I remember 2 examples from the Standard, ?DUP and SEARCH-WORDLIST . I find ?DUP useful in the following situation: ... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... For example, looking at a threaded list item and quitting if it's zero. ?DUP gives a nice clean result. You could do it this way: ... DO-SOMETHING? ( addr|0 ) DUP IF DO-IT ELSE DROP THEN ... and what does it really get you? Or you could do: ... DO-SOMETHING? ( addr flag ) DUP IF DO-IT ELSE DROP THEN ... which is even worse. But it might be clearer for some people, which is worth careful consideration. Anyway, the word that the above fragment was embedded in wouldn't have a funny stack diagram because the divergent stack would be all healed up before the end. The trouble with the line "Do it my way because it's the way I understand it best" is that this argument works best for C programmers. The trouble with the line "I'm doing it the most elegant way so study my code and learn wisdom" is that such code is likely to get rewritten instead of understood. I wish I knew how to resolve this. But these aren't the only two simultaneous constraints.... From: Brad Rodriguez Subject: Re: Objects for ANS Forth Date: Mon, 19 Aug 1996 08:51:46 -0700 Message-ID: <32188D92.4B5C@headwaters.com> References: <4v0b2g$p1r@godzilla.zeta.org.au> <3215D918.3C79@paisley.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Peter J Knaggs wrote: > Well, we had a working group at euroFORTH '95 on just this topic. > Len Zettel has the notes. Yes! I just found those notes. They appeared in SIGPlan Notices 31:4 (April 1996), along with my survey article of OOFs. -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Ken Staton Subject: PIC Forth? Date: 19 Aug 1996 15:48:42 GMT Message-ID: <4va2cq$2qu@hplms2.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.05 9000/735) X-URL: news:comp.lang.forth I'm looking for a Forth implementation on Microchip PIC processors. From: Brad Rodriguez Subject: Re: Help to start 8031 forth Date: Tue, 06 Aug 1996 08:26:10 -0700 Message-ID: <32076412.3C97@headwaters.com> References: <3207D2D6.778@nyp.ac.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) To: David Pau David Pau wrote: > I'll appreaciate help to design a 8051 single board computer that will work with Forth, > and help to get started in Forth programming for 8051 using Forth by Payne. There is one important hardware feature which you will need for most 8051 Forths: you must have some writable RAM in the Program memory space. Since the 8051 can't write to Program space, this means you'll have to have some RAM appear in BOTH the Program and Data spaces. This can be done most easily by ANDing the signals PSEN\ and RD\, and using this as the read signal to your RAM chip. (This modification to a Blue Ridge Micros 8051 board was published in The Computer Journal #71.) Note that if you only had one ROM and one RAM, you may now need some address decoding logic. Sorry, I haven't used Payne's 8051 Forth, so I can't offer any software advice. -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent -- inquire within. Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Elizabeth Rather Subject: Re: multiple entries Date: Mon, 19 Aug 1996 11:22:41 +0000 Message-ID: <32184E81.23F9@forth.com> References: <4ud5e1$1so@news.tuwien.ac.at> <4udtm5$t99@unlisys.unlisys.net> <4uo5ae$8oa@news.tuwien.ac.at> <4usigc$fkr@ns2.ryerson.ca> Reply-To: erather@forth.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Macintosh; U; PPC) John Verne - CNED/F94 wrote: > > Anton Ertl (anton@a0.complang.tuwien.ac.at) said: > : In article <4udtm5$t99@unlisys.unlisys.net>, phpr@berlin.snafu.de wrote: > : |> >a compiler could apply tail call elimination (i.e., convert the > : |> >call/EXIT at the end of draw-sprite-16x16 into a jump) and jump > : |> >optimization, resulting in code corresponding to your assembly code > : |> >(well the compiler would have to use good register allocation, too). > : |> > : |> >Of course such a good Forth compiler has yet to be written:-) > : |> Which was already done, a couple of years ago, and is not difficult, > : |> anyway, even with a threaded code (token) compiler. > > : Care to name it? > > : znmeb@plaza.ds.adp.com mailed me that he thinks hforth does it. Our compilers for the Novix and RTX families did it 10 yrs ago, and some of our systems (e.g., our Europay Open Terminal Architecture kernels) do today. > My understanding of the inner workings, and differences between, various > compilers is limited, to say the least. I do understand that one of the > most attractive things about this, is that there is no (little?) penalty > for "empty" words. i.e. CHARS and CELLS (instead of 2*) can be used with no > interpretation penalty. Correct. -- 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://www.forth.com From: dibald@netcom.com (Dave Baldwin) Subject: Re: Faster than assembler (Was: Hang on, isn't Forth out of date now?) Message-ID: References: <320C74D6.7BEA@headwaters.com> <4va8nb$28q@news.tuwien.ac.at> Date: Mon, 19 Aug 1996 20:00:35 GMT Anton Ertl (anton@a0.complang.tuwien.ac.at) wrote: : There is another way how Forth can be faster than assembler: If the : Forth code is smaller than machine language (or just has better : caching characteristics), it can be faster simply by having fewer : cache misses. You keep assuming the Forth programmer is better than the ASM programmer. -- -=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=- Dave Baldwin: dibald@netcom.com | The Computer Journal 1(800)424-8825 DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/" Voice : (916) 722-3877 | Hands-on hardware and software TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480 -=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=- From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Mon, 19 Aug 1996 10:26:34 -0500 Message-ID: <321887AA.7BDC@austin.finnigan.com> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Marcel Hendrix wrote: > Trying out TEST.FTH and TESTER.FTH (ftp-ed from the site > Andrew McKewan mentioned) presented some unexpected problems > with CLASS.FTH. > > All but one of them have to do with the fact that the files have > lines wrapped at unconvenient locations (changing their > meaning to a Forth interpreter). I give the corrections below. > The original "->" overwrote every cell available to iForth. I have checked the files again and I don't see this problem. I think they must have been damaged when you downloaded them. > The serious problem is that when a method name is chosen that is > already the name of an existing Forth word, the code for the new > method is not generated (or not findable). Instead, the original > Forth word executes whenever you try to use the presumed method. > > In my Forth the word Exec: already exists, that's how I found out. > Try : Put: CR ." Oeps." ; and load class.fth to see what will happen. > > I think this is a problem that should be removed, or at least > flagged with an error message. Yes, this can be a problem. Here are some possible soutions: 1. Explicitly define the selectors that conflict with existing Forth words, e.g. Selector Exec: 2. Have a way for the system to not only see if a word has been defined, but is really a selector. This can be done by either compiling a special tag into the selector pfa (wasting some space and not foolproof) or just seeing if the selector has been defined after ClassInit: a) : ?Selector ( pfa -- f ) @ selectorTag = ; b) : ?Selector ( pfa -- f ) ['] ClassInit: >BODY U< 0= ; 3. Just rename the selectors to be different from existing forth words. This would not be usefull if we developed some standard class libraries. Option 1 is the simplest. If you wanted to keep your old word, you could make a synonym or put the class stuff in a separate wordlist. If there is a great need, I will put solution 2 into my implementation. I prefer option 2b. From: Andrew McKewan Subject: Re: Manipulating Return Addresses Date: Mon, 19 Aug 1996 10:42:57 -0500 Message-ID: <32188B81.7F69@austin.finnigan.com> References: <4ud4bb$8v@news.tuwien.ac.at> <4uo9at$8oa@news.tuwien.ac.at> <79eBCOA0oMEyEwUY@apvpeter.demon.co.uk> <4v24v9$ck@news.tuwien.ac.at> <32171EFD.1776@headwaters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Brad Rodriguez wrote: > > > |> That's it exactly. You might consider the more efficient: > > |> > > |> : RADrop S" R> DROP" EVALUATE ; IMMEDIATE > > Is EVALUATE guaranteed to leave nothing on the return stack while it > executes? Looking at the standard, no mention is made of the return stack. But since we are compiling, "R> DROP" should have no effect on either stack. -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Objects for ANS Forth Date: 19 Aug 1996 21:07:19 +0200 Message-ID: <4vae17$29f@iaehv.IAEhv.nl> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <321887AA.7BDC@austin.finnigan.com> David N. Williams wrote Re: Objects for ANS Forth > Marcel Hendrix wrote: [..] >> All but one of them have to do with the fact that the files have >> lines wrapped at unconvenient locations (changing their >> meaning to a Forth interpreter). I give the corrections below. [..] > There was nothing like this in the files I got from > ftp.netcom.com/pub/mc/mckewan. Have they been fixed? I told my browser (MIE 2.0) to save the two text files, not get the .zip file. I cannot deduce from your post if you got the .zip or the texts. If you got the .zip, there is no discrepancy. (Until somebody reports they work fine on his ANS system). If you got the text files, I have one other program to disgustedly add to the 'broken toy' heap (founded by micro-emacs and notepad32). > The file test.4th works fine on my system in ANS compatibility mode. I > haven't yet checked the name conflict problem Marcel brings up. Please do. It probably can be fixed with SEARCH-WORDLIST . > By the way I never succeeded in getting a directory listing for this > site with NetScape, much less a download, with tries on several > different days. I finally did ftp the old way from a UNIX machine. It's a very slow site. I know, I downloaded the latest win32for from it. (sigh..) -marcel From: ouversonm@aol.com (OuversonM) Subject: Re: PIC Forth? Date: 19 Aug 1996 13:12:39 -0400 Message-ID: <4va7a7$s9p@newsbf02.news.aol.com> References: <4va2cq$2qu@hplms2.hpl.hp.com> Reply-To: ouversonm@aol.com (OuversonM) Ken Staton wrote: >I'm looking for a Forth implementation on Microchip PIC >processors. I can refer you to Forth Dimensions magazine, issues 17/3 and 17/4 for an interesting and useful treatment of the subject by respected Forth author and educator Prof. Tim Hendtlass. Back issues of the magazine are available from: Forth Interest Group P.O. Box 2154 Oakland, California 94621 USA telephone: 510-893-6784 fax: 510-535-1295 e-mail: office@forth.org Web home page: http://www.forth.org/fig.html From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Faster than assembler (Was: Hang on, isn't Forth out of date now?) Date: 19 Aug 1996 17:36:43 GMT Message-ID: <4va8nb$28q@news.tuwien.ac.at> References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> There is another way how Forth can be faster than assembler: If the Forth code is smaller than machine language (or just has better caching characteristics), it can be faster simply by having fewer cache misses. Currently this is pretty theoretical, but as the processor/memory speed difference grows, it will get more important. Some people argue that we will see a memory wall, where the execution time will be determined by the number of memory accesses. - 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: Tom Zimmer Subject: Re: Wanted: Forth for OS/2 Date: Mon, 19 Aug 1996 15:26:44 -0500 Message-ID: <3218CE04.5A60@austin.finnigan.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) J Christopher Kennedy wrote: > > I am very interested in finding a Forth for use under OS/2. I already have > PFE, and Forth/2. Both appear to be stagnant. I am willing to pay for a > profesional solution, if one exists. What I want is a Forth system that > can run ANS standard programs (but perhaps it itself is not ANS standard), > takes full advantage of OS/2 (eg. multi-threading, sytem API calls, etc), > and ideally, have the potential to create Presentation Manager programs > (PM is the GUI method used by OS/2). Also, I should be able to generate > SOM compliant objects, as SOM is the standard object model for OS/2. > The ability to compile stand-alone executables would also be appreciated. > > A fancy developement environment (IDE, resource editors, etc.) is not > required, but would be appreciated. IF you know of such a system, or > am willing to make one available (preferably in the under $300USD range), > please either post to this newsgroup, or respond via email. > > I want this for my own personal use. As any language for OS/2 will cost > in the under $300USD range, no matter whether it is C, C++, or Modula-2 > I am willing to pay up to $300USD for such a Forth system. Thank you for > your time. Win32Forth runs under Win32s. I know thats not what you want, but if you are interested in porting it to run under the OS/2 API, it might be simpler than starting from scratch. Actually it would be a _lot_ simpler than starting from scratch. I looked at the Presentation manager docs at one point, and they are similar to Windows, but not the same. If you are _very_ familiar with the OS/2 API, it might be worth a shot. There is at least one forth that I found (can't remember the name), that ran as a console application (no graphics). I'm sure you can find it on one of the OS/2 software sites. Tom Zimmer From: pfrenger@ix.netcom.com(Paul Frenger) Subject: Re: Hang on, isn't Forth out of date now? Date: 20 Aug 1996 01:29:01 GMT Message-ID: <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com> References: X-NETCOM-Date: Mon Aug 19 8:29:01 PM CDT 1996 >Paul Shirley wrote: >>Paul Frenger wrote: >>Will the Forth programmer get his project done first? >>NO CONTEST. >This was *not* my experience in the mid 80's, for the >simple reason that the dominant delay was rebooting the >system after a fatal crash (about 2-4 minutes!) >The editor/assembler/debugger I used was pretty good at >catching fatal memory writes before they did any damage. >The Forth system in contrast was quite easy to crash even >before running the app! Paul, I'm really sorry you had this kind of experience. Let's dissect it a little and find out just what the problem was. First, what kind of system were you using? Mid-80's might be an early PC (8088/8086), or an Apple II (6502), or a CP/M machine (8080/Z80), or even an old Macintosh (68000). All of these had Forths available then. Clock speeds weren't impressive (ie: 4.77 MHz 8088 for the PC), and you likely were using a floppy-only system. Second, whose Forth did you use? Probably not polyForth (a commercial product: quite good but in the $3000 range). Was likely to be Fig-Forth, which was a good starting point but not very stable for most platforms (it required customizing). There were some good, inexpensive PD products (MVP-Forth, $25) and commercial ones too (LMI Forth, about $150). Forth has come a long way since then. I have used dozens of Forths since 1981 ... some great, some terrible. The usual problem is NOT FORTH but the implementation. Public domain Forths are great for learning but not for commercial projects! You heard it here! Quote me on this. If you can recall the problems you had, and whose Forth it was, I'd be happy to follow up on this point. Paul Frenger, Forth editor ACM Sigplan Notices PS: I think I've heard your name before. Who are you, Paul? From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Help to start 8031 forth Date: 7 Aug 1996 10:05:29 GMT Message-ID: <4u9pp9$5tm@majipoor.cygnus.com> References: <3207D2D6.778@nyp.ac.sg> <32076412.3C97@headwaters.com> <4u93an$13f4@news.goodnet.com> Brad Eckert (di44539@goodnet.com) wrote: : Brad Rodriguez wrote: : [...] : >Since the 8051 can't write to Program space, this means you'll have to : >have some RAM appear in BOTH the Program and Data spaces. This can be : >done most easily by ANDing the signals PSEN\ and RD\, and using this as : >the read signal to your RAM chip. (This modification to a Blue Ridge : >Micros 8051 board was published in The Computer Journal #71.) : > : >Note that if you only had one ROM and one RAM, you may now need some : >address decoding logic. : [...] : Actually, you don't have to AND PSEN\ and RD\ if you only read from : memory using MOVC (not MOVX). RD\ isn't even used. All of my 8051 : designs use this trick. You can usually use a single inverter for : address decoding, with A15 driving the ROM CS\ and A15\ driving the RAM : CS\. The maximum size of both devices is then 32 kbytes each. The 8K : static RAMs (6264s, etc.) have an extra chip select that is active high, : which would let you omit the inverter. : So, you could do away with glue logic if you put the ROM at 0000..7FFF : and the RAM at 8000..9FFF and implemented fetch instructions using MOVC. But that means that you can't interactively test CODE definitions! Given that the 8051's internal IO all has to be driven by using directly addressed MOV instructions that isn't going to be much fun. Andrew. From: japs@netcom.com (Jim Schneider) Subject: Re: Hang on, isn't Forth out of date now? Message-ID: References: <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> Date: Mon, 19 Aug 1996 19:53:01 GMT In article Paul Shirley writes: >In article <4v3k64$d95@sjx-ixn6.ix.netcom.com>, pfrenger@ix.netcom.com >writes >>Will the Forth programmer get his project done first? NO CONTEST. > >This was *not* my experience in the mid 80's, for the simple reason that >the dominant delay was rebooting the system after a fatal crash (about >2-4 minutes!) > >The editor/assembler/debugger I used was pretty good at catching fatal >memory writes before they did any damage. The Forth system in contrast >was quite easy to crash even before running the app! > >-- >Paul Shirley Actually, I find that having a system were a bug crashes the system taught me a *LOT* about how to write programs that don't have that kind of bug... From: ouversonm@aol.com (OuversonM) Subject: Forth Dimensions (vol. 18, no. 3) Date: 19 Aug 1996 16:45:20 -0400 Message-ID: <4vajp0$5g7@newsbf02.news.aol.com> Reply-To: ouversonm@aol.com (OuversonM) The September-October 1996 issue of Forth Dimensions will be arriving soon! It features the following: ========================================================================== == The Elephant Who Refuses to Be Bagged by C.H. Ting When attempting to use a compression algorithm in Forth that had been presented at a conference, the new data presented new challenges. The accompanying code documents the thorny trail of discovery, analysis, and "resolution." 4tH, an Experiment in C by Hans Bezemer 4tH is a different Forth implementation. It contains much of Forth, but is translated to C. Yes, it has two interpreters, but they behave differently. It is token-threaded, but has no dictionary. It is a Forth using conventional compiler technology, but it isn't a standalone compiler -- it is a library. One result: 4tH produces bytecode, like Java, which can be used without any modification on every platform to which is has been ported. Development Aids for New Micros by Richard W. Fergus The author uses popular New Micros products, but wanted to enhance the facilities provided -- to the point that his platform would have a significantly enhanced "feel." He shares how he attacked downloading and terminal emulation, separated RAM variables, Motorola S19 record output, Brodie's MAKE-DOER, multitasking, and a logging function in the terminal emulation mode to copy S19 records. Rochester Forth Conference by Nick Solntseff Canada's first Forth conference presented papers on a wide-ranging variety of contemporary issues. "Rochester-in-Toronto" marked the first time the esteemed Rochester Forth Conference was held outside New York and, as this reporter comments, signs of Forth's vitality were well represented. Stretching Forth by Wil Baden "Breaking Code: Forth Solves 150-year-old Problem" ...in which the author uses Forth to crack the mysteries of a book written in code and printed in the early 1850s. Forthware: Using Forth to Manipulate the Real World by Skip Carter "Digital Input and Synchronous I/O" We turn to the problems and issues involved with getting digital data into our application from the outside world. FIG Board Increases Member Benefits by Elizabeth Rather The Board of Directors of the Forth Interest Group met at the recent Rochester Forth Conference. Major actions included instituting additional benefits for FIG members, clarification of benefits for corporate members, review of Forth Dimensions advertising rates, planning of promotional activities, and review of plans for managing the FIG office and activities. ...and more! ========================================================================== == Forth Dimensions welcomes written contributions on a variety of Forth-related topics. Tutorials, ANS Forth, application stories, and programming techniques are a few general categories of interest. We welcome your contributions -- contact editor@forth.org with your article idea. Thank you! ========================================================================== == If you are not presently a reader of Forth Dimensions, we invite you to subscribe. An on-line "mini-sampler" can be viewed at the Forth Interest Group web page (http://www.forth.org/fig.html). The owner of a popular Silicon Valley computer bookstore called FD "the best special-interest technical magazine ever." Software, Forth texts and tutorials, conference proceedings, and other Forth resources are also available, with a discount to FD subscribers. Contact: Forth Interest Group P.O. Box 2154 Oakland, California 94621 USA telephone: 510-893-6784 fax: 510-535-1295 e-mail: office@forth.org Web home page: http://www.forth.org/fig.html ========================================================================== == From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: interfaces (was Re: multiple values) Date: 20 Aug 1996 05:45:31 GMT Message-ID: <4vbjdr$6uo@sjx-ixn3.ix.netcom.com> References: <40.10697.1617@channel1.com> X-NETCOM-Date: Mon Aug 19 10:45:31 PM PDT 1996 In Paul Shirley writes: >In article <4v98sr$ipc@dfw-ixnews6.ix.netcom.com>, Jonah Thomas > writes >>Sometimes, to some extent, it makes great sense to program for today. >>When and how much is an unsolved question. >My point is really that 'programming for today' and planning for the >future are often less mutually exclusive than most people assume. I completely agree. When you can work toward portability and it costs you very little, there's nothing to lose by doing so. if it turns out later that the things you thought would improve portability actually didn't, that's not too bad -- you didn't have much invested in them anyway. When people find themselves jumping through flaming hoops trying to approach a portability mirage, that's something different. When it _does_ look like an expensive trade-off, then it takes careful thought and some lucky guesses to do well. From: phpr@berlin.snafu.de (H.-Peter Recktenwald) Subject: Re: multiple entries Date: Mon, 19 Aug 1996 01:45:11 GMT Message-ID: <4vb8ot$t5a@unlisys.unlisys.net> References: <4ud5e1$1so@news.tuwien.ac.at> <4udtm5$t99@unlisys.unlisys.net> <4uo5ae$8oa@news.tuwien.ac.at> Reply-To: phpr@berlin.snafu.de anton@a0.complang.tuwien.ac.at (Anton Ertl) wrote: >|> >Of course such a good Forth compiler has yet to be written:-) >|> Which was already done, a couple of years ago, and is not difficult, >|> anyway, even with a threaded code (token) compiler. >Care to name it? Sorry for the late answer, I'd miss that article. BUT (hi, Tom), answer is also a bit peculiar as I'd happen to modify another persons 680xx-compiler (and sent him the result) after I received a very unhappy diskussion due to just some words about that systems performance compared to others. So I leave the name to your supposition. That system compiles native code, where it is very easy for the "return from subroutine"-compiler of "semis" to looking back wether a subroutine call was compiled previously. If so it just modifies that call to a jump instead of additionally compiling the "return". Which also resolves an end-recursion. The same approch can be used with treaded interpretive compilers, where also the words type is to be responded to in an appropriate way. In my current system besides some safety checking I just look for the last word being a colon definition and less than 32K away (64K small memory model) and then, if so, compile a "branch". The above "optimising" may be far from perfect, nevertheless it saves a lot of execution time, dispensing with one nesting level each time a hi-level word is called last in a definition. This is very often the case, and mainly long chains of short hi-level words will be executed considerably faster. The (my) system is a f.i.g.-forth style threaded interpretive compiler with many extensions of the more recent standards (locals, voc-stack etc.) for the kind of very special OS's "QDOS" and "SMSQ" of the Sinclair QL and its derivatives, with the 680xx processors. Anyway, if you (or anyone else) like to see how that got managed I'd like to send you the sources, if I only would know where to. B.t.w. I'm just working (got ready, but didn't check it all) on ANS compliance. Yours Peter - phpr@berlin.snafu.de - .hpr - From: Paul Shirley Subject: Re: interfaces (was Re: multiple values) Date: Mon, 19 Aug 1996 21:23:12 +0100 Message-ID: References: <40.10697.1617@channel1.com> <4uvhlf$mch@dfw-ixnews6.ix.netcom.com> <4v24hb$3ei@map.mda.ca> <32144D48.5CAD@forth.com> <4v2utp$jvh@gerd.cs.cornell.edu> <321604B8.3DB2@cs.cornell.edu> <4v98sr$ipc@dfw-ixnews6.ix.netcom.com> Mime-Version: 1.0 In article <4v98sr$ipc@dfw-ixnews6.ix.netcom.com>, Jonah Thomas writes > >Sometimes it makes sense to get it running now, and handle the porting >problems when you need to port it. If you never need to port this >particular code to a particular system, then all the time you put into >dealing with that level of portability is wasted. It always makes sense to choose the portable route if it costs no more than the 'quick' way. What is the cost of portable code? 1: It may be less efficient, if thats important then it will be important in any port later so do it the quick way. 2: It takes longer to code. I would bet (2) is the reason so few people attempt any sort of defensive programming. However its largely a myth. Portable/robust code is *not* inherently much harder to write (if at all), for most people it ends up taking longer because they rarely do it. Do it all the time and the 'cost' soon falls. >It's a tradeoff. If you save an hour now, and it costs you an hour 3 >years from now when you have to port it, you do better to spend the hour >later. This year's hours are more valuable than later years' hours -- >not least because you might die this year. But also you get paid for >this year's project this year, and work done now on year-2002 projects >won't get paid for some time. ...however if cost now is negligible? >Anyway, when you design for one system you can test it and see what you >get. When you design to be maximally portable, you can't. You can port >to a few representative systems. Beyond that you follow rules; you hope >you're following the rules correctly; you hope the rule-checkers you use >work correctly; you hope the rules are correct; and you hope the later >systems will follow the rules. As long as you get it mostly right, someone else (or you) can get it totally right if or when needed with significantly less effort. There's no point trying to predict all possibilities, equally there's no point in avoiding simple, cheap things because they might not be needed. >Sometimes, to some extent, it makes great sense to program for today. >When and how much is an unsolved question. My point is really that 'programming for today' and planning for the future are often less mutually exclusive than most people assume. -- Paul Shirley From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Objects for ANS Forth Date: 19 Aug 1996 23:11:42 +0200 Message-ID: <4valae$k3t@iaehv.IAEhv.nl> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <321887AA.7BDC@austin.finnigan.com> Andrew McKewan wrote Re: Objects for ANS Forth > Marcel Hendrix wrote: [ problem with line feeds in TEST(ER).FTH ] > I have checked the files again and I don't see this problem. I think > they must have been damaged when you downloaded them. Okay (exit MIE). [ selectors not getting defined when Forth word with same name exists ] > Yes, this can be a problem. Here are some possible soutions: > > 1. Explicitly define the selectors that conflict with existing Forth > words, e.g. > > Selector Exec: > If you know there is a conflict, there is no problem. In practice Selector must then be used always. Maybe it is not bad to be so explicit? > 2. Have a way for the system to not only see if a word has been defined, > but is really a selector. This can be done by either compiling a special > tag into the selector pfa (wasting some space and not foolproof) or just > seeing if the selector has been defined after ClassInit: > > a) : ?Selector ( pfa -- f ) @ selectorTag = ; > > b) : ?Selector ( pfa -- f ) ['] ClassInit: >BODY U< 0= ; > A transputer has signed addresses (from $80000000 to $7FFFFFFF), so b) won't work on it (don't know any other CPU that has this "feature"). Also, I guess there exist 'heap Forths' where code can be moved around freely (Jupiter Ace, Fcode???). > 3. Just rename the selectors to be different from existing forth words. > This would not be usefull if we developed some standard class libraries. Isn't this too error-prone? When you need to start testing with HAVE Exec: [IF] etc. it is probably better to use Selector right away. > Option 1 is the simplest. If you wanted to keep your old word, you could > make a synonym or put the class stuff in a separate wordlist. To my dismay, I see that a separate wordlist won't work. The selectors must be globally visible, so SEARCH-WORDLIST will only work when the syntax changes from 6 Put: Apples to 6 Apples :Put . I can imagine this is unacceptable to you, and in that case my preference is option 1. > If there is a great need, I will put solution 2 into my implementation. > I prefer option 2b. Well, right now it *is* an invisible implementation problem, but I vote for 1. -marcel From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Help to start 8031 forth Date: 8 Aug 1996 17:22:37 GMT Message-ID: <4ud7ot$786@majipoor.cygnus.com> References: <3207D2D6.778@nyp.ac.sg> <32076412.3C97@headwaters.com> <4u93an$13f4@news.goodnet.com> <4u9pp9$5tm@majipoor.cygnus.com> <320A1D6D.59DD@headwaters.com> Brad Rodriguez (bj@headwaters.com) wrote: : Andrew Haley wrote: : > But that means that you can't interactively test CODE definitions! : > Given that the 8051's internal IO all has to be driven by using : > directly addressed MOV instructions that isn't going to be much fun. : If I understood Brad Eckert correctly, he's proposing to use PSEN\ and : WR\ as the memory read and write strobes, respectively. In this case you : could test CODE definitions. But it means that _every_ data read has to : use the abominable MOVC instruction. Possible, but painful. Oh, I see. Gag. : I believe the original query was how should 8051 hardware be designed to : work with _existing_ Forths. To the best of my knowledge, they all use : MOVX for external RAM, so you'd still want to AND PSEN\ and RD\ in a new : hardware design...for some of your memory space, anyway. I've always used an eprom emulator attached to the parallel port of a PC. Using chipFORTH, which has the dictionary on the host and the actual code on the target, it's possible to download code into an eprom emulator as it's compiled. 8051 chipFORTH was designed to run its code entirely out of an eprom, so all fetches of code (both machine code and threaded code) use PSEN\. To interactively develp code destined for a masked processor, use an eprom emulator with a "piggyback eprom" version of the 8051. That way it's possible to use all of the I/O ports. Andrew. From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Tue, 20 Aug 1996 09:03:06 -0500 Message-ID: <3219C59A.763A@austin.finnigan.com> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <321887AA.7BDC@austin.finnigan.com> <4valae$k3t@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Marcel Hendrix wrote: > > > > b) : ?Selector ( pfa -- f ) ['] ClassInit: >BODY U< 0= ; > > > A transputer has signed addresses (from $80000000 to $7FFFFFFF), so b) won't > work on it (don't know any other CPU that has this "feature"). > Also, I guess there exist 'heap Forths' where code can be moved around > freely (Jupiter Ace, Fcode???). To allow for the transputer, how about: : ?Selector ( pfa -- f ) ['] ClassInit: >BODY HERE WITHIN ; As for "heap Forths" I guess this (b) just won't work there. > > 3. Just rename the selectors to be different from existing forth words. > > This would not be usefull if we developed some standard class libraries. > > Isn't this too error-prone? When you need to start testing with > HAVE Exec: [IF] etc. it is probably better to use Selector right away. > > > Option 1 is the simplest. If you wanted to keep your old word, you could > > make a synonym or put the class stuff in a separate wordlist. > > To my dismay, I see that a separate wordlist won't work. The selectors > must be globally visible, so SEARCH-WORDLIST will only work when the > syntax changes from 6 Put: Apples to 6 Apples :Put . > > I can imagine this is unacceptable to you, and in that case my preference > is option 1. If by "unaccetable" you mean putting wordlists into the implementation, then I kind of agree. I didn't want to have this rely on the vocabulary mechanism (AFAIK neither Yerk or Mops have vocabularies). > > If there is a great need, I will put solution 2 into my implementation. > > I prefer option 2b. > > Well, right now it *is* an invisible implementation problem, but I vote > for 1. In Yerk/Mops you have no choice. FIND is patched to look for selectors first, so even if you defined a word called Exec: you could never find it. But these systems were designed specifically for object-oriented programming. Just enough Forth to bring up the system and provide the low-level implementation of methods. Everything was tailored to objects. Ok, the vote's 2-0 in favor of option 1. Let's leave it as it is for now. -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: "Bruce R. McFarling" Subject: Re: subroutines that return variable #'s of results Date: 19 Aug 1996 03:55:13 GMT Message-ID: <4v8oj1$p62@seagoon.newcastle.edu.au> References: <4usvuk$1tu@news.tuwien.ac.at> <32161DCB.6E47C02A@informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) Bernd Paysan wrote: >Anton Ertl wrote: >> In article , jvn@faraday.clas.Virginia.EDU (Julian V. Noble) writes: >> |> The difficulties arising from variable numbers of return >> |> values are not restricted to Forth. If memory serves, C >> |> permits functions that return variable numbers of results. >> No. It permits functions with a variable number of arguments. Typical >> C calling conventions ensure that passing more arguments than >> necessary does not cause trouble. >As C returns additional values through pointers in the calling arguments >(uh, uh), it's possible to give a variable number of pointers. scanf >uses this approach. If you don't specify enough addresses, the program >will crash horrible (GCC has -Wall, the others could use lint). Here I am always griping about definitional quibbling, and then I set out to say the following: C doesn't return multiple values through pointers in the calling argument ... the C programmer does. but the point is that returning multiple values in Forth is a natural extension of returning a single value. Multiple values can be returned (in this sense of a natural extension of returning a single value): the equivalent in C is to return allocate a structure and return a pointer to the structure ... for an example, see the ANSI C fopen() routine that creates and returns a pointer to a structure of type FILE. Contrast this with the FSL structures, which take advantage of the flexibility of multiple return values to have structures defined by a pair of values -- reference to the structure definition and reference to the specific structure location -- in the style that so aggravates "one data item -- one stack entry" proponents. Of course, in either case (pointer to composite data item or direct manipulation of data items by passing their arguments as pointers) the Forth approach to returning multiple values is a much more direct extension of the Forth approach of returning a single value. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: rfl@yerkes.uchicago.edu Subject: Re: Objects for ANS Forth X-Nntp-Posting-Host: bob.yerkes.uchicago.edu Content-Type: text/plain; charset=us-ascii Message-ID: <3219BD5F.2442@yerkes.uchicago.edu> Reply-To: rfl@yerkes.uchicago.edu Content-Transfer-Encoding: 7bit References: <4v0b2g$p1r@godzilla.zeta.org.au> Mime-Version: 1.0 Date: Tue, 20 Aug 1996 13:28:01 GMT X-Mailer: Mozilla 3.0b5Gold (Macintosh; I; PPC) Michael Hore wrote: > > At least a dynamic bind is explicit in the syntax, which I think > is a Good Thing. Well to be more precise, in Neon and Yerk there > are situations where you can implicitly late-bind, but these have > got me into so much trouble that they're now no longer supported > in Mops. I use this late-binding technique reasonably often (when it is warrented) in Yerk and have never had a problem with it. What kinds of trouble, Mike?? From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Backtracking in ANS Forth (Was: Manipulating Return Addresses) Date: 20 Aug 1996 11:59:31 GMT Message-ID: <4vc9b3$b10@news.tuwien.ac.at> References: <320B3C25.6E4C@austin.finnigan.com> <320F1536.38E8@forth.com> <320FD2B3.522A@ix.netcom.com> <32132C17.5EAA@ix.netcom.com> Let me first present the problem in a simplified context: Assume that ONE-or-TWO ( -- n ) can deliver two solutions: on calling it, it delivers 1; when backtracking into it, it succeeds again, delivering 2; then it fails on backtracking. The word FAIL always fails. Let's define : foo \ always fails ONE-or-TWO . FAIL ; Calling foo prints 1, then it prints 2, the fails. How can we implement this? I will use THROW to implement FAIL, but this does not work with calls and returns as we know them. So we have to use a different implementation of calling and EXITing. The trouble for backtracking is the EXIT, so let's make it explicit (if you ever see "continuation-passing style", that's what this is about). We have to make the return information explicit; in Forth (without locals), this is just the return stack. Let's implement it as linked list; a return address is represented as xt: : push-return ( ret-stack1 ret-addr -- ret-stack2 ) 2 cells allocate throw swap over cell+ ! swap over ! ; : pop-return ( ret-satck1 -- ret-stack2 ret-addr ) dup cell+ @ swap @ ; : return ( ret-stack1 -- ret-stack2 ) \ never EXITs; stack-effect with respect to the word returned to. pop-return execute ; This, of course, requires some transformations of the programs that should use this explicit return mechanism. E.g., : bar ( ... -- ... ) PRIM1 DEF1 PRIM2 PRIM3 ; becomes : bar-part2 ( ... ret-stack1 -- ... ret-stack2 ) >r PRIM2 PRIM3 r> return ; : bar ( ... ret-stack1 -- ... ret-stack2 ) \ does not EXIT; stack-effect with respect to "return"ing >r PRIM1 ['] bar-part2 r> push-return DEF1 \ def1 never EXITs, so no return is necessary ; This does not look pretty (and with control structures it's even worse), but the transformation can be done automatically. It also leaks memory, but in the context of backtracking we could use a memory management mechanism (instead of allocate) that reclaims memory on failure. Moreover, all these never returning definitions and EXECUTEs could overflow the return stack; but they are tail calls, so the Forth system can use tail call optimization. Let's get back to backtracking. : choice \ works like return ( ret-stack1 -- ret-stack2 ), but creates a choicepoint \ i.e., it catches a failure; \ EXITs upon failure with stack effect ( ret-stack -- ) pop-return CATCH dup 1 <> if \ it's not a failure, but something else THROW then drop ; Here's how FAIL and ONE-or-TWO could be implemented: : FAIL \ neither EXITs nor returns 1 THROW ; : ONE-or-TWO ( ret-stack1 -- n ret-stack2 ) >r 1 r@ choice 2 r> return ; It should be helpful to remember that choice behaves like return, except that it will catch a failure, upon which it will EXIT and continue with the rest of ONE-or-TWO. We have to convert foo to use the explicit return mechanism: \ original: \ : foo \ always fails \ ONE-or-TWO . FAIL ; : foo-part2 ( ret-stack -- ... ) \ never EXITs, never returns \ we can treat "." as primitive here; it does not do choicepoints, failure etc. >r . FAIL ; : foo ( ret-stack -- ... ) \ never EXITs, never returns ['] foo-part2 swap push-ret ONE-OR-TWO ; Now we just need a wrapper to get into and out of the return/backtracking execution mode: : success-throw \ get out of the return/backtracking mode 2 throw ; : wrapper ( xt -- ) \ execute xt in return/backtrackin mode ['] success-throw 0 push-return swap catch case 1 of ." failure" endof 2 of ." success" endof throw endcase ; and we can call foo thus: ' foo wrapper So: it's ugly, but it's ANS Forth. I'm sure you can find ways to make it syntactically more pleasant. In applications such as FOSM, it may even be possible to hide the mechanism completely. - 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: Brad Rodriguez Subject: Re: Where is Lee Brodie? Date: Tue, 20 Aug 1996 08:44:42 -0700 Message-ID: <3219DD6A.4E35@headwaters.com> References: <01bb8d31$04904be0$63c3dece@dialin.inetnebr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Jerry Kreps wrote: > Brodie's book was, perhaps, the best > introduction to a computer language that I ever read! As I re-read it now, > to bring myself back up to speed, I recall reading that a more recent > version is available. Is that true? And, what is Brodie doing these days? I don't know what Leo is doing these days, but you can buy the second edition of "Starting Forth" from the Forth Interest Group. Email office@forth.org or check the web page . The web page might have a link to Leo Brodie's web page. Also recommended: Leo's sequel, "Thinking Forth," also available from FIG. -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Brad Rodriguez Subject: Re: Manipulating Return Addresses Date: Tue, 20 Aug 1996 08:47:13 -0700 Message-ID: <3219DE01.45F7@headwaters.com> References: <4ud4bb$8v@news.tuwien.ac.at> <4uo9at$8oa@news.tuwien.ac.at> <79eBCOA0oMEyEwUY@apvpeter.demon.co.uk> <4v24v9$ck@news.tuwien.ac.at> <32171EFD.1776@headwaters.com> <32188B81.7F69@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Andrew McKewan wrote: > Looking at the standard, no mention is made of the return stack. But > since we are compiling, "R> DROP" should have no effect on either > stack. Yes, I finally woke up and saw the word IMMEDIATE. That's what I get for reading this newsgroup at 6 am. :-) -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Environment Variables Date: 20 Aug 1996 14:11:05 GMT Message-ID: <4vch1p$c27@news.tuwien.ac.at> References: <3215F919.7102@umich.edu> To: David.N.Williams@umich.edu In article <3215F919.7102@umich.edu>, "David N. Williams" writes: |> and a POSIX function |> |> char *getenv(const char *name) This one is even ANSI C. Gforth has a word getenv c_addr1 u1 -- c_addr2 u2 that performs this function. |> I thought it might as well be opened up a bit to allow the user to add |> variables not provided by the system, and to set the values as well as |> read them. Looks like you mean add to the environment variables as visible to Forth. What's the point of that? What's the advantage over normal variables? In Unix, if you put something in the environment, the children of the present process inherit it. AFAIK this is not the case with your environment additions - 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: "Bruce R. McFarling" Subject: Re: multiple values Date: 20 Aug 1996 04:07:04 GMT Message-ID: <4vbdl8$i73@seagoon.newcastle.edu.au> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> <4v9a2i$av@dfw-ixnews5.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) JEThomas@ix.netcom.com (Jonah Thomas) wrote: >I find ?DUP useful in the following situation: > >... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... If that what ?DUP can be used for safely, then why not build it into a version of IF -- since that permits the peephole optimization of an IF that simply does not consume a non-zero top of stack. In other words, ?DUP-IF DO-IT THEN (I'm not going to worry about a good name for it today) will be no worse than ?DUP IF DO-IT THEN and it might be better. And the same would apply to the use of ?DUP in an UNTIL loop. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: mikc@gnu.ai.mit.edu (Mike Coughlin) Subject: Re: Forth for SUN 3/50 Date: 20 Aug 1996 14:42:19 GMT Message-ID: <4vcisb$50g@life.ai.mit.edu> References: <199608162308.a16455@ms3.maus.de> In article <199608162308.a16455@ms3.maus.de>, Georg Bauer wrote: >Does anyone have a Forth system that can be installed on an old 68K Sun as >the prime system instead of Sun OS? I don't really like to use a full Unix >on the system because it is awfull slow (it's only a 4M RAM system). But >since the system has nice hardware, it would be fun to reactivate it with a >Forth system and use it again (especially the 19" monitor is worth the >try). Nothing like that has ever been published. Mitch Bradley who wrote the original Sun Sparc Open Boot ROM might have written one, but I never heard of anybody else using it. The whole idea of using a Sun computer is to use Unix on a network. The design and documentation is concerned only with using Unix. If anyone wanted to write a stand alone Forth, he would get no help from Sun. Still such a thing might be possible. The I/O chips and their absolute addresses are known quantities. The memory management hardware and video are strictly a Sun design. I've seen several projects for Sun 3 computers which are not being completed since details about the Sun hardware is not available. I use Sun 3 computers as my main machines. They are only slow when doing graphics and compiling large programs. Sun 3's display text much faster than I can read it. Four megabytes is a large memory, unless you waste it on operating systems like Unix and worse. Since Forth programs don't waste memory or compile time, they would work extremely well on a Sun 3/50. If you use SunOS 4.1.1 on a 3/50, you could use gforth-0.1beta. This was written and tested on a Sparc, but it works on my Sun 3. It uses special features of the gnu c compiler and a binary of gcc is available. There is a PC to Motorola 68000 cross development program available based on Laxen & Perry's F83 which would enable you to port Forth to a bare 68000 board. I've never heard of anybody using this to complete a project. Getting Forth running on 68000 computer boards is a good idea, but people who do manage to write Forth systems almost always write them for the IBM-PC and MS-DOS. Oh well, too bad. -- Michael Coughlin mikc@gnu.ai.mit.edu Cambridge, MA USA From: Elizabeth Rather Subject: Re: Where is Lee Brodie? Date: Tue, 20 Aug 1996 10:07:06 +0000 Message-ID: <32198E4A.33D8@forth.com> References: <01bb8d31$04904be0$63c3dece@dialin.inetnebr.com> <3219DD6A.4E35@headwaters.com> Reply-To: erather@forth.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Macintosh; U; PPC) Brad Rodriguez wrote: > > Jerry Kreps wrote: > > Brodie's book was, perhaps, the best > > introduction to a computer language that I ever read! As I re-read it now, > > to bring myself back up to speed, I recall reading that a more recent > > version is available. Is that true? And, what is Brodie doing these days? > > I don't know what Leo is doing these days, but you can buy the second > edition of "Starting Forth" from the Forth Interest Group.... > ... > Also recommended: Leo's sequel, "Thinking Forth," also available from > FIG. Leo is doing some Forth programming and a lot of work with puppets. Check him out at http://www.rockisland.com/~leo/punch. Cheers, Elizabeth -- 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://www.forth.com From: "Douglas Beattie Jr." Subject: Forth for CP/M-86 anywhere? Date: Tue, 20 Aug 1996 13:50:51 -0700 Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anybody know where a FORTH for CP/M-86 can be found? Funny that it hadn't occurred to me sooner; I've had CP/M-86 for almost two years, but haven't used it much because I have no languages for it. Perhaps FORTH then... -- Douglas Beattie Jr. From: "Bruce R. McFarling" Subject: Re: Objects for ANS Forth Date: 20 Aug 1996 04:24:19 GMT Message-ID: <4vbelj$i73@seagoon.newcastle.edu.au> References: <4v9ht6$m6p@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: > >Well, this thread is interesting. ;-) > >As for the "object method" and "method object" cathegories, there >is my (Dyn)OOF (the new release is on taygeta and it is called dynoof >for the sake of German speakers) which is in fact a third cathegory. >Here the "object" has to be activated by a word (I like to refer to >it as a case-ending, although in Forth, of course, it is written >as a separate word) "{". I like this object + activator approach (not that I necessarily like it "the most", just that its appealing). But I have the same question I had when { } was suggested for nested compilation: how does this interact with the FSL matrix notation? Recall that in the FSL matrix notation, } }} }}} (etc.?) are words that resolve 1, 2, 3 (etc.?) matrix indices. Thus you would normally name a vector something like X{ and a matrix something like A{{, so that the corresponding } and }} look perfectly natural. If I recall correctly, the solution proposed for the nested compilation token was :[ ]: Since the operation of the token is "turn on the object represented on the top of stack", perhaps +{ }+ would work. And it types relatively well on this PC keyboard, since +, {, and } are all shifted characters close to each other. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "David N. Williams" Subject: Re: Environment Variables Date: Tue, 20 Aug 1996 13:36:34 -0400 Message-ID: <3219F7A2.57DD@umich.edu> References: <3215F919.7102@umich.edu> <4vch1p$c27@news.tuwien.ac.at> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) Anton Ertl wrote: > > In article <3215F919.7102@umich.edu>, "David N. Williams" writes: > |> and a POSIX function > |> > |> char *getenv(const char *name) > > This one is even ANSI C. > > Gforth has a word > > getenv c_addr1 u1 -- c_addr2 u2 > > that performs this function. Good! I didn't know the name "getenv" when I grep'd the gforth distribution, and gave up to soon. I'll check that out. > |> I thought it might as well be opened up a bit to allow the user to add > |> variables not provided by the system, and to set the values as well as > |> read them. > > Looks like you mean add to the environment variables as visible to Forth. > > What's the point of that? What's the advantage over normal variables? They are essentially normal varibles, with a private name space. Seemed not a bad idea to me to keep them separate in case I want to use some of the names in my code that the system happens to use for an environment variable. > In Unix, if you put something in the environment, the children of the > present process inherit it. AFAIK this is not the case with your > environment additions 'struth, I'm groping a bit about possible uses. If I were to spawn a process in a Forth application, I could imagine having it inherit in just that way. But I was thinking of simpler things, like conditional compilation for different systems. The shells I use on my Mac and Amiga don't make it easy to set environment variables, while the one I use on the NeXT does. The real reason I did it that way was probably that it's just as easy to include setting them as reading them, it appealed to my notion of symmetry, and there seemed no reason not to. -David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: "Robert S. Sciuk" Subject: Re: Objects for ANS Forth In-Reply-To: <4v8omu$ou7@godzilla.zeta.org.au> X-Nntp-Posting-Host: enfm.utcc Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: To: Michael Hore Originator: news@enfm.utcc.utoronto.ca References: <4v8omu$ou7@godzilla.zeta.org.au> Mime-Version: 1.0 Date: Tue, 20 Aug 1996 20:35:37 GMT On 19 Aug 1996, Michael Hore wrote: > pai1@ix.netcom.com(Lloyd Prentice ) writes: > > >David N. Williams wrote... > > > I have here a copy of the SOM/CORBA spec - it's almost 500 > pages, and rather daunting. I find myself wondering, is > anybody actually going to use this stuff? But I suppose > they will, indirectly. That is, they'll use OpenDoc or > whatever, which is based on SOM. So they'll write to an > API that uses SOM behind the scenes. Mike, An ANS forth binding for CORBA 2.0 and/or ILU (see Xerox PARC) would go a long way towards bringing the forth into the new century ... Rob. > > Anyway over the next couple of weeks I'll see if I can > get my mind around some of this, and maybe then I'll > be able to come up with some words of wisdom (?) > > Cheers, Mike. > > ---------------------------------------------------------- > Mike Hore mikeh@zeta.org.au > ---------------------------------------------------------- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Robert S. Sciuk Legato Systems Inc. Phone: (905) 529-1800 xt203 204-200 James St S. Hamilton, Ont. Can. L8P 3A9 Fax: (905) 529-8297 rsciuk@legato.com OR rob@innovus.com From: "Paul E. Bennett" Subject: Re: Hang on, isn't Forth out of date now? Date: Tue, 20 Aug 96 09:59:35 GMT Message-ID: <840535175snz@tcontec.demon.co.uk> References: <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article japs@netcom.com "Jim Schneider" writes: > In article Paul Shirley > writes: > >In article <4v3k64$d95@sjx-ixn6.ix.netcom.com>, pfrenger@ix.netcom.com > >writes > >>Will the Forth programmer get his project done first? NO CONTEST. > > > >This was *not* my experience in the mid 80's, for the simple reason that > >the dominant delay was rebooting the system after a fatal crash (about > >2-4 minutes!) > > > >The editor/assembler/debugger I used was pretty good at catching fatal > >memory writes before they did any damage. The Forth system in contrast > >was quite easy to crash even before running the app! > > > >-- > >Paul Shirley > > Actually, I find that having a system were a bug crashes the system taught > me a *LOT* about how to write programs that don't have that kind of bug... > The time taken to reboot the system is an excellent period to consider the reasons for the crash and identify the error of your ways. It can be the most productively useful part of the programming exercise. Just spend the time wisely and ask yourself "why did it crash?". There is often a very simple explanation. No-one can develop a perfect system from scratch and get it right first time through the development stage. The aim is to get it right before the first "live commissioning run". Never do the development on the on-line computers. Use a development machine for the task and accurately simulate what you do not have. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: indirect vs. subroutine threading X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <32108C7E.3969@austin.finnigan.com> Date: Wed, 21 Aug 1996 00:14:44 GMT Andrew McKewan writes: > Anton Ertl wrote: > > I don't know the ARM, but I can give you the code sequences for other > > processors. E.g., on the 486, a simple CALL/RET takes 8 cycles, > > whereas the MOV/ADD/JMP sequence for indirect threading takes 7 > > cycles. C compilers usually do more than just a CALL/RET for a C > > function call. > > The real benefit (speed wise) of subroutine threading is when you do > inline code expansion and pinhole optimization. Then it can greatly > outperform indirect threading. I'm not sure I follow. One of the Forths I use regularly has a recursive-descent optimizer that generates an inline CODE word from what used to be a hi-level word. It has some minor code optimizations like eliminating redundant push/pop pairs. This particular Forth is indirect-threaded. In tests, the speed of optimized hi-level code is only about 1.5x slower than the cleverest assembly I can generate (and I have had lots of experience in tricky assembler optimizations). This is usually slightly better than most optimized C's. Perhaps what Andrew meant to say was that it is _easier_ to turn subroutine-threaded code into inline- and/or peephole-optimized code, than with indirect threaded code. But the latter is really not very hard, judging from the small size of the optimizer that came with HS/FORTH. -- Julian V. Noble jvn@virginia.edu From: Tom Zimmer Subject: Re: Forth for CP/M-86 anywhere? Date: Tue, 20 Aug 1996 18:37:41 -0600 Message-ID: <321A5A4B.1B73@ix.netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Tue Aug 20 6:35:28 PM CDT 1996 X-Mailer: Mozilla 3.0b7 (Macintosh; I; PPC) Douglas Beattie Jr. wrote: > > Does anybody know where a FORTH for CP/M-86 can be found? Funny > that it hadn't occurred to me sooner; I've had CP/M-86 for almost > two years, but haven't used it much because I have no languages > for it. Perhaps FORTH then... > > -- Douglas Beattie Jr. Sorry, I did a search on the taygeta archive, but couldn't find any CP/M-86 information. Its located at: http://taygeta.com/forth.html8 if you would like to look yourself. Tom Zimmer From: almy@teleport.com (Tom Almy) Subject: Re: Forth for CP/M-86 anywhere? Date: Tue, 20 Aug 1996 21:41:54 -0400 Message-ID: References: In article , "Douglas Beattie Jr." wrote: >Does anybody know where a FORTH for CP/M-86 can be found? Funny >that it hadn't occurred to me sooner; I've had CP/M-86 for almost >two years, but haven't used it much because I have no languages >for it. Perhaps FORTH then... Back in the early 80's I had a copy of F83 for CP/M-86, along with their MSDOS and CP/M-80 versions (I used the last one most often). Since CP/M-86 and MSDOS (at least with the old FCB file interface in F83) had almost identical OS interfaces and very simular file formats, you could probably masage the metacompiler in the MSDOS version to generate a CP/M-86 executable. The two probably only differed in no more than a half dozen screens. Tom From: bluemist@wolfe.net (James E Brumbaugh) Subject: Re: Wanted: Forth for OS/2 Date: 21 Aug 1996 01:10:17 GMT Message-ID: <4vdnlp$fs4@ratty.wolfe.net> References: <3218CE04.5A60@austin.finnigan.com> Tom Zimmer (tzimmer@austin.finnigan.com) wrote: : J Christopher Kennedy wrote: : > : > I am very interested in finding a Forth for use under OS/2. I already have : > PFE, and Forth/2. Both appear to be stagnant. I am willing to pay for a : > profesional solution, if one exists. What I want is a Forth system that : > can run ANS standard programs (but perhaps it itself is not ANS standard), : > takes full advantage of OS/2 (eg. multi-threading, sytem API calls, etc), : > and ideally, have the potential to create Presentation Manager programs : > (PM is the GUI method used by OS/2). Also, I should be able to generate : > SOM compliant objects, as SOM is the standard object model for OS/2. : > The ability to compile stand-alone executables would also be appreciated. : > : > A fancy developement environment (IDE, resource editors, etc.) is not : > required, but would be appreciated. IF you know of such a system, or : > am willing to make one available (preferably in the under $300USD range), : > please either post to this newsgroup, or respond via email. : > : > I want this for my own personal use. As any language for OS/2 will cost : > in the under $300USD range, no matter whether it is C, C++, or Modula-2 : > I am willing to pay up to $300USD for such a Forth system. Thank you for : > your time. : Win32Forth runs under Win32s. I know thats not what you want, but if you are : interested in porting it to run under the OS/2 API, it might be simpler than : starting from scratch. Actually it would be a _lot_ simpler than starting : from scratch. I looked at the Presentation manager docs at one point, and : they are similar to Windows, but not the same. If you are _very_ familiar : with the OS/2 API, it might be worth a shot. : There is at least one forth that I found (can't remember the name), that ran : as a console application (no graphics). I'm sure you can find it on one of : the OS/2 software sites. : Tom Zimmer One problem with the Win32s route is that OS/2 currently supports version 1.25 and is unlikely go even to the current level of 1.30c (I believe) unless Merlin ups the ante. Even if the vendor currently does not use 1.30, the next upgrade of the product probably will. If this comes to pass you can bet the MS will upgrade Win32s to forever keep it out of reach of OS/2 users as Windows-95 already is. It's relatively easy for MS to do this as Windows breaks so many safety requirements (for Intel CPU multitasking) to gain speed with their VXD's that OS/2 must have a replacement OS/2 DLL written to replace it. The cost is always greater to IBM to keep up in this Red Queens race. Summary. Bad idea to use a Win32s application under OS/2. -- --Jim Brumbaugh "I want a computer so powerful that when I take |"Computer" - noun, A the case off of it, I can read manuals by the |relentless devourer of radiation emitted off the processor. Until then,|time, unfortunately more I'm _sort of_ happy." --Mark Lockwood (the mad) |addictive than tobacco. From: matt@access5.digex.net (Matt Lawrence) Subject: Re: multiple values Date: 20 Aug 1996 19:06:04 GMT Message-ID: <4vd2as$55i@news3.digex.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> <4v26ic$gq5@news3.digex.net> <4v95bj$pbn@news.NL.net> Hans Bezemer (hbezemer@vsngroep.nl) wrote: : We're talking about stack effects. If in fact, a Forth word returned the : (optional) parameters in variables, I would not put up an argument, sice the : stack effects would be the same -- just a flag. In fact, most error-situations : in C can be evaluated without errno. In the I/O routines you just have to : compare the number of bytes actually written or read against the number you : wanted to read or write. errno is just there for additional information. You don't have direct access to the stack in C, so you have to squirrel other information away in global variables if you need more than one return value. Also, everything has to be named. I've never had problems with variable number of parameters in Forth. In fact, the construct "?DUP IF" is really handy and perfectly obvious to me. : That means: in C the stack is always balanced. I would have found the va_ : routines a much better example. There you can have multiple input parameters. I : do not know many Forth words that allow this. C uses stack frames. Large amounts of the stack are thrown away at return time. Very different programming model. -- Matt From: "Bruce R. McFarling" Subject: Re: interfaces (was Re: multiple values) Date: 21 Aug 1996 02:17:50 GMT Message-ID: <4vdrke$2st@seagoon.newcastle.edu.au> References: <40.10697.1617@channel1.com> <4vbjdr$6uo@sjx-ixn3.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) JEThomas@ix.netcom.com (Jonah Thomas) wrote: >In Paul Shirley > writes: >> My point is really that 'programming for today' and planning for >> the future are often less mutually exclusive than most people >> assume. >I completely agree. > When you can work toward portability and it costs you very little, > there's nothing to lose by doing so. if it turns out later that > the things you thought would improve portability actually didn't, > that's not too bad -- you didn't have much invested in them anyway. > When people find themselves jumping through flaming hoops trying > to approach a portability mirage, that's something different. > When it _does_ look like an expensive trade-off, then it takes > careful thought and some lucky guesses to do well. How surprising to find a classic problem in the economics of uncertainty in a computer language newsfeed. ... The core of solutions that are normally used in other productive activities for this situation is to budget how much time you will devote to the activity. In the event that the effort to improve portability is waste of time, the time you devote to it has been wasted; in the event that it is almost the same effort as programming without taking portability into account, the benefit is likely to far outweight the cost. Some problems will involve one scenario, some the other, some a mixture of the two, and prior to committing the time to the problem you do not know which it is. So comitting time to this task is a speculative venture. The central problem with this type of speculative venture is the human tendency to overestimate our successes in retrospect ... so in the face of the "waste of time" scenario, we tend to overestimate the progress we have made, and underestimate the likelihood that devoting more time will be throwing "good time after bad". In speculative investment, you limit this risk by budgeting a maximum amount of your portfolio to speculative ventures *prior* to engaging in them, and then sticking to it. This limits your losses if in fact you are facing a "waste of time" scenario, and still permits you to benefit from the high returns of a speculative success. In some situations, and especially if this is time budgeting for free lance work, the best time to allocate to the speculative problem solving might be the end of the workday. As a rule of thumb, for an 8 hour workday, the last hour is between 5% and 10% investment: and then if you really get into it, the extra time spent on this is your time instead of the time budgeted for the contract. In a sense, this is the labor service equivalent of including allowance for capital equipment replacement in the overhead cost of a bid for a job. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "Bruce R. McFarling" Subject: Re: Environment Variables Date: 21 Aug 1996 02:47:03 GMT Message-ID: <4vdtb7$2st@seagoon.newcastle.edu.au> References: <3215F919.7102@umich.edu> <4vch1p$c27@news.tuwien.ac.at> <3219F7A2.57DD@umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) "David N. Williams" wrote: >Anton Ertl wrote: >> In article <3215F919.7102@umich.edu>, "David N. Williams" >> wrote: >>> I thought it might as well be opened up a bit to allow the >>> user to add variables not provided by the system, and to set >>> the values as well as read them. >> Looks like you mean add to the environment variables as visible >> to Forth. >> >> What's the point of that? What's the advantage over normal >> variables? > They are essentially normal varibles, with a private name space. > Seemed not a bad idea to me to keep them separate in case I want > to use some of the names in my code that the system happens to use > for an environment variable. >> In Unix, if you put something in the environment, the children of >> the present process inherit it. AFAIK this is not the case with >> your environment additions >'struth, I'm groping a bit about possible uses. If I were to > spawn a process in a Forth application, I could imagine having > it inherit in just that way. > ... > The real reason I did it that way was probably that it's just as > easy to include setting them as reading them, it appealed to my > notion of symmetry, and there seemed no reason not to. Having a way to read environment variables from the host environment is a good step to integrating with host systems that provide that service. There are two approaches: providing direct access to the host system environment variables, or copying the host system environment variables into memory under the control of Forth. If environment variables can be written, this implies the second implementation, because you can't assume write access to the host environment variables. So what is the advantage of *not* providing a word to write to an environment variable? If you do not provide this facility, you can extend the list of environment variables for spawning a process without having to recopy the entire environment variable date. Instead, you only require the new environment variable information, and only the pointers to the old environment variable information need be copied (after the pointers to the new info, so that environment variable redefinitions automatically supercede the original information). So, in summary, read-only environment variables *permits* (but doesn't require) an env'nt-variable-text-once, duplicate-pointers system, while read-write env'nt variables *requires* a duplicated-env'nt-variable-text system. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multiple values Date: 21 Aug 1996 07:16:08 GMT Message-ID: <4ved3o$4kq@dfw-ixnews7.ix.netcom.com> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> <4v9a2i$av@dfw-ixnews5.ix.netcom.com> <4vbdl8$i73@seagoon.newcastle.edu.au> X-NETCOM-Date: Wed Aug 21 2:16:08 AM CDT 1996 In <4vbdl8$i73@seagoon.newcastle.edu.au> "Bruce R. McFarling" writes: >JEThomas@ix.netcom.com (Jonah Thomas) wrote: >>I find ?DUP useful in the following situation: >>... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... > If that what ?DUP can be used for safely, then why not >build it into a version of IF -- since that permits the peephole >optimization of an IF that simply does not consume a non-zero >top of stack. In other words, > ?DUP-IF DO-IT THEN >(I'm not going to worry about a good name for it today) will be >no worse than ?DUP IF DO-IT THEN and it might be better. And the >same would apply to the use of ?DUP in an UNTIL loop. That makes sense. I've seen the suggestion before, and it made sense then. I've implemented it and not used it. I've never noticed anybody use it, although the idea has been around a long time. Every Forth implementation I've ever seen has has ?DUP and it gets used. I don't know why. Tradition, maybe? It's potentially more flexible than the ?DUP bundled into IF WHILE and UNTIL but I've never noticed much use for that flexibility. I dunno. Oh, here's one example. You start with a number and a flag, and you want to either do something that consumes the number or just drop it. ( n f ) ?DUP AND IF CONSUME-NUMBER THEN I did this once in my wild youth and it was more "efficient" than the other ways I tried on that particular system -- an ELSE DROP took more space and more time. It was easy for me to maintain because I got a little warm feeling at how smart I was every time I looked at it. After a while I gave up being that smart. There might be some sort of valid use for something vaguely like that. I don't know what it would be. Variable stack results have to result in branching somewhere along the line unless they're very carefully matched. From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Hang on, isn't Forth out of date now? Date: 21 Aug 1996 07:51:57 +0200 Message-ID: <4ve85t$clf@iaehv.IAEhv.nl> References: <3215D350.2344BDFE@informatik.tu-muenchen.de> Bernd Paysan writes Re: Hang on, isn't Forth out of date now? [ .. ] >> subr: nest \ nest a colon definition, eg., call it >> sub ebp, # 4 >> mov 0 [ebp], esi > > This takes 3 cycles since you have a one cycle penalty for modifying a > register before using it as addess. Use > > mov -4 [ebx], esi [1] > sub ebp, # 4 > > instead (one cycle on the Pentium, since it can be done in u and v > pipeline) Nice. But isn't there a (very small) chance of a bug here? Imagine an interrupt handler written in Forth, that kicks in at [1] (At that place you are writing to a location that is not yours yet.) I know of one very expensive compiler from a very well known vendor, for a very well-known Forth chip, that isn't interrupt proof. These bugs are a pain to track down. Of course on a PC in protected mode there is neglible chance your users want to write IRQ handlers :-) BTW, do you happen to have any more of these Pentium coding tips (or pointers to them)? -marcel From: peterh@lsil.com Subject: Mips Forth Date: 21 Aug 1996 11:31:31 +0200 Message-ID: Hi all, I'm currently work w/ R3000/R4000 Mips processors in embedded systems. I wonder if there are Forth implementations or cross development systems for this target available. Thanks for any pointers Peter ------------------------------------------------------ Peter Hober peterh@lsil.com | _/_/_/_/ _/ CoreWare Implementation | _/ _/ _/ LSI Logic GmbH | _/ _/ _/ Orleansstr. 4 | _/_/_/_/___/ D-81669 Munich | _/ _/ Tel.: +49-89-45833464 | _/ _/ Fax.: +49-89-45833419 | _/ _/ From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 09:41:57 GMT Message-ID: <4vell5$149@news.tuwien.ac.at> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> In article <4v6pqb$nlg@iaehv.IAEhv.nl>, mhx@IAEhv.nl (Marcel Hendrix) writes: |> > e.g., I |> > think the Neon syntax makes it necessary to use FIND (or generally, |> > half of a text interpreter) in the implementation, which I find ugly. |> |> Do you dislike the Neon syntax as such, or the fact that the interpreter |> must be modified to accommodate it? I don't think you have to modify the interpreter (you can't do that in the standard). However, you have to write part of an interpreter yourself; I dislike that. There are other reasons why I don't like the Neon syntax: 1) In its natural form it requires named objects. If you want to send a message to an object that you compute at run-time, you have to use a special, less convenient syntax. 2) Similarly, the Neon syntax makes late binding inconvenient. But the important thing about object-oriented programming languages (in comparison with languages like Ada and Modula-2) is late binding. IMO late binding should be easy; it should be the default. 3) Finally, though that may be a matter of taste, I dislike the "selector object" order. Forth always put the operation last, and communicated through the stack. Similarly, the method selector should expect its object on the stack instead of in the input stream. Passing the object to the selector on the stack would also resolve the other problems: It becomes as natural to deal with unnamed objects as with named objects, and late binding would be the default (because the selector does not know what object it will see). Generally, words that read from the input stream are a bad idea. They cannot be used easily when the parameter coming from the input stream does not reside in the input stream originally (yes, you can do a hack with EVALUATE, but that is cumbersome, slow, and has many pitfalls). Words that read from the input stream should be factored into a part that reads the input stream, and a processing part. If it does not say so somewhere in Thinking Forth, IMO it should. |> Personally I think Forth would benefit from some sort of on-the-fly |> "interpreter manipulation" now and then. Trivial examples are |> the ability to parse matrix, record and string operations: a[2] +TO |> warehouse.apples.1stquality, $name+$extensions TO $filename). The obvious |> disadvantage of these abilities is that they make user extensibility |> very difficult. The idea of virtual methods in an OOF might point to a |> solution. I don't think so. It would become incredibly complicated. They tried this with the Algol languages, and failed. Languages like Magic/L tried more conventional syntax with Forth, and failed. I think Forth's simple postfix syntax is an asset, even though it makes it unpopular. When you try to "fix" it, you get something that cannot survive. OO won't help us there. I your above example "a[2]", how do you specify a computed index? How do you specify a computed base array? |> > My general position has been to write those bits of object-orientation |> > that an application needs, when it is needed. E.g., in the Gray parser |> > generator I used a simple implementation of OO that was tailored to |> > the task. |> |> With this approach you will never find a need to do OOP, or will never |> realize you're doing it. Well, I did use it, so I saw a need. And I realized what I was doing. And if people do it without knowing it is OOP, so what? |> You must be willing to use somebody else's |> libraries. Or is there more to OOP than this? You can see it as a good way to organize libraries. One of my collegues says that OO is about reusability. - 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: stephenb@harlequin.co.uk (Stephen J Bevan) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 10:45:56 GMT Message-ID: References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> In-reply-to: anton@a0.complang.tuwien.ac.at's message of 21 Aug 1996 09:41:57 GMT In article <4vell5$149@news.tuwien.ac.at> anton@a0.complang.tuwien.ac.at (Anton Ertl) writes: 2) Similarly, the Neon syntax makes late binding inconvenient. But the important thing about object-oriented programming languages (in comparison with languages like Ada and Modula-2) is late binding. FYI: Ada (95) has late binding. From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 11:30:38 GMT Message-ID: <4ves0u$7k@news.tuwien.ac.at> References: <4v8ooh$ovo@godzilla.zeta.org.au> In article <4v8ooh$ovo@godzilla.zeta.org.au>, mikeh@zeta.org.au (Michael Hore) writes: |> anton@a0.complang.tuwien.ac.at (Anton Ertl) writes: |> > e.g., I |> >think the Neon syntax makes it necessary to use FIND (or generally, |> >half of a text interpreter) in the implementation, which I find ugly. |> |> Not really - or not quite... |> |> In Neon and Mops, selectors and instance variable names are hashed |> to 32-bit (cell) values. The regular FIND isn't used for these, since |> the lookup process is a lot simpler, basically just a loop which |> follows a link and compares two cells. There's no text string |> handling involved. So none of the text interpreter is needed at run |> time - just this special lookup word. I did not mean using FIND at run-time; using it at compile time is ugly enough. |> >So, I think the way to get a standard OO syntax for Forth is to write |> >a class library for it. The 17 other syntaxes will fall into disuse. |> >No need for a standards committe for that one. |> |> Agreed. After all, it works for Micro$oft. :-) Let's say it works for Netscape. As for MS, they would just have to announce that they will do an OO package with a different syntax, and everything else falls into disuse;-) - 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Faster than assembler (Was: Hang on, isn't Forth out of date now?) Date: 21 Aug 1996 11:56:20 GMT Message-ID: <4veth4$7k@news.tuwien.ac.at> References: <320C74D6.7BEA@headwaters.com> <4va8nb$28q@news.tuwien.ac.at> In article , dibald@netcom.com (Dave Baldwin) writes: |> Anton Ertl (anton@a0.complang.tuwien.ac.at) wrote: |> : There is another way how Forth can be faster than assembler: If the |> : Forth code is smaller than machine language (or just has better |> : caching characteristics), it can be faster simply by having fewer |> : cache misses. |> |> You keep assuming the Forth programmer is better than the ASM programmer. Not really. The condition (not assumption) here is that the Forth code is smaller than the machine code. Small Forth code has been often reported. There are several ways in which Forth code can be smaller than assembly code for the same problem, with the programmers at the same level of expertise: 1) Use of a Forth system with a space-saving encoding of the intermediate code. 2) Programming practices; e.g., Forth programmers tend to write shorter routines than assembly programmers (at the same level of expertise), which tends to increase code reuse. 3) Being faster at debugging, the Forth programmaer may have more time to make the program small. Of course, you can say that the assembly programmer can first write an interpreter with a space-saving encoding, and program the rest in that; but it takes more time and probably also more expertise than programming in Forth in the first place. OTOH, maybe programming in Forth makes the programmers better programmers than programming for the same time in assembly?-) I think a mix of diverse languages is optimal (for a start, some Algol language, some assembly language, Forth, Lisp, Prolog and Haskell). - 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: Brad Rodriguez Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 06:30:44 -0700 Message-ID: <321B0F84.2D27@headwaters.com> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <32161CC4.513B399F@informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Bernd Paysan wrote: > Yep. The main difference I find between OOFs is the order of method > passing. Some use "method object", others use "object method". I prefer > the second, because it allows (enforces) active parsing of the method. > To preserve the implementation freedom, we should agree that all > object-parsing must happen in the same line (thus either FIND patching, > or BL WORD FIND in the class word works). A problem: I have often, in the past, needed to pass a method selector as an argument to a conventional Forth word (for late binding). Active parsing would seem to render this impossible. Can you do late binding without storing the source text of the program? -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Brad Rodriguez Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 06:37:26 -0700 Message-ID: <321B1116.3CA1@headwaters.com> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <321887AA.7BDC@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Andrew McKewan wrote: > 2. Have a way for the system to not only see if a word has been defined, > but is really a selector. This can be done by either compiling a special > tag into the selector pfa (wasting some space and not foolproof) or just > seeing if the selector has been defined after ClassInit: > > a) : ?Selector ( pfa -- f ) @ selectorTag = ; > > b) : ?Selector ( pfa -- f ) ['] ClassInit: >BODY U< 0= ; Does the ANS Standard guarantee that the dictionary pointer is monotonically increasing? -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Andrew McKewan Subject: Re: Hang on, isn't Forth out of date now? Date: Wed, 21 Aug 1996 09:57:25 -0500 Message-ID: <321B23D5.7E96@austin.finnigan.com> References: <3215D350.2344BDFE@informatik.tu-muenchen.de> <4ve85t$clf@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Marcel Hendrix wrote: > Nice. But isn't there a (very small) chance of a bug here? Imagine an > interrupt handler written in Forth, that kicks in at [1] (At that > place you are writing to a location that is not yours yet.) > > I know of one very expensive compiler from a very well known vendor, > for a very well-known Forth chip, that isn't interrupt proof. These > bugs are a pain to track down. Of course on a PC in protected mode > there is neglible chance your users want to write IRQ handlers :-) This is a very subtle problem in the Motorola 56000 series Dsp processor. The store with autoincrement instruction does the store first and then increments the register. This is a two-cycle instruction that can be interrupted in the middle! The C compiler uses r6 as the data stack pointer, so if an interrupt routine is to call C, it must start and end with this code: iserv: move (r6)+ ; "safety push" ... move (r6)- ; "safety pop" rti You could do the same in your Forth interrupt handler. -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: jayfar@netaxs.com (Jay Farrell) Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 11:38:03 -0500 Message-ID: References: <4v8ooh$ovo@godzilla.zeta.org.au> <4ves0u$7k@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Computer: Macintosh Quadra 605, OS 7.5.3 X-Coffee: Columbian Supremo In article <4ves0u$7k@news.tuwien.ac.at>, anton@a0.complang.tuwien.ac.at (Anton Ertl) wrote: | As for MS, they would just have to announce that they will do an OO | package with a different syntax, and everything else falls into | disuse;-) You would think so, but reality is shaping up a wee bit differently, at least in regards to the emerging *distributed* objects technologies. The Object Management Group's CORBA standard for distributed object has officially embraced OpenDoc rather than OLE as the standard for distributing components. MS is now trying to make OLE interoperate with OpenDoc. I'm oversimplifying this (because my own understanding is limited). A good read is "The Essential Distributed Objects Survival Guide," Orfali, Harkey, & Edwards, Wiley books. Cheers, Jayfar ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//// //// The Mops Page //// ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//// //// Mops is Mike Hore's freeware Forth/Smalltalk hybrid for Macintosh //// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jay Farrell jayfar@netaxs.com Philadelphia, Pennsylvania, USA From: dibald@netcom.com (Dave Baldwin) Subject: Re: Faster than assembler (Was: Hang on, isn't Forth out of date now?) Message-ID: References: <320C74D6.7BEA@headwaters.com> <4va8nb$28q@news.tuwien.ac.at> <4veth4$7k@news.tuwien.ac.at> Date: Wed, 21 Aug 1996 14:32:10 GMT Anton Ertl (anton@a0.complang.tuwien.ac.at) wrote: : Of course, you can say that the assembly programmer can first write an : interpreter with a space-saving encoding, and program the rest in : that; but it takes more time and probably also more expertise than : programming in Forth in the first place. One of the first things that an ASM programmer will write is some sort of command interpreter. While the first version will be a long way from a 'language' interpreter, it's not unusual for programmable features to start creeping in. Like putting the parameters on the stack as you parse the command line. Like adding a little in-line math. Like providing variable assignment and storage. These things just seem to grow. : OTOH, maybe programming in Forth makes the programmers better : programmers than programming for the same time in assembly?-) I think : a mix of diverse languages is optimal (for a start, some Algol : language, some assembly language, Forth, Lisp, Prolog and Haskell). I think any programming you do with a view to what's good, bad, and reusable makes you better. Even BASIC can teach you something at one point. And these days, you really ought to know enough about 'C' to understand stack frames and how they're built and used. After a while, exposure to 'high' level languages tends to make you a different sort of ASM programmer. Trying to write larger programs in ASM will change your viewpoint also. Little things you can hack, but as programs get larger, you better get organized or you will lose track. Gives one a fine feel for the benefits of 'high' level languages. -- -=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=- Dave Baldwin: dibald@netcom.com | The Computer Journal 1(800)424-8825 DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/" Voice : (916) 722-3877 | Hands-on hardware and software TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480 -=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=- From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Hang on, isn't Forth out of date now? X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com> Date: Wed, 21 Aug 1996 16:28:31 GMT pfrenger@ix.netcom.com writes: > >Paul Shirley wrote: > > >>Paul Frenger wrote: > >>Will the Forth programmer get his project done first? > >>NO CONTEST. > > >This was *not* my experience in the mid 80's, for the > >simple reason that the dominant delay was rebooting the > >system after a fatal crash (about 2-4 minutes!) > >The editor/assembler/debugger I used was pretty good at > >catching fatal memory writes before they did any damage. > >The Forth system in contrast was quite easy to crash even > >before running the app! > > Paul, I'm really sorry you had this kind of experience. > Let's dissect it a little and find out just what the > problem was. > > First, what kind of system were you using? Mid-80's might > be an early PC (8088/8086), or an Apple II (6502), or a > CP/M machine (8080/Z80), or even an old Macintosh (68000). > All of these had Forths available then. Clock speeds weren't > impressive (ie: 4.77 MHz 8088 for the PC), and you likely > were using a floppy-only system. > > Second, whose Forth did you use? Probably not polyForth (a > commercial product: quite good but in the $3000 range). Was > likely to be Fig-Forth, which was a good starting point but > not very stable for most platforms (it required customizing). > There were some good, inexpensive PD products (MVP-Forth, $25) > and commercial ones too (LMI Forth, about $150). > > Forth has come a long way since then. I have used dozens of > Forths since 1981 ... some great, some terrible. The usual > problem is NOT FORTH but the implementation. Public domain > Forths are great for learning but not for commercial projects! > You heard it here! Quote me on this. I find I still crash and burn about once in 10-20 compiles, when I am doing something I do not really understand. It has little to do with the implementation, more to do with a) not having taken the time to REALLY understand what a word I do not ordinarily use REALLY does; b) getting impatient and failing to test each word as it is entered; c) coding directly from the terminal (and auto-logging the keystrokes) rather than thinking things through (another kind of impatience); d) letting words get so long I can't keep them in my personal input buffer. When I take my time and exercise self-discipline, I rarely have to reboot. But this took a couple of years to learn, of course. As George Bernard Shaw once remarked, "Youth is wasted on the young." -- Julian V. Noble jvn@virginia.edu From: echapin@interlog.com Subject: Re: Hang on, isn't Forth out of date now? Date: 21 Aug 1996 17:22:37 GMT Message-ID: <4vfgkt$go5@news.interlog.com> References: <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com> Reply-To: echapin@interlog.com In , jvn@faraday.clas.Virginia.EDU (Julian V. Noble) writes: >pfrenger@ix.netcom.com writes: >> >Paul Shirley wrote: >> >> >>Paul Frenger wrote: >> >>Will the Forth programmer get his project done first? >> >>NO CONTEST. >> >> >This was *not* my experience in the mid 80's, for the >> >simple reason that the dominant delay was rebooting the >> >system after a fatal crash (about 2-4 minutes!) The system that Mitch Bradley used to sell came up in debugging mode if you threw it garbage. From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 12:39:23 GMT Message-ID: <4vf01r$iu@hkusuc.hku.hk> References: <4v9ht6$m6p@hkusuc.hku.hk> <4vbelj$i73@seagoon.newcastle.edu.au> Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: >h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >> >>Well, this thread is interesting. ;-) >> >>As for the "object method" and "method object" cathegories, there >>is my (Dyn)OOF (the new release is on taygeta and it is called dynoof >>for the sake of German speakers) which is in fact a third cathegory. >>Here the "object" has to be activated by a word (I like to refer to >>it as a case-ending, although in Forth, of course, it is written >>as a separate word) "{". > I like this object + activator approach (not that I >necessarily like it "the most", just that its appealing). But >I have the same question I had when { } was suggested for >nested compilation: how does this interact with the FSL matrix >notation? > Recall that in the FSL matrix notation, } }} }}} (etc.?) >are words that resolve 1, 2, 3 (etc.?) matrix indices. Thus you >would normally name a vector something like X{ and a matrix Well, probably it would intefere, but "{" and "}" were the only kind of brackets which were not already used for something quite useless in Forth. [I mean they are not in THE STANDARD.] (Strange, that we have "(" for comments, what noone else does, and it seems that "\" is getting more popular anyway, and there is no reason, apart from tradition, for not using "[" for matrix, or whatever else indexes as most of the other languages do. [Really, how often do you need to change compilation state?]) May be I am not normal, but I have similar problems with other Forth words like @ ! , . ? Somehow I do not use them often enough directly to justify that these handy notations are wasted. Not to mention # , which is actually very rarely used. >something like A{{, so that the corresponding } and }} look >perfectly natural. >If I recall correctly, the solution proposed for the nested >compilation token was > :[ ]: >Since the operation of the token is "turn on the object >represented on the top of stack", perhaps +{ }+ would work. >And it types relatively well on this PC keyboard, since >+, {, and } are all shifted characters close to each other. >-- It would be possible, although ugly. Because I do not use the matrix notation in (Dyn)OOF, it never occured to me, that the words "{" and "}" are actually have a meaning assigned to them. :-((( BTW: FSL is ANS Forth, so in (Dyn)OOF it is to be compiled in ANS Forth mode, where the words "{" and "}" do not exist. [They are defined in the vocabulary Objects, so they do not interfere with words compiled in ANS Forth mode. Of course "modern" Forth systems discourage keeping different pieces of information in separate directories :-(, but in (Dyn)OOF it is not a problem.] Andras From: "David N. Williams" Subject: Re: Environment Variables Date: Wed, 21 Aug 1996 08:13:54 +0000 Message-ID: <321AC542.35D3@umich.edu> References: <3215F919.7102@umich.edu> <4vch1p$c27@news.tuwien.ac.at> <3219F7A2.57DD@umich.edu> <4vdtb7$2st@seagoon.newcastle.edu.au> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) Bruce R. McFarling wrote: > [...] > > There are two approaches: providing direct access to the > host system environment variables, or copying the host system > environment variables into memory under the control of Forth. > If environment variables can be written, this implies the > second implementation, because you can't assume write access > to the host environment variables. > [...] > > So, in summary, read-only environment variables *permits* > (but doesn't require) an env'nt-variable-text-once, duplicate-pointers > system, while read-write env'nt variables *requires* a > duplicated-env'nt-variable-text system. I understand what you're saying. But won't there be situations where a spawned process lives longer than its parent, in which case it wouldn't be sufficient to give it only pointers to the parent's system environment variables, which are not untypically at the bottom of the parent's stack, and vanished. Anyway, I think providing glue for the standard C library getenv() is likely to be enough for many purposes--I'm guessing without having checked it yet that that's what gforth does. Still, I'll keep the read/write variables in my system... --David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: "David N. Williams" Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 09:29:01 +0000 Message-ID: <321AD6DD.619@umich.edu> References: <4v9ht6$m6p@hkusuc.hku.hk> <4vbelj$i73@seagoon.newcastle.edu.au> <4vf01r$iu@hkusuc.hku.hk> Reply-To: David.N.Williams@umich.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Macintosh; I; PPC) Zsoter Andras wrote: > > Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: > > Recall that in the FSL matrix notation, } }} }}} (etc.?) > >are words that resolve 1, 2, 3 (etc.?) matrix indices. Thus you > >would normally name a vector something like X{ and a matrix > > Well, probably it would intefere, but "{" and "}" were the only > kind of brackets which were not already used for something quite > useless in Forth. > [I mean they are not in THE STANDARD.] I like the FSL matrix notation a lot. Only half tongue-in-cheek, I advocate that { and } be declared as standard anti-words, guaranteed never to appear as words in the standard, because there are so many diverse and worthwhile uses for them in applications. That is, one should always expect them to be locally defined, and always be aware that they may get redefined. --David _ _________________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ University of Michigan Fax: 1-(313)-763-2213 \ |:-) Physics Department Email: David.N.Williams@umich.edu \| Ann Arbor, MI 48109-1120 From: Tom Zimmer Subject: Re: Wanted: Forth for OS/2 Date: Wed, 21 Aug 1996 14:05:04 -0500 Message-ID: <321B5DE0.72D4@austin.finnigan.com> References: <3218CE04.5A60@austin.finnigan.com> <4vdnlp$fs4@ratty.wolfe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) James E Brumbaugh wrote: > > Tom Zimmer (tzimmer@austin.finnigan.com) wrote: > : J Christopher Kennedy wrote: > : > > : > I am very interested in finding a Forth for use under OS/2. > > : Win32Forth runs under Win32s. I know thats not what you want, but if you are > : interested in porting it to run under the OS/2 API, it might be simpler than > : starting from scratch. Actually it would be a _lot_ simpler than starting > : from scratch. I looked at the Presentation manager docs at one point, and > : they are similar to Windows, but not the same. If you are _very_ familiar > : with the OS/2 API, it might be worth a shot. > > : Tom Zimmer > > One problem with the Win32s route is that OS/2 currently supports version > 1.25 and is unlikely go even to the current level of 1.30c (I believe) > unless Merlin ups the ante. > > Even if the vendor currently does not use 1.30, the next upgrade of the > product probably will. > > If this comes to pass you can bet the MS will upgrade Win32s to forever > keep it out of reach of OS/2 users as Windows-95 already is. It's > relatively easy for MS to do this as Windows breaks so many safety > requirements (for Intel CPU multitasking) to gain speed with their VXD's > that OS/2 must have a replacement OS/2 DLL written to replace it. The cost > is always greater to IBM to keep up in this Red Queens race. > > Summary. Bad idea to use a Win32s application under OS/2. I generally agree with you, except that you missed my point completely. My point was, that Christopher could have started with Win32Forth, and re-written its Win32s API interface into the very similar, but not quite the same Presentation Manager API. Assuming he has the technical expertise of course. Tom Zimmer From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Faster than assembler (Was: Hang on, isn't Forth out of date now?) X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <4va8nb$28q@news.tuwien.ac.at> Date: Wed, 21 Aug 1996 16:49:41 GMT anton@a0.complang.tuwien.ac.at writes: > There is another way how Forth can be faster than assembler: If the > Forth code is smaller than machine language (or just has better > caching characteristics), it can be faster simply by having fewer > cache misses. > > Currently this is pretty theoretical, but as the processor/memory > speed difference grows, it will get more important. Some people argue > that we will see a memory wall, where the execution time will be > determined by the number of memory accesses. We already have a memory-access-time limitation on execution speed. Look at any program that does number-crunching on a large data set: with fast co-processors, the arithmetic execution time (except for things like transcendental functions) is swamped by the fetch/store time. Caching doesn't help much because cahches are finite in size. Thus the time eventually asymptotes to the DRAM access time. There was an article in DDJ some time ago timing FORTRAN compilers running on Pentium machines. There was a substantial hit in Mflops going from small- to large-matrix problems, using otherwise-identical software. The "problem" was eventually traced to exceeding the size of pipelines and/or cache memory. In fact, when designing such things as coprocessors, one must take into account the memory speed. The reason is that surely one could make the math operations time as small as one wished, by making the chips arbitrarily costly. There is no point to this, since even if the math took zero time, the speedup would only be a factor of two over the most cost-effective solution (which typically takes equal amounts of access and computation time for common calculations). -- Julian V. Noble jvn@virginia.edu From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Hang on, isn't Forth out of date now? Date: 21 Aug 1996 14:07:49 GMT Message-ID: <4vf57l$6p0@news.tuwien.ac.at> References: <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> <840535175snz@tcontec.demon.co.uk> In article <840535175snz@tcontec.demon.co.uk>, "Paul E. Bennett" writes: |> The time taken to reboot the system is an excellent period to consider the |> reasons for the crash and identify the error of your ways. It can be the |> most productively useful part of the programming exercise. So the much-touted interactiveness of Forth is actually a disadvantage? One should rather spend the time during the recompile to contemplate the possibility of more errors, better factoring or a better design? I don't buy that. Yes, there are times when you have to stand back and think, but I can do that much better, when I know that, as soon as I have an idea, I can check it out in seconds. - 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: rfl@yerkes.uchicago.edu Subject: Re: Objects for ANS Forth X-Nntp-Posting-Host: bob.yerkes.uchicago.edu Content-Type: text/plain; charset=us-ascii Message-ID: <321B1877.55C8@yerkes.uchicago.edu> Reply-To: rfl@yerkes.uchicago.edu Content-Transfer-Encoding: 7bit References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> Mime-Version: 1.0 Date: Wed, 21 Aug 1996 14:08:58 GMT X-Mailer: Mozilla 3.0b5Gold (Macintosh; I; PPC) Anton Ertl wrote: > I don't think you have to modify the interpreter (you can't do that in > the standard). However, you have to write part of an interpreter > yourself; I dislike that. There are other reasons why I don't like the > Neon syntax: > > 1) In its natural form it requires named objects. If you want to send a > message to an object that you compute at run-time, you have to use a > special, less convenient syntax. This is not really true. While Yerk (neon) does have an alternate syntax, you can also instantiate objects into a value (mcfa word). Sending a message to that value routes the message to the object stored in the value. The syntax is exactly the same for late or early bound objects. > 3) Finally, though that may be a matter of taste, I dislike the "selector > object" order. Forth always put the operation last, and communicated > through the stack. Similarly, the method selector should expect its > object on the stack instead of in the input stream. Yerk does this with the late bound syntax this IS different: motor move: [ ] From: Bernd Paysan Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 18:55:14 +0200 Message-ID: <321B3F72.3E992345@informatik.tu-muenchen.de> References: <840414075.AA00428@ear.co.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.13 i486) Ewald Pfau wrote: > > Bernd Paysan wrote: > > BP> Yep. The main difference I find between OOFs is the order of method > BP> passing. Some use "method object", others use "object method". > > This is not just swapping the sequence. A bit more extended wording shows the > more versatile scope, if Forth meets syntax: Add a stack comment after each > nomination of a name. For "Message Object" this is not possible, since "Object" > has to be parsed at compile time. For "Object Message", you may have a > parameter in between. So it may as well read: "Object [ -- parameter ] .. for a walk, make coffee> .. [ parameter -- ] Message". There are parsing OOFs out there, and non-parsing, both orders. E.g. the " "-approach lets push an ID to the stack (e.g. the offset in the object's dispatch table), and contains the message dispatcher code. My OOF is of the "object method" type, and each object parses the method. This allows compile time checks for valid message id (method name), and, what I'm more interested, to optimize code. So if your favourite OOF implementation does it by pushing the object pointer to the stack, ok. But what I want to find is something we could standardize, so we have to put restrictions that are artificial on one OOF implementation, but natural on the other. > (Did I miss something > that I'd be wrong and it really should read "Method" here? - 'the method' is > just only the special instance which is applied; by reading a source text, you > will find the name of 'the message'.) A message is a method/message id and parameters, passed to an object. OO vocabulary is inherently inconsistent :-(. > BP> prefer the second, because it allows (enforces) active parsing of > BP> the method. To preserve the implementation freedom, we should agree > BP> that all object-parsing must happen in the same line (thus either > BP> FIND patching, or BL WORD FIND in the class word works). > > The 'inline' approach expects a reading like "count the apples". With RPN > reading, it is legitimate to underline the action involved: "Here are apples. > Let's count them" (many non-Forthers and some Forthers sometimes as well, have > a problem here, with reading the abbreviation of this: "Apples Count" :) ). > > But now we are back at very common Forth level handling. Why should the object > be on the same line? If the inline syntax reading is gone, so there is no need > for it. As I could see, the ported Yerk approach uses names ending in colons to > indicate the message, as "Count: Apples". If swapped, there is no such > syntactical writing needed (it cuts down to cosmetics for reading: "Apples > Is-Counted"). It's just the language you chose, in german, this syntax is ok. It's not imperative, but descriptive. Following Leo Brodie, we should not force natural language diction, if there's a better approach. If you say "apples @", natural english language would say "fetch (number of) apples". BTW: conventional OO language almost all use the "object method" order, so the C++ people should not have a problem here. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 09:49:49 -0500 Message-ID: <321B220D.60A1@austin.finnigan.com> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Anton Ertl wrote: > I don't think you have to modify the interpreter (you can't do that in > the standard). However, you have to write part of an interpreter > yourself; I dislike that. There are other reasons why I don't like the > Neon syntax: > > 1) In its natural form it requires named objects. If you want to send a > message to an object that you compute at run-time, you have to use a > special, less convenient syntax. I believe most uses will be for named objects. Dynamic object creation is not used as much in Forth as in other languages. The syntax is less convenient, but does explicitly express what you are doing. Early bind: Print: myObj Late bind: Print: [ myObj ] > 2) Similarly, the Neon syntax makes late binding inconvenient. But the > important thing about object-oriented programming languages (in > comparison with languages like Ada and Modula-2) is late binding. IMO > late binding should be easy; it should be the default. This is an argument we will not settle here. In a "pure" OO model like Smalltalk, all messages are late bound. This provides the most flexible model. But it has a few disadvantages: 1. It is slower that early binding (often considerably slower). 2. Unknown messages are caught at runtime, making debugging more difficult. [As an aside, the C++ model is not really message passing. It does to compile-time checking and is very efficient, but you cannot send an arbitrary message to an arbitrary object (they must descend from a common base class).] If the OO model is just used as a special part of an application, then this might be fine. All selectors could just be Forth words like: : BIND ( obj sel -- xt ) ... ; : Selector ( n -- ) CREATE , DOES> @ BIND EXECUTE ; 1 Selector Print myObj Print But the idea in Yerk is that this is the fundamental was of coding a program. In that context, speed is essential. And as I mentioned above, I think most messages will be to named object whose class is known at compile time. > 3) Finally, though that may be a matter of taste, I dislike the "selector > object" order. Forth always put the operation last, and communicated > through the stack. Similarly, the method selector should expect its > object on the stack instead of in the input stream. I agree, but this complicates early binding. To do this, we really need to get both the object and selector together, so one would need to parse the other. Think of "Selector: object" as a single syntactic unit, just like "POSTPONE AWORD". > Generally, words that read from the input stream are a bad idea. But sometimes the best and most convenient way. How about changing Forth to be truly postfix: S" NAME" : ; 0 S" ZERO" CONSTANT Whoops, S" parses from the input stream. CHAR N CHAR A CHAR M CHAR E 4 : ; So does CHAR! 78 65 77 69 4 : ; Ah, that't better :-) -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: Paul Shirley Subject: Re: Hang on, isn't Forth out of date now? Date: Tue, 20 Aug 1996 23:57:59 +0100 Message-ID: References: <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com> Mime-Version: 1.0 In article <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com>, pfrenger@ix.netcom.com writes >First, what kind of system were you using? Mid-80's might >be an early PC (8088/8086), or an Apple II (6502), or a >CP/M machine (8080/Z80), or even an old Macintosh (68000). >All of these had Forths available then. Clock speeds weren't >impressive (ie: 4.77 MHz 8088 for the PC), and you likely >were using a floppy-only system. Disc drive... if only! Nope I'm talking about cassette tape systems (hence the 2-4 minutes load time). >Second, whose Forth did you use? Probably not polyForth (a >commercial product: quite good but in the $3000 range). Was >likely to be Fig-Forth, which was a good starting point but >not very stable for most platforms (it required customizing). >There were some good, inexpensive PD products (MVP-Forth, $25) >and commercial ones too (LMI Forth, about $150). The first one was a truly awful Fig Forth for the Oric (6502,slow tape interface). It actually worked quite well after a friend and I fixed it. I ended up just configuring it as a macro assembler... (games need 110% of the speed available ;) The Forth V assembler/debugger comparisons are for the Amstrad CPC464 (z80,64K ram, slowish tape drive), and the C64 (with the disc drive slower than some audio tape drivers I've written ;) The Forths where from Oasis, assemblers from Oasis (C64), Hisoft (CPC). In both cases saving current work was appallingly slow, rebooting allowed time to make a coffee! That is not a good environment for Forth style testing if your words manipulate raw memory! (And *all* the tools cost about the same ($50), $3000 was a bit beyond my means back then ;) >Forth has come a long way since then. I have used dozens of I know, but so have assemblers! >Forths since 1981 ... some great, some terrible. The usual >problem is NOT FORTH but the implementation. Public domain >Forths are great for learning but not for commercial projects! >You heard it here! Quote me on this. Never left a PD forth on any system longer than an hour... In many ways its a historically oddity I found asm quicker to use than Forth. -- Paul Shirley From: Bill Zimmerly Subject: Re: multiple values Date: Wed, 21 Aug 1996 14:48:58 -0500 Message-ID: <321B682A.77C8@inlink.com> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> <4v9a2i$av@dfw-ixnews5.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) Jonah Thomas wrote: > > In <32164C9F.179F@inlink.com> Bill Zimmerly writes: > > >As a matter of principle, I avoid using words that exhibit > >this behavior (like ?DUP) since I abhor words that express > >what I like to call "funny" stacks. I see them as being the > >functional equivalent of multiple entry points since they > >leave it up to subsequent branches to clean up the mess that > >they've introduced. I prefer that the cleanup be done WITHIN > >the appropriate followup branch RATHER than before the branch > >occurs and unnecessarily forces the stack diagram to report > >it's alternate behaviors. I just don't like diagrams like > >this... > > > ( n -- d | 0 false | 1 a l true -- ) \ etc. > > >...instead prefering nothing more complicated than a before > >and after effect... > > > ( a -- a+1 len ) > > OK. Right off I remember 2 examples from the Standard, ?DUP and > SEARCH-WORDLIST . Agreed...but the problem, IMHO, is when other programmers see that the standard condones this kind of stack effect and begin creating new words with ever more perplexing stack effects. I prefer to keep things as simple as possible at the level where I look at a word's stack effect diagram and, as your following examples illustrate, keep the complexity *WITHIN* the word... > I find ?DUP useful in the following situation: > > ... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... I'm *not* saying that this is wrong!!! But I am saying that I prefer... > For example, looking at a threaded list item and quitting if it's zero. > ?DUP gives a nice clean result. You could do it this way: > > ... DO-SOMETHING? ( addr|0 ) DUP IF DO-IT ELSE DROP THEN ... Yes! I do prefer *THIS* style over the ?DUP one above because the complexity is kept *WITHIN* the single definition! As a matter of personal preference (and habit), whenever I type an "IF", I immediately follow it up with the "ELSE" and "THEN"...and then proceed backwards to take care of the word's functionality. For example, I might begin such a word like this... : time-to-eat ( -- ) \ Process programmer hunger. hungry? if else then ; ...and then go back into the branched of the word to deal with the issues of what to do. I simply don't like words like HUNGRY? with stack-effect diagrams like the following... : hungry? ( -- a l TRUE | FALSE ) \ "a l" == type of food to order. .. .. ; Instead, prefering the far simpler... : hungry? ( -- f ) \ TRUE == yes, I'm hungry: FALSE == No, I'm not. .. .. ; ...then, I can deal with the IF clause determining the kind of pizza and the toppings, whereas the ELSE clause can either be deleted or enhanced with actions that I may decide are logically correct such as... : time-to-eat ( -- ) \ Process programmer hunger. hungry? if @prefered-toppings \ Programmers only want *one* kind of food! :-) @prefered-style \ (This should be factored along career lines later on!) @prefered-vendor call-in-pizza-order else 30 minutes myself queue \ Queue this up again for 1/2 hour later. then ; ...and we all know that programmers *LOVE* their work so much that they have to be reminded to eat!! Perhaps it's because I like to work in environments where I can have multiple processes, multiple tasks and multiple processors being kept busy and running cleanly that I like to keep the simplicity established in other places...i.e. the stack effect diagram of EVERY WORD. > and what does it really get you? Or you could do: > > ... DO-SOMETHING? ( addr flag ) DUP IF DO-IT ELSE DROP THEN ... > > which is even worse. But it might be clearer for some people, which is > worth careful consideration. Anyway, the word that the above fragment > was embedded in wouldn't have a funny stack diagram because the > divergent stack would be all healed up before the end. *I AM* such a "people-thing", to quote one of my favorite movie lines. (From "The God's Must Be Crazy"). > The trouble with the line "Do it my way because it's the way I > understand it best" is that this argument works best for C programmers. > The trouble with the line "I'm doing it the most elegant way so study my > code and learn wisdom" is that such code is likely to get rewritten > instead of understood. I wish I knew how to resolve this. But these > aren't the only two simultaneous constraints.... Agreed! Very heartily!! Well put! - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 3 of 6, Vendors & Authors Date: 21 Aug 96 21:03:17 GMT Expires: 25 Sep 96 20:53:09 Message-ID: References: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part3 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. Archive-name: forth/FAQ/vendors Comp-lang-forth-archive-name: vendors-faq Last-modified: 4 Mar 1996 Version: 1.01 Posting-Frequency: monthly comp.lang.forth Frequently Asked Questions, part 3 of 6 Forth Vendors Send all Corrections, Additions, and/or Deletions to: L. Greg Lisle L.G.Lisle@ieee.org These firms are primarily software, systems and support FirmWorks; Mitch Bradley; 415 917-0100 480 San Antonio Rd, Ste 115; Mountain View; CA 94040; USA Open Firmware, ForthMon, Forthmacs; info@firmworks.com; fax: 415 917-6990 Specialists in IEEE Std 1275 Boot Firmware Forth Interest Group; John D. Hall; 510 893-6784 PO Box 2154; Oakland; CA 94621; USA " "; fig@taygeta.com; fax: 510 535-1295 Literature & Software Source FORTH, Inc; Elizabeth Rather; 800 553-6784 111 N. Sepulveda Blvd. Ste 300 ; Manhattan Beach; CA 90266; USA polyFORTH ; ERATHER@forth.com; fax: 310 318-7130 Other services include 5-day courses in introductory and FORTH, Inc; Steve Agarwal; 800 553-6784 111 N. Sepulveda Blvd. Ste 300 ; Manhattan Beach; CA 90266; USA chipFORTH; SAGARWAL@forth.com; fax: 310 318-7130 More than 9 cross-development targets Laboratory Microsystems, Inc. (LMI); Ray Duncan; 310 306-7412 PO Box 10430, Marina del Rey, CA 90295 ; Los Angeles; CA 90066; USA UR/FORTH (16-bit), 80386 UR/FORTH (32-bit), WinForth, LMI ; duncan@nic.cerf.net; fax: 310 301-0761 WinForth, LMI Forth-83 Metacompiler MicroProcessor Engineering Ltd.; Stephen Pelc; +44 1703 631441 133 Hill Lane ; Southampton; -- SO15 5AF ; England PowerForth, ProForth ; sales@mpeltd.demon.co.uk; fax: +44 1703 339691 Large range of cross compilers Miller Microcomputer Services; A. Richard Miller; 508 653-6136 61 Lake Shore Road ; Natick; MA 01760-2099 ; USA MMSFORTH ; dmiller@im.lcs.mit.edu; fax: MMSFORTH and many application modules are available in native Mountain View Press, Division of Epsilon Lyra, Inc.; Glen Haydon; 415 747-0760 Star Rt 2 Box 429; La Honda; CA 94020-9726 ; USA MVP Forth (which I wrote)and other public domain ; ghaydon@forsythe.stanford.edu; fax: 415 747 0760 Ext 3 Literature & Software MP7; Marc Petremann; (33) 1 43 03 40 36 17, allee de la Noiseraie; F - 93160 NOISY LE GRAND; ; France Turbo-Forth; 100647.3306@compuserve.com; fax: Offete Enterprises, Inc.; C.H. Ting; 415 574-8250 1306 South B St.; San Mateo; CA 94402; USA eFORTH,F83&; tingch@ccmail.apldbio.com; fax: 415 571-5004 Books & Software for figForth, F83, FPC etc These Firms are primarily hardware vendors Ampro Computers Inc.; ; 408 522-4825 990 Almanor Ave.; Sunnyvale; CA 94086; USA " "; techsupport@ampro.com; fax: 408 720-1305 SBC Inovative Integration; James Henderson; 818 865-6150 31352 Via Colinas #101; Westlake Village; CA 91362; USA ; ; fax: 818 879-1770 TMS320C31, C32, C25, C44 Mosaic Industries, Inc; Patrick Campbell; 510 790-1255 5437 Central Ave Ste 1; Newark; CA 94560; USA " "; ; fax: 510 790-0925 QED SBC Saelig Company; Alan Lowne; 716 425-3753 1193 Moseley Rd.; Victor; NY 14564; USA " "; 71042.17@compuserve.com; fax: 716 425-3835 Rep for Triangle Data Svs Silicon Composers Inc.; George Nicol; 415 961-8778 655 W. Evelyn Ave. #7; Mountain View; CA 94041; USA " "; ; fax: 415 961-6778 RTX 2000 & SC32 boards Triangle Digital Services Ltd.; Peter Rush; +44-181-539-0285 223 Lea Bridge Road; London; UK E1O 7NE; England TDS2020 &; 100065.75@COMPUSERVE.COM; fax: +44-181-558-8110 SBC w/ on board Forth Vesta Technology, Inc; Cyndi Reish; 303 422-8088 7100 W. 44th Ave Ste 101; Wheat Ridge; CO 80033; USA Forth-83+; ; fax: 303 422-9800 SBC w/ Forth in ROM These Firms are primarily custom consulting 4th Wave Computers Ltd.; Peter Caven; 905 335-6844 2314 Cavendish Drive ; Burlington; ON L7P 3P3; Canada " "; p.caven@ieee.org; fax: Custom SW Development in Forth & C A Working Hypothesis, Inc; Paul Frenger; 713 293-9484 PO Box 820506; Houston; TX 77282; USA " "; 70410.1173@Compuserve.com; fax: AM Research; Albert Mitchell; 800 949-8051 4600 Hidden Oaks Lane; Loomis; CA 95650-9479; USA " "; sofia@netcom.com; fax: 916 652-6642 8051, 6811 & 80C166 Forth Dev Systems Bernd Paysan; Bernd Paysan; ++49 89 798557 Stockmannstr. 14 ; 81477 Muenchen; FRG ; Germany BigForth ; paysan@informatik.tu-muenchen.de; fax: ++49 89 794378 Object Oriented Blue Star Systems; Mike Warot; PO Box 4043; Hammond; IN 46324; USA Forth/2 ; ka9dgx@interaccess.com; fax: A direct threaded implementation of forth for OS/2 text mode, 32 bit Compucyber, Inc.; Boris Bibershtein; 416 733-1630 PO Box 3182; North York; ON M2M 3A6; Canada DOS; ; fax: both F-PC and LMI Forth Delta Research; Phil Burk; 415 453-4320 PO Box 151051; San Rafael; CA 94915; USA JForth ; phil@3do.edu; fax: JForth is a subroutine thread Forth for Amiga. Frank Sergeant; Frank C. Sergeant; 809 W. San Antonio St. ; San Marcos; TX 78666; USA Pygmy ; sergeant@axiom.net; fax: I am recommending and/or using Pygmy or one of my specialized Frog Peak Music; Larry Polansky; 603 448-8837 PO Box A36 ; Hanover; NH 03755; USA HMSL - Hierarchical Music Specification Language ; phil@3do.edu; fax: HMSL is a set of music related Forth extensions based on L Squared Electronics; L. G. Lisle; 910 924-0629 2160 Foxhunter Ct.; Winston-Salem; NC 27106; USA Pygtools, Pygmy; L.SQUARED@GEnie.com; fax: Engineering consulting using Forth for industry Michael Hore; Michael Hore; +61-2-557-5836 54 Frederick St ; Sydenham; NSW 02044; Australia Mops ; mikeh@zeta.org.au; fax: Mops is a PD OOP system Redshift Limited; Charlie Springer; 206 564-3315 726 No. Locust Lane; Tacoma; WA 98406; USA " "; RedForth@AOL.com; fax: A simple 32 bit indirect threaded Forth for ARM Rob Chapman; Rob Chapman; 403 430-2605 11120-178 st.; Edmonton; AB T5S 1P2; Canada botKernel, Timbre; rob@idacom.hp.com; fax: 403 430-2772 Science Applications International Corp.; Norman Smith; 615 482-9031 301 Laboratory Road ; Oak Ridge; TN 37831; USA Until, LMI, Uniforth ; smithn@orvb.saic.com; fax: 615 482-6828 Write Your Own Programming Lang. w/ C++ T-Recursive Technology; B.J. Rodriguez; 905 308-3698 221 King St. East, Suite 32 ; Hamilton; ON L8N 1B5 ; Canada ; BJ@headwaters.com; fax: 519 986-4266 Contract programming & hardware design for small/embedded systems TOS Systems Inc.; Roger Stern; 617 431-2456 PO Box 81-128; Wellesley; MA 02181; USA LMI; rstern@world.std.com; fax: 617 431-2456 Software & Hardware Consulting Transport Control Technology Ltd.; Paul Bennett; +44 (0) 117-9499861 7 Broadfield Ave, Kingswood; Bristol; BS15 1HX; UK " "; enquiry@transcontech.co.uk; fax: Company Emphasizes Safety Critical Systems Ultra Technology; Jeff Fox; 510 848-2149 2510 10th St.; Berkekey; CA 94710; USA P21Forth ; jfox@netcom.com; fax: I do consulting on systems besides MuP21 and F21, From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 4 of 6, Forth Systems Date: 21 Aug 96 21:03:26 GMT Expires: 25 Sep 96 20:53:09 Message-ID: References: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part4 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. comp.lang.forth Frequently Asked Questions, part 4 of 6 Forth Systems: Commercial, Shareware, and Freeware Stephen J. Bevan, 19 Sept 1995 Bradford J. Rodriguez, 7 Feb 1996 Jon D. Verne, 1 Mar 1996 Please send omissions or corrections to Jon D. Verne . [This FAQ is adopted in its entirety from the "implementations" FAQ produced by Stephen J. Bevan, last updated September 1995. Thanks Stephen! -bjr] ------------------------------ Table of Contents: [1] Forth for the 8051/8031 [2] Forth for a PC [3] 32-bit protected-mode PC Forth [4] Forth for Windows (3.1/NT/95) [5] Forth for OS/2 [6] Forth for the 6811/68HC16 [7] Forth written in C [8] Forth for UNIX [9] Forth for a Sun [10] Forth for a MAC [11] Forth for an Amiga [12] Forth for an Atari ST [13] Forth for a Transputer [14] Forth for a Tandy TRS-80 [15] Forth for the Apple II [16] Forth for 68000 boards (including cross development from PCs) [17] Forth for (miscellaneous) DSP chips [18] Forth for VMS [19] Forth for playing with Music [20] PD/ShareWare Forth for the BrouHaHa-7245 [21] Forth that isn't necessarily Forth [22] Forth Vendors/Authors [23] Contributors to the FAQ Search for [#] to get to section number '#' quickly. Please note that the sections are in "digest" form so cooperating NEWS/MAIL readers can step through the sections easily. Recent Changes: 95-07-22 bevan Added wpforth listing. 95-07-22 bevan Added OOF listing. 95-07-22 bevan Added Ale Forth listing. 95-07-22 bevan Added gforth description. 95-08-07 bevan Updated 51forth address. 95-08-07 bevan Added author for Pygmy Forth. 95-08-07 bevan Added MacQForth entry. 95-09-13 bevan Updated New Micros address information. 95-09-19 bevan Updated Apple II info. wrt LWV latest Apple II catalogue. 96-01-01 bjr Changed taygeta path. 96-03-01 jdv Added TURBO-Forth listing. Editted duplicate info. 96-04-01 jdv Cut & pasted. Updated Gforth listings. 96-05-01 jdv Updated MacForth listing. 96-06-15 jdv Removed stale DSP listings. 96-06-19 jdv Updated FORTH, Inc., MVP, & Pocket Forth info Please Note: 1. Some of these Forth systems are listed as being available from particular anonymous ftp addresses, or from "good archives". Please try and use as close a site to you as possible. 2. Most of the vendors mentioned herein can supply a Forth system for a wide variety of platforms. If you can't find a Forth system for your platform explicitly listed, try any/all of the vendors listed. 3. If an entry is short it is probably because the system is available on more than one machine. Company addresses, and contact information are in section [22], below. 4. You may quote from this FAQ freely, on the one condition that credit is given to the contributors. Some terms mentioned in this document are known to be trademarks or service marks. However, the author(s) have made no real attempt to mark them as such. The reader should contact the appropriate companies for complete information regarding trademarks and registration. 'Nuff said. ------------------------------ Subject: [1] Forth for the 8051/8031 Commercial: AM Research offer amrFORTH; a cross-development system for the 8051 that features a kernel of less than 700 bytes. FORTH, Inc.: chipFORTH; an interactive cross-development tool for embedded systems. Laboratory Microsystems, Inc. (LMI) sell an 8051 system. Mikrap and Forth Systeme sell SwissForth and act as agents for LMI. MicroProcessor Engineering, Ltd. (MPE) offer the Forth5 Cross Compiler. Offete: 8051 eForth, C. H. Ting. A small ROM based Forth system with source code in MASM for $25. Free: William H. Payne, the author of "Embedded Controller Forth for the 8051 Family", has made all the code for the system described in his book available. Please see ftp://asterix.inescn.pt/pub/forth/8051/read51.txt EFORTH51.ZIP may be downloaded free of charge from the RealTime Control and Forth Board (RCFB) [see] or from the GEnie Forth Interest Group RoundTable. 51forth is a subroutine threaded Forth by Scott Gehmlich. ftp://fims-ftp.massey.ac.nz/pub/GMoretti/51forth.zip [APH:950807] CamelForth/51 by Brad Rodriguez is an ANSI Standard Forth that is free for non-commercial work (negotiate with the author if you want to use it in a commercial product). ftp://taygeta.com/pub/Forth/Camel/cam51-11.zip [SJB:950721] ------------------------------ Subject: [2] Forth for a PC Commercial: FORTH, Inc.: polyFORTH; Real-time system for DOS computers, including libraries for math, graphics, database, GUIs, and many other functions. Harvard Softworks sells HS/FORTH that can link with object files. It makes full use of extended memory, and comes with an optimizer, sound, graphics, and 8087 libraries. MicroMotion: MasterFORTH. [see also: 15] Miller Microcomputer Services (MMS) offer MMSFORTH V2.5 for systems with and without DOS. MPE: PC PowerForth Plus v3.2 and Modular Forth v3.6. LMI offer PC/FORTH, in 16- and 32-bit implementations. They provide libraries for telecommunications, 8087 support, custom characters, target compiler, and more. Also: 8080 FORTH, and 8086 FORTH. MP7: TURBO-Forth. Four versions optimized for specific CPU's. Also: FASTGRAF; an I/O and graphics package for TURBO-Forth. [JDV:960216] Free: eForth is a very portable, ANS-aligned, public-domain Forth that comes with all sources and only 29 words in assembler. [see also: 1, 3, 8] Golden Porcupine Forth, v92.5 by Alexandr Larionov. Distributed as FREEWARE, with Russian docs, for non-commercial work. Includes various useful libraries for graphics, sound &etc. Follows the Forth-83 Standard. Phone: 7 095 288-2660. [VPF:93] Pygmy Forth v1.4 is a small, 16-bit DOS Forth written by Frank Sergeant that is modeled after Chuck Moore's cmFORTH for NOVIX. It is shareware but there is no charge for registration. If you DO choose to register, there is a Bonus Disk with goodies for ~$20. Complete with documented source code, editor, assembler, and metacompiler. MVP-FORTH, a Forth-79 from Mountain View Press, Inc. (MVP), is freely available for different platforms. MVP also offer other commercial Forth systems, information, and books. TCOM v2.5 by Tom Zimmer is a 16-bit cross/metacompiler for DOS. ftp://taygeta.com/pub/Forth/Reviewed/tcom25.zip [SJB:950720] F-PC v3.6 is a 16-bit Forth that is based on the Forth-83 standard but includes numerous extensions. Very complete implementation. ftp://taygeta.com/pub/Forth/Reviewed/fpc36.zip http://www.efn.org/~fwarren/fpc.html [SJB:950722] hForth v0.9.5 by Wonyong Koh is an ANS Forth inspired by eForth. This free beta release is ANS compliant, and all commented MASM source code is included. There are three hForth models to choose from: A standard EXE (for segmented memory machines), RAM (for any other RAM-only system), and ROM (for small embedded systems). The author asserts that it is very easy to optimize for any specific CPU. ftp://taygeta.com/pub/Forth/Reviewed/hf86v09.zip [SJB:950720] wpforth v1.0 by Albert Chan is a prototype of a typographical programming system built around WordPerfect v5.x and Pygmy Forth v1.4. ftp://taygeta.com/pub/Forth/Reviewed/wpforth.zip [SJB:950722] The following are available in any SIMTEL mirror site: 4thcmp21.zip: Native code Forth compiler: COM, EXE, SYS, TSR, ROM bbl_[ab].zip: Fast 16/32-bit Forth based on F83 -- needs work zen1_10.zip: Forth with source to match ANS X3J14, BASIS 10 min4th25.zip: MiniForth system v2.5, with A86 source uniforth.zip: Sampler of floating point Forth compiler fig86.zip: Original Fig-86 Forth compiler [SJB:931030] ------------------------------ Subject: [3] 32-bit protected-mode PC Forth Commercial: Bradley Forthware sells Forthmacs for $250. Price includes source and DOS extender. FORTH, Inc.: polyFORTH. [see] Harvard Softworks has a version of HS/FORTH that provides access to a full, flat 4Gb of memory. [JVN:93] LMI sell a 32-bit protected-mode Forth called 80386 UR/FORTH. It runs on DOS and is based on the 'Phar Lap' DOS Extender. It is fully compatible with XMS, EMS, and DPMI memory managers. MPE ProForth for DOS, v2.0. Offete has a protected-mode 32-bit eForth that comes with source code and a public domain DOS extender. bigFORTH by Bernd Paysan. [see] Free: eForth is available as a 32-bit port by Andy Valencia. [see also: 8] FROTH is a free 32-bit Forth system, with source, available on Taygeta. Gforth v0.1b is a GNU C-forth for Linux/DOS. [see also: 7, 8] OOF is an object-oriented 32-bit Forth System written by Zsoter Andras. It does not use a threaded paradigm, and generates native machine code. Although many ANS Forth programs will run on OOF, it is not fully ANS Forth compliant. All source is under the GNU General Public License. ftp://taygeta.com/pub/Forth/Reviewed/oof.zip [SJB:940722] Ale Forth by Johns Lutz Sammer. Implements ANS Basis 17 wordset along with lots of extensions. Supports subroutine threading, native code generation and inline words. ftp://taygeta.com/pub/Forth/Reviewed/alefth.zoo [SJB:940722] ------------------------------ Subject: [4] Forth for Windows (3.1/NT/95) Commercial: Bradley Forthware Forthmacs is available for Windows 3.1 and costs $250. It includes an emacs editor and comes complete with source. LMI WinForth v1.01 is a 16-bit Forth for Windows 3.1 available from their BBS for a $100 (US) fee. ftp://taygeta.com/pub/Forth/Reviewed/wfshr101.exe [SJB:940721] MPE ProForth v1.420 for Windows 3.1x, NT, and Win95. A very complete environment for Windows applications development. FORTH, Inc., are agents in North America for MPE's ProForth for Windows. Free: Jax4th, a freeware 32-bit Forth for Windows NT complete with source code. The current version features complete access to NT DLL's and BLOCK loading facility. Written in MASM by Jack Woehr [see]. ftp://ftp.cygnus.com/pub/forth/JX4NT106.ZIP [JJW:931021] LMI WinForth. [see above] Win32forth v1.20292 by Tom Zimmer and Andrew McKewan. ftp://taygeta.com/pub/Forth/Reviewed/win32for.zip [SJB:940721] ------------------------------ Subject: [5] Forth for OS/2 Commercial: Forth/2 by Michael A. Warot [see] and Brian Mathewson [see] can be licensed for commercial work. Talk to Brian if you have something to add or you have any suggestions regarding Forth/2. Contact Michael if you want to obtain a commercial license and/or source code. ftp://ftp-os2.cdrom.com/pub/os2/2_x/program/forth025.zip ftp://ftp-os2.nmsu.edu/os2/2_x/program/forth025.zip Free: Forth/2 by Michael A. Warot and Brian Mathewson is available by ftp for non-commercial work. [see above] ------------------------------ Subject: [6] Forth for the 6811/68HC16 Commercial: AM Research support their development boards with amrFORTH; a complete cross-compiler system for the '68xx family. FORTH, Inc.: chipFORTH. [see] MPE Forth5 Cross Compiler. New Micros, Inc., has Max-FORTH which is burned into the ROMs of their OEM '6811 development boards. Max-FORTH uses a serial port to talk to the outside world, and can be compiled to off-chip ram. [BL:931117] Free: various at ftp://asterix.inescn.pt/pub/forth/68hc11/ and ftp://ftp.taygeta.com/pub/Forth/Archive/68hc11/ ------------------------------ Subject: [7] Forth written in C Commercial: Bradley Forthware C-Forth costs $100. Free: ThisForth v1.0.0.d is an ANS Forth written by Will Baden. You will need M4 and an ANSI-C compiler to compile it. Binaries are available for a number of architectures (CRAY, MIPS, SUN, SGI). ftp://taygeta.com/pub/Forth/ANS/this4th.tar.gz [SJB:940720] PFE (Portable Forth Environment) v0.9.14 is an ANS compatible Forth implementation written in ANSI-C. All the code is under the GNU General Public Licence. Binaries for various architectures available. ftp://taygeta.com/pub/Forth/ANS/pfe*.* [SJB:940720] Gforth is a fast and portable implementation of the ANS Forth language. It works nicely with the emacs editor, offers some nice features such as input completion and history and a powerful locals facility, and it even has (the beginnings of) a manual. Distributed under the GNU General Public license. Gforth runs under UN*X and DOS and should not be hard to port to other systems supported by GCC. Gforth-0.1beta has been tested successfully on Linux (Intel), SunOS (SPARC) and Ultrix (MIPS). http://www.complang.tuwien.ac.at/forth/gforth/ ftp://ftp.complang.tuwien.ac.at/pub/forth/gforth/ HENCE4TH v1.2 - A figForth written in C that currently runs under V7 Unix, Personal C Compiler, and Mix Power C. Porting to other platforms should be trivial, considering how vastly different these three are! ftp://wuarchive.wustl.edu/msdos/forth/ [KH:93] C-Forth available from comp.sources.unix and also ftp://asterix.inescn.pt/pub/forth/unix/c-forth.tar.z TILEforth by Mikael Patel is a 32-bit Forth-83 written in C. Until v2.5.1 is (almost) Forth-83 written in C. Its internals are described in the book "Write Your Own Programming Language Using C++" (ISBN# 1-55622-264-5) by Norman Smith . This implementation was designed to call, and be called, by other C functions; so it is ideal as a 'macro' language embedded in C/C++ applications. Comes with 175 pages of documentation. ftp://taygeta.com/pub/Forth/Reviewed/until251.zip [SJB:950720] ------------------------------ Subject: [8] Forth for UNIX Commercial: Bradley Forthware's Forthmacs. [see] Free: 68K: An indirect threaded 32-bit Forth based on the 83 standard. Written in 68K assembly (Motorola format) by Andy Valencia ftp://asterix.inescn.pt/pub/forth/68000/forth-68000.tar.Z [SJB:94] Forth-83: A UN*X port is available. ftp://ftp.taygeta.com/pub/Forth/Archive/f83.tar.z PDP-11: A version of figForth in PDP-11 assembler is available. ftp://asterix.inescn.pt/pub/forth/others/pdp114th.zip [SJB:950718] Linux/i386: An eForth v1.0 port (by Francois-Rene Rideau) to Linux on an i386 architecture is based on the DJGPP/GO32 version by Andy Valencia. ftp://taygeta.com/pub/Forth/Reviewed/linux-eforth-1.0c.tar.gz [SJB:950720] eForth [see] has been also ported to Linux by Marcel Hendrix. See also: [7] ------------------------------ Subject: [9] Forth for a Sun Commercial: Bradley Forthware: Their Forthmacs costs $200. It comes with source code, an assembly debugger, and floating point routines. Free: Open Boot PROM: built-in to the SPARCstation PROMs. Inaccessible from the UNIX environment; you have to interrupt the boot process and then type 'n' to get to Forth. For more information on this see http://www.firmworks.com [SJB:950720] See also: [7] & [8] ------------------------------ Subject: [10] Forth for a MAC Commercial: Bradley Forthware: Forthmacs is available for $50. MacForth by Creative Solutions, Inc.; acquired by FORTH, Inc. Includes MacForth Plus, the latest version of the popular MacForth system first introduced in 1984, and the new Power MacForth, a highly optimized version for Power Macintoshes. MacForth: US$199, Power MacForth: US$299 See the review in Dr. Dobb's Journal, #108 (1985). Micromotion offer a version of their MasterForth for the Mac. Free: Yerk is an object-oriented language based on Forth for the Macintosh and was originally a product marketed as Neon (reviewed in Dr. Dobb's #108, 1985). Yerk runs on all Macs with at least System 6.0 but requires System 7.0 (or greater) for full compatibility. ftp://astro.uchicago.edu/pub/MAC/Yerk/yerk_367.sea.bin ftp://astro.uchicago.edu/pub/MAC/Yerk/yerkManual3.67.sea.bin Mops v2.7, by Michael Hore, is an object oriented Forth also derived from Neon [see]. There is a PPC native version in the works. http://www.netaxs.com/~jayfar/mops.html ftp://taygeta.com/pub/Forth/Mops/Mops26s.sea ftp://taygeta.com/pub/Forth/Mops/Mops26m.sea [SJB:950718] Pocket Forth v6.5, by Chris Heilman. Subroutine threaded with 16-bit words. Supports 16-bit relative, 32-bit absolute addressing. Allows "inline" definitions, but doesn't have an in-line assembler. Minimal Toolbox support; but it does supports Apple Events. Comes as a 17K application, and a desk accessory. Distribution comes with complete source; the kernel is in assembly. There is a MPW version available. http://chemlab.pc.maricopa.edu/pocket/pocket65.sit.hqx ftp://kreeft.intmed.mcw.edu/q/pub/forth/Pocket65.cpt.hqx MacQForth is an adaptation of (Apple II) QForth to the Macintosh. Created with Mops [see] and accompanied by the Mops sources. An attractive introductory package, including some witty and instructive material proselytizing on behalf of Forth. ftp://kreeft.intmed.mcw.edu/q/pub/mac/macqforth.cpt.hqx [BB:950807] ------------------------------ Subject: [11] Forth for an Amiga Commercial: Delta Research: JForth Professional 3.x true-compiled Forth for $179.95. Includes a tutorial, libraries, and examples. [MH:93] Free: A4th by Appleman is a 32-bit port of L&P F83 complete with metacompiler written for the A1000. ftp://asterix.inescn.pt/pub/forth/amiga/a4th*.* [JJW:931021] Joerg Plewe: F68K and F68KANS should work if you can obtain/implement a loader. Jax4th is a dp-ANS2 implementation by Jack J. Woehr. It is available on the RCFB [see]. [JJW:931021] MVP-FORTH by MVP is available for the Amiga at various sites. Try http://src.doc.ic.ac.uk/aminet/dev/lang/MVP-FORTH.lha ------------------------------ Subject: [12] Forth for an Atari ST Commercial: Bradley Forthware: Forthmacs is available for $50 w/ optional GEM support. Bernd Paysan: bigFORTH is available for 200 DM. Extras: Source code, floating point, GEM interface, object-oriented FORTH, native code compiler. F68KANS by Joerg Plewe. As per the free version, but you can use it commercially. Contact Joerg for licensing details. HiSoft FORTH is a 32-bit Forth for the Atari ST, with full support for GEM. It is subroutine threaded, and a Motorola 68000 assembler is also included. The price in the UK is about 39 pounds. [HM:93] Free: F68K and F68KANS by Joerg Plewe. ------------------------------ Subject: [13] Forth for a Transputer Commercial: MPE Forth5 Cross Compiler. Offete: eForth [see] has been ported to the Transputer by Bob Barr. Free: There is a free/public-domain Transputer Forth written by Laurie Pegrum available. It is an implementation of Forth for 16 & 32-bit Transputers that includes source. It requires the D705 occam development system, and a 32-bit Transputer board with 1M of memory to recompile. ftp://unix.hensa.ac.uk/parallel/software/forth ------------------------------ Subject: [14] Forth for a Tandy TRS-80 MMS: MMSFORTH v2.4 nonDOS version only. MVP: MVP-FORTH for the Model 4, by Art Wetmore. ------------------------------ Subject: [15] Forth for the Apple II Commercial: Apple Forth v1.6: Cap'n Software - Uses a unique disk format. [LWV:93] 6502 Forth v1.2: Programma International. [LWV:93] FORTH II for the II+ or //e by Softape. [LWV:93] Raven Forth (+) by C. K. Haun, runs on IIgs. Available on GEnie Library 19 as file 903. [LWV:950919] MicroMotion: MasterFORTH for II's. Features: graphics, debugger, file handling, software floating point. MVP offer MVP-FORTH; a 79-standard for II's. Free: GraFORTH(+) for DOS 3.3, by Paul Lutus. Available on GEnie Library 8, file 3299. [LWV:950919] Mad Apple Forth(+) ftp://wuarchive.wustl.edu/system/apple2/Lang/Forth [LWV:93] Purple Forth(+) ftp://cco.caltech.edu/pub/apple2/8bit/source [LWV:93] QForth(+) v2.0, Alpha 1.0, is a small integer Forth written by Toshiyasu Morita ftp://ftp.uu.net/systems/apple2/languages/forth [LWV:93] GS 16 FORTH II, Version II (+) - A 16-bit implementation able to make use of the GS Toolbox. Includes assembler and full screen editor. ftp://cco.caltech.edu/pub/apple2/source/GS16Forth.shk Also available on GEnie: Library 18, file 2124/2125. [LWV:950919] ------------------------------ Subject: [16] Forth for 68000 boards (including cross development from PCs) Commercial: Bradley Forthware: ForthMon is available for $500. FORTH, Inc.: chipFORTH. [see] MPE: Forth5 Cross compiler. LMI offer 68000 FORTH that comes with a target compiler and more. Free: There is a version of Laxen and Perry's F83 which will metacompile 68000 code on a PC that can be burned to ROM, or used with S records any way you like. It is available on GEnie as M16PC.ARC. [MC:93] bot-Forth: The source code is comprised of 3 parts: the metacompiler, mini-assembler, and the kernel. The kernel will metacompile itself. The metacompiler was presented at the 1989 Rochester Forth Conference. ftp://asterix.inescn.pt/pub/forth/68000/botfth68.arc ~/botforth.txt [SJB:93] Joerg Plewe: F68ANS and F68K [see] eForth for the VME 68K. A subroutine threaded implementation of ECBE4TH 32-bit eForth, derived from Haskell, is available on GEnie as MVME167.ZIP. ------------------------------ Subject: [17] Forth for (miscellaneous) DSP chips Commercial: FORTH, Inc. offers a version of chipForth for the ADSP2020. Offete: A port of eFORTH to ADSP2100 is being contemplated. [any info?] Micro-K Systems produce complete AT&T DSP32 boards running Forth. Includes the AT&T DSP library. MPE Forth5 Cross Compiler for various DSP chips. Free: A port of eForth to the 56002 DSP is available. Contact the author, Dave Taliaferro , for information. ------------------------------ Subject: [18] Forth for VMS You can find three Forth implementations in ftp://hpcsos.col.hp.com/mirrors/forth/vax [SJB:950721] Klaus Flesch wrote a VAX VMS Forth some years ago. It is believed to be derived from FIG-FORTH. Availability is uncertain, try contacting the author c/o Forth Systeme. See also: [7] & [8] as some C and UNIX based systems (may) port without (too) much effort. ------------------------------ Subject: [19] Forth for playing with Music HMSL (Hierarchical Music Specification Language); Frog Peak Music. Contact Delta Research, or Phil Burk , at the Center for Contemporary Music at Mills College. ------------------------------ Subject: [20] PD/ShareWare Forth for the BrouHaHa-7245 CP/M/Z80 CamelForth/80 by Brad Rodriguez is an ANSI Standard Forth that is free for non-commercial work (please negotiate with the author if you want to use it commercially). ftp://taygeta.com/pub/Forth/Camel/cam80-12.zip [SJB:950721] 6809 CamelForth/09 by Brad Rodriguez. Free. [see above for restrictions] ftp://taygeta.com/pub/Forth/Camel/cam09-10.zip [SJB:950721] Archimedes/RISCOS Forthmacs is Hanno Schwalm's port of Mitch Bradley's Forthmacs v3.0. This Risc-OS Forthmacs follows the Forth-83 standard, and has been written with portability to other platforms and former versions in mind. It runs almost any software that has been written for Forthmacs, or will with very little re-coding. ftp://taygeta.com/pub/Forth/Reviewed/forthmacs.arc ------------------------------ Subject: [21] Forth that isn't necessarily Forth Commercial: FIFTH by Software Construction Co. Available for the Amiga, PC. Charles Moore's OK for PC's. Available through Offete Enterprises for around $75. [RH:940314] Free: Kevo by Antero Taivalsaari is a prototypical (classless) object-oriented language which has a Forth feel to it. Runs on Macs. Features multitasking, dynamic memory management, and an integrated Mac Finder -like iconic programming environment. Comes with source, demo programs, and some documentation. ftp://cs.uta.fi/pub/kevo/* [AT:931021] ANNforth by Bruce J. McDonald. No documentation, but a header file states "ANN simulator with forth interpreter". Written in C++. ftp://ftp.taygeta.com/pub/Forth/Archive/unix/annforth.arc [SJB:931026] ------------------------------ Subject: [22] Forth Vendors/Authors AM Research, 4600 Hidden Oaks Lane, Loomis, CA 95650 USA phone: (916) 652-7472 or 1-800-949-8051 http://www.amresearch.com Bernd Paysan, Stockmannstr. 14, D-81477 Munchen, GERMANY email: paysan@informatik.tu-muenchen.de Products: bigFORTH 386, bigFORTH ST Bradley Forthware, Inc., P.O. Box 4444, Mountain View, CA 94040 USA voice: (415) 961-1302 fax: (415) 962-0927 email: wmb@forthware.com Products: Forthmacs, ForthMon, C Forth, floating point libraries Computer Continuum, 75 Southgate Ave., Suite 6, Daly City, CA 94015 USA Eric Reiter, engineer and owner phone: (415) 755-1978 Products: Specialists in motion control and data acquisition Creative Solutions 4701 Randolph Road, Suite 12, Rockville, Maryland 20852 USA phone: (301) 984-0262 or 1-800-FORTH-OK On CompuServe 'GO FORTH' to go to the Forth SIG they sponsor. Delta Research, P.O. Box 151051, San Rafael, CA 94915-1051 USA phone: (415) 453-4320 Products: JForth Professional 3.x for $179.95, HMSL (Hierarchical Music Specification Language) [w/ Frog Peak Music] FORTH, Inc. 111 N. Sepulveda Blvd., Suite 300, Manhattan Beach, CA 90266-6847 USA phone: (310) 372-8493 or (US only) 1-800-55FORTH fax: (310) 318-7130 email: forthsales@forth.com http://www.earthlink.net/~forth Products: polyFORTH, chipFORTH, MPE's ProForth for Windows, programming courses and custom programming services, MacForth Forth Systeme, P.O. Box 1103, Breisach, GERMANY phone: 7767-551 Harvard Softworks, P.O. Box 69, Springboro, OH 45066 USA phone: (513) 748-0390 Products: HS/FORTH Chris Heilman, PO Box 8345, Phoenix, AZ 85066-8345 USA email: heilman@pc.maricopa.edu compuserve: 70566,1474 Products: Pocket Forth HiSoft, email: hisoft@cix.compulink.co.uk Joerg Plewe, Haarzopfer Str. 32, D-45472 Muelheim an der Ruhr, GERMANY phone: (+49)-(0)208-497068 email: joerg.plewe@mpi-dortmund.mpg.de Products: F68K, F68KANS Laboratory Microsystems, Inc. (LMI) 12555 W. Jefferson Blvd., Suite 202, Los Angles, CA 90066 USA voice: (310) 306-7412 fax: (310) 301-0761 BBS (310) 306-3530 email: lmi@nic.cerf.net Products: 68000 FORTH[+], 8080 FORTH[+], 8086 FORTH[+], PC/FORTH[+], Z80 FORTH[+] Miller Microcomputer Services (MMS) 61 Lake Shore Road, Natick, MA 01760-2099, USA. phone: 617/653-6136 (9am-9pm EST) email: dmiller@im.lcs.mit.edu Products: MMSFORTH V2.5, MMSFORTH/MS-DOS, TGRAPH vector graphics, DATAHANDLER and DATAHANDLER-PLUS flat-file databases, FORTHWRITE word-processor EXPERT-2 expert system, MMSFORTH V2.4, Forth books, and some Conference Proceedings (email book list sent by request) MP7: 17, allee de la Noiseraie, F-93160 NOISY LE GRAND, FRANCE phone: (33) 1 43 03 40 36 email: 100647.3306@compuserve.com http://ourworld.compuserve.com/homepages/mp7 Products: TURBO-Forth, FASTGRAF graphics & I/O package, French-language Forth books MicroProcessor Engineering, Ltd. (MPE) 133 Hill Lane, Shirley, Southampton, SO1 5AF U.K. phone: 01703-631441 fax: 01703-339691 email: mpe@mpeltd.demon.co.uk U.S. contact: AMICS Enterprises (phone: 716-461-9187) Canadian contact: Universal Cross-Assemblers (phone: 506-847-0681) Products: Forth5 Cross Compiler (v5.1) for target chips: 80x96, 8031/51x/55x, 68HC1[16], 680x0/68332, Z80/64180, TMS320C3x, H8/500, RTX2000/1A/10. PC PowerForth Plus v3.2, Modular Forth v3.6 for MS-DOS, ProForth for DOS v2 (was PowerForth/386), ProForth for Windows v1.4, free catalogue MicroMotion, 12077 Wilshire Boulevard, Los Angeles, CA 90025 USA phone: (213) 821-4340 Products: MicroMotion FORTH-79, MasterFORTH Mountain View Press (MVP), Box 429, Star Route 2, La Honda, CA 94020 USA New Micros, Inc. (NMI), 1601 Chalk Hill Rd., Dallas, Texas 75212 USA phone: (214) 339-2204 fax: (214) 339-1585 email: general@newmicros.com http://www.newmicros.com/general Offete Enterprises, Inc., 1306 South B Street, San Mateo, CA 94402 USA phone: (415) 574-8250 Software Construction Co., Inc. 2900B Longmire College Station, Texas 77845 USA phone: (409) 696-5432 Michael A. Warot, PO BOX 4043, Hammond, Indiana 46324 USA email: ka9dgx@chinet.com Brian Mathewson, 21576 Kenwood Avenue, Rocky River, OH 44116-1232 USA email: bbm@r2d2.eeap.cwru.edu Products: Forth/2 for OS/2 2.0 Jack J. Woehr, sysop of the RealTime Control and Forth Board (RCFB) BBS: (303) 278-0364 email: jax@cygnus.com ------------------------------ Subject: [23] Contributors to the FAQ Thanks to the following for providing the information that makes up this section of the FAQ: BB: Bruce Bennet SJB: Stephen J Bevan MB: Mitch Bradley MC: Mike Coughlin VPF: Valery P Frolov MH: Mike Haas KH: Kevin Haddock RH: Rick Hoensee APH: Andrew P. Houghton CL: Nan-Hung (Carl) Lin BL: Benjamin Lee HM: Henry McGeough DM: Dick Miller JVN: Julian V. Noble BP: Bernd Paysan AT: Antero Taivalsaari JDV: Jon D. Verne LWV: Larry W. Virden JJW: Jack J. Woehr From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 5 of 6, Forth Books Date: 21 Aug 96 21:03:41 GMT Expires: 25 Sep 96 20:53:09 Message-ID: References: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part5 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. comp.lang.forth Frequently Asked Questions, part 5 of 6 Books, Periodicals, and Tutorials Chris Jakeman, 28 July 1996 Changes since the previous posting are marked with a "|". Please send your updates, comments or suggestions to me at cjakeman@apvpeter.demon.co.uk. ------------------------------ Subject: Table of Contents [1] Periodicals [2] Standards Documents [3] Books - Organisation [4] Books - Tutorial [5] Books - Advanced [6] Books - Related [7] Suppliers [8] Indexes ------------------------------ Subject: [1] Periodicals Forth Dimensions (ISSN 0884-0822) Published 6 issues/year to members; Marlin Ouverson, editor . Subscriptions are US$40/year (before March 1, 1996), plus US$15/year for foreign subscriptions. Forth Interest Group, P.O. Box 2154, Oakland, CA 94621 USA, 'phone 510-893-6784, fax 510-535-1295. Advertising sales: 'phone 805-946-2272. Brad Rodriguez writes: Forth Dimensions is the official publication of the Forth Interest Group, and is probably the foremost journal devoted exclusively to the Forth language. It is in its 17th year of publication. FORML and euroForth Conference Proceedings Published annually by FIG at $40; Robert Reiling, director . FORML is an educational forum for sharing and discussing new or unproved proposals intended to benefit Forth. The first conference was held in 1980 and euroForth conferences began in 1992. FIG (above) published an index for these. Rochester Forth Conference Published annually by the Institute for Applied Research at $25 to $35 (depending on year); Larry Forsley, director . The conference covers all topics of Forth implementation and application. Conferences began in 1981. See http://maccs.dcss.mcmaster.ca/~ns/96roch.html for this year. Does anyone have information about: - conferences in Australia, China etc.? - "More on Forth Engines" Dr.C.H.Ting, Editor? Journal of Forth Application and Research (ISSN 0738-2022) Published nominally 4 issues/year; Len Zettel, editor . Journal of Forth Application and Research, 70 Elmwood Avenue, Rochester, NY 14611 USA, telephone 716-235-0168. Brad Rodriguez writes: JFAR is the only peer-reviewed Forth journal. It is currently being revived after a long hiatus; the last issue was published in 1994. Len Zettel has assumed the post of editor, and is soliciting contributions to the Journal. The Computer Journal Published 6 issues/year; Dave Baldwin, editor . Subscriptions are US$24/year in U.S., US$34/year Canada/Mexico (air mail), US$44/year foreign (air mail). The Computer Journal, P.O. Box 3900, Citrus Heights, CA 95611-3900 USA, telephone 916-722-4970, fax 916-722-7480, email tcj@psyber.com, . Brad Rodriguez writes: The Computer Journal is not a Forth magazine; it is devoted to "classic", small, and non-mainstream computers. It frequently carries articles about the Forth language. Some national FIG groups publish their own periodicals, eg FIG UK and Forth-Gesellschaft e.V. See the FAQ: groups - part 6/6 for details. ------------------------------ Subject: [2] Standards Documents For details of the Forth standards see the FAQ: general - part 1/6. Published standards since 1978 are Forth 79 and Forth 83 from the Forth Standards Team, ANS Forth - document X3.215-1994 - by the X3J14 Technical Committee and the Open Boot Standard. The most recent standard, ANS Forth, defines a set of core words and some optional extensions and takes care to allow great freedom in how these words are implemented. The range of hardware which can support an ANS Forth Standard System is wider than any previous Forth standard and probably wider than any programming language standard ever. The document includes 90 pages of annexes, providing an insight into the decisions which had to be taken in drafting ANS Forth. Copies of the standard cost $193 from the American National Standards Institute Sales Department (212) 642-4900, but the final draft of ANS Forth is free and available (subject to copyright restrictions) at: ftp://ftp.uu.net/vendor/minerva/x3j14/dpans94.zip (Word For Windows, v2) ftp://ftp.uu.net/vendor/minerva/x3j14/dpans94.hqx (Word For Macintosh) ftp://taygeta.com/pub/Forth/Literature/dpans94a.zip (plain ASCII) The Open Boot Standard defines the use of Forth to configure the hardware attached to a computer at startup. It is a token-threaded, open standard closely modelled on ANS Forth used by Sun, IBM, Motorola and Apple. IEEE Std 1275-1994 is recognised as an American National Standard: "IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices, 262p, ISBN 1-55937-426-8, about $60 from IEEE Computer Society, email stds.info@ieee.org. ------------------------------ Subject: [3] Books - Organisation There is not space here to provide an abstract to every book on Forth. Instead this is a guide to those items which Forth users have found most helpful, together with a list of other Forth books. If you have been especially helped by a book, please write me an abstract for it. Where publications are not widely available, a supplier is listed. Approximate prices are given as a guide. ------------------------------ Subject: [4] Books - Tutorial "Starting FORTH: an introduction to the FORTH language and operating system for beginners and professionals" Leo Brodie, Prentice Hall 1981 (2nd Ed., 1987), 346 pages, ISBN 0-13-842922-7, price $29. Chris Jakeman writes: This is the classic introduction to Forth, with helpful cartoons, exercises and solutions. See also Brodie's "Thinking Forth" below. "The Forth Course" Richard Haskell, 156 pages with disk, price $25, supplier FIG. FIG writes: This set of 11 lessons is designed to make it easy for you to learn Forth. The material was developed over several years of teaching Forth as part of a senior/graduate course in desing of embedded software computer systems at Oakland Univeristy in Rochester, Michigan. "FORTH: A Text And Reference" Mahon Kelly and Nick Spies, Prentice-Hall, 1986, 487pps ISBN 0-13-326331-2 and in hardcover 0-13-326349-5, $19 and $25 from MMS below. Dick Miller writes: Very readable, covers beginner level through relatively advanced, including Assembler and 8087 math co-processor details, particularly appropriate to IBM PC and MMSFORTH, but very strong for general use as well. The only college-level Forth textbook, complete with exercises and answers. "Forth Applications In Engineering And Industry" John Matthews, Ellis Horwood, 1989 ISBN 0-85312-659-3, price UKP35. Currently out of print, this book may be available from libraries. MPE Ltd. writes: If you are starting out in the field of real-time control of hardware using Forth, then this book is for you! This text covers most aspects of real-time control under Forth, from the very basics of what Forth is, through to control loops and digital implementations of analogue filters. "Embedded Controller FORTH for the 8051 family" William H. Payne, Academic Press, 1990, 511 pages with DOS disks, ISBN 0125475705, price $72 book, $20 disk. J. Fulcher, Computing Reviews, 9105-0316 writes: ... This hobbyist-style book goes into considerable detail regarding the implementation of FORTH on the i8051 family of microcontrollers (down to circuit diagrams, PCB layouts, and wire-wrap board schematics) ... Almost two-thirds of this book is devoted to appendices -- 19 in all. These primarily contain code listings ... Paul Frenger, SIGFORTH, 2(4):31-32, 1990 reviews the book and gives it 10/10. Notes that the book contains everything you need: all the source is there as well as all the circuit diagrams. There are 19 appendices, which make up half of the book, and contain things like: the source to the 8086 Forth, 8051 Forth, full screen editor code, 8051 disassembler code, Nautilus metacompiler, 8086/8051 meta-assemblers, Forth decompilers and much more. See also the FAQ: on-line - part 2/6, for tutorials and Forth systems to try them on. Other titles are: 90, Zech, Forth for Professionals, Ellis Horwood, 0-13-327040-8 88, Tracy, Mastering Forth 87, Henric-Coll, La Practique du Forth avec Hector I 85, Bishop, Exploring Forth, Prentice-Hall, 0-246-12188-2 85, Burnap, Forth, The Fourth-Generation Language 85, Olney and Benson, Fundamental Forth, Pan Books 85, Salman, Forth 84, Anderson, Mastering Forth, Bowie (yes, same title as Tracy above :) 84, Armstrong, Learning Forth 84, Chirlian, Beginning Forth 84, Lampton, Forth for Beginners 84, Oakley, Forth For Micros, Newnes Technical Books, 0-408-01366-4 83, de Grandis-Harrison, Forth on the BBC Microcomputer, 0-907876-06-4 83, McCade, Forth Fundamentals, Matrix 83, Winfield, The Complete Forth, Sigma Technical Press, 0-905104-22-6 82, Hogan, Discover Forth, Osborne 82, Scanlon, Forth Programming, Sams 81, Katzan, Invitation to Forth, Petrocelli Books 81, Knecht, Introduction To Forth, Sams Hendtlass, Real-Time Forth (on-line only http://www.forth.org/fig.html) Pitman, Pocket Guide to Forth MVP-Forth Series 1 - All About Forth, '90, Haydon 2 - MVP Forth source listings, '83?, Haydon & Kuntz 3 - Integer and Floating Point, '83, Koopman 4 - Expert System, '84, Park 5 - File Management System, '84, Moreton 6 - Expert Tutorial, '84, Derick 7 - Forth Guide, '85, Haydon 8 - IBM Professional Application Development System, '85, Wempe 9 - Word Processor And Calculator, Programmers Guide, '85, Wempe 10 - Word Processor And Calculator, File & Print source, '85, Wempe ------------------------------ Subject: [5] Books - Advanced "Scientific FORTH: a modern language for scientific computing" Julian V. Noble, Mechum Banks Publishing, 19??, 300 pages, ISBN 0-9632775-0-2, price $50. Julian V. Noble writes: While not intended for the Forth novice, Scientific FORTH contains a good many serious examples of Forth programming style, useful programs, as well as innovations intended to simplify number crunching in Forth. It can now be found in the libraries of several major universities (e.g. Yale, U. of Chicago and Rockefeller U.) and government and industrial laboratories (e.g. Fermilab and Motorola). It comes with a disk containing all the programs discussed in the book. An update file has recently been posted to GEnie/FIG. "Thinking FORTH" Leo Brodie, Prentice Hall, 1984, ??? pages, ISBN: 0-13-917576-8 and 0-13-917568-7 (pbk.), price $20. Dick Miller writes: This is a top-notch book on strategy, and always was our [MMS] top recommendation for the SECOND book, after you bought a textbook to learn the Forth words. This one teaches you which ones to select when, how to hone your habits for better Forth (and other) programming, etc. It's been unavailable for a year or two, and has been reprinted at last! MMS has worked to reduce its price from a proposed $40 (in paperback), and is pleased to offer it at $19.95. "Forth: The Next Step" Ron Geere, Addison-Wesley, 1986, 89 pages, ISBN 0-201-18050-2, price ??. Stephen J. Bevan writes: As the title might suggest, this is not for the complete beginner. It is aimed at those who have mastered the idea of reverse polish ... etc. and now want to do something a bit more complicated. Covers areas like: using double length numbers, formatting, reading/writing values from/to a port and `infinite' precision integers. "Object-oriented Forth - Implementation of Data Structures" Dick Pountain Academic Press, 1987, 108 pages, ISBN 0-12-563570-2, price $35. Chris Jakeman writes: Pountain is a Byte contributing editor. His "book sets out to develop systematic ways of constructing complex data structures in Forth ... with a few easy to use syntax extensions to the language." Efficient techniques for records and arrays are presented and refined with great clarity. Objects are built from these by adding methods with a small change to the dictionary structure. The techniques are demonstrated using lists, a heap and a dynamic simulation of queuing at the bank. "Forth: The New Model - A Programmer's Handbook" Jack Woehr, M&T Publishing, 1992, 315 pages, ISBN: 0-13-036328-6, DOS disk included, price $45. Describes features of ANS Forth and how to use it to write portable Forth programs. Published 2 years before the Standard was approved, it predicts the Standard very closely. Currently the only book about ANS Forth. Ong Hian Leong writes: The author is (as at time of print) VP of Forth Interest Group and member of X3J14, so he presumably knows what he's talking about. 8-) Other titles are: 87, Dr.Dobb's Toolbook of Forth, Vols I & II, M&T Publishing 86, Reynolds, Advanced Forth, Sigma 86, Terry, Library of Forth Routines and Utilities 85, Olney and Benson, Forth Techniques, Pan Books, 0-330-28961-6 85, Roberts, Forth Applications, ELCOMP Publishing, 3-88963-061-8 84, Feierbach, Forth Tools and Applications, Reston 81, Loeliger, Threaded Interpretive Languages, Byte Books, 0-07-038360-x ----------------------------- Subject: [6] Books - Related "The Evolution Of FORTH - An Unusual Language" C.H.Moore, Byte, Aug. 1980. Forth's history by its creator. "The Evolution of Forth" E.D.Rather, D.R.Colburn, C.H.Moore, ACM SIGPLAN Notices, Volume 28, No.3 March 1993, 46 pages. An larger and more recent history of Forth by the early pioneers. This is also available on the Forth Inc. home page at http://home.earthlink.net/~forth "Stack Computers: The New Wave" Phillip Koopman, John Wiley & Sons, 1989, ISBN 0-470-21467-8, price $82. Stephen J. Bevan writes: This isn't a book about Forth, rather it is about computers that potentially execute Forth very efficiently. The book contains a detailed overview of a number of Forth chips as well as a potted history of what seems to be every stack-based computer ever designed. Paul Frenger, SIGFORTH, 1(3):28-29, 1989 writes: Overall, I highly recommend this book to anyone who programs in Forth or any other high level language of whatever variety, or who is interested in the hardware details of Forth engines or the pitfalls of conventional CPU design. | The author reports (July 96): | My stack computer architecture book has recently gone out of print, | but I still receive occasional inquiries as to availability. The | former publisher, Ellis Horwood Ltd., has graciously returned the | copyright ownership to me. So, I have decided to place the book | on-line at http://www.cs.cmu.edu/~koopman/stack_computers/index.html | | The book contains, among other things, case studies of seven late-80's | stack computers. Perhaps there is renewed relevance with Java (and, | perhaps not -- that question has already been debated at length). | The book is still copyrighted, but is readable in its entirety from | the above URL (see the copyright statement at that URL for details). | | I don't have time, and there doesn't seem to be market demand at this | point, for a revised edition. However, if you e-mail me pointers to | web sites that describe newer stack computer information, I will | consider putting them in the on-line supplement as time permits. "Write Your Own Programming Language Using C++" Norman Smith, Wordware Publishing, Plano, Texas. 108 pages, DOS disk included, ISBN 1-55622-264-5, price: $15. Norman E. Smith writes: This book presents a minimal Forth implementation called Until, for UNconventional Threaded Interpretive Language. Until is designed to be used as a macro language embedded in other applications. It can both call and be called by other C functions. Chris Jakeman writes: Continued development has enhanced Until since this publication. For details of the latest public version, see FAQ: system - part 4/6. ------------------------------ Subject: [7] Suppliers Brad Rodriguez writes: Most of these books and conference proceedings are available from the Forth Interest Group, P.O. Box 2154, Oakland, CA 94621 USA, telephone 510-893-6784, fax 510-535-1295. Other suppliers include: FORTH Inc. - email to forthsales@forth.com Miller Microcomputer Services (MMS) - email to dmiller@im.lcs.mit.edu Mountain View Press (MVP) - email to ?? Box 429, Star Route 2 La Honda, CA 94020 and, in the UK, MicroProcessor Engineering Ltd.(MPE) - email to mpe@mpeltd.demon.co.uk Why not call them for a complete list of their Forth publications? ------------------------------ Indexes: [8] Indexes Currently there is no comprehensive on-line index to books or published papers about Forth. FIG supplies a printed index of FORML and euroForml papers. http://www.bookshop.co.uk/SEARCH.HTM finds 45 books but omits some important ones like Scientific Forth. http://liinwww.ira.uka.de/bibliography/Compiler/forth.html is part of the Computer Science Bibliography Collection at the University Of Karlsruhe and 13 mirror sites around the world. It contains 668 references to published papers, mostly proceedings of euroForth conferences. See also http://www.paisley.ac.uk/~cis/forth/index.html From: Bernd Paysan Subject: Re: Hang on, isn't Forth out of date now? Date: Wed, 21 Aug 1996 23:56:48 +0200 Message-ID: <321B8620.4CD8C7AB@informatik.tu-muenchen.de> References: <4vb4ct$cj2@dfw-ixnews4.ix.netcom.com> <4vfgkt$go5@news.interlog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.13 i486) echapin@interlog.com wrote: > > In , jvn@faraday.clas.Virginia.EDU (Julian V. Noble) writes: > >pfrenger@ix.netcom.com writes: > >> >Paul Shirley wrote: > >> > >> >>Paul Frenger wrote: > >> >>Will the Forth programmer get his project done first? > >> >>NO CONTEST. > >> > >> >This was *not* my experience in the mid 80's, for the > >> >simple reason that the dominant delay was rebooting the > >> >system after a fatal crash (about 2-4 minutes!) > > The system that Mitch Bradley used to sell came up in debugging mode > if you threw it garbage. That's what I expect of any Forth. A Forth should be only deadly shot if you hit the error recovery code (or the vocabulary links or some I/O ports ;-). And if you have a modern OS like Linux, a reboot form abuse of Forth is almost impossible. You must start it as root and access some I/O ports to confuse the kernel. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 15:10:16 GMT Message-ID: <4vf8so$bg5@hkusuc.hku.hk> If I think about it the (Dyn)OOF syntax with the "{"-s (which can be replaced with something else if someone so wishes) has the defit advantage that the need to handle pointers-to-an-object disappears. The object represented by the cell on the top of the stack is activated by " { ", regardless how that cell was obtained in the first place. Andras From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: multiple values Date: Wed, 21 Aug 1996 16:05:10 GMT Message-ID: <4vfc60$hc3@news.NL.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> <4v26ic$gq5@news3.digex.net> <4v95bj$pbn@news.NL.net> <4vd2as$55i@news3.digex.net> Reply-To: hbezemer@vsngroep.nl matt@access5.digex.net (Matt Lawrence) wrote: >You don't have direct access to the stack in C, so you have to squirrel >other information away in global variables if you need more than one >return value. Also, everything has to be named. I've never had problems >with variable number of parameters in Forth. In fact, the construct "?DUP >IF" is really handy and perfectly obvious to me. To you may be.. But sometimes maintenance is not done by the initial programmer. Worse, there might be programmers that create words with variable stackresults, that may be NOT that obvious. >C uses stack frames. Large amounts of the stack are thrown away at return >time. Very different programming model. I'm talking about maintainability, syntax, and clearity of code. I know most Forth programmers are really concerned about what happens under the hood, but I don't think that angle is appropriate or relevant in this discussion. Hans. From: matt@access5.digex.net (Matt Lawrence) Subject: Re: multiple values Date: 21 Aug 1996 16:22:13 GMT Message-ID: <4vfd3l$anq@news4.digex.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> <4v26ic$gq5@news3.digex.net> <4v95bj$pbn@news.NL.net> <4vd2as$55i@news3.digex.net> <4vfc60$hc3@news.NL.net> Hans Bezemer (hbezemer@vsngroep.nl) wrote: : > In fact, the construct "?DUP : >IF" is really handy and perfectly obvious to me. : : To you may be.. But sometimes maintenance is not done by the initial : programmer. Worse, there might be programmers that create words with variable : stackresults, that may be NOT that obvious. That's what documentation is for. The Forth words that I write tend to have far fewer side effects than most C functions. Really bad coding is doable in just about any language. : >C uses stack frames. Large amounts of the stack are thrown away at return : >time. Very different programming model. : : I'm talking about maintainability, syntax, and clearity of code. I know most : Forth programmers are really concerned about what happens under the hood, but I : don't think that angle is appropriate or relevant in this discussion. Yes it is. I've had to work on C functions that depended on the fact that values were still accessable after a return from a function. Really bad programming (the author was an IC designer). As a C programmer, I find that I have to be very aware of the stack and its usage. Basically, if a variable is defined globally or statically it isn't on the stack, otherwise it is. Makes for some really clear code :-). Your maintainablility arguments seem to be: If a C programmer can't maintain a Forth program, then Forth is a bad language. -- Matt From: Bernd Paysan Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 23:47:09 +0200 Message-ID: <321B83DC.DB799AC@informatik.tu-muenchen.de> References: <4vf8so$bg5@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.13 i486) Zsoter Andras wrote: > > If I think about it the (Dyn)OOF syntax with the "{"-s (which can be replaced > with something else if someone so wishes) has the defit advantage > that the need to handle pointers-to-an-object disappears. > > The object represented by the cell on the top of the stack is activated > by " { ", regardless how that cell was obtained in the first place. I use >O O> for this purpose (this implies that there is an object stack, which is the truth). Because I hide the methods in class-specific wordlists, method passing to an anonymous object still requires "class method", which passes the method to the current object. Using "object method" thus is only a shortcut for "object self >o class method o>" (SELF is the method returning the pointer to the object). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 23:42:45 +0200 Message-ID: <321B82D5.5B69391@informatik.tu-muenchen.de> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <32161CC4.513B399F@informatik.tu-muenchen.de> <321B0F84.2D27@headwaters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.13 i486) Brad Rodriguez wrote: > > Bernd Paysan wrote: > > Yep. The main difference I find between OOFs is the order of method > > passing. Some use "method object", others use "object method". I prefer > > the second, because it allows (enforces) active parsing of the method. > > To preserve the implementation freedom, we should agree that all > > object-parsing must happen in the same line (thus either FIND patching, > > or BL WORD FIND in the class word works). > > A problem: I have often, in the past, needed to pass a method selector as > an argument to a conventional Forth word (for late binding). Active > parsing would seem to render this impossible. Can you do late binding > without storing the source text of the program? Yes, I can do it. My OOF builds a dispatch table at compile time, and the first cell of each object points to this dispatch table. You can generate method selectors (not bound to an object) using the base class. Well, these method selectors execute on the current objects, so you need to pack them into an (possibly anonymous) word. It would be possible to optain the method selector with a method ' or ['] (for compiling), because methods in fact are just executable themselves. Late binding is default, except if the object is known at compile time. And as Anton Ertl shows, it's possible to do the "object method" approach without parsing. Then a selector is obtained by just '-ing the method name, and executing it when it should be passed to the object. IMHO, the main problem with OOF is that it is easy enough to make an OOF, so there are more OOF systems out there than (reasonable large) OOF applications. For my OOF (part of bigForth), there are two application in the 200+ screens range, so I have a good ratio ;-). BTW: this is really a good idea. I'll add the tree methods ', ['], and EXECUTE (or PASS, which is more appropriate) as standard methods (I use them already in my turbo-vision style UI). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Hang on, isn't Forth out of date now? X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <4ve85t$clf@iaehv.IAEhv.nl> Date: Wed, 21 Aug 1996 16:32:07 GMT mhx@IAEhv.nl writes: [ previous disc. deleted ] > BTW, do you happen to have any more of these Pentium coding tips (or > pointers to them)? > > -marcel "Pentium Processor Optimization Tools" by Schmit. Academic Press, 1995. Comes with a diskette including a 32-bit DEBUG. Yum. -- Julian V. Noble jvn@virginia.edu From: Bernd Paysan Subject: Re: Hang on, isn't Forth out of date now? Date: Wed, 21 Aug 1996 23:51:45 +0200 Message-ID: <321B84F1.422653AD@informatik.tu-muenchen.de> References: <4ve85t$clf@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b6 (X11; I; Linux 2.0.13 i486) Julian V. Noble wrote: > > mhx@IAEhv.nl writes: > > [ previous disc. deleted ] > > > BTW, do you happen to have any more of these Pentium coding tips (or > > pointers to them)? > > > > -marcel > > "Pentium Processor Optimization Tools" by Schmit. Academic Press, 1995. AFAIK, Intel revealed the famous appendix H (so you can get it without signing a NDA). My knowledge just comes from the pipeline organization of the Pentium and the insight how pipelined CPUs work. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Objects for ANS Forth Date: 21 Aug 1996 16:38:05 GMT Message-ID: <4vfe1d$ffq@hkusuc.hku.hk> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> <321B220D.60A1@austin.finnigan.com> Andrew McKewan (mckewan@austin.finnigan.com) wrote: >> 2) Similarly, the Neon syntax makes late binding inconvenient. But the >> important thing about object-oriented programming languages (in >> comparison with languages like Ada and Modula-2) is late binding. IMO >> late binding should be easy; it should be the default. >This is an argument we will not settle here. In a "pure" OO model like >Smalltalk, all messages are late bound. This provides the most flexible >model. But it has a few disadvantages: >1. It is slower that early binding (often considerably slower). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A common misconception. Look at my paper about the topic in FD. http://www.forth.org/fig/oopf.html >2. Unknown messages are caught at runtime, making debugging more >difficult. >[As an aside, the C++ model is not really message passing. It does to >compile-time checking and is very efficient, but you cannot send an >arbitrary message to an arbitrary object (they must descend from a common >base class).] Well, so be it. You have to define what kind of object you are expecting at a certain place, but it gives you so many advantages (early catch of errors, increase in speed, etc.) that it is very well worth the restrictions. > S" NAME" : ; > 0 S" ZERO" CONSTANT >Whoops, S" parses from the input stream. But you can factor out the parsing part into one word. So you only need one word (S" ) to parse the input stream instead of several. (BTW: Isn't there something similar in PostScript?) Andras From: jon@taygeta.com (J. D. Verne) Subject: comp.lang.forth FAQ-lite Date: 21 Aug 96 21:01:35 GMT Expires: 29 Aug 96 20:52:01 Message-ID: Reply-To: faq@taygeta.com (FAQ maintainers list) Summary: A pointer to, and a short description of, the Forth Programming Language FAQ-files posted regularily to comp.lang.forth. Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq-lite Posting-Frequency: Posted on the 7th, 14th, and 21st of each month. Here is a brief summary and description of the Forth language Frequently Asked Questions files. They are posted monthly to the comp.lang.forth USENET group, and are updated regularily. These files are available for reading, or downloading, at: http://www.taygeta.com/fig.html ftp://ftp.forth.org/pub/Forth/FAQ If the site is slow or busy, please try again, later. ==> forthfaq.1 'general' <== comp.lang.forth Frequently Asked Questions, part 1 of 6 General/Miscellaneous - a brief historical background, a discussion of standards, and an overview of the FAQ - An HTML version is available at: http://www.complang.tuwien.ac.at/forth/faq/faq-general.html ==> forthfaq.2 'online' <== comp.lang.forth Frequently Asked Questions, part 2 of 6 Online Resources - a relatively comprehensive guide to Forth info online - An HTML version is available at: http://www.complang.tuwien.ac.at/forth/forl.html ==> forthfaq.3 'vendors' <== comp.lang.forth Frequently Asked Questions, part 3 of 6 Forth Vendors - a listing of Forth vendors and authors ==> forthfaq.4 'systems' <== comp.lang.forth Frequently Asked Questions, part 4 of 6 Forth Systems: Commercial, Shareware, and Freeware - a large listing of various Forth and Forth-like systems for many different architectures (& budgets...) ==> forthfaq.5 'books' <== comp.lang.forth Frequently Asked Questions, part 5 of 6 Books, Periodicals, and Tutorials - a bibliography of printed resources available for Forth users ==> forthfaq.6 'groups' <== comp.lang.forth Frequently Asked Questions, part 6 of 6 Forth Groups & Organizations - a listing of organizations for the Forth professional, and hobbyist Please direct any comments or queries to . From: barrym@neosoft.com (barrym) Subject: Re: Hang on, isn't Forth out of date now? Date: 22 Aug 1996 00:43:13 GMT Message-ID: <4vgaf1$m2d@uuneo.neosoft.com> References: <320C74D6.7BEA@headwaters.com> <4uqb90$p6r@majipoor.cygnus.com> Dave Baldwin (dibald@netcom.com) wrote: : : All of the 'string' handling functions are in the 'C' library. Anytime : you have to do 'real' programming with 'real' data like databases and text : files, you're going to have to write some functions that aren't in the : standard library (or buy them from someone who did). Same for ASM. If : you're programming for 8-bit controllers, you're going to use an 8-bit : count for counted strings if you can. It seems like everyone here is ignoring the mem functions on all the modern c compilers and even in most older ones. They do just about the same things the str functions do, except they do it with a count and they couldn't care less about imbedded 0's. Given 2 very powerful and flexible languages like c and forth, you won't find many things that either can do that the other can't. In most cases I think it's just a matter of which one do you want to use. Barry From: Bill Zimmerly Subject: Re: Hang on, isn't Forth out of date now? Date: Wed, 21 Aug 1996 10:05:33 -0500 Message-ID: <321B25BD.303@inlink.com> References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) Paul Shirley wrote: > > In article <4v3k64$d95@sjx-ixn6.ix.netcom.com>, pfrenger@ix.netcom.com > writes > >Will the Forth programmer get his project done first? NO CONTEST. > > This was *not* my experience in the mid 80's, for the simple reason that > the dominant delay was rebooting the system after a fatal crash (about > 2-4 minutes!) I was a full-time assembler programmer during the mid-80's (Z-80 & 8088) and a Forth programmer too, and my experience in getting the project done first was, as "pfrenger@ix.netcom.com" wrote..."NO CONTEST". Since you mention that the "dominant delay was rebooting the system after a fatal crash", the only thing I can conclude was that I experienced "fatal crashes" a *lot* less frequently than you did. Perhaps your skills as a Forth programmer weren't equal to your skills as an assembler programmer...but mine were...this certainly is *not* a reflection of any defect on the part of Forth! > The editor/assembler/debugger I used was pretty good at catching fatal > memory writes before they did any damage. The Forth system in contrast > was quite easy to crash even before running the app! > > -- > Paul Shirley Well shucks, Paul, freedom does come at a price, doesn't it? - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: Andrew McKewan Subject: Re: Environment Variables Date: Wed, 21 Aug 1996 10:06:11 -0500 Message-ID: <321B25E3.48C9@austin.finnigan.com> References: <3215F919.7102@umich.edu> <4vch1p$c27@news.tuwien.ac.at> <3219F7A2.57DD@umich.edu> <4vdtb7$2st@seagoon.newcastle.edu.au> <321AC542.35D3@umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) David N. Williams wrote: > Anyway, I think providing glue for the standard C library getenv() is > likely to be enough for many purposes--I'm guessing without having > checked it yet that that's what gforth does. > > Still, I'll keep the read/write variables in my system... Although not ANSI C, the Microsoft run-time library provided a putenv() function to write to the local environment. Spawned processes can inherit this environment. I'm sure other compiler provide a similar function. Win32 provides both GetEnvironmentVariable and SetEnvironmentVariable. -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: Andrew McKewan Subject: Re: Objects for ANS Forth Date: Wed, 21 Aug 1996 09:21:33 -0500 Message-ID: <321B1B6D.680C@austin.finnigan.com> References: <32107F3C.360E@austin.finnigan.com> <32133CB8.F1@austin.finnigan.com> <4v2p2p$nmt@iaehv.IAEhv.nl> <321887AA.7BDC@austin.finnigan.com> <321B1116.3CA1@headwaters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Brad Rodriguez wrote: > Andrew McKewan wrote: > > 2. Have a way for the system to not only see if a word has been defined, > > but is really a selector. This can be done by either compiling a special > > tag into the selector pfa (wasting some space and not foolproof) or just > > seeing if the selector has been defined after ClassInit: > > > > a) : ?Selector ( pfa -- f ) @ selectorTag = ; > > > > b) : ?Selector ( pfa -- f ) ['] ClassInit: >BODY U< 0= ; > > Does the ANS Standard guarantee that the dictionary pointer is > monotonically increasing? I don't think so. All that is guaranteed is the spaces after a CREATE is available, using ALLOT, "," etc. When you define a new word, all bets are off. I think my option b) is non-standard. -- Andrew McKewan mckewan@austin.finnigan.com Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547 From: Paul Shirley Subject: Re: Hang on, isn't Forth out of date now? Date: Thu, 22 Aug 1996 04:07:18 +0100 Message-ID: References: <320C74D6.7BEA@headwaters.com> <4ujsst$197@dfw-ixnews8.ix.netcom.com> <4uo8r3$8oa@news.tuwien.ac.at> <4uu272$9t5@ns2.borg.com> <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> <321B25BD.303@inlink.com> Mime-Version: 1.0 In article <321B25BD.303@inlink.com>, Bill Zimmerly writes >Since you mention that the "dominant delay was rebooting the system after a >fatal crash", the only >thing I can conclude was that I experienced "fatal crashes" a *lot* less >frequently than you did. >Perhaps your skills as a Forth programmer weren't equal to your skills as an >assembler >programmer...but mine were...this certainly is *not* a reflection of any defect >on the part of >Forth! > Perhaps I ought to explain that I write video games for a living. In the early 80's it was a new industry with few tools, dozens of target machines and without fail machines had *no* accurate documentation. Forth seemed like a good way to avoid the problems of learning new machines every year, porting between machines and generally getting the most out of underpowered hardware. The sort of code I needed to write is rather more likely to crash than most, (no error checking - for speed, full of shortcuts and approximations). Calling a blit routine from the keyboard is not a good idea in that situation ;) I'll quite happily admit being a better asm programmer than Forth programmer. Most asm programmers are :-) -- Paul Shirley From: "Bruce R. McFarling" Subject: Re: multiple values Date: 22 Aug 1996 02:46:23 GMT Message-ID: <4vghlv$qra@seagoon.newcastle.edu.au> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> <4v9a2i$av@dfw-ixnews5.ix.netcom.com> <4vbdl8$i73@seagoon.newcastle.edu.au> <4ved3o$4kq@dfw-ixnews7.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) JEThomas@ix.netcom.com (Jonah Thomas) wrote: >In <4vbdl8$i73@seagoon.newcastle.edu.au> "Bruce R. McFarling" > writes: >>JEThomas@ix.netcom.com (Jonah Thomas) wrote: >>>I find ?DUP useful in the following situation: >>>... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... >> If that what ?DUP can be used for safely, then why not >>build it into a version of IF -- since that permits the peephole >>optimization of an IF that simply does not consume a non-zero >>top of stack. In other words, >> ?DUP-IF DO-IT THEN >> ... will be no worse than ?DUP IF DO-IT THEN and it might be >> better. And the same would apply to the use of ?DUP in an UNTIL >> loop. >That makes sense. I've seen the suggestion before, and it made sense >then. I've implemented it and not used it. I've never noticed anybody >use it, although the idea has been around a long time. Every Forth >implementation I've ever seen has has ?DUP and it gets used. I don't >know why. Tradition, maybe? I'm wondering whether this is a word that you would have to re-write for different versions of Forth, so that if the ANS standard permits a default definition of ?DUP-IF (etc.), it would permit the efficient implementation on the target system backed up by a portability definition for systems without ?DUP-IF (etc.) defined. > It's potentially more flexible than the > ?DUP bundled into IF WHILE and UNTIL but I've never noticed much > use for that flexibility. I dunno. >Oh, here's one example. You start with a number and a flag, and you >want to either do something that consumes the number or just drop it. >( n f ) ?DUP AND IF CONSUME-NUMBER THEN > ??? As in 8 8 AND . 8 OK >I did this once in my wild youth and it was more "efficient" than >the other ways I tried on that particular system -- an ELSE DROP >took more space and more time. >It was easy for me to maintain because I got a little warm >feeling at how smart I was every time I looked at it. !!! > After a while I gave up being that smart. There might be some > sort of valid use for something vaguely like that. I don't know > what it would be. > Variable stack results have to result in branching > somewhere along the line unless they're very carefully > matched. When things have to be very carefully matched, that is the kind of precision task that I would like to have computer assistence in doing. And in terms of developing that computer assistence, I'd rather the effort went into a compiler that was smart enough to optimize the: DUP IF ... ELSE DROP THEN pattern, in which case the ?DUP-IF might be an internal operation selected by the compiler that I wouldn't have to keep in mind. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 1 of 6, General Information Date: 21 Aug 96 21:03:07 GMT Expires: 25 Sep 96 20:53:09 Message-ID: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part1 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. comp.lang.forth Frequently Asked Questions (1/6): Gen- eral/Misc M. Anton Ertl, anton@mips.complang.tuwien.ac.at ____________________________________________________________ Table of Contents: 1. Acknowledgements 2. comp.lang.forth FAQs 3. General Questions 3.1. What is Forth? 3.2. Why and where is Forth used? 3.3. What language standards exist for Forth? 3.4. What is an RFI? 3.5. What is the Forth Interest Group? 4. Flame baits 4.1. Commercial vs. free Forth systems 4.2. Free Forth systems are bad for Forth. 4.3. Blocks vs. files 5. Miscellaneous 5.1. Where can I find a C-to-Forth compiler? 5.2. Where can I find a Forth-to-C compiler? 5.3. RECORDS in Forth? 5.4. Why does THEN finish an IF structure? ______________________________________________________________________ 1. Acknowledgements This FAQ is based on previous work by Gregory Haverkamp, J. D. Verne, and Bradford J. Rodriguez. 2. comp.lang.forth FAQs The comp.lang.forth FAQ is published in six parts, corresponding to these six sections. This part is the General/Misc FAQ, where the questions not covered in the other FAQs are answered. The six parts are: o General questions o Online resources o Forth vendors o Forth systems o Books, periodicals, tutorials o Forth groups & organizations These FAQs are intended to be a brief overview of the tools and information available for the new FORTHer. For a historical reference, programming paradigms, and deep technical information try some of the listed references. For general questions on the internet, or the methods used to get this information, try these other Usenet groups: o news.announce.newusers o news.newusers.questions o news.announce.important 3. General Questions 3.1. What is Forth? Forth is a stack-based, extensible language without type-checking. It is probably best known for its "reverse Polish" (postfix) arithmetic notation, familiar to users of Hewlett-Packard calculators: to add two numbers in Forth, you would type 3 5 + instead of 3+5. The fundamental program unit in Forth is the "word": a named data item, subroutine, or operator. Programming in Forth consists of defining new words in terms of existing ones. The Forth statement ______________________________________________________________________ : SQUARED DUP * ; ______________________________________________________________________ defines a new word SQUARED whose function is to square a number (mul- tiply it by itself). Since the entire language structure is embodied in words, the application programmer can "extend" Forth to add new operators, program constructs, or data types at will. The Forth "core" includes operators for integers, addresses, characters, and Boolean values; string and floating-point operators may be optionally added. 3.2. Why and where is Forth used? Although invented in 1970, Forth became widely known with the advent of personal computers, where its high performance and economy of memory were attractive. These advantages still make Forth popular in embedded microcontroller systems, in locations ranging from the Space Shuttle to the bar-code reader used by your Federal Express driver. Forth's interactive nature streamlines the test and development of new hardware. Incremental development, a fast program-debug cycle, full interactive access to any level of the program, and the ability to work at a high "level of abstraction," all contribute to Forth's reputation for very high programmer productivity. These, plus the flexibility and malleability of the language, are the reasons most cited for choosing Forth for embedded systems. 3.3. What language standards exist for Forth? An American National Standard for Forth, ANSI X3.215-1994, is accepted worldwide as the definitive Forth standard. ("ANS Forth") IEEE Standard 1275-1994, the "Open Firmware" standard, is a Forth derivative which has been adopted by Sun Microsystems, HP, Apple, IBM, and others as the official language for writing bootstrap and driver firmware. Prior Forth standards include the Forth-83 Standard and the Forth-79 Standard issued by the Forth Standards Team. The earlier FIG-Forth, while never formally offered as such, was a de facto "standard" for some years. "FORTH STANDARDS Published standards since 1978 are Forth 79 and Forth 83 from the Forth Standard Team, and ANS Forth - document X3.215-1994 - by the X3J14 Technical Committee. The most recent standard, ANS Forth, defines a set of core words and some optional extensions and takes care to allow great freedom in how these words are implemented. The range of hardware which can support an ANS Forth Standard System is far wider than any previous Forth standard and probably wider than any programming language standard ever. See web page for latest details. Copies of the standard cost $193, but the final draft of ANS Forth is free and available (subject to copyright restrictions) via ftp..." --Chris Jakeman, apvpeter.demon.co.uk The (un)official ANS Forth document is available in various formats at and at To get yourself on the ANS-Forth mailing list, consult the various README files at . Two unofficial test suites are available for checking conformance to the ANS Standard Forth: o John Hayes has written a test suite to test ANS Standard Systems (available through ). o JET Thomas has written a test suite to test ANS Standard Programs: 3.4. What is an RFI? A Request For Interpretation. If you find something in the standard document ambiguous or unclear, you can make an RFI, and the TC (technical committee), that produced the standard, will work out a clarification. You can make an RFI by mailing it to greg@minerva.com and labeling it as RFI. The answers to earlier RFIs are available at ftp://ftp.uu.net/vendor/minerva/x3j14/queries/. 3.5. What is the Forth Interest Group? The Forth Interest Group "FIG" was formed in 1978 to disseminate information and popularize the Forth language, and it remains the premier organization for professional Forth programmers. FIG maintains a Web page at , with a more complete introduction to the Forth language, and links to the Web pages of many Forth vendors. 4. Flame baits Some statements spawn long and heated discussions where the participants repeat their positions and ignore the arguments of the other side (flame wars). You may want to avoid such statements. Here, I present some regularly appearing flame baits and the positions you will read (so you don't have to start a flame war to learn them). 4.1. Commercial vs. free Forth systems "You get what you pay for. With a commercial Forth you get commercial documentation and support. We need commercial Forth systems or Forth will die." "I have had good experiences with free Forths. I cannot afford a commercial Forth system. I want source code (some commercial vendors don't provide it for the whole system). Examples of bad support from commercial software vendors. Without free Forth systems Forth will die." 4.2. Free Forth systems are bad for Forth. "Anyone can write a bad Forth and give it away without documentation or support; after trying such a system, nobody wants to work with Forth anymore. Free Forths give Forth a bad name. Free Forths take business away from the vendors." "Many people learned Forth with fig-Forth. There are good free Forths. Most successful languages started with (and still have) free implementations. Languages without free implementations (like Ada, Eiffel and Miranda) are not very popular." 4.3. Blocks vs. files The discussions on this topic are much cooler since Mike Haas has dropped from comp.lang.forth. "Everyone is using files and all third-party tools are designed for files. Files waste less space. Blocks lead to horizontal, unreadable code. Blocks make Forth ridiculous." "We are not always working under an operating system, so on some machines we don't have files. We have very nice block editors and other tools and coding standards for working with blocks (e.g., shadow screens)." 5. Miscellaneous 5.1. Where can I find a C-to-Forth compiler? There have been roumors about such a compiler at Harris (for the RTX chip) and elsewhere. The most concrete answer to this question has come from Stephen Pelc (sfp@mpeltd.demon.co.uk): MPE has produced a C to stack-machine compiler. This generates tokens for a 2-stack virtual machine. The code quality is such that the token space used by compiled programs is better than that of the commercial C compilers we have tested against. This a consequence of the virtual machine design. However, to achieve this the virtual machine design has local variable support. The tokens can then be back end interpreted, or translated to a Forth system. The translater can be written in high level Forth, and is largely portable, except for the target architecture sections. These are not shareware tools, and were written to support a portable binary system. 5.2. Where can I find a Forth-to-C compiler? An unsupported prototype Forth-to-C compiler is available at . It is described in the EuroForth'94 paper . Another Forth-to-C compiler is supplied with Rob Chapman's Timbre system. 5.3. RECORDS in Forth? Many packages for data structuring facilities like Pascal's RECORDs and C's structs have been posted. E.g., the structures of the Forth Scientific Library ( ) or the structures supplied with Gforth . 5.4. Why does THEN finish an IF structure? Some people find the way THEN is used in Forth unnatural, others do not. According to Webster's New Encyclopedic Dictionary, then" (adv.) has the following meanings: 2b: following next after in order ... 3d: as a necessary consequence (if you were there, then you saw them). Forth's THEN has the meaning 2b, whereas THEN in Pascal and other pro- gramming languages has the meaning 3d. If you don't like to use THEN in this way, you can easily define ENDIF as a replacement: ______________________________________________________________________ : ENDIF POSTPONE THEN ; IMMEDIATE ______________________________________________________________________ From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 2 of 6, Online Resources Date: 21 Aug 96 21:03:14 GMT Expires: 25 Sep 96 20:53:09 Message-ID: References: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part2 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. From: faq@forth.org Subject: comp.lang.forth FAQ: online (1 Apr 1996), part 2/6 Reply-To: forl@artopro.mlnet.com Archive-name: forth/FAQ/online Comp-lang-forth-archive-name: online-faq Last-modified: 1 Apr 1996 Version: 1.00 Posting-Frequency: monthly Send additions, deletions, or changes to Kenneth O'Heskin The Forth Online Resources Quick-Ref Card Listing ------------------------------------------------- WWW version: http://www.complang.tuwien.ac.at/forth/forl.html A detailed hardcopy version with additional data is available in Forth Dimensions magazine (below). ------------------------------------------------- --Bulletin Boards-- Arcane Incantations 617-899-6672 Art of Programming BBS 604-826-9663 Bitter Butter Better BBS 503-691-7938 Gold Country Forth BBS 916-652-7117 LMI Forth BBS 310-306-3530 MindLink (604) 528-3500 Telnet: mindlink.bc.ca RCFB "The Rocky Coast Free Board" 303.278.0364 The FROG Pond BBS 716/461-1924 --FTP Sites-- ANS Forth x3j14 ftp://ftp.uu.net Asterix Forth archive ftp://asterix.inescn.pt/pub/forth Brain ftp://brain.physics.swin.oz.au Cygnus Support Ftp Service ftp://ftp.cygnus.com David N. Williams ftp://williams.physics.lsa.umich.edu/pub/forth Dwight Elvey ftp://hal.com/pub/elvey Fare's FTP site, FORTH subsection ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/ Hewlett Packard ftp://col.hp.com/mirrors/Forth Marcel Hendrix ftp://iaehv.iaehv.nl/pub/users/mhx Microtronix ftp://ftp.microtronix.com/pub/forth Robert Jay Brown ftp://eli.wariat.org/pub/forth SimTel ftp://ftp.coast.net/SimTel/msdos/forth Yerk ftp://astro.uchicago.edu/pub/MAC/Yerk --FTP/Web Sites-- Institut fr Computersprachen http://www.complang.tuwien.ac.at/projects/forth.html Ron's Mac and Apple II archive http://141.106.68.98/ or ftp:/141.106.68.98/ Skip Carter's Forth Page http://www.forth.org/forth.html The Mops Page http://www.netaxs.com/~jayfar/mops.html University of Bremen http://ftp.uni-bremen.de/FTP/ftp.html --Internet Mailing Lists-- MISC mailing list subscribe: misc-request@pisa.rockefeller.edu The Win32For mailing list subscribe: win32for-requests@edmail.spc.uchicago.edu --Electronic Mailboxes-- ANSForth Mail Group ansforth-request@minerva (for joining ANSForth mail group) FIG - Forth Interest Group board@forth.org all FIG Board of Directors (broadcast) editor@forth.org Marlin Ouverson Forth Dimensions Editor office@forth.org John Hall FIG business office pres@forth.org Skip Carter FIG President sec@forth.org Mike Elola FIG Secretary treas@forth.org Andrew McKewan FIG Treasurer vp@forth.org Jeff Fox FIG Vice President FORTH Gesellschaft - German Forth users' group secretary@admin.forth-ev.de LMI Technical Support support@lmi.la.ca.us Miller Microcomputer Services dmiller@im.lcs.mit.edu PYGMY Forth - Frank Sergeant pygmy@pobox.com The Forth Online Resources Survey forl@artopro.mlnet.com --Newsgroups, Conferences, et. al-- comp.lang.forth ftp://asterix.inescn.pt/pub/forth/news/ CompuServe Forth Forum (type) GO FORTH GEnie Information Services (GEIS) 800-638-9636. --World Wide Web-- 1996 Rochester Conference http://maccs.dcss.mcmaster.ca/~ns/96roch.htmlx Alaric B. Williams http://www.hardcafe.co.uk/Alaric/os.htm ATLAST http://www.fourmilab.ch Bernd Paysan's Web site http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle2/~paysan/ Cimprovisor http://www.asi.bc.ca/asi/affiliates/cimprovisor/cimhome.html euroFORTH http://www.paisley.ac.uk/~cis/euro FIG home page http://www.forth.org/fig.html Forth Bibliography (Mirrored) http://liinwww.ira.uka.de/bibliography/Compiler/forth.html FORTH, Inc. Home Page http://www.earthlink.net/~forth F-PC Homepage http://www.efn.org/~fwarren/fpc.html Frank Sergeant http://www.eskimo.com/~pygmy Immersive Systems, Inc. http://www.immersive.com Internet Hot List List - Forth http://www.cera.com/forth.htm Jeff Fox's Home Page http://www.dnai.com/~jfox Jumbo http://www.jumbo.com/prog/dos/forth/ Laboratory Microsystems Inc. http://www.cerfnet.com/~lmi Learning Forth Page http://sherman.pas.rochester.edu/Forth/forth.html Leo Brodie Services http://www.pacificrim.net/~lbrodie/lbs.html New Micros Inc http://www.newmicros.com/systems Nick Francesco's Forth Page http://raptor.rit.edu/Nick/forth.htm Open FirmWare http://www.firmworks.com Paisley Forth Page http://www.paisley.ac.uk/~cis/forth/index.html Patriot Scientific Corporation http://www.ptsc.com Phil Koopman's Forth Mini-Page http://www.cs.cmu.edu/~koopman Pocket Forth Home Page http://chemlab.pc.maricopa.edu/pocket.html Roger Ivie http://cc.usu.edu/~ivie/ The Computer Journal http://www.psyber.com/~tcj/ The TUNES project http://www.eleves.ens.fr:8080/home/rideau/Tunes/ Tom Almy - ForthCMP http://www.teleport.com/~almy Tout sur le Forth en France http://ourworld.compuserve.com/homepages/mp7 Triangle Digital Services Ltd http://ourworld.compuserve.com/homepages/triangle WebBook http://webbook.com >From Forth Dimensions XVII No.4 Nov/Dec 1995 ================================= current FIG address/contact info: ================================= Forth Interest Group P.O. Box 2154 Oakland, California 94621 telephone: 510-893-6784 fax: 510-535-1295 e-mail: office@forth.org Forth Interest Group home page: http://www.forth.org/fig.html From: jon@taygeta.com (J. D. Verne) Subject: Forth Programming Language FAQ: Part 6 of 6, Forth Groups Date: 21 Aug 96 21:03:48 GMT Expires: 25 Sep 96 20:53:09 Message-ID: References: Reply-To: faq@taygeta.com (FAQ maintainers list) Keywords: FAQ FORTH FIG Originator: jon@taygeta.com Posted-By: auto-faq 3.3 beta (Perl 5.001) Archive-name: forth-faq/part6 Posting-Frequency: Monthly. A how-to-find-the-FAQ article is posted weekly. comp.lang.forth Frequently Asked Questions, part 6 of 6 Forth Groups & Organizations Bradford J. Rodriguez, 7 Feb 1996 We are currently seeking a volunteer to maintain this FAQ. Please contact Brad Rodriguez if you're interested. Please send additions, deletions, or changes to Brad Rodriguez in the meantime. ------------------------------ Subject: Table of Contents [1] Forth Organizations [2] FIG Chapters [3] Forth Conferences NOTE: this FAQ is in the early stages of construction. Contributions and suggestions are welcome. ------------------------------ Subject: [1] Forth Organizations Forth Interest Group (FIG) P.O. Box 2154 Oakland, CA 94621 USA telephone: 510-893-6784 (510-89-FORTH) fax: 510-535-1295 e-mail: johnhall@aol.com Membership in FIG is US$40 per year (before March 1st), plus an additional US$15 per year for foreign members. This includes a subscription to the bimonthly magazine Forth Dimensions. FIG holds the annual FORML conference. FIG-UK The UK Chapter of the Forth Interest Group publishes its own Forthwrite magazine 6 times a year, maintains an extensive lending library of books and periodicals (including Forth Dimensions, JOFAR and FORML) with a number of items on disk too. Meetings with invited speakers are held 4 times a year at the South Bank University, London. To join (at only 10 pounds a year, you can't afford not to :-) contact Doug Neale on 0181 542 2747 or by post to: 58 Woodland Way MORDEN Surrey SM4 4DS Institute for Applied Forth Research 70 Elmwood Avenue Rochester, NY 14611 USA telephone 716-235-0168 email: lforsley@jwk.com Publishes the peer-reviewed Journal of Forth Application and Research, and holds the annual Rochester Forth Conference. Association for Computing Machinery (SIGForth) ACM's Special Interest Group on Forth has been absorbed into ACM SIGPlan, the Special Interest Group on Programming Languages. ------------------------------ Subject: [2] FIG Chapters [This section is under revision. If you have information about an active FIG chapter, please send it to the FAQ maintainer.] CALIFORNIA North Bay Chapter Meets monthly, 2nd Sat., at BMUG, 2055 Center Street, Berkeley (1/2 block from Berkeley BART station). Tutorial at noon, meeting at 1 pm. Contact Leonard Morgenstern, 510-376-5241, . CANADA Southern Ontario Chapter Meets quarterly, 1st Sat. of March/June/Dec., 2nd Sat. of Sept., 2 pm, at McMaster University, General Science Building, Rm. 301, Hamilton, Ontario. Contact Dr. N. Solntseff, 905-525-9140 x.23443, . Maintains software library. UNITED KINGDOM see "FIG-UK" listing under "[1] Forth Organizations" ------------------------------ Subject: [3] Forth Conferences Rochester Forth Conference The Rochester Forth Conference is held in (or near) the Eastern U.S. every June. This year's conference, the 16th annual, will be held from June 19-22 at Ryerson Polytechnic University in Toronto, Ontario, Canada. The conference theme is "Open Systems" and papers are being solicited. Direct inquiries to the Program Chair, Nicholas Solntseff, . WWW page: EuroForth Conference The EuroForth Conference is held in various European countries, usually in late October or early November. The 1996 conference is scheduled to be held October 4-7 in St. Petersburg, Russia. FORML Conference The FORML Conference is held at the Asilomar Conference Center in California every November. Other Forth conferences have been held in Australia and China. From: Paul Shirley Subject: Re: Hang on, isn't Forth out of date now? Date: Thu, 22 Aug 1996 03:26:51 +0100 Message-ID: References: <4v299e$ck@news.tuwien.ac.at> <4v3k64$d95@sjx-ixn6.ix.netcom.com> <840535175snz@tcontec.demon.co.uk> Mime-Version: 1.0 In article <840535175snz@tcontec.demon.co.uk>, "Paul E. Bennett" writes >The time taken to reboot the system is an excellent period to consider the >reasons for the crash and identify the error of your ways. It can be the ...the time the crash would have happened at is an even better time to think about bugs, achieved in this case by letting the debugger auto single step through code till *it* spotted a bad write, avoiding a crash. (Completely possible in Forth of course... if I'd felt capable of writing it myself ;) >Never do the development on the on-line computers. Use a development machine >for the task and accurately simulate what you do not have. Not too useful for people with no money, before anyone built any such system! (Remember this was 1983-4 using home computers) -- Paul Shirley From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: multiple values Date: Wed, 21 Aug 1996 22:14:23 GMT Message-ID: <4vg1oh$jo3@news.NL.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <840101213snz@tcontec.demon.co.uk> <4v26ic$gq5@news3.digex.net> <4v95bj$pbn@news.NL.net> <4vd2as$55i@news3.digex.net> <4vfc60$hc3@news.NL.net> <4vfd3l$anq@news4.digex.net> matt@access5.digex.net (Matt Lawrence) wrote: >: I'm talking about maintainability, syntax, and clearity of code. I know most >: Forth programmers are really concerned about what happens under the hood, but I >: don't think that angle is appropriate or relevant in this discussion. >Yes it is. I've had to work on C functions that depended on the fact that >values were still accessable after a return from a function. Really bad >programming (the author was an IC designer). As a C programmer, I find >that I have to be very aware of the stack and its usage. Basically, if a >variable is defined globally or statically it isn't on the stack, >otherwise it is. Makes for some really clear code :-). I don't care where a variable is. What interests me is the scope, type and size of a variable. How it is implemented is transparent. Using a variable outside its scope is just bad programming. Period. I've been using C for over ten years, writing compilers and system-utilities. When speed is an issue, it can important how it is fetched, I agree. But still, speed is not the issue here. Maintainability is. >Your maintainablility arguments seem to be: If a C programmer can't >maintain a Forth program, then Forth is a bad language. My point is, that when code is not clear at first glance, it cannot properly be maintained. And I think a variable number of items on a stack is confusing and prone to error when maintaining: 15 CONSTANT SOMETHING : CHECK IF DROP THEN ; ( f | n f -- ) : DUPLICATE ?DUP ; SOMETHING DUPLICATE CHECK Is it clear at first glance that DUPLICATE returns variable items??? Is it clear at first glance that CHECK balances the stack??? What is either of them is changed??? Nuf said... Hans. From: kb7nmu@olywa.net (J Christopher Kennedy) Subject: Re: Wanted: Forth for OS/2 Message-ID: Date: Thu, 22 Aug 1996 08:21:17 GMT References: <3218CE04.5A60@austin.finnigan.com> <4vdnlp$fs4@ratty.wolfe.net> <321B5DE0.72D4@austin.finnigan.com> Reply-To: kb7nmu@olywa.net On Wed, 21 Aug 1996 14:05:04 -0500, Tom Zimmer wrote: >My point was, that Christopher could have started with Win32Forth, and re-writte > n >its Win32s API interface into the very similar, but not quite the same Presentat > ion >Manager API. Assuming he has the technical expertise of course. > >Tom Zimmer > Actually Tom, _you_ have the expertise. :) I meant to look it up first, but oh well. IBM has released a spec called 'Open32'. It is a subset of Win32 API calls that can be compiled directly to OS/2. Then you simply separate out the system dependent code into separate source files. Then when you compile, you run one compile to Windows(whatever), and another compile to OS/2. I will go ahead and look up a URL for Open32, but you should be able to find it with either a search tool, or by hitting an IBM site. The idea behind Open32 is to allow easy porting of code to OS/2. It is my understanding that Open32 encompases some 700(???) API calls that are common in all but name between Win32 and OS/2. Things like opening windows, dialog boxes, opening a file, etc. It should be a relatively easy way to do a simple port to OS/2. Of course, it would probably not take advantage of specific OS/2 features. But it would be a start. J Christopher Kennedy kb7nmu@olywa.net From: jverne@acs.ryerson.ca (John Verne - CNED/F94) Subject: 'FAQ (pointer to FAQ) Date: 21 Aug 1996 20:25:00 GMT Expires: Wed, 28 Aug 96 08:00:00 Message-ID: <4vfras$a6f@ns2.ryerson.ca> Summary: A pointer to the c.l.f. FAQ-files Keywords: FORTH FAQ FIG Here is a brief summary and description of the Forth language Frequently Asked Questions files. They are posted monthly to the comp.lang.forth USENET group, and are updated regularily. These files are available for reading, or downloading, at: http://www.taygeta.com/fig.html ftp://ftp.forth.org/pub/Forth/FAQ If the site is slow or busy, please try again, later. ==> forthfaq.1 'general' <== comp.lang.forth Frequently Asked Questions, part 1 of 6 General/Miscellaneous - a brief historical background, a discussion of standards, and an overview of the FAQ - An HTML version is available at: http://www.complang.tuwien.ac.at/forth/faq/faq-general.html ==> forthfaq.2 'online' <== comp.lang.forth Frequently Asked Questions, part 2 of 6 Online Resources - a relatively comprehensive guide to Forth info online - An HTML version is available at: http://www.complang.tuwien.ac.at/forth/forl.html ==> forthfaq.3 'vendors' <== comp.lang.forth Frequently Asked Questions, part 3 of 6 Forth Vendors - a listing of Forth vendors and authors ==> forthfaq.4 'systems' <== comp.lang.forth Frequently Asked Questions, part 4 of 6 Forth Systems: Commercial, Shareware, and Freeware - a large listing of various Forth and Forth-like systems for many different architectures (& budgets...) ==> forthfaq.5 'books' <== comp.lang.forth Frequently Asked Questions, part 5 of 6 Books, Periodicals, and Tutorials - a bibliography of printed resources available for Forth users ==> forthfaq.6 'groups' <== comp.lang.forth Frequently Asked Questions, part 6 of 6 Forth Groups & Organizations - a listing of organizations for the Forth professional, and hobbyist Please direct any comments or queries to . From: "Bruce R. McFarling" Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 03:17:03 GMT Message-ID: <4vgjff$qra@seagoon.newcastle.edu.au> References: <4v9ht6$m6p@hkusuc.hku.hk> <4vbelj$i73@seagoon.newcastle.edu.au> <4vf01r$iu@hkusuc.hku.hk> <321AD6DD.619@umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) Responding to two on one go: "David N. Williams" wrote: >Zsoter Andras wrote: >> Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: >>> Recall that in the FSL matrix notation, } }} }}} (etc.?) >>> are words that resolve 1, 2, 3 (etc.?) matrix indices. Thus you >>> would normally name a vector something like X{ and a matrix >> Well, probably it would intefere, but "{" and "}" were the only >> kind of brackets which were not already used for something quite >> useless in Forth. >> [I mean they are not in THE STANDARD.] That was where the :[ ]: notion for nested definitions essentially came from: there are a lot mor digraph brackets than single brackets, and of the single brackets < and > are used in their arithmatic connotation. So we could expect a lot of recourse to { }. If it is a question of developing a de-facto standard for a particular problem domain, the matrix use has a case, since the depth of the indexing is indicated with } }} }}} etc., so that it's really a family of brackets. But there is also a lot to be said for: > I like the FSL matrix notation a lot. Only half tongue-in-cheek, > I advocate that { and } be declared as standard anti-words, > guaranteed never to appear as words in the standard, because > there are so many diverse and worthwhile uses for them in > applications. That is, one should always expect them to be > locally defined, and always be aware that they may get > redefined. The problem only arises when you might wish to combine two different uses of braces in the same application. I'm not sure what I would use OO-programming for other than for modelling, and in that context I would definitely want matrix operations available. So that might extend into "when combining multiple uses of brace delimiters from pre-written vocabularies, all but one will have to be renamed". At the very least, even if its not the best approach, its a workable approach, and sometimes the unattainable best is the enemy of the attainable good. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: Tom Zimmer Subject: Re: Wanted: Forth for OS/2 Date: Thu, 22 Aug 1996 08:01:59 -0600 Message-ID: <321C684F.EB4@ix.netcom.com> References: <3218CE04.5A60@austin.finnigan.com> <4vdnlp$fs4@ratty.wolfe.net> <321B5DE0.72D4@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Thu Aug 22 7:59:44 AM CDT 1996 X-Mailer: Mozilla 3.0b7 (Macintosh; I; PPC) J Christopher Kennedy wrote: > > On Wed, 21 Aug 1996 14:05:04 -0500, Tom Zimmer wrote: > >My point was, that Christopher could have started with Win32Forth, and re-writte > > n > >its Win32s API interface into the very similar, but not quite the same Presentat > > ion > >Manager API. Assuming he has the technical expertise of course. > > > >Tom Zimmer > > > > Actually Tom, _you_ have the expertise. :) But I don't have: 1. Time 2. Tools 3. Inclination 4. Expertise on Presentation Manager What is needed is someone with the above. Tom Zimmer From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 08:00:37 +0200 Message-ID: <4vgt25$qrd@iaehv.IAEhv.nl> References: <32107F3C.360E@austin.finnigan.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> Anton Ertl wrote Re: Objects for ANS Forth [ a few reasons why one would dislike the Neon syntax ] > Generally, words that read from the input stream are a bad idea. They > cannot be used easily when the parameter coming from the input stream > does not reside in the input stream originally (yes, you can do a hack > with EVALUATE, but that is cumbersome, slow, and has many > pitfalls). Words that read from the input stream should be factored > into a part that reads the input stream, and a processing part. If it > does not say so somewhere in Thinking Forth, IMO it should. My thoughts exactly. For instance, (I'm not expecting you to agree here), it is not possible to use WORD and PARSE to process memory strings. This is a waste of good code, which could come in handy to write string operations and general purpose filters. Where are (WORD) ( s1 del -- s2 s3 ) and (PARSE) ( s1 del -- s2 s3 ) ? [ possible uses of on-the-fly interpreting ] > I don't think so. It would become incredibly complicated. They tried > this with the Algol languages, and failed. Languages like Magic/L > tried more conventional syntax with Forth, and failed. I think Forth's > simple postfix syntax is an asset, even though it makes it > unpopular. When you try to "fix" it, you get something that cannot > survive. OO won't help us there. - Is Magic/L described somewhere? - Are you spelling doom for Mops here :-) > I your above example "a[2]", how do you specify a computed index? How > do you specify a computed base array? Well, a[], a[I], a[J] and a[K] is enough in most cases, but it wouldn't be difficult to allow a[]. If you mean a full expression between '[' and ']', you must draw the line somewhere. Computed base: LOCAL a a[1]=4 , which is my favourite construction with the FSL-style arrays. Agreed, I do not see how to do this with objects easily (maybe 'local objects' would be nice?). >|> > My general position has been to write those bits of object-orientation >|> > that an application needs, when it is needed. E.g., in the Gray parser >|> > generator I used a simple implementation of OO that was tailored to >|> > the task. >|> >|> With this approach you will never find a need to do OOP, or will never >|> realize you're doing it. > > Well, I did use it, so I saw a need. And I realized what I was > doing. And if people do it without knowing it is OOP, so what? It was not my intention to imply you didn't know what you were doing. I have said several times I like Gray very much, but it never struck me as 'obviously object oriented'. BTW, "object oriented programming tailored to the task" strikes me as a contradiction in terms. > |> You must be willing to use somebody else's > |> libraries. Or is there more to OOP than this? > > You can see it as a good way to organize libraries. One of my > collegues says that OO is about reusability. Why bother with the additional syntax then? -marcel From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 08:09:35 GMT Message-ID: <4vh4jv$35b@hkusuc.hku.hk> References: <4v9ht6$m6p@hkusuc.hku.hk> <4vbelj$i73@seagoon.newcastle.edu.au> <4vf01r$iu@hkusuc.hku.hk> <321AD6DD.619@umich.edu> <4vgjff$qra@seagoon.newcastle.edu.au> Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: > The problem only arises when you might wish to combine >two different uses of braces in the same application. I'm not Fortunatelly this is not the case in (Dyn)OOF. It encourages the programmer to put everything into a separate vocabulary, thus into separate name space, so you can have both, the matrix { } and the OOF { } in paralell, you just have to specify if you are talking about OOP or matrices, but this is what CONTEXT is for. ;-)))) Andras From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 11:43:10 GMT Message-ID: <4vhh4e$cr@news.tuwien.ac.at> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> In article , stephenb@harlequin.co.uk (Stephen J Bevan) writes: |> In article <4vell5$149@news.tuwien.ac.at> anton@a0.complang.tuwien.ac.at (Anton Ertl) writes: |> 2) Similarly, the Neon syntax makes late binding inconvenient. But the |> important thing about object-oriented programming languages (in |> comparison with languages like Ada and Modula-2) is late binding. |> |> FYI: Ada (95) has late binding. Ada 95 is an object-oriented language. I, of course was referring to Ada 83, which was not object-oriented. - 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: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 08:06:06 GMT Message-ID: <4vh4de$35b@hkusuc.hku.hk> References: <4vf8so$bg5@hkusuc.hku.hk> <321B83DC.DB799AC@informatik.tu-muenchen.de> Bernd Paysan (paysan@informatik.tu-muenchen.de) wrote: >Zsoter Andras wrote: >> >> If I think about it the (Dyn)OOF syntax with the "{"-s (which can be replaced >> with something else if someone so wishes) has the defit advantage >> that the need to handle pointers-to-an-object disappears. >> >> The object represented by the cell on the top of the stack is activated >> by " { ", regardless how that cell was obtained in the first place. >I use >O O> for this purpose (this implies that there is an object >stack, which is the truth). Because I hide the methods in class-specific I have also though about a separate object stack, but I did not have enough registers on the brain-damaged x86 series to spare one for Object-Stack-Pointer, so I have settled with saving the previous object on the return stack by " { " and reloading it by " } ". >wordlists, method passing to an anonymous object still requires "class >method", which passes the method to the current object. Using "object In my (Dyn)OOF the method selector is identified by CONTEXT at compile time. On the other hand, the actual implementation of the method is identified by the value of the (hidden) VMT register (VMT Virtual Method Table, I have borrowed the term from Turbo Pascal, as the insides of the tables in these languages (TP and my (Dyn)OOF) are similar). >method" thus is only a shortcut for "object self >o class method o>" >(SELF is the method returning the pointer to the object). Well, in (Dyn)OOF it is " class method " then. I mean you have to specify an assumed class (by changing CONTEXT) at compile time, but the object itself can come from anywhere at run time, just make sure that it belongs to a class which "is an" object of a class you have assumed at compile time. ("Is a" means that, of course, the object can be of some subclass of the assumed class.) Andras From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 14:01:24 GMT Message-ID: <4vhp7k$6qb@news.tuwien.ac.at> References: <32107F3C.360E@austin.finnigan.com> <3211CD2B.2878@headwaters.com> <4v2cm2$ck@news.tuwien.ac.at> <4v6pqb$nlg@iaehv.IAEhv.nl> <4vell5$149@news.tuwien.ac.at> <321B220D.60A1@austin.finnigan.com> In article <321B220D.60A1@austin.finnigan.com>, Andrew McKewan writes: |> Anton Ertl wrote: |> > There are other reasons why I don't like the |> > Neon syntax: |> > |> > 1) In its natural form it requires named objects. If you want to send a |> > message to an object that you compute at run-time, you have to use a |> > special, less convenient syntax. |> |> I believe most uses will be for named objects. Dynamic object creation is |> not used as much in Forth as in other languages. Perhaps anonymous objects are not used in your Forth code. They are certainly used in mine. And what do you get for inconveniencing users of anonymous object? Do you get more convenient use of named objects? No. |> > 2) Similarly, the Neon syntax makes late binding inconvenient. But the |> > important thing about object-oriented programming languages (in |> > comparison with languages like Ada and Modula-2) is late binding. IMO |> > late binding should be easy; it should be the default. |> |> This is an argument we will not settle here. In a "pure" OO model like |> Smalltalk, all messages are late bound. This provides the most flexible |> model. But it has a few disadvantages: |> |> 1. It is slower that early binding Yes, but people accept the slight run-time penalty when they want to do OOP. When they don't do late binding, they don't do OOP. The typical OOP example is the list of graphical objects (circles, triangles,...), where you send each object the message DrawThyself. To make this work, you need late binding (note also the use of anonymous objects). Of course, when you always send messages to named objects, you don't need late binding. You don't need OOP. What you are doing is not OOP, but static overloading resolution. Anyway, my point was that the Neon syntax makes late binding inconvenient. It is possible to have a syntax that makes late binding convenient; in the case of a named object (i.e., the case when the Neon syntax is convenient and does early binding), early binding can be applied as an optimization, if you want (Bernd Paysan does this (in an ugly way)). However, IMO the optimization is not worth the trouble. |> (often considerably slower). AFAIK that's the case for your reference implementation. Here's the code sequence doing late binding in my package: does> @ over @ + perform Rewrite that as ;CODE-sequence, and the overhead will be negligible. |> 2. Unknown messages are caught at runtime, making debugging more |> difficult. We (i.e., the Forth community) have lived without static checking for a long time. We have even lived without dynamic checking. I think we know how to deal with this. |> > 3) Finally, though that may be a matter of taste, I dislike the "selector |> > object" order. Forth always put the operation last, and communicated |> > through the stack. Similarly, the method selector should expect its |> > object on the stack instead of in the input stream. |> |> I agree, but this complicates early binding. To do this, we really need |> to get both the object and selector together, so one would need to parse |> the other. There are other methods. E.g., the selector could check the last word (in the intermediate code). If it is an object, it can perform early binding. Anyway, early binding when the object is known is just an optimization; it does not enhance expressive power. |> > Generally, words that read from the input stream are a bad idea. |> |> But sometimes the best and most convenient way. How about changing Forth |> to be truly postfix: |> |> S" NAME" : ; |> 0 S" ZERO" CONSTANT |> |> Whoops, S" parses from the input stream. I also wrote: Words that read from the input stream should be factored into a part that reads the input stream, and a processing part. S" is a word whose job is to parse the input stream and nothing else, so it's ok (it has it's problems, but that is another topic). So, yes, factoring : into a word that parses the input stream (ANS Forth provides several) and a word :NAME ( addr u -- ) is a good idea. In Gforth, we did something more general: there is a word NEXTNAME ( addr u -- ) that provides the name for the next compilation word. This is not as nice as :NAME etc. would be, but it works with all defining words. - 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Objects for ANS Forth Date: 22 Aug 1996 14:40:42 GMT Message-ID: <4vhrha$6qb@news.tuwien.ac.at> References: <840414075.AA00428@ear.co.at> <321B3F72.3E992345@informatik.tu-muenchen.de> In article <321B3F72.3E992345@informatik.tu-muenchen.de>, Bernd Paysan writes: |> There are parsing OOFs out there, and non-parsing, both orders. E.g. the |> " "-approach lets push an ID to the stack (e.g. |> the offset in the object's dispatch table), and contains the |> message dispatcher code. That would be the non-parsing " " approach. That would mean that the mention of a named object always tries to do a method dispatch for this object. If we want to pass a named object around on the stack, we would have to (e.g.) tick it. If we want to send a message to a computed object, we would have to use a sequence like " SWAP EXECUTE". IMO this shows that the " " approach is unnatural for non-parsing OOFs. The " " syntax is natural for them. As you point out, " " can also be used with parsing OOFs. The Neon syntax is such that you have to use a parsing approach. |> A message is a method/message id and parameters, passed to an object. OO |> vocabulary is inherently inconsistent :-(. Let's use "(method) selector" for the "method/message id". [apples :count] |> It's just the language you chose, in german, this syntax is ok. I saw some very old English (actually Anglo-Saxon) recently. In that sample, there was apparently no subject-predicat-object rule, but the predicate came in the second position, like in German. |> Following Leo Brodie, we should not force |> natural language diction, if there's a better approach. Yes. - anton If you say |> "apples @", natural english language would say "fetch (number of) |> apples". BTW: conventional OO language almost all use the "object |> method" order, so the C++ people should not have a problem here. |> |> -- |> Bernd Paysan |> "Late answers are wrong answers!" |> http://www.informatik.tu-muenchen.de/~paysan/ -- 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: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Hang on, isn't Forth out of date now? Date: 22 Aug 1996 09:48:07 GMT Message-ID: <4vhacn$cr@news.tuwien.ac.at> References: <3215D350.2344BDFE@informatik.tu-muenchen.de> <4ve85t$clf@iaehv.IAEhv.nl> To: mhx@IAEhv.nl (Marcel Hendrix) In article <4ve85t$clf@iaehv.IAEhv.nl>, mhx@IAEhv.nl (Marcel Hendrix) writes: |> Bernd Paysan writes |> > mov -4 [ebx], esi |> |> [1] |> |> > sub ebp, # 4 |> Nice. But isn't there a (very small) chance of a bug here? Imagine an |> interrupt handler written in Forth, that kicks in at [1] (At that |> place you are writing to a location that is not yours yet.) Just change the convention: The interrupt handler has to assume that -4[ebp] belongs to the interrupted program (the ebx above seems to be a typo). |> BTW, do you happen to have any more of these Pentium coding tips (or |> pointers to them)? The Pentium Manual mentions the application note AP-500, Optimizations for Intel's 32-bit Processors, order number 241799. I once downloaded it from some Intel site (in MS Word format, brrr; had to use a Mac to print it, and MS Word is not even compatible between Wiondows and Mac :-(((), but the last time I looked (to see if they had updated it), I did not find it. - 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: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: array notation -- again! X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: Date: Thu, 22 Aug 1996 16:50:25 GMT Marcel Hendrix wrote, anent Andrew McKewan's object code \ This is a very simple-minded test, using the extended TO operators \ available in iForth: 0 value index 6 array apples : test CR timer-reset CLEAR index 10000000 0 DO 12 +TO (( index )) apples LOOP .elapsed CR 0 apples . ; test \ Output: 0.727 seconds elapsed. 120000000 ok \ Here's how I did the same with CLASS.FTH loaded. Var Index 6 Array Apples : test2 CR TIMER-RESET Clear: Index 10000000 0 DO 12 Get: Index +To: Apples LOOP .ELAPSED CR 0 At: Apples . ; test2 \ Output: 20.896 seconds elapsed. 120000000 ok The (speed) difference is quite unacceptable. (for other Forth implementations the results might be less extreme). Also, I hope there is a terser way to address arrays. What I've ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ done above is not very readable :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ While I do not feel competent to comment on the specifically OO part of the posts (objects? never touch the stuff!) I agree with Marcel that there should be a terser and more graceful way to address arrays. In fact, in the interest of making an array notation that would be clearer to users of more mainstream languages, while remaining within the canons of Forth usage, I developed the notation touted in my book. It was adopted by the Scientific Subroutine Library Project so I suppose others agree. My arrays are dumb--or at least half-witted, since they return a type descriptor as well as an address. The smartness is contained in the operator } that, given a type descriptor, index and base address, computes the physical address of the array element: : } ( base-adr type ndx -- adr type) >r tuck #bytes r> * + swap ; Normally this would be optimized as a CODE definition. The other part of the array notation is the inclusion of a { in the array name, purely for esthetic reasons. Thus, apples{ 5 } returns the address and type of the 6th element of apples{ . Lately I have changed the type descriptors: I use only 4 types, so there is a lot of waste if I use an entire CELL to hold it. (And alignment generally demands a whole cell.) Until recently a lookup table returned the number of bytes occupied by each entry. However, it has occurred that to me that it is easier to include the length information in the type descriptor. Thus, in a 16-bit system : TYPE swap 256* + CONSTANT ; 4 0 TYPE REAL*4 8 1 TYPE REAL*8 8 2 TYPE COMPLEX 16 3 TYPE DCOMPLEX \ etc. alias #bytes 256/ \ 8-bit right-shift Don't know why I didn't think of it 5 years ago... -- Julian V. Noble jvn@virginia.edu From: Georg_Bauer@ms3.maus.westfalen.de (Georg Bauer) Message-ID: <199608221437.a31895@ms3.maus.de> References: <4vcisb$50g@life.ai.mit.edu> Subject: Forth for SUN 3/50 X-Software: Erwinsgate gb1.0 (c) es@do2.maus.ruhr.de, gb@ms3.maus.westfalen.de Date: Thu, 22 Aug 96 14:37:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! MC> The whole idea of using a Sun computer is to use Unix on a MC>network. But that's the problem - as you say, Unix is a memory hog. Ok, SunOs isn't that big, but on a 4M system you get in trouble as soon as you try to do something with graphics (even SunView get's a bit sluggish on a 4M system). MC>Four megabytes is a large memory, unless you waste it on operating MC>systems like Unix and worse. :-) MC> Since Forth programs don't waste memory or MC>compile time, they would work extremely well on a Sun 3/50. Exactly. That's why I asked. Hmm. Maybe I find some spare time and can go and try it myself. bye, Georg From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: multiple values Date: Thu, 22 Aug 1996 17:26:18 GMT Message-ID: <4vi58f$qp2@news.NL.net> References: <40.10697.1617@channel1.com> <32109842.66AA@inlink.com> <4uqv9c$b8g@news.NL.net> <321383F0.58FB@inlink.com> <4v17ou$j5k@dfw-ixnews10.ix.netcom.com> <32164C9F.179F@inlink.com> <4v9a2i$av@dfw-ixnews5.ix.netcom.com> <4vbdl8$i73@seagoon.newcastle.edu.au> <4vhs3g$6qb@news.tuwien.ac.at> anton@a0.complang.tuwien.ac.at (Anton Ertl) wrote: >In article <4vbdl8$i73@seagoon.newcastle.edu.au>, "Bruce R. McFarling" writes: >|> JEThomas@ix.netcom.com (Jonah Thomas) wrote: >|> >I find ?DUP useful in the following situation: >|> > >|> >... DO-SOMETHING? ( addr|0 ) ?DUP IF DO-IT THEN ... >|> >|> If that what ?DUP can be used for safely, then why not >|> build it into a version of IF -- since that permits the peephole >|> optimization of an IF that simply does not consume a non-zero >|> top of stack. In other words, >|> >|> ?DUP-IF DO-IT THEN >Yes. Gforth has ?DUP-IF and ?DUP-0=-IF. In the current development >version (not yet released) they are faster than the corresponding >sequence of words. >It does not provide ?DUP-WHILE, ?DUP-UNTIL etc. In the IF case the >?DUP stuff can eliminate the need for an ELSE part. That's not the >case for WHILE and UNTIL. At least it binds the ?DUP to the IF part. If anything, I think this is the best solution to this problem so far. H.