From: mikeh@starnine.com (Mike Haas) Subject: Re: Forth in Forth? Date: Wed, 12 Oct 1994 04:19:17 GMT In article <36pspk$8f0@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes: >In article <36kd0g$jr9@nyx10.cs.du.edu> jwoehr@nyx10.cs.du.edu (jack woehr) writes: >>tommy.hallgren@flower.ct.se (Tommy Hallgren) writes: >>>Has anyone written a FORTH using FORTH? I think this is too abstract for me, so >>>some examples of how to do it would be nice. >> Most Forth was written in Forth in the classic era. See Laxen&Perry >>F83 for example, or read Ting's book, _INSIDE F83_. > >Strange to think of F83 as the classic era... > >I wonder what the true mix is now as far as implementation techniques >goes. Assembler data statements a la Fig-Forth have pretty much >disappeared (except for EFORTH anyway), and the public domain systems >seem to have drifted towards Forth-in-C, I have seen Forth-in-C offer valuable debugging services for C programmers, but wonder if it is useful for any real-world applications. I've not spent any great dwal of time with any of them, but from the little I've seen, they seem to be too slow for serious applications-based programming. >our UR/FORTH systems are built by compiling Forth source code >directly into Intel OMF modules, which are then fed through the >system linker (along with object modules produced with Masm, C, and >other tools) to create the executable kernel. The full development >environment is then constructed by loading Forth source code on top >of the kernel in a more conventional fashion. Our ROMable Forth >kernels for microcontrollers, on the other hand, are still compiled >directly from Forth source code to an absolute executable image, >which is left in a file on disk ready for transfer to an EPROM >or ROM emulator. I still prefer this approach because it is simple >and self-contained, but it has become impractical in complex >host system environments. > >It will be interesting to hear what techniques other Forth vendors >are using these days, if they care to comment. > JForth's kernel is created from a very-standard 68K assembler. The rest of the system is self-generated on top of that. JForth is primarily JSR-threaded, but the compiler allows one to set a variable called MAX-INLINE. Basically, if the word being compiled is equal or smaller than the value of MAX-INLINE (which is user-settable), it will simply lay down the assembly inline, rather than compiling a JSR to that word. This allows for drastic control over size vs. speed situations... one can even change the setting to something large for the body of a loop, then back to something small outside of the loop, all within a definition. Being so assemby-oriented, JForth requires birth from assembler so that the exact assembly make-up of each work can be specified. From: gordon@charlton.demon.co.uk (Gordon Charlton)@charlton.demon.co.uk (Gordon Charlton) Subject: Eat crow, Charlton! Date: Tue, 11 Oct 1994 22:47:06 GMT As everyone else has been too polite to mention it, allow me to draw attention to my own errors. I have stated, both here and in other places, that WHILE can be followed by ELSE in ANS Forth. Of course it can't. What you can do (and I'm not trying to resurrect the control flow debate yet again, just setting the record straight) is; : WHEN POSTPONE 0= POSTPONE WHILE ; IMMEDIATE : DONE 1 CS-ROLL POSTPONE ELSE 1 CS-ROLL ; IMMEDIATE WHEN ... DONE is allowable. Trouble was I've been using my own system for so long that I just assumed ANS worked the same way without checking. Of course when I tried to do it for myself I got a nasty shock... BCNU Gordon {gordon@charlton.demon.co.uk} For many years I wished to join a Glee Club, on the supposition that it would be a body of people dedicated to promoting the act of grinning like a ninny. From: mikc@gnu.ai.mit.edu (Mike Coughlin) Subject: Re: a proposed computer Date: 12 Oct 1994 13:25:26 GMT In article <37dnnv$d5l@purzel.e-technik.uni-kiel.de>, Ulrich Hoffmann wrote: >In jvn@fermi.clas.Virginia.EDU (Julian V. Noble) writes: > >>It [the Jupiter ACE] was fast compared with ZX81, but >>it had no function library (unlike the ZX81). > >Do you mean ACE-Forth was faster than ZX81-Basic? >What about ZX-Forth? The Sinclair ZX-80 and ZX-81 were designed when computer memory was vastly more expensive than it is now. These computers came with 1048 bytes of RAM. Yes 1 Kbyte. The version of Basic traded speed for memory use. It was a wonder that a computer could be made with such a small amount of RAM, and that it would do anything interesting at all. You could use these as programable calculators, write simple games, and learn about the joys and perils of programming at a very low cost. When 16 kbyte memories became available, versions of Forth were produced that could run at least 10 times faster than ZX Basic. But by that time other inexpensive computers such as the Commodore 64 were available, so Forth on the Sinclair never went anywhere. >I always thought the ZX81 and the Jupiter-ACE had a >very similar architecture. I don't see where the ACE >should get its performance... The developers of the Jupiter ACE worked for Sinclair but they could not convince the boss to make a special Forth computer. So they started their own company. The similarity between the two computers is a result of this common experience. The ACE had improved performance since it had enough RAM to use Forth's method of incremental compilation instead of Basic's slow intrepretation. The ACE had two major flaws it shared with the ZX-81. There was no easy way to plug in larger RAM chips to use the full 64 Kbyte address space and there was no floppy disk interface. If the ACE had these and also used a Motorola 6809 processor instead of the Zilog Z80, we would have had a true Forth machine that would have made a big difference in how the world looked at Forth. By the way, there is no truth to the rumor that Sinclair Basic was written in Forth. -- Michael Coughlin mikc@gnu.ai.mit.edu Cambridge, MA USA From: gordon@charlton.demon.co.uk (Gordon Charlton)@charlton.demon.co.uk (Gordon Charlton) Subject: Re: Code Bloat Date: Tue, 11 Oct 1994 23:10:40 GMT >What is interesting is that now there is research on measuring the >maintainability of code by looking at its code complexity, mainly the >nesting of control structures. When I sat though some presentations at >the fourth annual IEEE conference about the techniques I began to think >about Thinking Forth. I wonder what type of maintainability index a Forth >program would have? Paul E Bennett argues that Forth does pretty well, in his piece Forth And Safety Related Systems in euroForml '90 proceedings 1990, precisely by reducing the number of paths a program can take by reducing the need for conditional branching. Its a good article, not just for other people in the safety related business. It may not be financially viable to apply all of the stuff he suggests outside of that arena, but by God the folk at micro$oft could take a look at it, if they cared one iota about the number of bugs in their software. BCNU Gordon {gordon@charlton.demon.co.uk} There is only one reason that programs go wrong, and that's complexity. The proof? Anyone can write a bug free program, providing it's trivial enough. From: cgra@se.bel.alcbel.be (Chris Gray) Subject: Re: Forth in Forth? Date: 12 Oct 1994 15:39:14 GMT Reply-To: cgra@se.bel.alcatel.be In article , tommy.hallgren@flower.ct.se (Tommy Hallgren) writes: > [...] it's very abstract to write a forth in forth, at least for me. More so than writing a C compiler in C? ________________________________________________________________________ ___ Chris Gray cgra@btma74.se.bel.alcatel.be Compu$erve: 100065,2102 ________________________________________________________________________ ___ From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Code Bloat Date: 12 Oct 1994 10:42:24 -0700 (Darin Johnson) writes: > (Michel W Pelletier) writes: >> I won't reiterate most of the excelent explanations givin here. >> Suffice to say that factoring was discovered lon agon by mathamatics to >> simplify expressions. Same holds for any programming language. >But it's not the same, the only thing the same is the name and >the basic concept. For instance, as you have: What else is there? The basic concept is, in essence, the whole of factoring! (Sorry, that did sound sorta Zen :). >> (6xy^2z + 2x^2yz^2 + 4xyzb)/(2xy) >> [Factoring, cancelation...] >> z(3y + xz + 2b) >> Hmmm. Yes, much longer. >That's nothing at all like program factoring. (except perhaps >functional programming, which forth is not) What you simplified >was an expression only. It's an absurd analogy. Forth is (or can be) functional. That's one nice thing about it. >Instead, in a programming language (assuming procedural stuff >like forth), you may have: > a b c op1 > d op2 e op3 op4 > f op2 g op3 op4 >which could factor into: > ( assuming single ret value for op2) > : op5 ( arg1 arg2) swap op2 swap op3 op4 ; >Note, 1 more function than we had before :-) But the code >might be clearer. Well, your main problem here is that you're trying to solve the general factoring problem-- I don't think it can be done. I highly suspect that factoring is NP complete. There is no way to do a generic factor. >The original example, "open_window_with_two_sliders", or whatever >while ludicrous to have in a windowing system *library*, is ok >for use within a program if defined for ease of use. Ie, "op5" >above may be the same function. I'll buy that. However, if you ever have to open any other type of window, you'd best factor that. >> Also, the benifits of factoring and other stylist "optimizations" >> in the long run improve speed (in the short run in most cases), gives a >> program an automatic speed advantage. This is because factoring make you >> think smart, not like a computer (which is by no means smart). >A bit incorrect here. You have to do optimizations other than >factoring. Factoring, at least how I've had it explained to me >doesn't involve changing algorithms, it involves extracting >common functionality into reusable bits - that is the sequence >of steps taken remains basically the same. This by itself does >nothing. Instead, if you use those bits in different ways, then >you can get improvements. Factoring helps in distilling things >down into smaller chunks which can then be used when modifying >the algorithm. True. It's the thinking smart that helps the algorithm, not the factoring-- but the factoring helps the thinking smart. >But then this is silly. One should be factoring as one goes >along writing the initial algorithm, rather than trying to >factor an existing one (when circumstances allow). True. >> One area of 'compiler optimization' that I hate is the >> fact that language optimizers (ala C, PASCAL, FORTRAN) are stupid. >> Thourough, but stupid. I wrote some C code once and had the optimizations >> on full. It optimized (and grossly enlarged) every section of code except >> the part that took 80% of the time (the critical section) >The job of the optimizer is not to improve on a bad algorithm. >A good algorithm has nothing to do with factoring. Optimizers >are good at factoring at the low level, pulling out common >subexpressions, finding redundant or unused bits, etc. That wasn't what he was complaining about, although I don't think his was a fair complaint (how's the compiler supposed to guess which part takes the most time? Only a functional language coud do that). >> We >> can do this very well in forth because we get to develop the program one >> step at a time, seeing the critical sections evolve dynamically. The most >> important design module ofa C program is the debugger. The most important >> module of a FORTH program is the *programmer*. >More religious crap. And what the heck are you using "critical >sections" to mean? Its *accepted* definition has to do with >concurrent programming, and is out of place in your argument. Hey! Relax. Please. You're gonna offend someone (if not me). He meant "critical" as in "important", or time pressed. >The debuggers is not an important design tool unless you're >a bad programmer (note, I said "bad programmer" not "bad C >programmer"). The only think I can really make out of your >arguments is that a dynamic development environment is better >than a static one. (which isn't a Forth vs C thing) Nonsense. Everyone has to use the debugger in C. It replaces the incremental testing in Forth. >There's nothing there to prevent you designing your C programs >in the same way as your Forth programs! I've developed C >programs one step at a time. Almost true. It's just easier in Forth. >> I'm not worried about code bloat. One of these days the big >> companies will crumble under their weight, just like their programs. It is >> that time than they will look for smart programmers, not quick and dirty >> programmers. >You have to note where code bloat comes from. Most of the time >it's NOT from poor coding. Much of it comes from statically >linked libraries, expanded code from the compiler (loop unrolling), >extra functionality (spell checkers, cut buffers, help files), >and auxillary files (I think you may find your PC C compiler is >mostly auxillary stuff). Poor coding, poor design. Same schmiel. >With that sort of baggaged attached, you're going to get bloat >even if you stick to Forth. That's true. Any time you just save the Forth image to disk (as an executable) you see this. -Billy From: dheller@netcom.com (D 4/dheller/.nameDheller) Subject: 8051 CONTEST - DESIGN KIT OFFER! Date: Wed, 12 Oct 1994 17:06:33 GMT 8051 CONTEST & DESIGN KIT OFFER This announcement should be of interest to many of the electronic design engineers, scientists, and students who frequent this newsgroup. If you or your team are interested in developing systems or sub-systems using 80C51 derivative microcontrollers you probably qualify to enter Philips Dream Machine 8XC750 Design Contest. (See eligibility requirements and restrictions below*) Prizes for best designs ----------------------- First Place: A Chevrolet Camaro or equivalent cash Second Place: A color laptop computer or equivalent cash Third Place: A monochrome laptop computer or equivalent cash Deadline: Entries must be received by October 30, 1994 To Enter, or for more information, send e-mail to: -------------------------------- 8051-Contest@InetBSystems.us.com -------------------------------- We'll automatically respond by sending you a one-time mailing containing all the information you need to enter the contest. ---------------- SPECIAL OFFER Development Tool Kit -------------------- With the entry information you'll also receive a special offer you can use to get a DS-750 development tool kit. This kit includes an emulation board with cables, a power supply, software, user's manual, and programming examples -- everything you need to create winning designs. *Eligibility and restrictions. The Philips Dream Machine 8XC750 Design Contest is open to any individual or team interested in developing systems or sub-systems utilizing Philips 80C51 microcontrollers. Those prohibited from entering include government employees, employees of Philips and Philips' subsidiaries or its advertising agencies, or any family member of those employees. ----------------------------------------------------------------------- This Contest is Co-sponsored by Philips Semiconductors and EDN Magazine ----------------------------------------------------------------------- From: mhx@iaehv.iaehv.nl (Marcel Hendrix) Subject: Arbitrary branching Date: 12 Oct 1994 18:52:58 +0100 gordon@charlton.demon.co.uk (Gordon Charlton) writes: > I have been looking at Lex style pattern matching - hard coding > regular expressions etc in Forth, the full nine yards. It's not > all that hard, having done it before, ('91 euroForml) but > requires the ability to branch to an arbitary position in > previously traversed code. I have written an AWK in Forth ( called HAWK, go figure :-) ) that has full regular expressions, but I don't remember needing arbitrary position branching, nor access to the return stack. I translated the Pascal code shown in Sedgewick's 'Algorithms', page 265 (ISBN0-201-06672-6). The program uses a deque. Below are some of the regexps it recognizes (first column, second column is a test string) : (a*b+ac)d cdaabcaaabddacdaac i*j iiij i\*j i*j X.Y X+Y x[-+*]y x+y COUNT[12] COUNT3 [0-9] 6911 [a-zA-Z ] Hawk is fun [0-9^] ABCab^c0123,.? []#![@%] [#!@%]ABab,. \(.*\) (test), (response .EQ. 'Y'), (x=0;x .LE. 20;x=x+1) \[[0-9]*] [1353]..[3]..[ ]..[]...[count] $\) ) ) ) but not \)$ ^${ { but not ^{$ ^$ \(a\*b\+ac\)d (a*b+ac)d \\ \hello\ $C ssssssssssC The documentation says: " A regular expression can have up to 128 states ( ~ characters..) and may contain upto 10 lists." The $FF character can not be specified in a regular expression. For very large associative arrays the Forth name space is too small. At that time a dynamic symbol table is called for." so I guess I had a memory problem somewhere. If I were to do it again I would use Anton Ertl's GRAY. .-------Marcel Hendrix----------.------- Voice: +31-4950-41529--------. | mhx@iaehv.iaehv.nl | novix, rtx2000, rtx2001, ARM6 | | tms320c30, T8, 386/486, 80c32 | Forth programmers did it with words | `-------------------------------'-------------------------------------' From: jfox@netcom.com (Jeff Fox) Subject: Re: Forth in Forth? Date: Wed, 12 Oct 1994 17:29:48 GMT In article tommy.hallgren@flower.ct.se writes: > \ \ >This sounds very interesting, but please enlighten me, what is a metacompiler? >I've heard it some times, but never got a good explanation for it. > Metacompilation is the term that refers to compiling a new system not just an application that sits on top of the old compiler. Metacompilation is a little more complicated than normal compilation for several resons. Often the system being metacompiled is being compiled in a different location in memory than the one in which it will run when it is executed. Often the system being metacompiled is for a processor other than the one doing the metacompilation, so the compiled code can NEVER be run on the host processor. I like to use "IF" as an example of what a normal Forth compiler does, and to contrast it to what a metacompiler must do. In a threaded Forth the compiler just looks up the address of non-immediate words and compiles their address into a list. Immediate words like "IF" must execute during compilation. "IF" compiles a branching primivite sometimes called "if" into the application, and compiles an unresolved branch address, and leaves the address of this branch address somewhere so that the correct address can be stored by an "ELSE" or "THEN". A metacompiler does almost the same thing, but it looks up the address of non-immediate words in the target dictionary and compiles the address into the target definition. But the word "IF" in the metacompiler must compile a reference to the target "if", and normally it cannot do this by just executing the target "IF". All of the words that do immediate things during compilation must have a definition in the metacompiler that will do these immediate things to the target system being compiled rather just extending the normal Forth system. The things that make it more complicated than normal compilation are that memory offsets may be needed to compensate for the fact that the target may be built up in one place in memory, but may be constructed to run in a different location in memory. The processor may be a different processor, so a new assembler may be needed, and none of the target code may actually be executable at all on the machine doing the metacompilation. I wrote a paper last year about how simple it is to metacompile eforth. It is my opinion that Forth beginners can understand all the things that go on in a metacompiler. I can email a copy of the paper to anyone who is interested, just send me some email. A couple of days ago I posted the latest metacompiler that I am using to metacompile MuP21 eForth in MuP21 eForth. This metacompiler is a special class of metacompiler where the target system sits in a location where it can run, and where the target code is executable by the machine doing the metacompilation. This type of metacompiler is so simple that it only needs one word. > JF> Jeff (If it can't compile itself from a few k of source to a couple k > JF> of object in a couple of seconds its crap!) Fox > >C00l! 8-) > >Well to sumarize this, it's very abstract to write a forth in forth, at least >for me. > > Tommy Hallgren(tommy@flower.ct.se) IRC: D-Bug > "DATORERNA RÄDDADE MIG FRÅN IDROTTEN!" - Tommy Hallgren > > The problem is often called "the chicken or egg" problem. Where does it all start? How can I compile Forth with Forth until I already have a Forth? The Forth that does the metacompilation must come from somewhere. It may be a Forth created in any way, and after a metacompiled is added to it it can compile new Forths. MuP21 eForth was first compiled with FPC. Now it is compiled by MuP21 eForth with its own metacompiler. Other than the conceptual problem of "the chicken or egg" a metacompiler is only slightly more complex than a normal Forth compiler. Jeff Fox From: tommy.hallgren@flower.ct.se (Tommy Hallgren) Subject: Syntax question Date: Wed, 12 Oct 94 10:54:00 +0100 Reply-To: tommy.hallgren@flower.ct.se In-Reply-To: Jim Schneider's message X-Mailer: uugate 0.35 (OS/2 2.99) (Fidonet Gateway) Jim Schneider wrote: JS> From: japs@netcom.com (Jim Schneider) JS> If I were writing an application to get Jack to put boxes on tables, JS> you can be sure I'd try to write it so I could say "JACK PUT BOX ON JS> TABLE". I prefer to think in stack diagrams. : box ( -- item ) ; : table ( -- item ) ; : put ( -- cmd ) ; : on ( -- state ) ; : jack ( item1 item2 state cmd -- ) ; Then just saying: box table on put jack of course the input of jack can be juggled with, this is just an example, perhaps another order would make life easier. In your example, it seems to me that it isn't jack that is putting the box on the table. Of course, your example is just as working as mine is. :-) Tommy Hallgren(tommy@flower.ct.se) IRC: D-Bug "DATORERNA RÄDDADE MIG FRÅN IDROTTEN!" - Tommy Hallgren From: sfp@mpeltd.demon.co.uk (Stephen Pelc) Subject: Re: Order of ORDER output Reply-To: sfp@mpeltd.demon.co.uk Date: Wed, 12 Oct 1994 19:47:48 +0000 In article plewe@ks.mpi-dortmund.mpg.de "J.Plewe" writes: > J.Plewe (plewe@ks.mpi-dortmund.mpg.de) wrote: > : Anton Ertl (anton@mips.complang.tuwien.ac.at) wrote: > : : How would you like the output of ORDER? In particular, in what order > : : should the names of the vocabularies be output? TOS first, as in F83, > : : or TOS last, as in stack comments? > > : TOS first, I think, is most common an intuitive. > > I looked it up: the standard is clear in this point (you are talking about > a standard system, do you?): > > 'Display the word lists in the search order in their search order sequence, > from first searched to last searched.' Is that from left to right, or from right to left? -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: tommy.hallgren@flower.ct.se (Tommy Hallgren) Subject: Why PD when commercial is SOO much better? Date: Wed, 12 Oct 94 12:12:00 +0100 Reply-To: tommy.hallgren@flower.ct.se In-Reply-To: Ulrich Hoffmann's message X-Mailer: uugate 0.35 (OS/2 2.99) (Fidonet Gateway) Ulrich Hoffmann wrote: UH> From: uho@informatik.uni-kiel.d400.de (Ulrich Hoffmann) >> I've seen some PD/FD forths, like F-PC(16-bit,MS-DOS), >> JaxForth(32-bit,Amiga), A4th(16-bit,Amiga) and perhaps some more. I must >> say it's like comparing a VW with a Mercedez. Of these JaxForth is the >> best so far. But they lack a lot of support files and good documentation, >> which is very important. Reading source code isn't the same you know. UH> Would you please explain, why you think F-PC is poorly documented, given UH> the User-Guide (included), The Reference-Guide by Ting and "Real Time UH> Forth" by Tim Hendtlass? All you get is a bunch of files. Named Chapter1-18 (I think) and some more. I've read most of them and I still don't get how parameters are passed to a code-word, at least no more than one parameter. And how do you make an executable from your code? And I don't mean something that is 170kb and writes 'Hello world' and includes the entire system. But it is perhaps not as bad as I said. UH> Would you please explain, why you think F-PC lacks support files, given UH> lots of user contributions available? Compared to JForth there are very few support files included that does something useful. And the editor isn't the greatest either. I would prefer using something more standard. Tommy Hallgren(tommy@flower.ct.se) IRC: D-Bug "DATORERNA RÄDDADE MIG FRÅN IDROTTEN!" - Tommy Hallgren From: gordon@charlton.demon.co.uk (Gordon Charlton)@charlton.demon.co.uk (Gordon Charlton) Subject: Re: Eat crow, Charlton! Date: Wed, 12 Oct 1994 09:24:08 GMT In article <86@charlton.demon.co.uk> I wrote; >: WHEN POSTPONE 0= POSTPONE WHILE ; IMMEDIATE Hmm, more boiled crow. Should be; : WHEN POSTPONE WHILE ; IMMEDIATE Oh foolish me. BCNU Gordon {gordon@charlton.demon.co.uk} From: qramika@kierac224.ericsson.se (Mikael Karlsson kons. AR/AF) Subject: Re: FORTH for us youngin's In-Reply-To: erather@aol.com's message of 11 Oct 1994 16:20:08 -0400 Date: Thu, 13 Oct 1994 08:34:06 GMT In article <37es1o$2e2@newsbf01.news.aol.com> erather@aol.com (Erather) writes: > Regarding the interesting discussion about learning Forth... . . > Although Mike Coughlin is right that ANS Forth itself isn't helpful to > beginners (it's a Standard, not a tutorial!), I hope that it will exert a > strong pressure on implementors to converge and minimize dialectic > differences. I would say that ANS Forth could be helpful to beginners... I am quite new to Forth and my way of getting to know Forth during the last 6 months or so has followed an 'ANS Forth path' : 1st I read this newsgroup ( not dedicated to ANS Forth but it is discussed occasionally ). 2nd I read Jack Woehrs book, Forth: The New Model, which I think is an excellent introduction to Forth as it also covers the ANS proposal. Yes you want to read about new things even though you don't know the whole History of Forth. Maybe I pick up Starting Forth or Thinking Forth later. 3rd I got my hands on a public ANS Forth, in my case the Portable Forth Environment, PFE, by Dirk Uwe Zoller. It is written in ANSI C, and covers most (all?) words in every word set in ANS Forth. 4th I downloaded the dpANS-6 document from: ftp://ftp.uu.net directory: /vendor/minerva/x3j14 I found that this document is an excellent reference, even for a novice. For me as a beginner ANS Forth has meant that I can concentrate on one Forth dialect when learning the language, and that I can get quite good information about it and also tools to excercise with. ANS Forth also attracts me as it points out that this language is alive and well worth to learn for future uses. ---- Mikael Karlsson qramika@eras70.ericsson.se From: jfox@netcom.com (Jeff Fox) Subject: Forth Opinion Poll Date: Thu, 13 Oct 1994 06:29:38 GMT I have noticed over the years that comp.lang.forth tends to discuss the same subjects every year or two. :-) Forth Opinion Poll Please Pick a number to represent your opinion on each of the questions. If your opinion cannot be expressed from 1 to 5 pick a number outside of this range ( <1 or >5 ) to represent more extreme opinions. Or some combination of numbers, or an essay answer is acceptable. If anyone does send me an opinion profile I will not publish the person's name and profile unless they specifically state that they want their name used as an example to educate/enlighten others. FIG is ___ 1 alive and well 2 alive and ok 3 neutral/don't know/don't care/no opinion 4 ill 5 dead Public domain Forth software is ___ 1 great, I love it 2 ok, but a lot of it is crap 3 neutral/don't know/don't care/no opinion 4 it's mostly crap 5 it's terrible, it ruins Forth for everyone Mysticism ___ 1 is key to Forth, I live for the Tao of Forth 2 important since Forth is a concept more than a language 3 neutral/don't know/don't care/no opinion 4 has no place here, Forth is a tool for practial things, get real 5 it's terrible, it ruins Forth for everyone The ANS Forth standard ___ 1 is great, I love standards, and this one in particular 2 is better than no Forth standard 3 neutral/don't know/don't care/no opinion 4 is ok for some people, but I won't use it much 5 it's terrible, it ruins Forth for everyone In Forth BLOCKS ___ 1 are great, they are fast and portable 2 are usually better than files, ANS says you need them with files 3 neutral/don't know/don't care/no opinion 4 files are better, get real 5 are terrible, they ruin Forth for everyone Minimalism in Forth ___ 1 is a key concept, if it isn't minimal is isn't Forth 2 sometimes useful 3 neutral/don't know/don't care/no opinion 4 usually the problem with what is wrong with Forth in the first place 5 it's terrible, it ruins Forth for everyone, if it doesn't have everything it's not Forth Comments ___ 1 are more important that code itself 2 are useful if done properly 3 neutral/don't know/don't care/no opinion 4 can be useful if the code isn't clear and well named 5 I don't need them "C" ___ 1 is a bad joke, you could write it in Forth but why bother 2 is ok for some things, but generally I avoid it 3 neutral/don't know/don't care/no opinion/all the same 4 is usually better than Forth, but Forth is still good for some things 5 is the language to use to write Forth if you want Forth A separate Floating Point stack in Forth ___ 1 is a key concept, it is the only way to go 2 is usually better, but ANS says both ways are ok 3 neutral/don't know/don't care/no opinion 4 is not better, anyway ANS says I don't need it 5 it's terrible, it ruins Forth for everyone, who needs FP anyway Cooperative multitasking in Forth ___ 1 is great, its simple and portable 2 sometimes it is ok, but there may be better alternatives 3 neutral/don't know/don't care/no opinion 4 is poor compared to hardware or OS supported pre-emptive multitasking 5 is terrible, it ruins Forth for everyone Local variables in Forth ___ 1 are a key concept, if you do them my way 2 are sometimes useful 3 neutral/don't know/don't care/no opinion 4 are more trouble than use 5 are terrible, they ruin Forth for everyone Object Oriented Forth ___ 1 is great, it is the best way to go 2 is good, but regular Forth or a real OO language might be better 3 neutral/don't know/don't care/no opinion 4 doesn't help much, or can be a problem 5 is terrible, it ruins Forth for everyone, stick to regular Forth I ___ 1 know very little about Forth or computers 2 know something about Forth or computers 3 know quite a bit about Forth or computers 4 am a Forth black belt 5 have mastered Forth Forth Opinion Poll FIG is ___ Public domain Forth software is ___ Mysticism ___ The ANS Forth standard ___ In Forth BLOCKS ___ Minimalism in Forth ___ Comments ___ "C" ___ A separate Floating Point stack in Forth ___ Cooperative multitasking in Forth ___ Local variables in Forth ___ Object Oriented Forth ___ I ___ Results may be expressed in a 13 digit form "2112121121424" or in a more detailed form and emailed to jfox@netcom.com :-) From: lennart@blade.stack.urc.tue.nl (Lennart Benschop) Subject: Re: a proposed computer Date: 13 Oct 1994 09:46:48 GMT In article <37go46INNkfj@life.ai.mit.edu>, Mike Coughlin wrote: > By the way, there is no truth to the rumor that Sinclair Basic was >written in Forth. What was true, that some of the arithmetic routines in Sinclair Basic (for COS , EXP etc) were written in some kind of byte-code for a stack machine. See "The Complete Spectrum ROM DIsassembly" for what I mean. This byte-code had primitives for addition, compare, etc of floating point numbers on a stack. Further there was a conditional branch primitive, DROP, SWAP and DUP primitives and primitives to store and load numbers in 5 calculator memories. Some of the byte codes were for literals and some called other routines that contained byte code in turn. There was a function table to convert byte codes to routine addresses. Byte code and regular machine code could be mixed in one routine. The RST 30h opcode called the byte code interpreter and one of the bytecodes returned to machine code execution from the next address. There may be some inaccuracies in this story, but the basics are true. -- Lennart Benschop --- lennart@stack.urc.tue.nl "Real programmers do it in hacks." 52 65 61 6C 20 70 72 6F 67 72 61 6D 6D 65 72 73 20 64 6F 20 69 74 20 69 6E 20 68 61 63 6B 73 2E Forth/C/6809/Linux/ZX-Spectrum/Z80/80x86 From: plewe@ks.mpi-dortmund.mpg.de (J.Plewe) Subject: Re: Order of ORDER output Date: Thu, 13 Oct 1994 13:08:16 GMT Stephen Pelc (sfp@mpeltd.demon.co.uk) wrote: : In article : plewe@ks.mpi-dortmund.mpg.de "J.Plewe" writes: : > J.Plewe (plewe@ks.mpi-dortmund.mpg.de) wrote: : > : > I looked it up: the standard is clear in this point (you are talking about : > a standard system, do you?): : > : > 'Display the word lists in the search order in their search order sequence, : > from first searched to last searched.' : Is that from left to right, or from right to left? Which direction do you normally write? - Joerg From: smithn@ORVB.SAIC.COM Subject: Re: Forth in Forth? Date: 13 Oct 1994 08:41:24 -0500 mikeh@starnine.com (Mike Haas) wrote: > >I have seen Forth-in-C offer valuable debugging services for >C programmers, but wonder if it is useful for any real-world >applications. I've not spent any great dwal of time with any >of them, but from the little I've seen, they seem to be too >slow for serious applications-based programming. I agree that Forth-in-C is useful for debugging C programs, at least ones that make it trivial to add new C functions as words. I disagree that Forth-in-Cs are automatically to slow for practical use. I use a Forth-in-C frequently for file filters and other text manipulation applications on a 486 and the programs don't feel any slower than the similar programs we have written in AWK. Having a Forth-in-C that includes access to the complete C String and I/O function libraries and is set up to handle strings as either counted or null terminated helps. Running on an 8088 would be miserable. It does not bother me to waste a few cycles of cpu on a 'slow' Forth than it does to waste mips keeping the GUI going. From my prospective, a slow Forth is better than NO Forth. I tend to develop 'serious' applications as a combination of Forth and C. This offsets much of the speed disadvantage of Forth-in-C. (This also assumes that you use a Forth-in-C that is easy to add new C functions to.) I can't imagine using a Forth-in-C for real-time or truly time critical applications, but speed is not an issue for run of the mill utility programs that only take 10 or 15 seconds to process a file anyway. Norm Smith smithn@orvb.saic.com From: djohnson@seuss.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 13 Oct 1994 16:38:29 GMT <37h760$qtu@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 12 Oct 1994 10:42:24 -0700 > Forth is (or can be) functional. That's one nice thing about it. You can write in a functional style, but I've seen nothing in it similar to modern functional programming languages (ala Haskell, Crystal, etc). While it can be functional, so can most procedural languages. > True. It's the thinking smart that helps the algorithm, not the > factoring-- but the factoring helps the thinking smart. My big question then is why is "factoring" such a big deal with Forth? It's available in any language, with the same results, yet in Forth books and in this group it's always talked about as a big advantage of Forth. Other languages don't even use this term. > Nonsense. Everyone has to use the debugger in C. It replaces the > incremental testing in Forth. Except most non-Forth programmers I know do incremental testing as well. If a debugger is used in this stage, it's to get the advantages of an interpretive environment, not a Forth environment. so why is Forth better than other interpretive (or partially interpretive) environments in this regard? > >There's nothing there to prevent you designing your C programs > >in the same way as your Forth programs! I've developed C > >programs one step at a time. > > Almost true. It's just easier in Forth. And even easier in Lisp :-) > >You have to note where code bloat comes from. Most of the time > >it's NOT from poor coding. Much of it comes from statically > >linked libraries, expanded code from the compiler (loop unrolling), > >extra functionality (spell checkers, cut buffers, help files), > >and auxillary files (I think you may find your PC C compiler is > >mostly auxillary stuff). > > Poor coding, poor design. Same schmiel. Nothing I listed that causes common bloat has anything to do with poor design. -- Darin Johnson djohnson@ucsd.edu Where am I? In the village... What do you want? Information... From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Chars to printer port #2 ? Date: Thu, 13 Oct 1994 17:03:46 GMT snf_dw@debet.nhh.no writes: > In article <1994Oct11.173206.2131@debet>, snf_dw@debet.nhh.no writes: > > Help, I'm trying to write out my bills, and my #1 parallel printer port > > is broken. I've been addressing it using I/O adddresses 378, 379, 37A > > but since my IBM tech.ref. manual is for the old XT machine, I can't > > look up the coresponding addresses for the #2 parallel printer port !! > > If you have a tech.ref.manual for the PC AT or later, I hope you can > > help me by looking up the I/O address space table, not too far from the > > front I hope... > > Many thanks, David Walker snf_dw@debet.nhh.no > WORSE AND WORSE !! > I've been trying 279 instead of 379, but it turns out the rest of my > code uses call #5 to the dos kernel (FDOS call) to print a character. > You should use the operating system services to get device independence, > right ? > WRONG ! I don't find any device independence for printers in DOS. > The MODE command will redirect a parallel port to a serial port, > but you can't use it to swsitch the "standard printer device" mentioned > in the original IBM DOS manual (for the XT machine, of course) to > another parallel port. I.e. it seems DOS will not redirect my print > output to printer port #2 when my program uses a DOS kernel call to > send it to the "standard printer device" (DOS 5.0). > > So how do you tell the DOS kernel to output a character to the 2nd > parallel printer port ? Does anyone know if later versions of the > DOS technical manual (if any) have another call to the kernel > (i.e. not number 5) for that ? > > If not, I guess it's back to programming the raw hardware like I > should have done in the first place. Wait until not busy and all > that. > There is a place in DOS where the distinction between LPT1: and LPT2: is stored. There is available a trivial .com program that switches the two. I used for years (unfortunately it is not here or I would uuencode it for you). Alternatively, you might want to first output to a file, then (assuming the file has embedded printer codes) copy /b file.name lpt2: should do it. If your word proccessor, program or whatever won't print to a file, you can use a utility prn2file.com found among the PC Magazine utilities to capture a printer stream to a file. -- Julian V. Noble jvn@virginia.edu From: roedy@BIX.com (Roedy Green) Subject: Re: Chars to printer port #2 ? Date: Thu, 13 Oct 1994 10:28:19 Here are some routines to deal with the printer, taken directly from BBL/Abundance. They are designed to be configured at compile time for a single printer, which explains the odd use of PRINTER-PORT rather than the stack: Note, these are the parallel port versions. Serial must be done a totally different way. They are written in SPASM PostFix assembler, which is similar to Laxen and Perry's assembler. 2 # AH MOV is MOV AH,2 in Intel assembler. AX BX ADD is ADD BX,AX =, IF, is JNE ******************************** 1 CONSTANT PRINTER-PORT ( 0= LPT1: 1=LPT2: etc ) HEX CODE PRINTER-READY? ( -- OK flag via ROM BIOS INT 17h ) \ bit 7 = not busy ) ( see page A-46 Tech Ref ROM BIOS ) \ bit 6 = ack *bit 5 = out of paper *bit 4 = selected \ *bit 3 = i/o error *bit 0 = timeout PUSHCB 2 # AH MOV PRINTER-PORT 3 FORTH AND ASSEMBLER ( 0= LPT1: 1=LPT2: etc ) # DX MOV 017 # INT ( status is in AH ) AH AL MOV AH AH XOR ( 0 ) BINARY 00111001 # AX AND ( mask off all but bits 5430 ) 00010000 # AX CMP ( good =no timeout, no err, sel, paper) DECIMAL =, IF, -1 # CX MOV ELSE, DI CX MOV THEN, CX BX MOV NEXT ;C ****************** HEX CODE PRINTER-RESET ( -- reset printer, Kills printer buffer! ) 1 # AH MOV PRINTER-PORT 3 FORTH AND ASSEMBLER ( 0= LPT1: 1=LPT2: etc ) # DX MOV 017 # INT NEXT ;C DECIMAL ********************** CODE PEMIT ( char -- : emit char to LPT2: printer ) CS: FORTH OUT ASSEMBLER #) WORD INC ( col counter ) BL AL MOV ( char -> al ) PRINTER-PORT 3 FORTH AND ASSEMBLER ( 0= LPT1: 1=LPT2: etc ) # DX MOV ( select LPT2: ) 0 # AH MOV ( function 0 ) HEX 17 # INT ( BIOS printer int ) POPCB NEXT ;C DECIMAL ************************************** PTYPE ( addr len -- : types string to LPT2: printer ) ( ok if len=0. Not ok if len<0. ) OVER + SWAP ( to+1 from ) ?DO I C@ PEMIT LOOP ; ****************************************** Roedy@bix.com -30- From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Code Bloat Date: 13 Oct 1994 11:15:31 -0700 In article djohnson@seuss.ucsd.edu (Darin Johnson) writes: >> Forth is (or can be) functional. That's one nice thing about it. >You can write in a functional style, but I've seen nothing >in it similar to modern functional programming languages (ala >Haskell, Crystal, etc). While it can be functional, so can >most procedural languages. And a well-factored procedure/module (notice how I changed the vocabulary here) is functional. Your point was that factoring only works well in functional languages; well, Forth is one when properly factored. Naturally, you're right that it's not strictly functional when considered by words, but often a modular structure should be used. >> True. It's the thinking smart that helps the algorithm, not the >> factoring-- but the factoring helps the thinking smart. >My big question then is why is "factoring" such a big deal >with Forth? It's available in any language, with the same >results, yet in Forth books and in this group it's always >talked about as a big advantage of Forth. Other languages >don't even use this term. Factored words look better and cost less in Forth. This is strictly due to the implicit parameter passing. In other languages factoring creates an ugly, time-consuming and unreadable mess; in forth it creates a clear, acceptably-quick and (you get the idea). Of course, factoring does use some computer speed; the word call takes a while longer, so commonly used words are combined (such as 2*). This is also due to algorithm, though, and as Thinking Forth says "any non-factored words must have clearly documented speed advantages". You can replace "must" with "should" here, if you like. >> Nonsense. Everyone has to use the debugger in C. It replaces the >> incremental testing in Forth. >Except most non-Forth programmers I know do incremental testing >as well. If a debugger is used in this stage, it's to get the >advantages of an interpretive environment, not a Forth environment. >so why is Forth better than other interpretive (or partially >interpretive) environments in this regard? In that respect it's not. I never said Forth was the be-all and end-all, I said factoring was the most efficient way to code (or something like that:). So Forth replaces a C compiler, debugger, and who knows what else in a fraction of the space. >> >There's nothing there to prevent you designing your C programs >> >in the same way as your Forth programs! I've developed C >> >programs one step at a time. >> Almost true. It's just easier in Forth. >And even easier in Lisp :-) It is as easy in Lisp, although I haven't ever done anything significant in it. The problem with Lisp is that it uses explicit parameter passing to give you a veritable nest of parenthesis; the advantage is that it uses explicit parameter passing to let the interpreter do some of your work for you. >> >You have to note where code bloat comes from. Most of the time >> >it's NOT from poor coding. Much of it comes from statically >> >linked libraries, expanded code from the compiler (loop unrolling), >> >extra functionality (spell checkers, cut buffers, help files), >> >and auxillary files (I think you may find your PC C compiler is >> >mostly auxillary stuff). >> Poor coding, poor design. Same schmiel. >Nothing I listed that causes common bloat has anything to >do with poor design. Non-optimal design then? I read that the same way as 'poor design', unless you can show that there's no other way to do the same thing. Do a 'dir /s *.exe' from your windoze directory and see what you come up with. If you want to be complete, include *.dll also. Then, do the same thing from the Geos directory, using *.exe and *.geo (geos executables, or Geodes). Compare the sizes you get, then tell me that code bloat is excusable. MS Word.exe is 8 megs (or is it only four?); GeoWrite.geo (equivalent functionality) is 83K. I don't really complain about the size of C compilers, I have DJGCC on my disk and use it occasionally to keep in shape. My Forth is far smaller, but my Forth can't handle C. Fair trade, I think. C is useful, but it's non-optimally designed. Politically correct language is also poorly-- I mean non-optimally-- designed. >Darin Johnson -Billy Paladin (take THAT, you foes of the One True Language! ;) From: andrejs@crl.com (Andrejs Vanags) Subject: Re: Local words and definitions? Date: 13 Oct 1994 11:23:25 -0700 Thanks for your response, while it is true I am new to forth, I am familiar with its limitations (at least for those of us that have trouble creating defining words and the such) The main objective of the programming language should be to HELP the programmer program the algorithm, in the easiest way possible. Now, even for simple two line statements, this business of ROTating, SWAPing, NIPing the stack, renders the code almost unreadable (takes time and a pad and pencil to follow the stack acrobatics) or cumbersome at best. If you want to have a 'space' in the word for keeping values internal to the word (I guess by using ALLOT) then you have to refer to those values by an address + an offset, again making the code unreadable. It would be MUCH better if those two examples could be refered to by name, using the existing vocabulary search in Forth. In fact, why couldnt you define ANYTHING inside a word? maybe the two examples above of referring to variables are too limited... Maybe I would like a variable that puts its value on the Fstack when called, or fetches and stores the value after a ->, or maybe and integer variable that did the same.. or other possibilities.. Let me give you a concrete example, a very simple 2nd order filter: I want a defining word 2FILTER that when loaded as: .5 .7 2FILTER 2ndOrder1 It would create the word 2ndOrder with parameters k1=.5 k2=.7 wich will filter the value on the fstack and put the result back on the fstack: .... x 2ndOrder1 xu + ... etc. Now, the implementation of this particular filter would do at run time SOMETHING (I have'nt figured out the details) like this: ( local variables, k2 k3 only get values when word is defined, and there rest only get initialized when defined ) locvar k2 locvar k1 0. locvar Xn 0. locvar Xn-1 0. locvar Yn-1 0. locvar Yn-2 ( input ) -> Xn ( macros ) : T2 ( -- x ) T SQUARED ; : DENOM ( -- x ) 4 k1 * 2 k2 * T * + T2 ; ( here is filter ) T2 DENOM / Xn Xn-2 + * 2 T2 * DENOM / Xn-1 * + 8 k1 * 2 T2 * - DENOM / Yn-1 * + 4 k1 * 2 k2 * T * - T2 + DENOM / Yn-2 * - -> Yn ( update values ) Xn-1 -> Xn-2 Xn -> Xn-1 Yn-1 -> Yn-1 Yn -> Yn-2 ( return value ) Yn Where all operations are in floating point, all variables put values on the fstack when called, or fetch and store if called after -> In addition, where k1, k2, Xn, Xn-1, Yn-1, Yn-2 are 'static' variables that live inside the word and remember their values nextime they are called, and are 'local' so that they are not accesible and the dictionary and therefore clutter the program. Note as well that I will have other defining words as LOWPASS, HIPASS, NOTCH, 3FILTER etc, and there will be 20 to 30 of each one of them in a particular application. Now, if I were to program the above using normal variables ( @ and !) it would be hard to read, much less to analize, or if I were to use the stack or addresses and offsets it would be UNREADABLE and NOT ANALIZABLE (at least without much effort) and it would defeat the purpose of the programming language. If I define Xn-1, Yn-1 etc outside the word (as I have done in the past) then for each filter y have to give them different names and after 5 or 6 filters I have an unreadable soup. So, HELP! how do I define words or definitions INSIDE words? how would you code something like the above, keeping in mind that the most important thing is readability so that one can concentrate in the algorithm and not in stack acrobatics, offsets, keeping track of previous words in the dictionary, etc. Yours Truly, Andrejs Vanags andrejs@crl.com P.S.: I think in this kind of cases the length of the word depends on the length of the mathematical formula, and although factoring helps, splitting the formula into separate words just makes it confusing) Erather (erather@aol.com) wrote: : In this discussion of local variables & definitions, I think the original : writer, who was new to Forth, has some basic misconceptions about the : nature and extent of a Forth word. The original design of Forth assumed : that a word was a truly tiny module...in much of Chuck Moore's code (he's : the inventor of Forth) you rarely found a word longer than about 3 lines, : and the majority were 1 or 2 lines. The style rewards factoring into tiny : reusable pieces, with minimal overhead for nesting. In contrast, programs : or subroutines in other high level languages run to pages. If you're : writing tightly factored, highly modular Forth code local variables and : definitions are irrelevant! In fact, one uses far fewer variables of any : kind. Generally one defines a variable or constant using the same logic : that would lead you to define a "global variable" elsewhere...its scope is : larger. For temporary values, you generally just use the stack. Note that the stack is no good for filters, I need a 'static' variable Subject: UN: GEnie 941013 From: elliott.chapin@canrem.com (Elliott Chapin) Date: Thu, 13 Oct 94 11:37:00 -0400 Forth Interest Group Category 8, Topic 8 Message 10 Wed Oct 12, 1994 JETHOMAS [Jet] at 21:40 EDT September MFIG Meeting Julian Noble talked to MFIG about scientific programming. He titled the talk "Forth isn't for number-crunching, is it?" Here's a rough outline: Julian is a physicist. He took up Forth when he was stuck using FORTRAN on a limited machine. "I could listen to my beard grow waiting for the compiler." He had prior Forth experience on the Jupiter Ace, and had a PC Forth with him, that he was able to use to perform floating point operations (even though it did not come with floating point). In essence he used Forth as a way to control the 8087 coprocessor through a calculation. Scientists and engineers need floating point arithmetic, both real and complex. Scaled arithmetic a la classic Forth is not good enough because for many problems the dynamic range can be 30 orders of magnitude. FP is at least as fast in hardware as scaled integer arithmetic on the CPU, so there is no reason not to use it. It is cheaper to buy a chip than to develop software floating point code. He bought a package from Harvard Softworks; it ran very fast. It was easy for him to add complex numbers and easy sophisticated matrices, things which were not so easy before. And of course he got more control of the machine. As he got better at Forth he found out how to optimise for speed. He already knew from FORTRAN to take things out of inner loops and factor out repeated expressions; now he started coding routines in assembly. He did it for the sense of power, because he _could_ do it. He over-used the assembler because it was so easy to do. Now sometimes he wants to port those early routines elsewhere and has to reverse-engineer the assembly code. Julian noticed that a lot of his time was spent evaluating complicated algebraic expressions. He translated each expression from infix notation into postfix by hand, and it was easy to make mistakes. The factoring that aided the programming didn't match up with the sort of factoring that helped him understand the problem, so that factoring, per se had limited value. Tools that were more valuable were special data structures, and functional notation. Too much detail in the form of "noise" words: @, !, >R, R>, etc. obscures the main pattern, so he learned to hide some details. (He pointed out that advances in physics often have come from improved notation that unclutters central ideas, eg Maxwell's Equations.) He came up with array notation that worked for him: 1array Y{ 2array M{{ Y{ I } M{{ I J }} Still, the debugging was tedious. Julian noticed that he included the original infix expression regularly as a comment. How much better if that comment could be his code! He wrote a parser he called a FORmula TRANslator. It was designed simply, to do the job he needed without lots of extras to go wrong. It's built around a sofware floating-point stack. Each item takes 18 bytes. That can hold the largest item he needs (double-precision complex) with 2 bytes left over to hold the data-type. Some audience members objected to the wasted memory. Some of his items, after all, would fit into 4 bytes. Julian explained that he rarely needed more than 40 items on the stack, so the space used was insignificant. He saved a lot of his execution time not having to worry about stack widths. (He first did a variable-width stack, and the speedup was a factor of 5-10.) Keeping the data-types with the calculations, his code could do mixed-mode arithmetic without needing his attention at all. Variables give warning messages when they don't have room for the items being stored. Two bytes is a lot of space for data-types when he only has 4 scalar data-types, but this is also unimportant. Some audience members pointed out the inefficiency of constantly removing items from the hardware stack in the coprocessor to the software floating stack, only to move them back. Julian said, "Some systems have an unlimited depth fp stack that extends the co-processor's 8-deep stack into memory. I wrote one of those about 6 years ago. But the coprocessor chips do not have any automatic push/pop or other intrinsic `hooks' to extend their stack into RAM, hence there is a lot of bookkeeping to do it this way. Eventually I came to realize that it was better to keep the fp stack in RAM, with just the TOS on the math chip (this works well for the Motorola and Weitek series of chips also). This is analogous to some Forths that keep the top of the data stack in the BX register, as a 1- deep cache. Studies show one can eliminate all but a few pushes and pops this way." He was asked what optimization his parser did. It didn't do much optimization. The most important ways to improve code are to remove things from inner loops and to factor repeated expressions, and these are things that programmers learn with their mother's milk. Then optimising compilers grind away looking for the inner loop items that aren't there. It seems that in scientific computing, it's often more important to get quick results than to get quick computation. A program might be used 1 to 10 times before being discarded or modified; it's much more important to get it to run (Continued in the next message) --- * DeLuxe2 1.12 #4315 * elliott.chapin@canrem.com Subject: UN: GEnie 941013 (#2) From: elliott.chapin@canrem.com (Elliott Chapin) Date: Thu, 13 Oct 94 11:37:00 -0400 (Continued from the previous message) right than to get it to run fast. Forth's primary competitor in this arena is not C but FORTRAN, and its most formidable competitor may be Visual Basic -- easy to use and quick results, though without Forth's flexibility. Many people try to use Mathematica or Maple, and find them very slow. Julian figured that if he did need to speed up his code, he'd do better to write an inner loop in assembler than complicate his parser. He gave an example from solving large systems of linear equations. The inner loop (of three) multiplies a row by a constant multiplier and subtracts it from another row. This is just a few instructions worth of assembler, hence easy to write and debug. A program with just this loop optimized is hardly longer than the un-optimed Forth, yet for large problems runs at the intrinsic speed of the silicon. He presented an example, a set of six simultaneous first-order differential equations. It modeled an automobile sliding sideways on pavement toward a curb. When the car hit the curb, it would flip over the curb and crunch beyond it (if the collision was inelastic) or bounce up and rotate about its center-of-mass (if the collision was elastic). The parameters were adjustable, to simulate sliding on dry pavement or ice, or to make the collision between tire and curb elastic or inelastic. The graphics were not fancy but they showed very well what was happening. When he showed us the code, there were about a dozen pages of parameters with comments, and toward the bottom were his six equations on one page. His parser had almost eliminated the complicated coding and debugging process! It's clear that the main remaining limiting factor is handling those parameters. Julian had special code that tested energy buildup; when the energy of his system increased rather than dissipated he could figure he had a term in the equation with the wrong sign. (Obviously, it's more important to get the signs right than to optimise for speed.) This kind of debugging was very simple using his flexible interactive system written in Forth. Julian noted that developing and commenting the Forth code for the car rollover simulation took about 2 days. His experience with FORTRAN leads him to believe the time would have been at least a week, even with a fast workstation and a fancy debugging environment. Graphics would have taken longer, which is why accident reconstruction experts often use FORTRAN codes to produce numerical results which are then fed to drawing programs such as AutoCad for animation. The expense, complexity and opportunity for something to be wrong in such jury-rigged systems is just beyond imagining. Julian Noble is doing several things intended to help spread the use of Forth. His book _Scientific Forth_ is still available, and people bought copies at the meeting. He's deeply involved in the thrust to build ANS Forth scientific libraries. He's writing a Forth textbook with Brad Rodriguez, intended primarily for EE departments. He doesn't know which things will work to make Forth more popular, and figures if we do enough different things we'll find out. "When you shoot a shotgun you don't know which pellet will bring down the bird." Elliott Chapin --- * DeLuxe2 1.12 #4315 * elliott.chapin@canrem.com From: duncan@nic.cerf.net (Ray Duncan) Subject: Re: Chars to printer port #2 ? Date: 13 Oct 1994 18:46:13 GMT In article <1994Oct11.220540.2133@debet> snf_dw@debet.nhh.no writes: >WRONG ! I don't find any device independence for printers in DOS. > >So how do you tell the DOS kernel to output a character to the 2nd >parallel printer port ? Does anyone know if later versions of the >DOS technical manual (if any) have another call to the kernel >(i.e. not number 5) for that ? Sure there is device independence for printers in DOS. You need to open (Int 21H Function 3DH) the 2nd printer using its logical device name ("LPT2"), then send characters to it using the "stream write" function (Int 21H Function 40H). These functions have been supported in DOS since 1983, so your technical manual must be pretty old!!! From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Code Bloat Date: 13 Oct 1994 15:24:17 -0400 <37h760$qtu@coyote.csusm.edu> In-reply-to: djohnson@seuss.ucsd.edu's message of 13 Oct 1994 16:38:29 GMT Darin Johnson: : My big question then is why is "factoring" such a big deal with : Forth? It's available in any language, with the same results, yet : in Forth books and in this group it's always talked about as a big : advantage of Forth. Other languages don't even use this term. It's not with the same results in most languages. Most languages don't let you define new defining words, or new control structures, etc. unless you jump through hoops (e.g. redefine the language and rebuild the interpreter or compiler and/or program loader). With forth, you can (for instance) build words for defining threads or continuations irregardless of what the operating system provides. Forth is the operating system. Other languages focus a lot of energy on type classification schemes. Most other languages have these type systems built into the syntax. Etc. etc. Many other languages don't even provide incremental compilation (they don't provide significant capability for manipulating code as data). Finally, Forth has a very low cost for function dispatch -- this removes the "practical, performance reason" for building large (unfactored) routines. So, in other words, Forth doesn't "get in the way" of factoring. -- Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.eHow is # normally defined in a Standard Forth? The definition says that >it divides an unsigned double by BASE and produces a remainder and an >unsigned double quotient, but I don't see a Standard word that performs >this operation. UM/MOD leaves a single-cell quotient, and the DOUBLE >word M*/ takes a signed double. > >I have made a new word for my use by # that works like UM/MOD except that >it returns a double quotient. Is there a common name for this word? Yes, MU/MOD is (non-standard, but) found in many systems. : UM/MOD ( ud u -- u_rem u_quot) ... ; \ number conversion routine (u = number base) : MU/MOD ( ud u -- u_rem ud_quot) >R 0 R@ UM/MOD R> SWAP >R UM/MOD R> ; ( e.g. 1234 0 10 MU/MOD .S --> 4 123 0 ) \ convert a number to a digit (i.e. 0..9 to '0'..'9', 10 to 'A' etc) : DIGIT ( u - c) DUP 9 > 7 AND + 48 + ; ( ASCII) \ transfer next digit of ud1 to the output string : # ( ud1 -- ud2) BASE @ MU/MOD ROT DIGIT HOLD ; >And what about a similar word that takes a triple dividend and returns >a double quotient, which it seems would be useful for implementing M*/? Unsigned? - Well, here is a triple beast: : TU/MOD ( ut u -- u_rem ut_quot) >R 0 R@ UM/MOD R> SWAP >R >R R@ UM/MOD R> SWAP >R UM/MOD R> R> ; Or, if you prefer a double precision quotient: : TMU/MOD ( ut u -- u_rem ud_quot) >R 0 R@ UM/MOD DROP R@ UM/MOD R> SWAP >R UM/MOD R> ; --Hannes -------- Forth BBS Munich jgt@BBS.FORTH-eV.de (Johannes Teich) ++49 89 8714548 The BBS of FORTH-eV... From: jgt@BBS.FORTH-eV.de (Johannes Teich) Subject: Re: Double Division in Standard Forth Date: Mon, 10 Oct 94 09:50:33 MSZ jgt@BBS.FORTH-eV.de (Johannes Teich, that's me) wrote with Subject: 'Re: Double Division in Standard Forth': > Unsigned? - Well, here is a triple beast: > > : TU/MOD ( ut u -- u_rem ut_quot) >R 0 R@ UM/MOD R> SWAP >R > >R R@ UM/MOD R> SWAP >R > UM/MOD R> R> ; > > Or, if you prefer a double precision quotient: > > : TMU/MOD ( ut u -- u_rem ud_quot) >R 0 R@ UM/MOD DROP > R@ UM/MOD R> SWAP >R > UM/MOD R> ; Oops, I should have mentioned that R@ UM/MOD DROP may be replaced here by ( R@ UM/MOD DROP). Two UM/MODs are enough, as Gordon Charlton has pointed out: > : T* ( ud u--ut) TUCK UM* 2SWAP UM* SWAP >R 0 D+ R> ROT ROT ; > : T/ ( ut u--ud) DUP >R UM/MOD ROT ROT R> UM/MOD NIP SWAP ; > : M*/ ( ud u u--ud) >R T* R> T/ ; (I will refer to T* and T/ below.) * * * This leads to the question, though, what we can do if we need M*/ in a *signed* version. Surely there are better solutions, but I happened to try it this way: \ First, let's provide an addition with carry in/out: : +C ( n1 n2 cy1 -- n3 cy2 ) 1 AND >R 0 SWAP OVER R> 0 D+ D+ ; \ The same word as an 8086 primitive with Pygmy's assembly syntax: \ CODE +C ( n1 n2 cy1 -- n3 cy2) AX POP, DX POP, CX CX XOR, \ BX BX TEST, 0=, IF, CLC, ELSE, STC, THEN, DX AX ADC, \ CS, IF, CX INC, THEN, AX PUSH, CX BX MOV, NXT, C; \ Now we can add a single value to a triple value: : TM+ ( t1 n -- t2) >R ROT R> 0 +C >R ROT 0 R> +C >R ROT 0 R> +C DROP ; \ Triple invert, negate, and absolute: : TINVERT ( t1 - t2) ROT INVERT ROT INVERT ROT INVERT ; : TNEGATE ( t1 - t2) TINVERT 1 TM+ ; : TABS ( t1 - t2) DUP 0< IF TNEGATE THEN ; \ We need to know if the value is getting inverted by ABS: : ABS? ( n1 - n2 f) DUP ABS SWAP 0< ; : DABS? ( d1 - d2 f) TUCK DABS ROT 0< ; : TABS? ( t2 - t2 f) DUP >R TABS R> 0< ; \ signed double by signed single multiplication, triple result: \ : TM* ( d n - t) ABS? >R -ROT DABS? R> XOR >R ROT \ (Gordon's unsigned) T* R> IF TNEGATE THEN ; \ signed triple by signed single division, double result: \ : TM/ ( t n - d) ABS? SWAP >R >R TABS? R> XOR R> SWAP >R \ (Gordon's unsigned) T/ R> IF DNEGATE THEN ; \ signed multiply/divide, triple intermediate product: \ : DM*/ ( d1 n1 n2 - d2) >R TM* R> TM/ ; I would be happy to see a more elegant solution. --Hannes -------- Forth BBS Munich jgt@BBS.FORTH-eV.de (Johannes Teich) ++49 89 8714548 The BBS of FORTH-eV... From: C.D.A.Hellon@bradford.ac.uk (Xian the Desk Lizard) Subject: Re: FORTH for us youngin's Date: Fri, 14 Oct 1994 00:00:17 GMT Originator: cdahello@ccw209 On 11 Oct 1994 16:20:08 -0400, Erather gave us: \ It's hard for me to imagine learning Forth with just SF and an \ un-documented, un-supported roll-yer-own system that differs in arbitrary \ and undocumented ways from any books or standards! \ Although Mike Coughlin is right that ANS Forth itself isn't helpful to \ beginners (it's a Standard, not a tutorial!), I hope that it will exert a \ strong pressure on implementors to converge and minimize dialectic \ differences. In the meantime, I'd encourage anyone really interested in \ learning Forth to buy a full-featured, fully supported commercial system \ and do it right! With respect, the oldest Forth vendor in the business would say that... |:> However, you may well be right, in some ways. I first became interested in Forth in 1984, and it took me 6 years to get hold of a computer that would run it! Following that, I have only ever used public domain, roll-yer-own systems, and I never even had the luxury of Starting Forth, having to make do with a range of other, less-than-satisfactory books on the language. But I feel that he experience in deciphering those systems, and the generosity that inspired them, has helped me to learn Forth far more thoroughly than any commercial version could, simply because for the PC there is a huge range of public domain systems out there, and I could compare practices, models and code at no cost to myself. From the beautiful simplicity of Pygmy 1.1 to the grotesquery of FPC, I have seen many examples of Forth and philosophy that I simply wouldn't have come across had I previously locked myself into one system by paying two or three hundred pounds for it. On the other hand, trying to configure some of those things so that they worked well on my system was a horrific task, and I had no help. Market pressure is good for Forths in that it forces the commercial products to be well-developed and well-supported, so that these problems don't arise; commercial Forths are the best choice, perhaps, for users as opposed to programmers. Having said which, the arguments in favour of PD put by Roedy Green in his Forth are very compelling - the world would be a lovely place if we could say, first of all and with no other considerations, "Look at polyForth, it's a wonderful system - just read this source code!" instead of "well, polyForth had better be the best, the price they charge for it". (Note, I am making no accusations here about quality or deservance of price!!! I am just thinking wishfully; I have no doubt that polyForth IS one of the best systems around.) And maybe then we wouldn't automatically consider the public domain a place for half finished systems. As regards learning Forth, the best reference anyone can have to learn is a Forth with the full source code available - I give Pygmy as an example here; it was the quality of this system that really got me up to speed on Forth. But there is no substitute for sitting and playing, and because of the nature of the language, just about any version can offer that. -- Xian the Desk Lizard | Email: c.d.a.hellon@bradford.ac.uk | New .plan! Mostly depressed, | finger cdahello@muser.brad.ac.uk|more part-time thinker, | Fundamentalism today is what Americans claim they full-time dosser | fled Europe to escape. -- jon on a.a From: sfp@mpeltd.demon.co.uk (Stephen Pelc) Subject: Re: FORTH for us youngin's Reply-To: sfp@mpeltd.demon.co.uk Date: Thu, 13 Oct 1994 23:40:41 +0000 In article <37es1o$2e2@newsbf01.news.aol.com> erather@aol.com "Erather" writes: > For 20 years we have been dealing with customers who, when they come to > us, do not know Forth and have to learn. We support them with extensive > documentation, a system that comes with source not only for the system but > also for lots of libraries of application-oriented stuff (graphics, data > base, math, etc.), and helpful folks on the hotline. We include Starting > Forth with all our systems, because that's a good introduction, but the > real instruction for using our systems is our 500pp Reference Manual and > 250pp CPU Supplement for the particular version you've bought. Plus > there's a pocket reference, on-line shadows with the software, etc. I > have seen several other successful commercial Forths, and they are also > well supported with documentation, etc. Let me just say "hear, hear" to this. Each vendor has its own style and emphasis, but the common ground includes documentation and support. It is difficult to emphasise just how important support is. One of my most difficult sales visits is to tell a potential customer that the in-house development system produced by a once-enthusiastic but now departed engineer is going to be *very* expensive to maintain, and that we will *only* do this work on daily rate. If you do the risk analysis of the costs involved in starting an in-house tool development against the cost of a commercial system, the commercial system wins hands down. And then consider the time to market issues. Why waste time developing tools, when you could actually be using them. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: cmbanker@aol.com (CMBanker) Subject: FIG in South Louisiana Date: 13 Oct 1994 13:06:03 -0400 Does anyone know of an active FIG in South (or for that matter All of..) La.? From: djohnson@seuss.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 14 Oct 1994 02:19:45 GMT <37h760$qtu@coyote.csusm.edu> In-reply-to: rockwell@nova.umd.edu's message of 13 Oct 1994 15:24:17 -0400 > It's not with the same results in most languages. Most languages > don't let you define new defining words, or new control structures, > etc. unless you jump through hoops (e.g. redefine the language and > rebuild the interpreter or compiler and/or program loader). But many do. Look at macros in Lisp. Plus, most of the stuff I have seen new defining words used for is to implement the same sort of stuff that's already there in many other languages. Most of the newly defined control structures are either dubious (of little practical use except to obfuscate things) or are not both efficient and unportable (ie a new structure is needed for concurrency or the like). And by adding these things, you increase the complexity of the code and make it much harder to maintain. If anyone has specific counter-examples, please give them. > With > forth, you can (for instance) build words for defining threads or > continuations irregardless of what the operating system provides. It's also very difficult to get efficient portable code this way. (you can get one or the other, but not both) > Other languages focus a lot of energy on type classification schemes. You many "some other languages". And this is not a bad thing per se - there is indeed a lot of debate over this but it is NOT a Forth versus other language debate. > Etc. etc. Many other languages don't even provide incremental > compilation (they don't provide significant capability for > manipulating code as data). Most Forth's don't provide incremental compilation, since most of them don't compile. Again - this is not a Forth only argument, it's an argument for interactive environments. Most other languages restrict treating code as data because it is dangerous. There's little reason to ever need more than handles to functions. > Finally, Forth has a very low cost for function dispatch -- this > removes the "practical, performance reason" for building large > (unfactored) routines. Except than in many Forths, straight code has a high cost compared to standard compiled languages (I know there are compiled forths). There are many more function dispatches overall when compared to many other languages, and this can add up quickly. Besides, machines are fast enough now that avoiding function calls isn't that important anymore. And if not, there are always macros and inline functions and smart compilers. But this, I think, is an important aspect of Forth - function calling is somewhat easy. It has big drawbacks though; no delimiters, type checking, etc - all things that may cause bugs much later in time. But this does help with ease of factoring. I'm not saying I don't like Forth. But I can't see how "ease of factoring" has remained so tightly associated with Forth. Maybe back in the 70's and early 80's when it's biggest competitors were assembler and basic... But compare it to Lisp or Smalltalk or other modern languages. Even if you compare it to C, the differences in factoring aren't all that great. So, if anyone has done a major multi-person project in Forth and another decent language, where the programmers were expert in both languages and disciplined, what's your experience? If you had advantages in one language, what disadvantages did you have? (you can't look at factoring by itself, you have to also look at maintenance, debugging, portability, performance, etc). -- Darin Johnson djohnson@ucsd.edu -- Strange things are afoot at the circle-K... From: Tony Reid-Anderson Subject: TEST Date: Fri, 14 Oct 1994 03:00:52 GMT My apologies for this test. I now have an alternate 'net provider and am using a new product for reading and posting. Please bear with me. TonyR-A ========================== tstark@andrais.demon.co.uk tstark@cix.compulink.co.uk ========================== From: josh@cgi.zeta.com (Jos'h Fuller) Subject: assistance with this4th Date: Thu, 13 Oct 1994 23:56:25 GMT hello! i am writing a radio-tv script writing program in this4th. the way it (will) work is that the unformatted script, written with a regular text editor is actually forth source code. ferinstance, this is loaded first: : .name ( prints the name of a word) ; : ftype ( formatted type, using margins and so on) ; : character create ( something) does> .name ." :" tab get-line ftype cr ; in the raw script file, the author says: character john character sally john Hello, how are you today? sally Just fine, thank you. Does your program work? john Nope. But I put a query out on the net. and when processed, he gets: JOHN: Hello, how are you today? SALLY: Just fine, thank you. Does your program work? JOHN: Nope. But I put a query out on the net. of course, if he does something wrong, the program aborts with an appropriate error. and it can easily get more elaborate, supporting sound effects and so on. the problem is, i don't know how to get the name of the word which is currently executing. since ans (not to mention the structure of this4th) precludes 'dump', i'm not sure how to retrieve it. i need to have the word print its name at the beginning of the line, using the hypothetical '.name'. to sum up, i need to be able to have a word identify itself, and then print its name. thanks! jrlf From: flacy@dip.eecs.umich.edu (Mark A Flacy) Subject: Re: Code Bloat Date: 14 Oct 1994 08:09:37 GMT <37h760$qtu@coyote.csusm.edu> In-reply-to: djohnson@seuss.ucsd.edu's message of 13 Oct 1994 16:38:29 GMT In article djohnson@seuss.ucsd.edu (Darin Johnson) writes: [stuff deleted] > >My big question then is why is "factoring" such a big deal >with Forth? It's available in any language, with the same >results, yet in Forth books and in this group it's always >talked about as a big advantage of Forth. Other languages >don't even use this term. > Well, I think the idea is that if you have a particular sequence of functions that you are calling, then you are repeating _something_. In most cases, that _something_ can be expressed as a concept with a name. If you can name it, then you should factor it out and replace it with a Forth word of that name. You now have a concept that is reflected by a named procedure. It's a little easier to do that in Forth, due to the implicit parameter passing. (It's a cut and paste operation, adding a colon, semicolon, and the name.) And, yup, you can do that in other languages like C, but you'll still have to fiddle with the parameter lists. To some extent, you can classify this as "religious crap" associated with Forth. When you classify something like that, then you're ignoring the _philosophy_ behind a programming language. After all, that philosophy drove a lot of the design decisions in creating the language in the first place. Bottom line? Part of the Forth philosophy is to name your procedures in a way that reflects what they do. Since any string of procedure calls can instantly become another procedure, you are encouraged to package repeated strings of calls within a name that describes what those calls are doing. -- / ------------------------------------------------------------------------ \ / Mark Flacy "There's a lot to be said for a blow to the head" \ / flacy@eecs.umich.edu - Blue Oyster Cult \ / "I guess ya had to be there." - Me \ From: u332302@twncu865.ncu.edu.tw Subject: RE: Chars to printer port #2 ? Date: 14 OCT 94 14:28:38 GMT If you really want the address of your 2nd,3rd printer port.... use "MFT" (comes with QEMM I think) to checkup or,you can fetch data from bios memory... 0000:0408h have all your printer port address in sequence 0 $408 @L you get LPT1 address 0 $409 @L is LPT2 0 $40A @L is LPT3 .... the address you get can be used with P@ & P! you'll get "0" if there is no such port and,the address you get is for data port, +1 is for status port and +2 is for control port Cheers, Clay From: h9290246@hkuxb.hku.hk (Zsoter Andras) Subject: Re: Code Bloat Date: Fri, 14 Oct 1994 11:31:53 GMT Mark A Flacy (flacy@dip.eecs.umich.edu) wrote: : : Well, I think the idea is that if you have a particular sequence of : functions that you are calling, then you are repeating _something_. In : most cases, that _something_ can be expressed as a concept with a : name. If you can name it, then you should factor it out and replace it with : a Forth word of that name. You now have a concept that is reflected by : a named procedure. : : It's a little easier to do that in Forth, due to the implicit : parameter passing. (It's a cut and paste operation, adding a colon, : semicolon, and the name.) And, yup, you can do that in other languages : like C, but you'll still have to fiddle with the parameter lists. Very well said! This is the point. n1 n2 ....nn A B .. Z is syntactically THE SAME as n1 n2 ... nn NEW where : NEW A B .. Z ; ;-) I do not think it is so easy in any other language but this message can function again as a flame bait as my posting about stack-ology. :-( Andras From: djohnson@seuss.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 14 Oct 1994 17:19:37 GMT <37jtg3$14vt@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 13 Oct 1994 11:15:31 -0700 In article <37jtg3$14vt@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes: > Factored words look better and cost less in Forth. This is strictly due > to the implicit parameter passing. In other languages factoring creates > an ugly, time-consuming and unreadable mess; in forth it creates a clear, > acceptably-quick and (you get the idea). Thisis highly debatable. I think the biggest drawback to implicit parameter passing is that it quickly leads to an unreadable mess. Not only is it difficult to tell where a logical function call beings or ends, you have to worry about all the stack manipulation stuff before you know what parameters go where. > The problem with Lisp is that it uses explicit parameter passing > to give you a veritable nest of parenthesis; the advantage is that it uses > explicit parameter passing to let the interpreter do some of your work for > you. I hope parentheses aren't your only problem with it, that would be too trite. But you certainly have no trouble finding out what goes where in a lisp program, and if you want to find where the 4th parameter is defined, you can do so in seconds. > So Forth replaces a C compiler, debugger, and who knows what else in a > fraction of the space. Except you end up with a poorer debugger when you need one. > Non-optimal design then? I read that the same way as 'poor design', > unless you can show that there's no other way to do the same thing. Static libraries, loop unrolling, help files, and so forth are non-optimal design? Not all of that bloat is from poor design. If you've got a C compiler on 12 disks, I'm pretty the compiler itself takes only a fraction (I'm not talking GNU here :-). If it's for a DOS system, perhaps most of it is random libraries to supplement the lack of an OS. (lack of an OS is the biggest example of bad factoring there is :-) > Do a 'dir /s *.exe' from your windoze directory and see what you come up > with. We're talking windoze here - that is TRUE bloat. I never said it wasn't. > functionality) is 83K. But is it equivalent functionality? While much of MS Word is bloat, much of it probably isn't. Does your 83K include a spelling dictionary, online help (ok, I know that windoze help isn't helpful, but...), and so forth. MS Word also has to deal with the lack of a decent OS. Port Geo apps to windoze and I bet it expands by a hefty chunk. Heck, windoze stuff outgrows X windows stuff, and X has more functionality. Really, it's an unfair comparison to bring in MS stuff - any fool can make themselves look good next to it. -- Darin Johnson djohnson@ucsd.edu The full name of the compiler is "Compiler Language With No Pronounceable Acronym", which is, for obvious reasons, abbreviated "INTERCAL". From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Code Bloat Date: 14 Oct 1994 15:51:41 -0700 In article djohnson@seuss.ucsd.edu (Darin Johnson) writes: >> Factored words look better and cost less in Forth. This is strictly due >> to the implicit parameter passing. In other languages factoring creates >> an ugly, time-consuming and unreadable mess; in forth it creates a clear, >> acceptably-quick and (you get the idea). >Thisis highly debatable. I think the biggest drawback to implicit >parameter passing is that it quickly leads to an unreadable mess. >Not only is it difficult to tell where a logical function call beings or >ends, you have to worry about all the stack manipulation stuff >before you know what parameters go where. The stack manipulation stuff is a pain; no argument. It IS the biggest drawback to implicit parameter passing. So? That doesn't affect the fact that implicit parameter passing helps readability in factoring. That's what we're talking about here (not "Forth is better than any other language in any situation." ;). >> The problem with Lisp is that it uses explicit parameter passing >> to give you a veritable nest of parenthesis; the advantage is that it uses >> explicit parameter passing to let the interpreter do some of your work for >> you. >I hope parentheses aren't your only problem with it, that would >be too trite. But you certainly have no trouble finding out >what goes where in a lisp program, and if you want to find where >the 4th parameter is defined, you can do so in seconds. They are the one thing that stopped me, yes. Full LISP code is entirely unreadable to me because I lose my depth so quickly. You really shouldn't call that trite, since you just complained about the converse in Forth. You can find things in seconds, even in poorly factored programs. My point. (Not that I can find them in seconds, but it takes me just as long to find them in poorly factored as in factored). I know that's not an argument for Forth, but it does show why other languages don't talk so much about factoring-- thier programmers don't get punished often enough ;). The bad effects of not factoring show in both environments, but in forth they LOOK ugly as well as acting ugly. >> So Forth replaces a C compiler, debugger, and who knows what else in a >> fraction of the space. >Except you end up with a poorer debugger when you need one. Why is this true? I beg to differ; I've gotten a lot of use out of my Forth debugger. It's especially handy for reading other people's code. (F-PC) >> Non-optimal design then? I read that the same way as 'poor design', >> unless you can show that there's no other way to do the same thing. >Static libraries, loop unrolling, help files, and so forth >are non-optimal design? Not all of that bloat is from poor >design. If you've got a C compiler on 12 disks, I'm pretty If the same functionality is attainable is less space, then it's poor design. >the compiler itself takes only a fraction (I'm not talking >GNU here :-). If it's for a DOS system, perhaps most of it >is random libraries to supplement the lack of an OS. (lack >of an OS is the biggest example of bad factoring there is :-) How true. :) >> Do a 'dir /s *.exe' from your windoze directory and see what you come up >> with. >We're talking windoze here - that is TRUE bloat. I never said it >wasn't. :) I'm giving examples. >> functionality) is 83K. >But is it equivalent functionality? While much of MS Word is >bloat, much of it probably isn't. Does your 83K include a >spelling dictionary, online help (ok, I know that windoze >help isn't helpful, but...), and so forth. MS Word also has Yes. It's only missing a automatic table function. But that isn't my point; I'm only trying to sell Geos subtly ;). My purpose is to clarify factoring to the original asker (and perhaps to help myself understand a little more about it myself). >to deal with the lack of a decent OS. Port Geo apps to >windoze and I bet it expands by a hefty chunk. Heck, windoze >stuff outgrows X windows stuff, and X has more functionality. MS Word takes up 3,483,000 bytes (approximately). This is JUST the EXE; the DLLs take up far more. Not to mention the spell-checking dictionary, etc. And yes, windoze apps ported to Geos are still bloated (the reverse port has not been attempted; I suspect it would be impossible to go from object-oriented multithreading to you-know-what without a complete rewrite) due to the "unfactoring" required to make a windows library function do what you actually wanted it to do. >Really, it's an unfair comparison to bring in MS stuff - any >fool can make themselves look good next to it. Precisely my point. Windows is bad factoring, and use of its programming conventions forces you to undo what their library did. I assume all this, having never programmed for windoze; am I right? If not, what else is the cause for consistant code bloat? In other words, I'm attempting to cite a witness to show the ill effects of not factoring. >Darin Johnson -Billy I don't work for Geoworks. Just a happy PC-Geos user! From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 15 Oct 1994 02:16:11 GMT <37n21t$1aol@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 14 Oct 1994 15:51:41 -0700 > That doesn't affect the > fact that implicit parameter passing helps readability in factoring. That's where I have to disagree, I think it's the biggest cause of unreadability :-) > >Static libraries, loop unrolling, help files, and so forth > >are non-optimal design? Not all of that bloat is from poor > >design. If you've got a C compiler on 12 disks, I'm pretty > > If the same functionality is attainable is less space, then it's poor > design. But it's not the same functionality. For instance, adding help files is an improvement. Compiler loop unrolling speeds things up. And so forth. Also note that there are many different design goals all in conflict with each other. Code size is only one of them. > MS Word takes up 3,483,000 bytes (approximately). This is JUST the EXE; > the DLLs take up far more. Yikes. That's pretty sad. All that space and I don't even get emacs bindings. What a waste. Pardon for a stupid question, but what's a DLL? -- Darin Johnson djohnson@ucsd.edu This is the first time I've ever eaten a patient -- Northern Exposure From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 15 Oct 1994 02:22:11 GMT In-reply-to: h9290246@hkuxb.hku.hk's message of Fri, 14 Oct 1994 11:31:53 GMT > : It's a little easier to do that in Forth, due to the implicit > : parameter passing. (It's a cut and paste operation, adding a colon, > : semicolon, and the name.) And, yup, you can do that in other languages > : like C, but you'll still have to fiddle with the parameter lists. Actually, as an aside. A friend is working on a program restructuring tool for his thesis. Ie, it can automatically restructure a program so that accesses to a set of global vars can be hidden behind a function lagyer, and so forth. The target language is scheme, one of the major reasons being that it is very simple to automatically (in a program) this sort of factoring. The explicit parameter passing helps here tremendously. It works even if you have a bad programming style. To do the same stuff by hand in Forth is ok as long as there is a good programming style. It doesn't help if you inherit a project from someone else. -- Darin Johnson djohnson@ucsd.edu Where am I? In the village... What do you want? Information... From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: Code Bloat Date: 15 Oct 1994 02:39:28 GMT <37h760$qtu@coyote.csusm.edu> In-reply-to: rockwell@nova.umd.edu's message of 14 Oct 1994 12:13:19 -0400 > Lisp, however, has many features which encourage the > construction of large functions. Similar features can be built in > Forth, but they're "unforthlike". Which is to say most applications > don't need these features. When I first learned Lisp, I tried very hard avoided non-functional constructs, since I assumed them to be very unlisplike :-) It's all a matter of training and discipline. > : It's also very difficult to get efficient portable code this way. > : (you can get one or the other, but not both) > > Neither are hard to get. The usual way to get both is: You listed the difficult way :-) My experience, though not vast, is that by being easy to add a new construct, programmers will do so with little hesitation. Then later on they end up trying to port it only to have troubles, or they pass the project on to some poor soul who spends a day trying to discover all the nuances of this new contruct. In a standardly compiled language, you can't do this much, and thus stick with things that the compiler can optimize the hell out of, things that other programmers can quickly understand and modify, and so forth. Sure, you get more power, but you also get drawbacks. (the first rule of computer science is that there is no win-win situation) > : Most Forth's don't provide incremental compilation, since most > : of them don't compile. Again - this is not a Forth only > : argument, it's an argument for interactive environments. > > Como se dice "compile"? The distinction between code and data is > often blurry. My apologies. I meant compile to mean translation to base machine code. There are languages that do incremental compilation in this regard (including some Forths), but the common Forth systems do very little compilation. Or even compilation to byte codes. > If your problem is > significantly different than the base facilities that your language > provides you have to build these facilities all over again. Forth > makes it easier to fit the language to the problem domain. What most people fail to consider, no matter what language, is that a major change in the problem domain often means a change in the language as well. -- Darin Johnson djohnson@ucsd.edu -- Toy cows in Africa From: jverne@acs.ryerson.ca (John Verne - CNED/F94) Subject: Forth in Forth? Date: 14 Oct 1994 22:13:19 GMT Now we are getting somewhere! Compilers create executable code (among other things) and some of those executables are other compilers. these compilers can have the same flavour as it's parent compiler, or be completely different. Now, creating a forth flavoured compiler in, say, C, is possible, sometimes handy and even desirable. However, it seems to me that simplicity would suggest that if you wanted to compile or thread extensions to this compiler (a la C or forth or lisp) it would be easiest done in it's own vernacular. Syntactically speaking, of course. The egg (kernal) and the chicken (higher level words) are, of course, mutually inclusive. It would probably be identical to use a C assembler to assemble a forth kernal on which you could compile forth. I mean, there is no such thing as 'pure' assembling, is there? (by assembers here I mean tools in languages that accept mnemonic labels for machine-dependent instructions). This is relatively simple and painless. I mean, who wants to change primitives like '.' and '!' ? Even if you had to, it can be done retro-actively. What I am meandering at here, is that coding high level words in one language for another is kinda like a Rube G. machine. It works and if you have all the good reasons to do it, then fine. But as a normal procedure to create tools for use on pcs and servers, I feel it's just not as good as the 'real' thing. Merely my $1.25 worth! So, which should I UNZIP first: pcforth, f83, or the other one I forgot the name of...? -- Yers, J. Verne From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Code Bloat Date: 15 Oct 1994 00:48:11 -0400 <37n21t$1aol@coyote.csusm.edu> In-reply-to: djohnson@arnold.ucsd.edu's message of 15 Oct 1994 02:16:11 GMT Darin Johnson: : what's a DLL? A dynamically linked library. Essentially, an interpreter for use with compiled programs. -- Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e djohnson@arnold.ucsd.edu (Darin Johnson) writes: >> That doesn't affect the >> fact that implicit parameter passing helps readability in factoring. >That's where I have to disagree, I think it's the biggest cause >of unreadability :-) Well, I guess... Maybe we're just opposite personality types. I hate all those parenthesis, you hate not having them. I would just rathher see: 2 toolbars 1 window with show thhan show( with( window(1), toolbars(2) )); Or the Lisp equivalent (which is almost the same). I see that it's a matter of preference; I just don't like to see the parameter details in that way. >> >Static libraries, loop unrolling, help files, and so forth >> >are non-optimal design? Not all of that bloat is from poor >> >design. If you've got a C compiler on 12 disks, I'm pretty >> If the same functionality is attainable is less space, then it's poor >> design. >But it's not the same functionality. For instance, adding help >files is an improvement. Compiler loop unrolling speeds things >up. And so forth. I said SAME functionality. What I said was a rule, not an imaginative quote (well, maybe it was both ;). Note the if..thhen staement. The quicksort has the same functionality as the brute-force sort, but is faster. Therefore using the brute-force sort is poor design. >Also note that there are many different design goals all in >conflict with each other. Code size is only one of them. Sigh. "Same functionality" means "all other things equal" (or as close as possible ;). >> MS Word takes up 3,483,000 bytes (approximately). This is JUST the EXE; >> the DLLs take up far more. >Yikes. That's pretty sad. All that space and I don't even get >emacs bindings. What a waste. Well, be fair hhere-- do you get emacs bindings on any othher word processor that can do all MSWord can? Not even geoWrite has them. >Pardon for a stupid question, but what's a DLL? That's windoze's version of a Geode. ;) Sorry, I meant to say that it's short for "Dynamic Link Library". MSWord come with quite a few large ones, but I didn't count them. >Darin Johnson -Billy Fun, fun, fun! From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Code Bloat Date: 14 Oct 1994 22:09:59 -0700 In article djohnson@arnold.ucsd.edu (Darin Johnson) writes: >It works even if you have a bad programming style. To do the same >stuff by hand in Forth is ok as long as there is a good programming >style. It doesn't help if you inherit a project from someone else. This, in an indirect way, helps make my point. Bad programming style is bad for everything, but with explicit param passing this is covered up until it becomes REAL bad, at whichh time you need a full rewrite. Implicit parameter passing makes bad programming REAL bad, not even readable by the computer, so you pretty quickly learn to code well enough. Conversely, extremely good style looks mediocre and undistinguished with explicit parameter passing, but brilliant and inspired with implicit. When you get the right phrase it just _feels_ right. >Darin Johnson -Billy And similar unprovable stuff... :) From: h9290246@hkuxb.hku.hk (Zsoter Andras) Subject: Re: Code Bloat Date: Sat, 15 Oct 1994 03:23:32 GMT Darin Johnson (djohnson@seuss.ucsd.edu) wrote: : In article <37jtg3$14vt@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes: : : > Factored words look better and cost less in Forth. This is strictly due : > to the implicit parameter passing. In other languages factoring creates : > an ugly, time-consuming and unreadable mess; in forth it creates a clear, : > acceptably-quick and (you get the idea). : : Thisis highly debatable. I think the biggest drawback to implicit : parameter passing is that it quickly leads to an unreadable mess. : Not only is it difficult to tell where a logical function call beings or : ends, you have to worry about all the stack manipulation stuff : before you know what parameters go where. : : > The problem with Lisp is that it uses explicit parameter passing : > to give you a veritable nest of parenthesis; the advantage is that it uses : > explicit parameter passing to let the interpreter do some of your work for : > you. : : I hope parentheses aren't your only problem with it, that would : be too trite. But you certainly have no trouble finding out : what goes where in a lisp program, and if you want to find where : the 4th parameter is defined, you can do so in seconds. : As ancient Greeks said (but only if they could speak Latin ;-) 'De gustibus non est disputandum.'. I can very hardly imagine more nasty and unreadable stuff than a LISP program, on the other hand a FORTH program looks nice to me. It can be partly because I am an obsessed assemly programmer and I use high level languages just as a kind of 'portable assembler', but I can perfectly well imagine that someone who believes that computer programs are just machine readable translations of mathematical ideas will feel quite the opposite way. Andras From: gordon@charlton.demon.co.uk (Gordon Charlton)@charlton.demon.co.uk (Gordon Charlton) Subject: Re: Forth in Forth? Date: Thu, 13 Oct 1994 21:05:13 GMT In article tommy.hallgren@flower.ct.se (Tommy Hallgren) writes: >This sounds very interesting, but please enlighten me, what is a metacompiler? >I've heard it some times, but never got a good explanation for it. A metacompiler is a program written in Forth that creates a stand alone executable program that just happens to be another Forth. If this is intended to run on some machine other than the one the original Forth ran on then it the usual term is cross-compiler. Of course this is all very confusing because metacompiler is the wrong term. What _we_ are is metacompilers, in the same way that metaphysicists are people who talk about physics. BCNU Gordon : shbd ( n--n) BASE @ >R 0 <# #s #> DECIMAL EVALUATE R> BASE ! ; HEX 12345 ( Damn, Should Have Been Decimal.) shbd ( There, that's fixed it.) DECIMAL . ( If you see what I mean.) From: gordon@charlton.demon.co.uk (Gordon Charlton)@charlton.demon.co.uk (Gordon Charlton) Subject: Re: Going to Euroforth '94? Date: Thu, 13 Oct 1994 21:09:28 GMT Repeat posting, in case you missed the first one. > >>Email me if you are coming to Heathrow, stating what time you expect your >>flight to arrive, and when you wish to leave Winchester (Sunday evening or >>Monday) and I will try and put people with similar requirements in touch with >>each other. >> >>Gordon {gordon@charlton.demon.co.uk} > >Also flight number and terminal would be helpful. > > This service is provided by request from the conference hosts, MPE. BCNU Gordon {gordon@charlton.demon.co.uk} Longer hours, shorter arms, Rise Of The Robots You don't need to grease their palms. The Stranglers From: C.D.A.Hellon@bradford.ac.uk (Xian the Desk Lizard) Subject: Re: Code Bloat Date: Sat, 15 Oct 1994 14:13:16 GMT Originator: cdahello@ccw210 On 13 Oct 1994 16:38:29 GMT, Darin Johnson gave us: \ > True. It's the thinking smart that helps the algorithm, not the \ > factoring-- but the factoring helps the thinking smart. \ My big question then is why is "factoring" such a big deal \ with Forth? It's available in any language, with the same \ results, yet in Forth books and in this group it's always \ talked about as a big advantage of Forth. Other languages \ don't even use this term. Two reasons, I think. Firstly, because of the fact that everything in Forth is a word, it becomes much easier to take half of the words in a definition outside with fewer side-effects. Something like C or Pascal has too much syntactical stuff to make it worthwhile. And secondly, because calls in Forth are much cheaper - there is no need for digging around on one big generic stack, as the arguments are already in place on one. \ > >You have to note where code bloat comes from. Most of the time \ > >it's NOT from poor coding. Much of it comes from statically \ > >linked libraries, expanded code from the compiler (loop unrolling), \ > >extra functionality (spell checkers, cut buffers, help files), \ > >and auxillary files (I think you may find your PC C compiler is \ > >mostly auxillary stuff). \ > \ > Poor coding, poor design. Same schmiel. \ Nothing I listed that causes common bloat has anything to \ do with poor design. I'd disagree. Everything you have listed is the result of overgeneralising a solution to a problem, or of simply whacking everything in and hoping that this constitutes a solution. But in any case, certainly for the PC market, I think you're wrong - code bloat mainly comes from stuffing features on to a package and releasing it as a new version, whilst the sensible thing to do would be to rewrite it completely. -- Xian the Desk Lizard | Email: c.d.a.hellon@bradford.ac.uk | New .plan! Mostly depressed, | finger cdahello@muser.brad.ac.uk|more part-time thinker, | Fundamentalism today is what Americans claim they full-time dosser | fled Europe to escape. -- jon on a.a From: singla@email.teaser.com (Olivier SINGLA) Subject: FORTH implementation on 386 Date: Thu, 13 Oct 1994 23:15:36 GMT I have realized an original implementation of FORTH language on 386 PC, under MS/DOS. I called it 'FROTH'. Here are the highlights: - complete and hightly interactive integrated dev. system: interpret, real compiler, editor. - run in 32-bits protected mode, using all memory (flat model) - writen entirely in 386 assembler (even the editor) for speed - powerfull source editor (FROSTED): up to 40 files open, macros, very fast, - tools for cross-reference (modify automatically your source) - Definitions browser (instant go to any definition), - Dynamic and local variables (yes!), with garbage collector, - Complete help engine, - Multi-threads (up to 32), - Protection agains stack underflow, memory exceptions, ... - Fast compilation - Complete manual (tutorial and reference): about 200 page. This is a PUBLIC DOMAIN version. The software and the manual will be released in one month. Ask me for details. Oliver SINGLA La Verriere FRANCE -- Olivier SINGLA Software developer. Domains: QNX (2.15 and POSIX), MSDOS, MS-WINDOWS, C, Forth, Pascal, Assemblers (386) From: duncan@nic.cerf.net (Ray Duncan) Subject: Re: Chars to printer port #2 ? Date: 15 Oct 1994 15:51:17 GMT In article <14OCT94.14283842@twncu865.ncu.edu.tw> u332302@twncu865.ncu.edu.tw writes: >or,you can fetch data from bios memory... > 0000:0408h have all your printer port address in sequence > 0 $408 @L you get LPT1 address > 0 $409 @L is LPT2 > 0 $40A @L is LPT3 .... the address you get can be used with P@ & P! > you'll get "0" if there is no such port This works for simple environments but in general is a bad approach unless you are only writing software for your own amusement. It doesn't work for printer redirection that happens at the DOS level (e.g. MODE command) or network printers and it is unreliable in environments where the hardware is partially or fully virtualized from the point of view of DOS applications (e.g. Windows/NT, OS/2 2.x). Not to mention fully emulated DOS environments such as Soft-Windows on the PowerPC. If the objective is hardware and host-system independence and to provide the end-user with the expected, predictable behavior, then BIOS-data-area and port-I/O-based approaches should be avoided. Opening the printer by its logical device name (Int 21H Function 3DH) and then writing characters to it with Int 21H Function 40H is the method that is most likely to work in all situations. The performance isn't that great but can be improved by putting the device handle into raw (binary) mode and writing strings instead of single characters. From: dana@isis.whoi.edu (Dana R. Yoerger) Subject: Where is the FAQ? Reply-To: dana@isis.whoi.edu (Dana R. Yoerger) Date: Sat, 15 Oct 1994 19:53:11 GMT forth folks: Having just installed Borland C++ on my PC (all 85 megabytes just so I could compile "Hello World"), my interest in Forth has been renewed. I've been away from Forth for about 10 years, and I'd like to get caught up on where things sit now. Where can I find the FAQ for this group? Any other suggestions on reading material? dana yoerger woods hole oceanographic institution From: jrible@cup.portal.com (john - Rible) Subject: Re: Order of ORDER output Date: Sat, 15 Oct 94 13:58:32 PDT Joerg Plewe wrote: > To my opinion, the ANSI ORDER cannot be as nice and informative as > the ORDERs we know from non-ANSI system. That's true _only_ if ORDER is implemented portably--if it takes advantage of "inside information" it can display whatever you want it to, and still be standard. The use of constants can even be dealt with by the system implementor, or, as you note, just display "execution tokens" for them. -John