From: Graham Chiu Subject: Re: Announcement DOOF-0.1.2 Date: Wed, 15 May 1996 13:49:34 +1300 Message-ID: References: <4n987p$obc@hkusuc.hku.hk> Mime-Version: 1.0 In article <4n987p$obc@hkusuc.hku.hk>, Zsoter Andras writes >I was thinking about a better name for DOOF. >I still don't want to change its real name (Dynamic Object-oriented Forth) >but because of the protest I am willing to change the acronym. > >Does DynOOF mean anything nasty, obscene, or stupid in anyone's language >in this group? > >If not, the next release will be called DynOOF. How about the RPN version Forth Oriented-Object Dynamic or Food for forth Graham Chiu CompKarori, Karori Shopping Mall, Karori, Wellington, New Zealand Amiga, Jaguar, PlayStation, and PC sales, & Wellington Internet Connections ph: +64 4 4760212 fax: +64 4 4769088, internet: gchiu@compkarori.co.nz web pages: http://www.compkarori.co.nz From: "Bruce R. McFarling" Subject: Re: Z80 Fossils and rambling notions Date: 15 May 1996 05:20:15 GMT Message-ID: <4nbpif$11c@seagoon.newcastle.edu.au> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <1996May12.064302.267@tb.forth-ev.de> <1996May12.091743.771@tb.forth-ev.de> <1996May12.194711.397@kbbs.org> <4n6tp1$8ug@news.whidbey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) "Douglas Beattie Jr." wrote: >Therefore, a 6502 running at a given clock speed, whether >it be 2 MHz, 8 MHz or 20 Mhz, is four times faster than a >Z80 running at the same clock speed. > >Obviously: the 6502 is superior to the Z80. Of course, this comes from synchronization of chip to the memory bus, so if the 6502 has to do something on its chip, it 'wastes' a clock cycle, and if the memory is too slow for the chip, you do not get graceful degradation of performance by introducing a 'wait state': you have to slow all chip operations to slow down memory accesses. Of course, that was then and this is now. Given the price of high speed static 64K RAM, and the cost of the current 20MHz 65c02 processors, then you do have to find that 80-MHz Z80 to run and catch up with it. And when you do, find a way to pay for it! 8-)# But all this was and is a side issue. The 6502 was used by Apple and CBM, etc., because it was cheaper, and it was cheaper because it was implemented in fewer transistors, and it was the 1-1 sync to the memory bus that accounts for some of that. The low transistor count and extra space that provides for single-chip ASIC's in a mask seems to be why WDC is able to continue licensing the CMOS version of the design. And if you can get more of your components on a single chip and the pins needed to connect chips, that is the cost factor coming in by another route. But I can't bring myself to say that one is better than the other, since I find it so much easier to grasp either than the wonderful complexities of something like the Pentium. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "Bruce R. McFarling" Subject: Re: Forth instead of JAVA (RFC) Date: 15 May 1996 05:09:00 GMT Message-ID: <4nbotc$11c@seagoon.newcastle.edu.au> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <317E2F3D.1279@dbsoftware.com> <3184E436.2ACB@minster.york.ac.uk> <318E3F50.868@blue.nowcom.co.kr> <4mncvo$2ac@seagoon.newcastle.edu.au> <831502301snz@tcontec.demon.co.uk> <4mscgv$k91@seagoon.newcastle.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) rj@eli.wariat.org (Robert J. Brown) wrote: >I think you should start with a token threaded implementation so you >can have a cross-platform portable binary image (assuming 32-bit 2's >compliment arithmetic, and IEEE floating point representations, and >some standard for endianess, etc.). With token threading, objects are >easy to implement (see http://eli.wariat.org/~rj/dreams/node1.html). >Tokens also make it easy to restrict what words are allowed to be >used. This should be able to provide a lot of security. Of course, >you need memory management hardware to watch out for illegal memory >accesses. This gets to the question I asked. Of course, Open Boot is already a standard, so one way to approach the question is to ask what restrictions need to be placed on Open Boot code to make it safe. In personal correspondence, it has been suggested that my original question was misdirected (though no question that elicits a useful redirection is *entirely* misdirected!): the question is not how to make Forth safe to run on a system, but how to make a system within which it is safe to run Forth. For example, an 'applet' Forth subsystem might have 32K RAM available to direct R/W access, and a set of 32 blocks provided in RAM, with loading and saving of the block system entirely beyond the control of the subsystem. Then even systems without hardware memory management might be able to achieve some protection in if @ and ! utilize 16-bit pointers within the applet RAM space. It would be interesting if a Forth subsystem could be designed that permitted Open Boot binary code to be executed safely, assuming viciously aggressive or stupid anonymous code, since that would square the circle: on the system itself, Open Boot has the level of access that is required for something that will support effective device drivers, etc., while within the confines of the open subsystem (call is 'Open Access', maybe?) it is firewalled from having the same kind of access. And at the same time would serve to promote Open Boot itself. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "Dave Carlton" Subject: Re: MacForth acquired by FORTH, Inc. Date: 15 May 96 00:54:48 -0700 Message-ID: References: <19960507154918.aaaa000FH@babyblue.cs.yale.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Cyberdog/1.0 X-News-Servers: trib.apple.com X-Newsgroups-TO: nntp://trib.apple.com/comp.lang.forth Congratulations! Is Don still involved? Guess I need to talk to you about cost of a site license. --------------------------------------------------- This message was created and sent using the Cyberdog Mail System --------------------------------------------------- From: "Dave Carlton" Subject: Re: Open Boot on Apple Power PC Date: 15 May 96 01:00:10 -0700 Message-ID: References: <4n4ffq$m3o@news.interpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Cyberdog/1.0 X-News-Servers: trib.apple.com X-Newsgroups-TO: nntp://trib.apple.com/comp.lang.forth Hook up a terminal to th modem port, set it to 38400 8-0-1 and hit Command-Option-O-F. If you have on-board video you can switch the display to it by "vci0/control/ output and the keyboard by "kbd" input --------------------------------------------------- This message was created and sent using the Cyberdog Mail System --------------------------------------------------- From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Announcement DOOF-0.1.2 Date: 15 May 1996 10:05:58 GMT Message-ID: <4ncaa6$lul@hkusuc.hku.hk> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> Tom Zimmer (zforth@ix.netcom.com) wrote: >Zsoter Andras wrote: >> P.S.: Say, I want to persuade people to use DOOF to program >> in Un*x, how can I explain, that words like OPEN-FILE need an address + count >> but if you are using something from the C library use need a '\0' terminated >> string? >> Any other tool on a Un*x I know about uses the latter one...... >In Win32Forth, an extention to local variables allows a temporary string buffer >to be allocated on the return stack along with other local variables while >inside a definition. Andrew implemented it, as LocalAlloc where the size was >passed to LocalAlloc, and it returned the address of a buffer that was valid Sounds like Alloca in DOOF (or DynOOF ;-) and alloca in C. >until the definition terminated. This seems to work well, and provides an >almost free mechanism to obtain a string buffer for the above described type >of work. Well, I can do that (and a couple of other things) the problem is that I really like to present my Forth to some end user as an ``application language''. If even strings are handled in an accidental manner then a not-quite-a- computer-jerk user will feel hmm, ``uncomfortable'' with the situation. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: RFI: execution tokens Date: 15 May 1996 10:48:30 GMT Message-ID: <4nccpu$lul@hkusuc.hku.hk> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> Jonah Thomas (JEThomas@ix.netcom.com) wrote: >>But 0BRANCH will do as a name! >Only it might not be a word that could be named 0BRANCH , it might be a scrap of >inline machine code. The standard doesn't specify at that level. ^^^^^^^^^^^^^^^^^^^^^^^ Well, so is DUP, SWAP and the like. Just because something can be implemented as inlined machine code it does not mean it cannot have a name. >>Why do we call it an ``execution semantics'' whe it is another word >>compiled by IF? >Because it isn't exactly clear what it _is_, all that's supposed to be clear is >what it _does_. And that's defined abstractly enough that implementations can be >optimised in a variety of different ways. I do not follow you. Why is an obscure and undefined term as ``execution semantics'' more abstract, or why does it give more freedom for optimization than a name like 0BRANCH? (I do not mean that 0BRANCH should be defined as it used to be, so that it takes 2 bytes from the address following it and adds it to the program counter or whatever, but a concept of 0BRANCH is more understandable than the concept of ``execution semantics'' which is neither compilation nor interpretation but a 3rd state.) >>And when it is not the same, introduce another word, so you don't >>have 3 semantics (interpretation, execution, compilation) just >>two, which simplifies your model. >That makes sense. The "execution semantics" thing came in at the last minute, >when all the substantive issues were settled and people were concentrating on >getting the logic just so, and maybe it got frozen at the wrong moment. That proves my point! The ``executions semantics'' is something not well thought of which -- as you say -- was added to the Standard at the last minute. Those things should not happen. Something might look good on the spot and turn out to be worse than useless after a second thought. A standard is not like a line of Forth code, and a little unnoticed mistake can affect system implementors for years. A conceptual issuse such as a Forth system really has 2 or 3 states (interpretation, compilation and execution) is a more serious thing than just add it to the Standard at the last minute. Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so behaviour to a definition? No need to invent a name for it as "execution semantics" because it is not the semantics of IF anyway, but the semantics of the chunk of code inserted by IF into the definition. Andras From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: Forth instead of JAVA (RFC) Date: 15 May 1996 13:28:08 +0200 Message-ID: <4ncf48$6oe@ite127.inf.tu-dresden.de> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <317E2F3D.1279@dbsoftware.com> <3184E436.2ACB@minster.york.ac.uk> <318E3F50.868@blue.nowcom.co.kr> <3190DF23.7498@paisley.ac.uk> <4n1k3q$309@news.whidbey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: "Douglas Beattie Jr."'s message of 11 May 1996 08:45:46 GMT >>>>> "Douglas" == "Douglas Beattie Jr " writes: Douglas> Peter Knaggs wrote: {snip!} >> In addition, we could supply Forth source code as part of the >> page which could be interpreted directly. Thus would have the >> same effect as Netscape's JavaScript. Douglas> ..an excellent idea; I think I will implement that Douglas> technique here within the lab. In the meantime: Douglas> ( program here) Yet another extension incompatible with the spirit of SGML. But if you insist, it would be better to follow the lead and use . -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/ E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: Peter Knaggs Subject: Re: Forth instead of JAVA (RFC) Date: Wed, 15 May 1996 13:22:47 +0100 Message-ID: <3199CC97.185D@paisley.ac.uk> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <317E2F3D.1279@dbsoftware.com> <3184E436.2ACB@minster.york.ac.uk> <318E3F50.868@blue.nowcom.co.kr> <3190DF23.7498@paisley.ac.uk> <4n1k3q$309@news.whidbey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b3 (Win95; I) Douglas Beattie Jr. wrote: > > Peter Knaggs wrote: > > >In addition, we could supply Forth source code as part of the page > >which could be interpreted directly. Thus would have the same effect > >as Netscape's JavaScript. > > ..an excellent idea; I think I will implement that technique > here within the lab. In the meantime: > > <--FORTH> > ( program here) > > > ..does that look okay? Why not use HTML/3.2 tag Thus you could implement a browser that could interpret LiveScript, JavaScript and Forth, dependent of the value of the Language attribute. -- Peter J Knaggs pjk@paisley.ac.uk From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Forth instead of JAVA (RFC) Date: 15 May 1996 10:12:06 GMT Message-ID: <4ncalm$lul@hkusuc.hku.hk> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <318E3F50.868@blue.nowcom.co.kr> <4mk3r4$kc3@dfw-ixnews4.ix.netcom.com> <4mouq6$sd0@ecuador.it.earthlink.net> <4nagsu$lja@webprod2.lehman.com> Hadil G. Sabbagh (hsabbagh@lehman.com) wrote: >IMHO, a) no large organization pushes Forth as a general-purpose computer >language suitable for solving many different types of problems and b) the >only way Forth will be introduced into this environment (or any other >environment in a big way) is by developing and selling an application >written in Forth, then making a big deal out of it. You forget one aspect: Forth in itself is an application. IMHO in a Un*x environment a ``Forth for Un*x'' would be an excellent shell, for example. (Just that nasty problem thet ANS-Forth trings are not Un*x strings. :-((( ) What I mean that Forth probably will not replace "C" in those systems but it can finds its place in a toolbox among, sh, awk and perl. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Announcement DOOF-0.1.2 Date: 15 May 1996 10:07:33 GMT Message-ID: <4ncad5$lul@hkusuc.hku.hk> References: <4n987p$obc@hkusuc.hku.hk> Graham Chiu (gchiu@compkarori.co.nz) wrote: >In article <4n987p$obc@hkusuc.hku.hk>, Zsoter Andras > writes >>I was thinking about a better name for DOOF. >>I still don't want to change its real name (Dynamic Object-oriented Forth) >>but because of the protest I am willing to change the acronym. >> >>Does DynOOF mean anything nasty, obscene, or stupid in anyone's language >>in this group? >> >>If not, the next release will be called DynOOF. >How about the RPN version >Forth Oriented-Object Dynamic >or Food for forth Well, someone have already suggested Food, is this name really *that* good? Andras From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Z80 Fossils and rambling notions Date: 15 May 1996 13:25:01 GMT Message-ID: <4nclvd$qtk@majipoor.cygnus.com> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4n5279$800@columbia.acc.brad.ac.uk> <4n5da7$pbr@yama.mcc.ac.uk> <4n7s76$941@columbia.acc.brad.ac.uk> xian the desk lisard (cdahello@comp.brad.ac.uk) wrote: : funny. 4MHz 6502s were around at the same time as 4MHz z80s (in fact : the first ever 65c02 was a 4MHz part, if memory serves) but they never : made it into computers. Are you sure? AFAIK the Z80H was available long before a CMOS 6502. : what got me about the 6502 was that for every z80 instruction, the : 6502 coder would have to (usually) write 2 to 5. A perusal of the fig_FORTHs for the two processors will soon show that this isn't really true. For example, try doing anthing like lda (fred),x on a Z80! The numbers of opcodes for the two Forths were fairly similar. NEXT was much nicer on a Z80, I admit. : . Now this is something I don't understand. Does that mean that you can : . give the Pentium Pro an instruction which will turn it into a completely : . different processor, with a different instruction set? Or does : . "32-bit mode" mean that all the 16-bit registers suddenly become : . 32 bits long? Would that mean that the 64K-boundary really disappears? Yes, of course. As soon as the processor is in 32 bit protected mode all registers are 32 bits wide. The '386 architecture has always been like that. Andrew. From: Andrew McKewan Subject: Re: Forth and RTOS, second posting Date: Wed, 15 May 1996 09:38:09 -0500 Message-ID: <3199EC51.142@austin.finnigan.com> References: <3198CE17.5260@abc.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Mattias Waldau wrote: > > I got no respons at all to my previous posting, thus I am posting it > again. If there are still no reponses I assume that no one is doing > embedded systems using Forth :-) > > Do people that do embedded systems using forth use anything more than > 1. Multitasking, and > 2. The ability to put forth-code in an interrupt handler. > > Is there a RTOS-package? What bothers me with the RTOS concept, is that there is something else other than my program in control of the system. We use a version of pSOS (with C) at Finnigan and I heard one of the engineers grumbling the other day that he couldn't find out where pSOS put the stacks for his tasks! > Typical RTOS features > 1. I do not need/want pre-emptive tasking > 2. I want to pass data using messaging > 3. I want semaphore > 4. I want syncronious and asyncronious communication > 5. Time management, i.e. delay for 100 msec Most commercial Forth packages (and some free ones) come with a multitasking toolkit. They include some or all of the features above. You can find links at the FIG home page: http://www.forth.org/fig.html The only thing I would add to your list are queues (which might be covered by message passing). I won't argue cooperative vs. prioritized pre-emptive multitasking (both have pros and cons). The real challenge in multitasking programming is correctly defining the tasks and synchronization methods. A poor design can lead to a real mess (I've seen some!). -- Andrew McKewan mckewan@austin.finnigan.com From: Andrew McKewan Subject: Re: RFI: execution tokens Date: Wed, 15 May 1996 09:56:46 -0500 Message-ID: <3199F0AE.8E6@austin.finnigan.com> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> <4nccpu$lul@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Zsoter Andras wrote: > > [stuff deleted] > > Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so > behaviour to a definition? No need to invent a name for it as "execution > semantics" because it is not the semantics of IF anyway, but the semantics > of the chunk of code inserted by IF into the definition. > Forth has always been a language of semantics rather that syntax. Other languages would talk about an "if statement" or "do while loop" as a whole. In FIG Forth, we always knew what IF and THEN did, and so we could use them to create other structures or even unstructured code (ever see [ ROT ] THEN). I think the writers of the ANS standard tried to keep to "one word, one definition" at the same time allow any type of language implementation. What if, instead, we went back to an "IF statement" type definition where we deal with IF, ELSE and THEN all together. Something like: "IF pops the top of the data stack. If it was zero, code execution begins following the next matching ELSE or THEN. If it was non-zero, code ececution continues following the IF." This is exactly how you would explain it to someone, it is what is does, and it can be implemented any-old-how. If we want a standardized language that can be implemented as token threaded or native code, we are going to have to stop playing all the tricks we have learned to spice up our code. Our code should be simple and easy to understand and unabmigious. Just because we have POSTPONE and COMPILE, doesn't mean that we should be using them in every program we write. Let's get back to our roots: : WASHER WASH SPIN RINSE SPIN ; -- Andrew McKewan mckewan@austin.finnigan.com From: Simon Read Subject: backward compatibility (was: ..fossils..) Date: 15 May 1996 15:59:25 GMT Message-ID: <4ncv0t$9er@yama.mcc.ac.uk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; OSF1 V3.2 alpha) X-URL: news:4nagk6$mhn@ecuador.it.earthlink.net ER: Elizabeth Rather ER> Compatibility is a double-edged sword. "Real" programmers hate it, but ER> the marketplace sure does love it ;-) ER> [and in the next article...] ER> No-one writing a program they hoped to sell or publish woulD ER> want to restrict it to a Pentium Pro. By they time "everyone" ER> has one, there will be several newer, better chips that you'll ER> also want to run on! --> Sounds like there's a fundamental difference of philosophy here. One attitude is, "My customers are stupid, *OR* my compilers are too complex. *OR* I don't want to give my customers that much control, so I'll never give out source code, I'll just sell the executable. My customers could never re-compile the source code for a new machine. Therefore, all my new machines must run the object code identical to that which the old machines ran." Another attitude is, "My customers aren't stupid, and my compiler is sufficiently simple, and I want to give my customers as much control as they need, so I'll just sell my source code, then my customers can re-compile the code on whatever new machine comes along. Therefore, there is no need to make newer processors code-compatible with older processors." It seems to me that FORTH goes with the second philosophy. In practice, this meant that I was able to port one extremely complex application (computer algebra) from a Z80 computer to an ARM computer, with most of the worry revolving around whether the serial port (to transfer the source code) would work or not. The machine-dependent code was isolated in 3 blocks. Apart from that, the code (over 100K of source code) ran unchanged. This was a consequence of using FORTH. Simon From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: RFI: execution tokens Date: 15 May 1996 15:16:48 GMT Message-ID: <4ncsh0$1aq@dfw-ixnews4.ix.netcom.com> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> <4nccpu$lul@hkusuc.hku.hk> X-NETCOM-Date: Wed May 15 10:16:48 AM CDT 1996 In <4nccpu$lul@hkusuc.hku.hk> h9290246@hkuxa.hku.hk (Zsoter Andras) writes: >Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so >behaviour to a definition? No need to invent a name for it as "execution >semantics" because it is not the semantics of IF anyway, but the semantics >of the chunk of code inserted by IF into the definition. Looking back, I think you're right. People have been confused about it here, that means the present terminology is confusing. But the same people who made this mistake, cleared up a whole lot of others. If you're clear about it now, maybe we could go on to something else? If you want to send in a request of clarification to the standards committee, they might work out a stock answer to give out the next time it comes up. From: Elizabeth Rather Subject: Re: MacForth acquired by FORTH, Inc. Date: 15 May 1996 17:06:43 GMT Message-ID: <4nd2v3$ee7@ecuador.it.earthlink.net> References: <19960507154918.aaaa000FH@babyblue.cs.yale.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: davec@apple.com,sagarwal@forth.com X-URL: news:ADBEDBE1-5C1D6@17.206.20.241 "Dave Carlton" wrote: >Congratulations! Thanks! >Is Don still involved? No, he retired last summer, and sold CSI to an outfit that had been mfg his Nubus boards. They were not interested in MacForth, so (at Don's suggestion) they sold it to us. >Guess I need to talk to you about cost of a site license. Delighted! The person to talk to is Steve Agarwal (sagarwal@forth.com). We are very interested in developing some OF tools for MacForth, and of course would be more than happy to do so w/ Apple. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Peter Churchyard Subject: Extensible language vs standardization Date: Wed, 15 May 1996 13:11:04 -0700 Message-ID: <319A3A58.3370@tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Hi back in the late 70's the forth's I implemented used a fairly minimal vocabulary. A sort of micro kernel.. From there I used to define control structures etc. That is the 'language' that I wrote the application in was variable. One day I might use just the IF ELSE THEN style, another day I might add words to do WHILE UNTIL BREAK CONTINUE ENDWHILE Do people now still do this? Or do you mostly use the provided control structures? The modern standards have a fairly extensive set of operations. Pete From: Elizabeth Rather Subject: Re: Forth and RTOS, second posting Date: 15 May 1996 17:22:40 GMT Message-ID: <4nd3t0$epm@ecuador.it.earthlink.net> References: <3198CE17.5260@abc.se> <3199EC51.142@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:3199EC51.142@austin.finnigan.com Andrew McKewan wrote: >What bothers me with the RTOS concept, is that there is something else >other than my program in control of the system. We use a version of pSOS >(with C) at Finnigan and I heard one of the engineers grumbling the >other day that he couldn't find out where pSOS put the stacks for his >tasks! Last year an old customer of ours, a Very Large Company, told us that the corp. suits had decided the next generation device would be programmed in pSOS & C because that's how everybody else does it. 9 mos. later they called in a tearing panic, because the C team barely had pSOS working on the device & they needed to ship in 3 mos. We were busy, but agreed to help on a part time basis. We delivered a kernel the following week, and drivers about 1/wk, while their Forth team ported the application. Not only was our code (1) working; (2) smaller; (3) faster, it also (4) used 0.1 x the power, which was important since it's a battery-powered hand-held device. The key to the latter was that we could jigger our multitasker to shut down the device when no tasks were running, which is in fact most of the time, only frequently in small intervals. pSOS, on the other hand, needed a fairly long time-out to shut down -- and, of course, it's a black box that the VLC couldn't modify. The s/w is now complete, all working, in final validation process, and will be released on schedule. The C team did end up writing some diagnostics which will be used, but the Forth guys didn't want to do that anyway ;-) >Most commercial Forth packages (and some free ones) come with a >multitasking toolkit. They include some or all of the features above. >You can find links at the FIG home page: > > http://www.forth.org/fig.html You might also check http://websites.earthlink.net/~forth (our site!) >The real challenge in multitasking programming is correctly defining the >tasks and synchronization methods. A poor design can lead to a real mess >(I've seen some!). Truer words are rarely emailed. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://websites.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: RFI: execution tokens Date: 15 May 1996 17:32:21 GMT Message-ID: <4nd4f5$epm@ecuador.it.earthlink.net> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> <4nccpu$lul@hkusuc.hku.hk> <4ncsh0$1aq@dfw-ixnews4.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:4ncsh0$1aq@dfw-ixnews4.ix.netcom.com JEThomas@ix.netcom.com (Jonah Thomas) wrote: >In <4nccpu$lul@hkusuc.hku.hk> h9290246@hkuxa.hku.hk (Zsoter Andras) writes: > >>Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so >>behaviour to a definition? No need to invent a name for it as "execution >>semantics" because it is not the semantics of IF anyway, but the semantics >>of the chunk of code inserted by IF into the definition. > >Looking back, I think you're right. People have been confused about it here, that >means the present terminology is confusing. That was the way things stood (no special term) for quite a while, until we became sick of saying, "you know, that stuff compiled by IF, WHILE, REPEAT, etc." and found a nice(er) shorthand. And in response to Andras' comment that we should have just given "the word" a name, that doesn't work for implementations that aren't compiling "a word" there, but an actual branch, multiple words, etc. Not to mention our reluctance in this, as in many other issues, to mandate a particular implementation. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Thomas Worthington Subject: Low level window hooks? Date: 15 May 1996 14:01:34 GMT Message-ID: <4nco3u$per@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) I'm starting a 32-bit ANS style Forth and I want to make Windows available, not as built in fuctions (I want a SMALL Forth not another Win32Forth) but in the form of a low level gateway system. All the docs I can find on Windows assumes that you are working in a high level language. Since it is easy to get lists of what paramiters Windows wants for each function, it would seem reasonably easy to: a) standardise the calling routine, and b) write the various windows routines in otherwise ANS forth to be loaded (even stored in blocks if you like!) as required. In the real world things aren't that easy, of course, but I thought I'd ask. Thomas Worthington From: Thomas Worthington Subject: Re: Low level window hooks? Date: 15 May 1996 14:32:02 GMT Message-ID: <4ncpt2$rd2@mercury.kingston.ac.uk> References: <4nco3u$per@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) I wrote: >I'm starting a 32-bit ANS style Forth and I want to make Windows >available, not as built in fuctions (I want a SMALL Forth not >another Win32Forth) but in the form of a low level gateway >system. All the docs I can find on Windows assumes that you are >working in a high level language. Since it is easy to get lists >of what paramiters Windows wants for each function, it would seem >reasonably easy to: > a) standardise the calling routine, and > b) write the various windows routines in otherwise ANS forth > to be loaded (even stored in blocks if you like!) as > required. > > In the real world things aren't that easy, of course, but I >thought I'd ask. > Thomas Worthington > I suppose I should actually say what my question was: Does anyone out there know what you have to do to call Windows from 386 or later assembler?. Thomas Worthington From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: Forth instead of JAVA (RFC) X-Nntp-Posting-Host: ztm99-6.zoetermeer.nl.net Message-ID: References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <318E3F50.868@blue.nowcom.co.kr> <4mk3r4$kc3@dfw-ixnews4.ix.netcom.com> <4mouq6$sd0@ecuador.it.earthlink.net> <4nagsu$lja@webprod2.lehman.com> <4ncalm$lul@hkusuc.hku.hk> Date: Wed, 15 May 1996 17:46:28 GMT h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >You forget one aspect: Forth in itself is an application. >IMHO in a Un*x environment a ``Forth for Un*x'' would be an excellent >shell, for example. >(Just that nasty problem thet ANS-Forth trings are not Un*x strings. :-((( ) But it can be done without much trouble! For technical reasons I use 0-delimited strings in my 4tH. But COUNT, TYPE, -TRAILING, etc. still work as expected! >What I mean that Forth probably will not replace "C" in those systems >but it can finds its place in a toolbox among, sh, awk and perl. Agreed! Hans From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: 8051 microcontroller FAQ Date: 15 May 1996 20:05:43 +0200 Message-ID: <4nd6dn$6q4@ite127.inf.tu-dresden.de> References: <1021@purr.demon.co.uk> <318ecff1.20522122@news.netspace.net.au> <4munpf$170@ite127.inf.tu-dresden.de> <1052@purr.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: jack@purr.demon.co.uk's message of 11 May 1996 01:37:11 GMT >>>>> "Jack" == Jack Campin writes: It seems you felt I stepped on your toes. It wasn't meant that way, perhaps I can clarify. Jack> gratz@ite.inf.tu-dresden.de (Achim Gratz) writes: >> I don't know what News software you are using, but usually you >> get the headers only from the Newsfeed, then apply your >> killfile, select what's leftover and then download the >> articles. Jack> This is actually a rather unusual procedure. Most people Jack> fall into one of two other categories: No, it's the way NNTP was designed and how you surely would do it if you were operating port 119 directly, trying to minimize your cost and effort. Both ways you describe sound like a misuse of the net to me anyway. Jack> 1. somebody else is paying, so the whole group gets Jack> downloaded and you get to choose by using killfiles (though Jack> even that wastes your time); Believe me, if my newsreader tried to download everything, I'd be up against the wall before it finished the first group I'm trying to read. Whether I use a killfile after that or not is moot, I agree. Jack> 2. the NNTP agent or provider makes no provision for Jack> cost-effective selectivity at all. This is all on the agents side, given the protocol is implemented correctly. The NNTP protocol provides for getting the headers and bodies of articles (and ranges of them) seperately, so any software that keeps telling you you ought to get them together with the articles (this is mainly used for Newsfeeds) is seriously flawed. It is also inefficient and wastes bandwith to do so, since you almost never want to read every single article in a group. If you do as suggested (not by me, by the protocol), you will minimize both connect time and transmission time. Jack> It is incredibly arrogant to assume that those of us - and Jack> there are quite a few who have posted in just this thread - Jack> who are in the second category above are doing it this way Jack> out of stupidity. I didn't assume stupidity on your part and I plead that you don't assume arrogance on mine. My point however was that your software is not working the way it should and could. There are enough good programs out there, for my choice see the X-Newsreader header. If your provider doesn't leave you the choice of the agent for some reason, well that's another story. [...] I didn't enjoy the personal attacks you were riding, I hope you cooled down a bit. -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/ E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: Russ Webb Subject: Re: Open Boot on Apple Power PC Date: Wed, 15 May 1996 15:34:19 -0500 Message-ID: <319A3FCB.4260@cornell.edu> References: <4n4ffq$m3o@news.interpath.net> Reply-To: rw20@cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Thanks for the PCI OBoot hints. I've been able to get everything to work exept for switching to the Mac screen. I can see the devalias "vci0" in the devalias list, but when I type "dev vci0" it cannot find the package. "dev kbd" works. I suspect this is because the video systems are not initialized. I am rebooting and holding option-command-o-f to get in to Open Boot, but open boot takes over before the monitor shows any signs of life. Is there a way to get to open boot after the video system is active? Or am I doing something else wrong? Thanks, Russ Webb From: fry@mail.powerup.com.au (Glen Fry) Subject: Suggestions for a good Windoze Editor Date: 15 May 1996 14:29:18 GMT Message-ID: <4ncpnu$7to@grissom.powerup.com.au> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII I'm programming a small controller with forth in it's prom. The editors I have been using create some sort of garbage in the files when saved hence the programs won't download and hence compile. - Dos vi works just fine - but I really need a good Win editor to allow pasting to my termional app.. Any suggestions? Thanks Glen Fry From: Andrew McKewan Subject: Re: Low level window hooks? Date: Wed, 15 May 1996 16:31:48 -0500 Message-ID: <319A4D44.40FB@austin.finnigan.com> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Look for Jack Woehr's Forth for NT on taygeta. (I couldn't connect the last few days, but found it on the Brehmen mirror:) ftp://ftp.uni-bremen.de/pub/languages/programming/forth/Taygeta-Archiv e/Reviewed/jx4nt110.zip It's written in 386 assembler and is quite small. Uses blocks of Unicode characters. Otherwise you can take Win32Forth and rip all the stuff you don't like off. The kernel is not that big. It will be much faster than trying to bring something up from scratch. Or you could just steal the code that calls Windows DLLs, that's all you really need. Could I ask what are your reasons for writing a new Forth? -- Andrew McKewan mckewan@austin.finnigan.com Thomas Worthington wrote: > >I'm starting a 32-bit ANS style Forth and I want to make Windows > >available, not as built in fuctions (I want a SMALL Forth not > >another Win32Forth) but in the form of a low level gateway > >system. All the docs I can find on Windows assumes that you are > >working in a high level language. Since it is easy to get lists > >of what paramiters Windows wants for each function, it would seem > >reasonably easy to: > > a) standardise the calling routine, and > > b) write the various windows routines in otherwise ANS forth > > to be loaded (even stored in blocks if you like!) as > > required. > > > > In the real world things aren't that easy, of course, but I > >thought I'd ask. > > I suppose I should actually say what my question was: Does anyone > out there know what you have to do to call Windows from 386 or > later assembler?. From: ehp@ear.co.at (Ewald Pfau) Subject: Forth and RTOS, second posting Message-ID: <832195369.AA00289@ear.co.at> Date: Wed, 15 May 1996 23:42:20 +0100 X-FTN-To: Mattias Waldau Mattias Waldau wrote: MW> Do people that do embedded systems using forth use anything MW> more than 1. Multitasking, and MW> 2. The ability to put forth-code in an interrupt handler. MW> Is there a RTOS-package? MW> Typical RTOS features MW> 1. I do not need/want pre-emptive tasking MW> 2. I want to pass data using messaging MW> 3. I want semaphore MW> 4. I want syncronious and asyncronious communication MW> 5. Time management, i.e. delay for 100 msec Generally: 1. .. 5. yes, why not. Forth gives the tool. Merely a promise spelled as solution. The rest is coding waiting to be done. 1. Tasking in Forth didn't make it into the ANS language specification. You may expect 'round-robin' tasking, as far as re-entrance in Forth is given at selected entrance levels for task switching. What remains of your questions deals with common coding practise. 2. Why not? Strings and numbers are just similar when encoded in bits'n bytes... 3. To ask for semaphores is asking for common variables. Yes, Forth has common variables :) 4. Look around for UART interfacing. 5. Look around for access to 'ticker' routines at the machine you deal with. At DOS machines, there is either the 2^16/1.193.800 sec ticker, or a non-re-entrant INT-call for better timing resolution down to microseconds (if a WIN- or OS/2-box preserves it; in Windox start with unknown, in OS/2 reduce to 30 msec slots). Ewald From: Bernd Paysan Subject: Re: ANS Forth question Date: Sun, 12 May 1996 22:18:40 +0200 Message-ID: <319647A0.298DBD87@informatik.tu-muenchen.de> References: <4m6fil$kvp@argentina.it.earthlink.net> <4mbtvq$3ge@seagoon.newcastle.edu.au> <831502382snz@mpeltd.demon.co.uk> <4mqfop$c16@columbia.acc.brad.ac.uk> <4ms0f9$18q@dfw-ixnews7.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.3.99 i486) Jonah Thomas wrote: > I tried writing an ANS Standard block editor, and it bugged me that I had no > official way to tell how many buffers were present. I couldn't assume there was > only one (which makes it simple to move blocks down to leave a gap in the middle) > and I couldn't assume there was more than one (which lets you copy parts from one > to another). Even if you have multiple buffers, you can't asume that they will be cached in a LRU manner (thus you can copy from the second newest buffer to the newest), e.g. gforth uses a direct mapped block cache (now, may change in future). You have only one chance: get the first buffer's address, copy the text to a save location, get the second buffer's address, store the text from the save location to the destination. This will always work. The block editors I know even make this behavior visible to the user, thus they have a line/char stack, and you don't copy from one buffer to the other, you either cut/copy to the stack, or you paste from the stack. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: POSTPONE and words with special compilation semantics Date: Sun, 12 May 1996 22:29:26 +0200 Message-ID: <31964A26.2469ECD8@informatik.tu-muenchen.de> References: <4mgb2e$2qn@news.tuwien.ac.at> <4mhn11$n2a@nis.dacom.co.kr> <4mkq2m$rqj@news.tuwien.ac.at> <4mkt9d$l04@lyra.csx.cam.ac.uk> <4mvjhr$47p@news.tuwien.ac.at> <4n4gjp$696@nis.dacom.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.3.99 i486) Wonyong Koh wrote: > You are right literally. However, I understand that TC's intention is > not to allow compilation during interpretation state. Can we get an official (from the TC) statement, that this was intented? The TC's intention was not to break common FORTH practice if this was not necessary. I thought my Forths were ANS conformant, but none of them passes postponetest.fs, and so do other Forths that are labeled "ANS". What I need is a official statement, that compilation during interpreation mode (via POSTPONE and [COMPILE]) is an ambigouos condition. > Apparently we need to ask TC for official > position. My words. > In current ANS Forth Standard, there is no way to define compilation > semantics and interpretation semantics seperately. Of course we may > introduce INTERPRETATION: or C:. Then how the execution semantics of a > definition can be represented by ***one*** xt? The DOOF way. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: cfindlay@netspace.net.au (Craig Findlay) Subject: Re: Suggestions for a good Windoze Editor Date: Wed, 15 May 1996 22:39:34 GMT Message-ID: <319a5d12.3840191@news.netspace.net.au> References: <4ncpnu$7to@grissom.powerup.com.au> fry@mail.powerup.com.au (Glen Fry) wrote: >I'm programming a small controller with forth in it's prom. The editors I >have been using create some sort of garbage in the files when saved hence the >programs won't download and hence compile. - Dos vi works just fine - but I >really need a good Win editor to allow pasting to my termional app.. PFE (Programmers File Editor) is the best. It was designed for programmers from the ground up. You can get it from its home page: http:://www.lancs.ac.uk/people/cpaap/pfe/ or from the large Windows software archive sites Regards Craig Findlay If all else fails, immortality can always be assured by spectacular error -- John Kenneth Galbraith From: Tom Zimmer Subject: Re: Suggestions for a good Windoze Editor Date: Wed, 15 May 1996 16:37:35 +0000 Message-ID: <319A084F.6B59@ix.netcom.com> References: <4ncpnu$7to@grissom.powerup.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Wed May 15 5:30:27 PM CDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Glen Fry wrote: > > I'm programming a small controller with forth in it's prom. The editors I > have been using create some sort of garbage in the files when saved hence the > programs won't download and hence compile. - Dos vi works just fine - but I > really need a good Win editor to allow pasting to my termional app.. Win32Forth includes as its development editor WinView a programmers editor with full cut, copy, paste capability. In fact WINSER.F a demo serial communications program included with Win32Forth has a very simple terminal program in it, that could be extended to interact as your host IDE for your embeded development. Its free of course, and available on the taygeta archive. From: Tom Zimmer Subject: Re: Low level window hooks? Date: Wed, 15 May 1996 16:45:31 +0000 Message-ID: <319A0A2B.365B@ix.netcom.com> References: <4nco3u$per@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Wed May 15 5:38:23 PM CDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Thomas Worthington wrote: > > I'm starting a 32-bit ANS style Forth and I want to make Windows > available, not as built in fuctions (I want a SMALL Forth not > another Win32Forth) but in the form of a low level gateway > system. All the docs I can find on Windows assumes that you are > working in a high level language. Since it is easy to get lists > of what paramiters Windows wants for each function, it would seem > reasonably easy to: > a) standardise the calling routine, and > b) write the various windows routines in otherwise ANS forth > to be loaded (even stored in blocks if you like!) as > required. What Win32Forth does, is create "on the fly" definitions for each window function referenced in your application. It does not automatically include all of them, though it did in an early version. The general technique is to look to see if a windows call is already defined, if it is, use it. If it isn't, then try to get its load address out of the list of known DLLs. If it is obtainable, then build a procedure call definition in the dictionary and resolve the reference to it. Building the procedure call must of course be defered until the current definition is finished compiling. Alternatively, you could require that the user define all the procedure calls they were going to use before referencing them, thus avoiding the forward reference problem. Win32Forth is very large, but its not because of the interface to windows procedure calls. Happy Windowing! Tom Zimmer From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Forth running under Windows 95 Date: 16 May 1996 02:55:07 +0200 Message-ID: <4ndudb$djp@iaehv.IAEhv.nl> I have ported iForth from Linux to (a 32-bit console) Windows 95 application. Since Forth vendors have suggested that Windows 95 has a huge overhead, resulting in their Forths running much slower than usual, I thought I'd run some tests. I'm using the benchmark suite developed to find out i486 / Pentium differences. The question was: Is there a difference between 1. iForth 1.06 under Windows 95, 2. iForth 1.06 under DOS 7.0 The exact same binary is used for these two Forths, the only difference is in their server code (gcc 2.7 for Linux, Borland C++ 4.5 for Win95). The server *should* not be important for the benchmarks as (almost) no I/O is performed. The full results are available at http://IAEhv.nl/users/mhx/forth.html. A summary follows. The strict average of all benchmark results says that Win95 is 9% slower than DOS 7.0. When the memory copy test is removed that figure goes to 17% slower. Two important results are even 40% below their DOS values, so quite a lot of cycles seem to be going down the GUI. The iForth server is build with Borland's C++ 4.5. I do not know if the Borland libraries set up a "cycle stealing scheme" to make Windows programming easier. I certainly notice strange delays in the input and output routines. I intend to go straight to the Win95 DLL's with the next server version, we'll see if that improves matters. -marcel Date: 15 May 1996 21:23:00 +0100 From: All@business.forth-ev.de (Wolfgang Allinger) Message-ID: <68uWD2Xb7QB@business.forth-ev.de> References: <4n987p$obc@hkusuc.hku.hk> Subject: Re: Announcement DOOF-0.1.2 On 14 May 96 in article <4n987p$obc@hkusuc.hku.hk> (Zsoter Andras) wrote: >I was thinking about a better name for DOOF. >If not, the next release will be called DynOOF. DynOFF sounds ok for german ears Bye bye by Wolfgang -- FORTHing @ work Cheap Fast Good ...pick any two of them Dipl.-Ing. Wolfgang Allinger Brander Weg 6 Voice/FAX [+49] [0] 212 / 66 8 11 D-42699 SOLINGEN eMail: all@business.forth-ev.de GERMANY ## CrossPoint v3.1 R ## From: dvrsn@bluefin.net (Diversion) Subject: Re: Z80 Fossils and rambling notions Date: 16 May 1996 00:31:54 -0400 Message-ID: <4neb3q$hc@dover-01-16.dialup.bluefin.net> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> Reply-To: dvrsn@nh.ultranet.com In article <4nagk6$mhn@ecuador.it.earthlink.net>, Elizabeth Rather wrote: >Compatibility is a double-edged sword. "Real" programmers hate it, but >the marketplace sure does love it ;-) > >No-one writing a program they hoped to sell or publish would want to restrict >it to a Pentium Pro. By they time "everyone" has one, there will be several >newer, better chips that you'll also want to run on! This is nice in theory, but the way it usually works (if you define Microsloth as 'usually') is you write the latest, greatest version of the app, and it is so abysmally slow on anything other than the latest, greatest hardware that (the latest, greatest hardware) that is what you market to. Although in theory it could run on older hardware, but no one does that. It also works the other way around: each new version of Intel's chips are compatible with the previous version so you can continue to run your old software and leverage your investment. But in order to get the best performance from your new hardware you have to upgrade all your software anyway, to get the P5 or P6 optimized version. And if you don't do that then you're "not getting optimal performance from your new machine." (So you get the new version optimized for your new hardware, which is bloated and ends up running at the same speed or slower, so you get faster hardware...) rant dup @ 1+ swap ! ( would 'rant @ 1+ rant !' be better?) Some of this (IMO) can be attributed to "modern" programming techniques. With a compiled language it becomes possible with hardware fast enough to simulate an interactive environment. Not too long ago I was wondering to myself (while going through edit->compile->edit... sessions, using multiple windows) how people used to do development effectively without having multiple windows. The answer is so blantantly obvious that it's easy to overlook. When people didn't have machines that could recompile and relink a 10000 line program in under a minute, they would actually think before coding. Maybe programming was better off when people submitted programs to be compiled and run overnight and didn't see the results for a day or two. rant dup @ 1+ swap ! Of course, compiled languages like C or C-- are inherently better than languages like FORTH or LISP that are by nature interpreted; even though the latter have much nicer interactive development environments, it's fairly easy to graft an interactive development environment to C or C-- with a fast machine and gobs of memory. Not to mention the fact that C-- is inherently better than C because it's object-oriented, so anything you write in it is also object-oriented, which is inherently better. 0 rant ! Well, enough ranting for now.. D From: Tom Zimmer Subject: Re: Announcement DOOF-0.1.2 Date: Wed, 15 May 1996 16:31:06 +0000 Message-ID: <319A06CA.7316@ix.netcom.com> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Wed May 15 5:23:57 PM CDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Zsoter Andras wrote: > > Well, I can do that (and a couple of other things) the problem is > that I really like to present my Forth to some end user as an > ``application language''. > > If even strings are handled in an accidental manner then a not-quite-a- > computer-jerk user will feel hmm, ``uncomfortable'' with the situation. It sounds to me like you are trying to stradle the fence on both side. Trying to be ANS and C compatible. There is such a difference between these two, I don't see how it can be done. You can never make everyone happy, just everyone miserable. Try to make yourself happy(er) at least. Tom Zimmer From: "Bruce R. McFarling" Subject: Re: Z80 Fossils and rambling notions Date: 16 May 1996 07:32:36 GMT Message-ID: <4nelmk$dr3@seagoon.newcastle.edu.au> References: <4n4s0l$ao6@yama.mcc.ac.uk> <4n561f$hu4@news1.delphi.com> <4n7rr3$941@columbia.acc.brad.ac.uk> <4n8toa$lgb@dfw-ixnews4.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) jmrubin@ix.netcom.com (Joel Rubin) wrote: >In article <4n7rr3$941@columbia.acc.brad.ac.uk>, cdahello@comp.brad.ac.uk >says... >>why would it? i don't call 256 registers particularly deficient... > Unless you want to consider zero page addresses to be registers, the > 6502 had A,X,Y,PC or IP and SP. Also, very zero-page addresses would > be free on most general-purpose 6502-based computers--most of them > would be used by the DOS or system ROM. For example: with the C64 'Kernal' and Basic ROMs in use, there are very few. But then, few serious C64 programs are in Basic, in which case there are about 130 available. As memory pointers or for a stack with 16-bit cells, that's 65, which isn't too shabby as far as the register situation goes. Of course, to make the zero page act more like registers by providing the zero-page and stack page in fast SRAM and access to the remaining memory from slower DRAMs requires a bit of extra handholding, but you gets what you pays for. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: RFI: execution tokens Date: 16 May 1996 08:24:42 GMT Message-ID: <4neooa$r9s@hkusuc.hku.hk> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> <4nccpu$lul@hkusuc.hku.hk> <3199F0AE.8E6@austin.finnigan.com> Andrew McKewan (mckewan@austin.finnigan.com) wrote: >Zsoter Andras wrote: >> >> [stuff deleted] >> >> Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so >> behaviour to a definition? No need to invent a name for it as "execution >> semantics" because it is not the semantics of IF anyway, but the semantics >> of the chunk of code inserted by IF into the definition. >> >Forth has always been a language of semantics rather that syntax. Other >languages would talk about an "if statement" or "do while loop" as a whole. IMHO we are talking about the same thing using different words! >I think the writers of the ANS standard tried to keep to "one word, one >definition" at the same time allow any type of language implementation. But when on Earth was it Forth philosophy to squeeze as much into one word as possible. >What if, instead, we went back to an "IF statement" type definition where we >deal with IF, ELSE and THEN all together. Something like: >"IF pops the top of the data stack. If it was zero, code execution begins >following the next matching ELSE or THEN. If it was non-zero, code ececution >continues following the IF." >This is exactly how you would explain it to someone, it is what is does, and >it can be implemented any-old-how. I agree. >If we want a standardized language that can be implemented as token threaded >or native code, we are going to have to stop playing all the tricks we have >learned to spice up our code. Our code should be simple and easy to >understand and unabmigious. Just because we have POSTPONE and COMPILE, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If we have POSTPONE and COMPILE, and we use them in a manner prescribed by a standard then why not? Andras From: regnirps@aol.com (Regnirps) Subject: Re: Z80 Fossils ... Date: 16 May 1996 00:50:30 -0400 Message-ID: <4nec6m$8e9@newsbf02.news.aol.com> Reply-To: regnirps@aol.com (Regnirps) Re: silly statements. If I thought you were being intentionally insulting I would say "blow it out your ass" but will assume for the moment that you are just being a jerk. I have been staring at the instruction set for about two months. If there are any load instructions that set processor status flags you will have to point them out. If there are any instructions that allow indexed addressing with a computed index without changing the base pointer you will have to point them out. If you can move IX or IY to the other double registers without doing it a byte at a time, you will have to point out how. From: Dallas Legan Subject: Re: Forth instead of JAVA (RFC) Date: Thu, 16 May 1996 02:40:06 -0700 Message-ID: References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <318E3F50.868@blue.nowcom.co.kr> <4mk3r4$kc3@dfw-ixnews4.ix.netcom.com> <4mouq6$sd0@ecuador.it.earthlink.net> <4nagsu$lja@webprod2.lehman.com> <4ncalm$lul@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: HB> HB> HB> From hbezemer@vsngroep.nl Thu May 16 01:20:19 1996 HB> Date: Wed, 15 May 1996 17:46:28 GMT HB> From: Hans Bezemer HB> Newsgroups: comp.lang.forth HB> Subject: Re: Forth instead of JAVA (RFC) HB> HB> h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: HB> HB> >You forget one aspect: Forth in itself is an application. HB> >IMHO in a Un*x environment a ``Forth for Un*x'' would be an excellent HB> >shell, for example. HB> >(Just that nasty problem thet ANS-Forth trings are not Un*x strings. :-((( ) HB> But it can be done without much trouble! For technical reasons I use HB> 0-delimited strings in my 4tH. But COUNT, TYPE, -TRAILING, etc. still work as HB> expected! HB> HB> >What I mean that Forth probably will not replace "C" in those systems HB> >but it can finds its place in a toolbox among, sh, awk and perl. HB> Agreed! HB> HB> Hans HB> HB> After reading "The UNIX Philosophy" by Mike Gancarz, I reached similar conclusions. UN*X is a networking, multitasking FILE operation system. (The original justification for creating it was to do word processing, surely a file operation if ever there was one.) The redirection and piping that were the heralded features of UN*X are the keystones of it's FILE operation nature. Things like awk and perl (and eventually C) are for writing particular operations to be done on the files. Forth fits in, as I view it right now, as a scripting language that really hits its stride in hardware oriented or constrained applications or where operations on files are largly irrelevent. When Forth programmers complain that the code they wrote with such painstaking attention to readability was rewritten several years later in C, what they are complaining about is that it falls in the typical life cycle of other Scripting Languages. The SL quickly proves that the problem can be solved, and does so in a manner that minimizes developement resources. Latter, when other priorities, like ready availability of nonspecialist programmers to maintain and fine tune performance become higher, they recode it in C and assembly. Sometimes, the SL fits the problem so well that this final stage is unnecessary, or is a definit step backwards in performance. The networking, file operation of UN*X makes the accumulation of more files of file operation tools almost an imperative, hence the steady code bloat it suffers from. Forth, to some extent, developed the notions behind UN*X 'alias', and MSDOS 'doskey' earlier, and in a more comprehensive and efficient manner, building a whole language around short, modular macros. The language that the programmer in Forth has available for writing Macros and compiler directives, unlike C, is a complete language with sequential, iterative and logical alternative flow control available, as well as the full set of operators the language normally has available. Hence, the language can transmute itself as needed without having to write a special preprocessor file operation, and simulates the ability of the human mind to alter it's beliefs, viewpoints, and knowledge as experience finds necessary. I believe this last point is part of the fascination of Forth. I hope that my painting things in broad brushstokes (and certain amount of Cyber/Psycho/Babble) of my current view of things (which have definite exceptions, they're just generalities) is not percieved as 'anti-Forth', but rather a viewpoint that sees things in harmony. Regards Dallas E. Legan P.O. Box 2099 Downey, CA 90242 U.S.A. (310) 862 - 4854 dlegan@heart.engr.csulb.edu aw585@lafn.org delii@sc.liberty.com From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Announcement DOOF-0.1.2 Date: 16 May 1996 10:09:27 GMT Message-ID: <4neusn$3ea@hkusuc.hku.hk> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> <319A06CA.7316@ix.netcom.com> Tom Zimmer (ZForth@ix.netcom.com) wrote: >It sounds to me like you are trying to stradle the fence on both side. >Trying to be ANS and C compatible. There is such a difference between ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Your observation is right but your wording is incorrect! It is not "C" compatible it is virtually any OS compatible. I know that some seriously believe that Forth should only be used in embedded controllers and it is a big NO-NO for the user to even know it was programmed in Forth but I think otherwise. I can declare that I am happy about something but that does not change the fact that we are pissing against the wind. [Well I appreciate that the ANS Forth way is superior, but so is metric system (everything is multiplied by 10-s so you don't have to remember how many cubic feet is a pint or vice versa). It seems that Americans chose the conservative way to comply to existing "standards". Why is it different with software? Anybody else is using a kind of string representation and we suddenly invent a superior one which just does not fit into anything. [Well, I am not so convinced about the superiority of the ANS strings anyway because they increase stack traffic.] What is even worse that the ANS Forth way of string representation was almost unprecedented inside the Forth community [apart from TYPE]. If a new idea had to be introduced why not one used by the "rest of the world"? Andras >these two, I don't see how it can be done. You can never make everyone >happy, just everyone miserable. Try to make yourself happy(er) at least. From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: backward compatibility (was: ..fossils..) Date: 16 May 1996 08:08:20 GMT Message-ID: <4nenpk$r9s@hkusuc.hku.hk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4ncv0t$9er@yama.mcc.ac.uk> Simon Read (s.read@cranfield.ac.uk) wrote: >It seems to me that FORTH goes with the second philosophy. In >practice, this meant that I was able to port one extremely >complex application (computer algebra) from a Z80 computer to an >ARM computer, with most of the worry revolving around whether the >serial port (to transfer the source code) would work or not. The >machine-dependent code was isolated in 3 blocks. Apart from that, >the code (over 100K of source code) ran unchanged. This was a >consequence of using FORTH. I am happy to read such comment here. There is always a debate that Forth is non-standard and you have to reinvent the wheel all the time, etc. In fact for me Forth was the first language that made the execution of a program I wrote on a C=64, on a PC possible. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Forth and RTOS, second posting Date: 16 May 1996 08:13:11 GMT Message-ID: <4neo2n$r9s@hkusuc.hku.hk> References: <832195369.AA00289@ear.co.at> Ewald Pfau (ehp@ear.co.at) wrote: >1. Tasking in Forth didn't make it into the ANS language specification. You may ^^^^^^^^^^^^^^^^^^^^^^^^^ >expect 'round-robin' tasking, as far as re-entrance in Forth is given at >selected entrance levels for task switching. Thanks God! Tasking is an *OS* concept not a language concept. It is just that many Forth-es happen to be OS-es on some embedded device. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: RFI: execution tokens Date: 16 May 1996 08:34:09 GMT Message-ID: <4nepa1$r9s@hkusuc.hku.hk> References: <19960513132751.aaaa006Xv@babyblue.cs.yale.edu> <4n98d1$obc@hkusuc.hku.hk> <4n9lcq$hi3@dfw-ixnews7.ix.netcom.com> <4na0f7$huj@hkusuc.hku.hk> <4na9af$nfm@dfw-ixnews6.ix.netcom.com> <4nccpu$lul@hkusuc.hku.hk> <4ncsh0$1aq@dfw-ixnews4.ix.netcom.com> <4nd4f5$epm@ecuador.it.earthlink.net> Elizabeth Rather (erather@forth.com) wrote: >JEThomas@ix.netcom.com (Jonah Thomas) wrote: >>In <4nccpu$lul@hkusuc.hku.hk> h9290246@hkuxa.hku.hk (Zsoter Andras) writes: >> >>>Why don't we just say, that IF (THEN, ELSE, REPEAT, etc.) add so and so >>>behaviour to a definition? No need to invent a name for it as "execution >>>semantics" because it is not the semantics of IF anyway, but the semantics >>>of the chunk of code inserted by IF into the definition. >> >>Looking back, I think you're right. People have been confused about it here, that >>means the present terminology is confusing. >That was the way things stood (no special term) for quite a while, until we became >sick of saying, "you know, that stuff compiled by IF, WHILE, REPEAT, etc." and >found a nice(er) shorthand. And in response to Andras' comment that we should have >just given "the word" a name, that doesn't work for implementations that aren't ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >compiling "a word" there, but an actual branch, multiple words, etc. Not to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is not 100% true. A word can be "conceptually" there without having a physical representation. E.g.: SWAP, DROP, DUP etc. can be inlined on a native code generating system. After an optimization the machine instructions might not even resemble the original Forth words, but the result is "as if" those operations have been carried out in that order. Why is it so different with IF or 0BRANCH? Andras From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Forth and RTOS, second posting Date: 16 May 1996 11:52:18 GMT Message-ID: <4nf4ti$o67@majipoor.cygnus.com> References: <832195369.AA00289@ear.co.at> <4neo2n$r9s@hkusuc.hku.hk> Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: : Ewald Pfau (ehp@ear.co.at) wrote: : >1. Tasking in Forth didn't make it into the ANS language specification. You may : ^^^^^^^^^^^^^^^^^^^^^^^^^ : >expect 'round-robin' tasking, as far as re-entrance in Forth is given at : >selected entrance levels for task switching. : Thanks God! Tasking is an *OS* concept not a language concept. That's nonsense! Many programming languages over the years have had concurrency as a built in language structure rather than as an OS feature. Burroughs Algol, Concurrent Pascal, Occam, Ada, and (classical) Forth are examples. It's a very useful feature that is sadly lacking in Standard C. Andrew. From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: Announcement DOOF-0.1.2 Date: 16 May 1996 13:18:43 +0200 Message-ID: <4nf2uj$75p@ite127.inf.tu-dresden.de> References: <4n987p$obc@hkusuc.hku.hk> <4ncad5$lul@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: h9290246@hkuxa.hku.hk's message of 15 May 1996 10:07:33 GMT >>>>> "Zsoter" == Zsoter Andras writes: Zsoter> Well, someone have already suggested Food, is this name Zsoter> really *that* good? I guess I was that someone. Here's my reasoning: A four letter abbreviation is not as good as a TLA and FOOD preserves both the letters as well as most of the ordering between them and is easily pronounced (most people even know the proper pronounciation if they don't know english). It doesn't mean anything nasty in some widely used language, as far as I know, and can be un-abbreviated to something meaningful with ease (although I admit that it didn't preserve the ``dynamical'' for the ``D''). OOD already has a meaning which would make it look interesting to those OO guys (they don't care as much about languages as other folks do as long as it is OO). I thought that would give the name some more leverage. If you don't like the name, don't use it. It's your call. I for my part could live with DOOF (although I would have to be careful if I talk about it in german ;) and I don't like DynOOF for the simple reason that I cannot figure out how to pronounce it without sounding wierd. It all boils down to a matter of taste. Come to think of it, since DOOF stems from OOF, D-OOF is the least intrusive change you can make to defuse the issue with the awful german language (this is of course taken from M. Twain). -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/ E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: Announcement DOOF-0.1.2 Date: 16 May 1996 13:39:38 +0200 Message-ID: <4nf45q$75t@ite127.inf.tu-dresden.de> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: h9290246@hkuxa.hku.hk's message of 13 May 1996 12:06:52 GMT >>>>> "Zsoter" == Zsoter Andras writes: Zsoter> My original idea was to put a wrapper around DOOF. BUT: Zsoter> If the functionality of Tk is available as shared Zsoter> libraries (I have never used it so I might be wrong) one Zsoter> can program it directly in Forth. No need to "touch" the Zsoter> system, DOOF can use the ELF shared libraries. (I guess Zsoter> the comment I received about Tcl/Tk in this thread has Zsoter> referred to this option.) I think so, this is what comes with DoomArena for example: libtcl.so.7* libtclutil.so.1* libtk.so.4* libtkutil.so.1* Zsoter> Another question: It seems that the ANS-Forth standard is Zsoter> pissing against the wind by declaring that a sting is Zsoter> represented by its address and length. All OS-s (Unices, Zsoter> Windows, even some parts of DOS) use C style strings, Zsoter> terminated by a '\0'. For me it is a real pain that I have Zsoter> to conform to both standards. Nobody else feels the same? Pascal and FORTRAN have counted strings too. The consensus of implementions of these languages on UNIX'en seems to be that you append the '\0' whenever possible and have the count anyway. BTW, there are few places in C where you work on counted strings rather than on null-terminated. Also Motif has a completely different string model. -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/ E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: Commodore 64 Nostalgia (was Re: ANS Forth question ) Date: 16 May 1996 13:46:00 +0200 Message-ID: <4nf4ho$75u@ite127.inf.tu-dresden.de> References: <4m6fil$kvp@argentina.it.earthlink.net> <4mbtvq$3ge@seagoon.newcastle.edu.au> <831502382snz@mpeltd.demon.co.uk> <4mou1o$sd0@ecuador.it.earthlink.net> <4mseen$k91@seagoon.newcastle.edu.au> <4mt51f$jep@myst.plaza.ds.adp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: znmeb@news's message of 9 May 1996 16:03:59 GMT >>>>> "Ed" == Ed Borasky writes: Ed> One other note about the 1541: it contained a fully-functional Ed> 6502 with 4K of RAM and you could run code in this 6502 if Ed> your 1541 was otherwise unoccupied. It was a little small for Ed> FIG-FORTH, but you could certainly load the kernel and a Ed> little bit of a dictionary into it and treat it as a Ed> co-processor. I heard a story, possibly apocryphal, about Ed> someone who was using a 1541 disk drive as an attached Ed> floating point co-processor; the code was written in assembler Ed> but he was a Forth programmer. I used the 1541 to compute Mandelbrot sets (it has a 2 MHz clock instead of just 1 MHz, so this really screams ;). I never finished a project that would have expanded the memory on the 1541 to 64k, so I could run a database engine in it. My C64 died and I couldn't be bothered to buy another one ... -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/ E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: Mike Plummer Subject: Re: Suggestions for a good Windoze Editor Message-ID: <319B1A14.3F54BC7E@apg.philips.co.uk> Date: Thu, 16 May 1996 12:05:40 GMT Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: <4ncpnu$7to@grissom.powerup.com.au> Mime-Version: 1.0 X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m) Glen Fry wrote: > > I'm programming a small controller with forth in it's prom. The editors I > have been using create some sort of garbage in the files when saved hence the > programs won't download and hence compile. - Dos vi works just fine - but I > really need a good Win editor to allow pasting to my termional app.. > > Any suggestions? > > Thanks > Glen Fry At the risk of starting yet another "my editor is bigger than yours argument :-)", what about MicroEmacs for Windows. I think you need to search for mewin.zip or something similar. Mike -- -------------------------------------------------------------------- Mike Plummer. Specialist Engineer, Multimedia Systems Group Advanced Projects Group, Philips Elec. Redhill, Surrey UK RH1 5HA Phone: +44 (0)1293 81 5235 Fax: +44 (0)1293 81 5050 Email: plunger@apg.philips.co.uk SERI: plummer:prlhp0 Compuserve: 100137,3545 The truth is out there. Trust no one. -------------------------------------------------------------------- From: h9290246@hkuxb.hku.hk (Zsoter Andras) Subject: Re: Announcement DOOF-0.1.2 Date: 16 May 1996 15:00:16 GMT Message-ID: <4nffu0$i7d@hkusuc.hku.hk> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4nf45q$75t@ite127.inf.tu-dresden.de> Achim Gratz (gratz@ite.inf.tu-dresden.de) wrote: >>>>>> "Zsoter" == Zsoter Andras writes: >I think so, this is what comes with DoomArena for example: >libtcl.so.7* >libtclutil.so.1* >libtk.so.4* >libtkutil.so.1* If there are such tools around are there any experts who want to play with them in Forth. (I am too busy at the moment, but it sounds very interesting. We could have a complete GUI for Forth in a few days.) Andras From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Forth GUI Date: 17 May 1996 22:28:50 +0200 Message-ID: <4nini2$b00@iaehv.IAEhv.nl> References: <4nhevm$kig@iaehv.IAEhv.nl> <4ni56s$b0l@hkusuc.hku.hk> Andras Zsoter wrote Re: Forth GUI >>editor with history, macros and partial completion). Multiple windows for >>all source files and documention, a few windows for the graphic output of the >>running program. The operating system tools like editor, grep etc. must be >>available from within Forth. > >Here I have to disagree. > >box, and I am quite happy about it. Why should a text editor be >integrated into Forth, or vice versa? >I am quite happy to use vim (an improved version of vi) to write >virtually anything I need, including my Forth source code, LaTeX >source code and .html files. >Of course you can start vi from Forth, or Forth from vi but why do you >need that? Because a minimum of communication is needed between the programs. I just want to type EDIT in Forth to start the system editor (I use joe). Which editor is started, and how, is regulated with preference files. Most editors can be directed to a certain line and cursor position, so Forth can jump in a file to the spot where an error was detected. >>- a feature in the commandline editor where you can pipe a text through an >> external command an re-insert in the type-ahead buffer ( a useful >> command is for instance trn [a-z] [A-Z] or dir h*.frt). > >This can be added as an external program. >Eg. DOOF can quite well read from its standard input or you can >install whatever device you wish as its "terminal", so a program >which does that could communicate with it via a pipe. >(Does not Tcl have some of these capabilities?) Yes, of course an external program can do it. A pipe is just what is needed here. However, when you try it I bet you will find details that will keep you busy for a few days. That is the reason that I don't have it yet. Tcl/Tk can do everything you want. Unfortunately, it is still a lot of work, and when finished it gives the writer *less* power than there was before. >- An HTML-aware editor to web and weave your source code and documentation > together. The HTML formatting codes should be invisible, when possible > (one might misuse unicode here :-)) > What does an HTML editor have to do with Forth???? Nothing in particular (What has a GUI got to do with Forth????). I'd love to have an editor that allows to write documentation and Forth code together. But HTML codes will confuse Forth, and they will certainly confuse ME when writing programs. Maybe the solution is intelligent data, changes to source code automatically change the HTML on-line document, the glossary etc. (and vv of course). Maybe this already exists... > Andras -marcel From: wuja@ms2.hinet.net () Subject: eforth 2.0 Date: 16 May 1996 21:14:19 GMT Message-ID: <4ng5rb$9m1@netnews.hinet.net> NNTP-Posting-User: wuja Dear Forth Interestor: Can anyone tell me where to get eforth 2.0 ? Thank you! Wuja 5/16/1996 email: wuja@ms2.hinet.net From: Thomas Worthington Subject: Re: Low level window hooks? Date: 17 May 1996 15:19:00 GMT Message-ID: <4ni5d4$p91@mercury.kingston.ac.uk> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> <319A4D44.40FB@austin.finnigan.com> <4nfid2$dve@mercury.kingston.ac.uk> <319BA266.6D0D@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) Tom Zimmer wrote: >I have heard others say that Win32Forth is not ANS standard, but >I sure wish someone would be more specific so I could fix >whatever incompatibilities exist. > >Tom Zimmer Since you ask, the locals handling and the input of floats are the two things which spring to mind at the moment, but that's not my main issue with Win32Forth. _Part_ of the point of a standard is to be able to load up and find yourself in an environment which is either: not falling down with words that you don't know the function of, or documented for those functions which are not standard, preferably with instructions on how to implement the new words on other compilers using only standard words. Obviously the whole windows section is an evironmental dependancy which can't be avoided but what about objects, for example? It's no use to me to write object orientated code if it's not portable. I repeat: I think Win32Forth is a good thing, I just don't think its the way to produce code if you want to use it on another platform. Sure, you can just ignore all those non-standard words and be left with a close approximation of the standard but this prompts the question that all fat systems must answer: `what is all that extra stuff doing taking up memory I could be working with?'. The failure to even address this question is a trend in computing which has led to more wastage of memory and processor cycles than anything else in the last ten years. Relax, don't take things personally, it's mainly a matter of taste in the end. Well, that's what I think. Thomas Worthington From: Tom Zimmer Subject: Re: Low level window hooks? Date: Fri, 17 May 1996 17:26:15 -0500 Message-ID: <319CFD07.7888@ix.netcom.com> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> <319A4D44.40FB@austin.finnigan.com> <4nfid2$dve@mercury.kingston.ac.uk> <319BA266.6D0D@ix.netcom.com> <4ni5d4$p91@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Thomas Worthington wrote: > > Tom Zimmer wrote: > >I have heard others say that Win32Forth is not ANS standard, but > >I sure wish someone would be more specific so I could fix > >whatever incompatibilities exist. > > Since you ask, the locals handling Win32Forth supports exactly the standard way of using local variable as far as I know. That is "LOCAL| name |" I just don't use the standard way of using them, instead prefering the stack picture version. > and the input of floats are > the two things which spring to mind at the moment, I guess I don't know about this, i'll have to check. I don't actually use floating point for much. I can say that floating point was implemented by Robert Smith, and I have trouble believing he would have not implemented it as ANS standard. > but that's not > my main issue with Win32Forth. _Part_ of the point of a standard > is to be able to load up and find yourself in an environment > which is either: not falling down with words that you don't know > the function of, or documented for those functions which are not > standard, preferably with instructions on how to implement the > new words on other compilers using only standard words. We would all like to have things we can't have. I would like this too, just don't have the time. Though there are at least two people I know that are working on tutorials for Win32Forth. > Obviously > the whole windows section is an evironmental dependancy which > can't be avoided agreed. > but what about objects, for example? It's no use > to me to write object orientated code if it's not portable. Well you could implement your own ANS standard OOP programming system on top of some Forth, but the performance would likely be terrible. And the portability of the window interface code would be no more porable than it is in Win32Forth. > I repeat: I think Win32Forth is a good thing, I just don't > think its the way to produce code if you want to use it on > another platform. I tend to agree. If you need portability of code for a particular application, then you would almost certainly need to implement your own generic GUI and hide the details of the target operating system beneath it. But then that would be much more work than just interfacing to a particular operating system. In fact, I would suggest that no one outside of a large company would likely have either the resources or the mandate to evenb try to accomplish such a thing. And even if they did, they might have trouble getting programmers interested in using their solution since it wouldn't match the methodologies used in sombodies 'C', or somebodies Basic. Of course when Java (or whatever) becomes the standard, then we can implement a Forth that uses Java for all its graphics, and we will have an inter platform standard that will make it easy to produce portable code. Till then, I think platform specific implementations are going to be with us for qhite a while. > Sure, you can just ignore all those > non-standard words and be left with a close approximation of the > standard but this prompts the question that all fat systems must > answer: `what is all that extra stuff doing taking up memory I > could be working with?'. Of course all those extra words are just taking up space until you have a need for their functionality. Of course it is intimidating to start up a Forth system that has 5000 words in it, of which only a few hundred ANS words are documented. Win32Forth was implemented by Andrew, myself, and others to perform a specific task, which it has done very well. It has helped in no small way to make my company in excess of 30 million dollars in the last year. Does that make it a product, no of course not. Does that make it useful to you, maybe not, but others may not agree with you. > The failure to even address this > question is a trend in computing which has led to more wastage of > memory and processor cycles than anything else in the last ten > years. I will say again, that Win32Forth was designed for the "exploration mentality" that is, it is tuned for someone who knows a relatively small set of utilities and knows how to use them to explore the system to discover the information they need. There is documentation on those tools, accessible from "F1" after Win32Forth starts up. > Relax, don't take things personally, it's mainly a matter of > taste in the end. I am (relatively) relaxed. I just wonder how many of your opinions will be the same after spending the next two years trying to solve the same problems. Tom Zimmer From: "Bruce R. McFarling" Subject: Re: Announcement DOOF-0.1.2 Date: Sat, 18 May 1996 16:36:49 -0700 Message-ID: <319E5F11.4BF4@cc.newcastle.edu.au> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> <319A06CA.7316@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Tom Zimmer wrote: > > Zsoter Andras wrote: > > If even strings are handled in an accidental manner then a not-quite-a- > > computer-jerk user will feel hmm, ``uncomfortable'' with the situation. > It sounds to me like you are trying to stradle the fence on both side. > Trying to be ANS and C compatible. There is such a difference between > these two, I don't see how it can be done. You can never make everyone > happy, just everyone miserable. Try to make yourself happy(er) at least. Even in C, I have always found it convenient to have functions that operate on strings of length specified in the function call as well functions that operate on null-delimited strings. I call the first 'text' functions and the second 'string' functions, and normally when I add an operation to my set of string or text functions, I add the corresponding function of the other type, just in case I need it in the other context. As long as you are consistent, I do not think there is anything to make the user 'uncomfortable' to say: "For operations that access the operating system, format the information as 'strings' (or whetever you have chosen to described the null-delimited variety). For your own use, you have the choice to use either string or text information." As far as I understand it, there is nothing in the standard that prohibits providing null-delimited versions of ANS standard operations that rely on counted strings. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "Paul E. Bennett" Subject: Re: Forth and RTOS, second posting Date: Fri, 17 May 96 21:49:56 GMT Message-ID: <832369796snz@tcontec.demon.co.uk> References: <3198CE17.5260@abc.se> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <3198CE17.5260@abc.se> mattias.waldau@abc.se "Mattias Waldau" writes: > I got no respons at all to my previous posting, thus I am posting it > again. If there are still no reponses I assume that no one is doing > embedded systems using Forth :-) Busy last time you posted this but I'll respond now. > Do people that do embedded systems using forth use anything more than > 1. Multitasking, and > 2. The ability to put forth-code in an interrupt handler. For a lot of systems I have had a hand in, interrupts were a problematic risk area that was best disabled and rendered harmless for the processor concerned. Limiting what you do in one processor does have some benefits and if the processor is cheap enough then more can often be a help in getting a system up and running. Many of the embedded systems have between 3 and 6 task threads on a round robin. > Is there a RTOS-package? Forth. > Typical RTOS features > 1. I do not need/want pre-emptive tasking > 2. I want to pass data using messaging > 3. I want semaphore > 4. I want syncronious and asyncronious communication > 5. Time management, i.e. delay for 100 msec With the right simple hardware selection all of 2 to 5 are relatively easy. For item 1, round robin scheduling is quite robust and fair. Just remember to put some pauses in the compute intensive tasks. Time delays are best run from a simple long counter chain (with reads of time rendering a natural binary representation of the 24 hour clock [32 bits]) and fairly fine granularity of ticks. Multi-tasked delays need local storage space to save the initial or limit time for the check. This is quite easy to provide. For communications facilities, if the processor is slow add the hardware, if the processor is ultra-fast and efficient at running Forth and has suitable interface logic you may have the option to do software comms if you want to. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: "Paul E. Bennett" Subject: Re: backward compatibility (was: ..fossils..) Date: Fri, 17 May 96 22:13:08 GMT Message-ID: <832371188snz@tcontec.demon.co.uk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4ncv0t$9er@yama.mcc.ac.uk> <4nenpk$r9s@hkusuc.hku.hk> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4nenpk$r9s@hkusuc.hku.hk> h9290246@hkuxa.hku.hk "Zsoter Andras" writes: > Simon Read (s.read@cranfield.ac.uk) wrote: > > >It seems to me that FORTH goes with the second philosophy. In > >practice, this meant that I was able to port one extremely > >complex application (computer algebra) from a Z80 computer to an > >ARM computer, with most of the worry revolving around whether the > >serial port (to transfer the source code) would work or not. The > >machine-dependent code was isolated in 3 blocks. Apart from that, > >the code (over 100K of source code) ran unchanged. This was a > >consequence of using FORTH. > > I am happy to read such comment here. > There is always a debate that Forth is non-standard and you have > to reinvent the wheel all the time, etc. > In fact for me Forth was the first language that made the execution of > a program I wrote on a C=64, on a PC possible. Forth has saved me a lot of hear tearing too many times for me to discard it's use now. I got involved on a project just as it was coming up to factory test stage. The equipment (a pick and place crane) had been installed on the factory floor, wired up and was just beginning it's test procedures. Testing stopped very quickly and several engineers scratched their heads when the Main Contactor failed to stay energised. The crane was being controlled from a PC running a programme (in BASIC) which was meant to simulate the mainframe computer system the crane would eventually be hooked up to. The problem seemed to be due to incompatibilities in the protocol timing. I took a copy of the protocol spec home and within 6 hours had the protocol running between a BBC MIcro (with JBForth) and a PC Laptop (with MPE's WorkForth). Having checked that I had implemented the protocol specification correctly I was armed with a useful tool for diagnosing the problem. It turned out that not only was the BASIC simulator programme incorrect in it's interpretation of the protocol but the communications timing was adrift on the PLC at the other end of the link. The JBForth and MPE WorkForths were sufficiently compatible for me to run either end of the protocol on either machine in simulation tests. I therefore ended up with two tools for the price of one. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: "Bruce R. McFarling" Subject: Re: Z80 Fossils ... Date: Sat, 18 May 1996 20:32:17 -0700 Message-ID: <319E9641.5929@cc.newcastle.edu.au> References: <4nec6m$8e9@newsbf02.news.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Regnirps wrote: > > Re: silly statements. > [snip] C'mon, calm down. This is a Forth newsgroup, and I think the reference to the way things are done in the fig-Forth implementations for both processors was pertinent. Much as I feel affection for the 6502, I don't see any point in a 6502 v Z80 flame war -- especially in this forum!! > I have been staring at the instruction set for about two months. If > there are any load instructions that set processor status flags you will > have to point them out. If there are any instructions that allow indexed > addressing with a computed index without changing the base pointer you > will have to point them out. If you can move IX or IY to the other double > registers without doing it a byte at a time, you will have to point out > how. I think this was the point: to accomplish the same goals on a Z80, rather than emulating the specific tasks that you would use on the 6502, you have to go about specifying tasks that are appropriate to the Z80. And the best way to find out is not by staring at the instruction set, but by looking at how assembly language programmers accustomed to the Z80 design their code. Some things are easier, some things are harder, some things are slower, some things are faster. Like, wouldn't it be nice if there was an direct 16-bit add in the 6502 to speed up multiplication? Not to mention (but I already did), this really isn't the place for a pure 6502 vs Z80 argument! Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: "Bruce R. McFarling" Subject: Re: ANS Forth question Date: Sat, 18 May 1996 21:04:30 -0700 Message-ID: <319E9DCE.2FA0@cc.newcastle.edu.au> References: <4m6fil$kvp@argentina.it.earthlink.net> <4mbtvq$3ge@seagoon.newcastle.edu.au> <831502382snz@mpeltd.demon.co.uk> <4mou1o$sd0@ecuador.it.earthlink.net> <832272254snz@mpeltd.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Stephen Pelc wrote: > Ah, just a conventional disk cache ... :-) However, what about > the point that the programmer can make *no* assumptions about > the persistence of the the disk buffer *after* BLOCK has been > called again? If there is a cooperative multi-tasker, BLOCK is one of the obvious places to PAUSE. If there is no assumption that an old BLOCK address is valid after BLOCK has been called again, then no problem (well, not much problem) on that front. OTOH, if you want buffers to do with as *you* want, instead of as the system wants, alloc the memory and design some buffer handling. Then the systems that cannot give you that much memory can complain in the normal way and you find out at a well-defined point in the sequence of operations, rather than when you hit the extent of available BLOCK buffers (which, by Murphy's Law, will not only be an unexpected point in the sequence of operations, but also a point where it is hard to tell what is the source of the problem). Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: graham@genesis.netgates.co.uk (Graham Willmott) Subject: Re: AMPLE (Music programming language)? Date: 18 May 1996 10:04:32 GMT Message-ID: <4nk7bg$5va@genesis.netgates.co.uk> References: <4n4n7v$k40@lyra.csx.cam.ac.uk> Reuben Thomas (rrt1001@cus.cam.ac.uk) wrote: : I recall a language called AMPLE, which was Forth-like. It was used for : writing music. Can anyone point me in the direction of a description, as : I'd like to implement something similar? What you need is the Music 5000 AMPLE Nucleus reference; the best way to get it is probably to buy an old Music 5000 from somewhere. Note for c.l.f people: The Music 5000 was a rather nice sound synthesis box which connected to the good old BBC Micro. It came with a FORTH-like language, which, though modified to be both musically useful and understandable to the beginner, nevertheless had many unexpected features. For example, it allowed you to multithread on a 1981 6502-based computer with 32K of RAM, and used that facility to let you program voices as if they were independant members of an orchestra. Also: it allowed you to write programs in a modular fashion with dynamic linking and unlinking - something pure FORTH has never been really good at. In some respects it was even a little object-oriented - all sound was produced by passing messages to voice modules. -Graham From: "Jean-Francois Brouillet" Subject: Re: SOD32 Forth Date: 18 May 96 14:16:45 +0200 Message-ID: References: <4n013i$k7e@Venus.mcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Cyberdog/1.0 X-News-Servers: news.micronet.fr X-Newsgroups-TO: nntp://news.micronet.fr/comp.lang.forth >After surfing the net the other day, I ran across a Forth interpreter >called SOD32, by L.C. Benschop. I have not really done any sort >of testing with this, but I was impressed with this very much upon >first encounter. > >I was really wondering if anyone has heard of this Yes. I used it (and its virtual machine implementation) as the basis of my own forth toy implementation. Maybe not the fastest forth ever, but clearly the most understandable I found. It even includes so-called "meta"- compilation. >and if they >know how to contact the author (as there was no mention of how >to contact him in the package.) Sorry, but no pointers here... --------------------------------------------------- This message was created and sent using the Cyberdog Mail System --------------------------------------------------- From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Low level window hooks? Date: 18 May 1996 12:53:45 GMT Message-ID: <4nkh8p$le6@hkusuc.hku.hk> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> <319A4D44.40FB@austin.finnigan.com> <4nfid2$dve@mercury.kingston.ac.uk> <319BA266.6D0D@ix.netcom.com> <4ni5d4$p91@mercury.kingston.ac.uk> Thomas Worthington (K956974@crystal.king.ac.uk) wrote: > Since you ask, the locals handling and the input of floats are >the two things which spring to mind at the moment, but that's not >my main issue with Win32Forth. _Part_ of the point of a standard >is to be able to load up and find yourself in an environment >which is either: not falling down with words that you don't know >the function of, or documented for those functions which are not >standard, preferably with instructions on how to implement the >new words on other compilers using only standard words. Obviously I guess if we restrict ourselves by the standard we will end up with a lot of identical looking brain-damaged systems. I don't mean that that STANDARD is brain-damaged but it is a common denominator, a set of words which supposed to be supported by every implementation. In a Unix a word like FORK makes very much sense and all Unix programmers should know what it is meant for, but how you give "instructions on how to implement" FORK on a DOS-based system? (Sorry for not giving a Win32Forth example I cannot even start up that one on my old Win3.1.) Or do you mean that a Forth implementation should support the Standard but nothing else? What about PC@ and PC! (they are not in the standard). How could anyone control hardware on most of the microprocessors using standard words only? Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Low level window hooks? Date: 18 May 1996 13:14:54 GMT Message-ID: <4nkige$le6@hkusuc.hku.hk> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> <319A4D44.40FB@austin.finnigan.com> <4nfid2$dve@mercury.kingston.ac.uk> <319BA266.6D0D@ix.netcom.com> <4ni5d4$p91@mercury.kingston.ac.uk> <319CFD07.7888@ix.netcom.com> Tom Zimmer (zforth@ix.netcom.com) wrote: >Well you could implement your own ANS standard OOP programming >system on top of some Forth, but the performance would likely be >terrible. And the portability of the window interface code would >be no more porable than it is in Win32Forth. I guess it is a childhood disease of Forth that everyone tries to hack some kind of OOP on the top of an already running system and then complains about its inefficiency. OOP should be supported by the kernel (Oh, we only should agree which OOP, my worst nightmare is that one day there will be OOP support in the standard and I have to support that one on the top of my OOF style just like I have to support CONVERT, #TIB an the like. The only problem is that even one OOP is complicated enough in one system not two or three incompatible ones.). >I will say again, that Win32Forth was designed for the "exploration >mentality" that is, it is tuned for someone who knows a relatively >small set of utilities and knows how to use them to explore the >system to discover the information they need. There is documentation >on those tools, accessible from "F1" after Win32Forth starts up. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you mean the system documentation which comes with Windoze I agree. I find it quite ridiculus that people expect every documentation to come with a compiler (maybe Borland and M$ made them think that way). The "how do I display a window with a menu bar" is not a language feature but a service of the OS. It does not belong to the definition of the C, Pascal, or Forth language. As long as the names are standard (I don't mean ANS Forth standard, but Windoze standard) in a compiler/library their original definition + some conventions (eg. how do you pass certain types of parameters from Forth) would do. I think the documentation of such services do not belong to the documentation of a Forth implementation using them, but really to the documentation of the OS. (In the Un*x world people are expected to find such things in man pages, and even worse, if they dare to ask about them in a "C" newsgroup they get flamed. Why should this be different with Forth?) Andras From: "Bruce R. McFarling" Subject: Re: Announcement DOOF-0.1.2 Date: Sat, 18 May 1996 23:10:33 -0700 Message-ID: <319EBB59.4EAF@cc.newcastle.edu.au> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> <319A06CA.7316@ix.netcom.com> <4neusn$3ea@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Zsoter Andras wrote: > What is even worse that the ANS Forth way of string representation > was almost unprecedented inside the Forth community [apart from TYPE]. > If a new idea had to be introduced why not one used by the "rest of the > world"? But this is the strongest argument *for* address & count strings! No matter how the string is represented out in memory (pre-counted by byte, pre-counted by word, pre-counted by variable length integer, null delimited FFh delimited -- well, whatever) if it can fit inside a memory space that can be addressed by a cell-wide pointer, it can be referred to by a cell-wide pointer and cell-wide count. It's not an accident that even though the normal 'string' is null-delimited, the ANSI C string library contains standard functions to handle ANS-Forth style strings: char *strncat(char *str1, char *str2, size_t n); int strncmp(char * str1, char *str2, size_t n); char *strncpy(char *str1, char *str2, size_t n); And this is *with* a pre-existing norm for null-delimited strings. *Without* a single pre-existing norm, how could the standards committee square its effort not to break existing implementations with a standardization on null-delimited strings? If the space for the nulls was not allowed for when a wordset was designed, and it was designed on the presumption that existing texts could be read as strings without requiring an additional memory, how does the committe *know* whether or not converting it to null-delimited strings is easy or hard? When, on the other hand, we do know that at worst a null-delimited string can be counted for use with base & count type string words. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Announcement DOOF-0.1.2 Date: 18 May 1996 15:36:37 GMT Message-ID: <4nkqq5$r51@hkusuc.hku.hk> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> <319A06CA.7316@ix.netcom.com> <4neusn$3ea@hkusuc.hku.hk> <319EBB59.4EAF@cc.newcastle.edu.au> Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: >strings. *Without* a single pre-existing norm, how could the standards >committee square its effort not to break existing implementations with This part is the hardest for me to understand, I mean "not to break existing implementations". Pre-ANS implementations are not ANS, period. Whatever is implemented after the ANS standard can be implemented so as to comply to the standard. I guess I am making an excuse with the null-terminated strings to complain against the standard because I simply hate the idea of representing something which as ONE entity as TWO cells on the stack. And the only way out is to require to copy the sting to a temporary buffer which will solve the problem (eg. put a count before the string and put a 0 at the end and you have something usable in all situations). (Even worse that the FILE wordset REQUIRES that the string is copied to a temporary buffer. I had trouble a couple of times when a have tried to rename a file in a manner like: S" name1" S" name2" RENAME-FILE with not quite the right effect. So the standard not just chose an implementation which is somehow clumse on the grounds that "you don't need a temporary buffer" but even negated this effort by requiring the use of a temporary buffer. :-((((((((((( ) >on the other hand, we do know that at worst a null-delimited string can >be counted for use with base & count type string words. But a counted string cannot be made null-terminated without pain. This supports my point that null-terminated strings should be the default because you can always convert them to counted ones if necessary but not vice versa! Andras From: rrt1001@cus.cam.ac.uk (Reuben Thomas) Subject: Re: SOD32 Forth Date: 18 May 1996 17:24:21 GMT Message-ID: <4nl145$4mo@lyra.csx.cam.ac.uk> References: <4n013i$k7e@Venus.mcs.com> In article , Jean-Francois Brouillet wrote: >>After surfing the net the other day, I ran across a Forth interpreter >>called SOD32, by L.C. Benschop. I have not really done any sort >>of testing with this, but I was impressed with this very much upon >>first encounter. >> >>I was really wondering if anyone has heard of this I used it to compare against my own virtual machine (rather more conventional, using byte codes). I thought it nice, too, but it seems rather slow as a result. >>and if they >>know how to contact the author (as there was no mention of how >>to contact him in the package.) I've tried looking at the original posting to comp.sources.misc and contacting his university, but no luck (I was trying to get a reference for my dissertation about my machine). Incidentally, the papers about my system are available on my web page, although the source code isn't at the moment. With a little effort I could put it up if people are interested; although it doesn't use config or anything fancy like that, it is highly portable (I've compiled it on SunOS, DEC BSD, MS DOS and RISC OS) and easy to adapt to a new system (though, alas, it's written in C). It comes with an ANSI Forth compiler. -- Web page: http://www.cl.cam.ac.uk/users/rrt1001/ From: regnirps@aol.com (Regnirps) Subject: Re: Z80 Fossils ... Date: 18 May 1996 14:42:22 -0400 Message-ID: <4nl5me$fne@newsbf02.news.aol.com> References: <319E9641.5929@cc.newcastle.edu.au> Reply-To: regnirps@aol.com (Regnirps) >Not to mention (but I already did), this really isn't the place for >a pure 6502 vs Z80 argument! How did it get to be a Z80/6502 thing? All I said was I was looking at reams of "legacy" code and Z80 for the first time and gave a list of things the Z80 does not do. Some one responded that I was being silly, as if I was wrong and it really does these things. Well, I looked through again, and it doesn't. The 6502 was just an example of a processor with indexing addressing modes. This has been eye opening though in understanding the development of brain dead systems like CP/M and MSDOS. These early Intel style architectures seem to really take a toll on the style of some programmers to the point of complete denial! They can't say "By jove you're right! We have had to do without those kinds of instructions.", it has to be "Those are silly statements. You're not doing it the Z80 way!" Kind of puts an end to a discussion of the differences between architectures, doesn't it? From: Robert Tkoch Subject: Forth in a window Date: Sat, 18 May 1996 11:49:36 -0700 Message-ID: <319E1BC0.55DF@starcenter.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Greetings! Does anyone know how to make Forth run in a window under Windows 3.11? I am using LMI's 32-bit 386 UR/Forth under DOS 6.22, VGA 16-color mode. When I put it in a window in Windows, all non-graphics functions work just fine. However, any attempt to run graphics functions causes a free-up, and I have to reboot. Does anyone know how to fix this? I already tried asking LMI. Or perhaps you might suggest where I could learn about these things? Thanks. Robert Tkoch robert@starcenter.com http://www.starcenter.com From: Bernd Paysan Subject: Re: Low level window hooks? Date: Thu, 16 May 1996 00:19:40 +0200 Message-ID: <319A587C.183CBBCA@informatik.tu-muenchen.de> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.3.100 i486) Thomas Worthington wrote: > > I wrote: > >I'm starting a 32-bit ANS style Forth and I want to make Windows > >available, not as built in fuctions (I want a SMALL Forth not > >another Win32Forth) but in the form of a low level gateway > >system. All the docs I can find on Windows assumes that you are > >working in a high level language. Since it is easy to get lists > >of what paramiters Windows wants for each function, it would seem > >reasonably easy to: > > a) standardise the calling routine, and > > b) write the various windows routines in otherwise ANS forth > > to be loaded (even stored in blocks if you like!) as > > required. > > > > In the real world things aren't that easy, of course, but I > >thought I'd ask. Things are as easy. You just load the dynamic library (LoadModule), and then query addresses (QueryProcAddr). > I suppose I should actually say what my question was: Does anyone > out there know what you have to do to call Windows from 386 or > later assembler?. Well, I won't do it in assembler. Just write a short C program wrapper that loads your Forth, contains a simple console interface (via shell.dll, at least until you found a way to set it up in Forth) and allows Forth to load DLLs and query prog addresses. The resulting address you get from QueryProdAddr is the address of a routine with is called in conventional C style (sometimes also refered as "Pascal" style, because registers are only used for return valued), so you push your parameters on the stack (in "wrong" order, thus from the last to the first in the C declaration), call the routine, discard all parameters, and find the result in AX or AX:DX if it is double (eax/eax:edx in Win32). Typical SI, DI, BP and SP are preserved. The funny thing about this approach is that it works with most modern OSes on the x86, thus you can write a Forth that is binary compatible between OS/2, Linux (or other Unixes) and Windows 95, until it starts to use OS-specific DLLs. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: Re: 8051 microcontroller FAQ Date: Thu, 16 May 1996 00:31:39 +0200 Message-ID: <319A5B4B.2686430D@informatik.tu-muenchen.de> References: <1021@purr.demon.co.uk> <318ecff1.20522122@news.netspace.net.au> <4munpf$170@ite127.inf.tu-dresden.de> <1052@purr.demon.co.uk> <4nd6dn$6q4@ite127.inf.tu-dresden.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.3.100 i486) Achim Gratz wrote: > This is all on the agents side, given the protocol is implemented > correctly. The NNTP protocol provides for getting the headers and > bodies of articles (and ranges of them) seperately, so any software > that keeps telling you you ought to get them together with the > articles (this is mainly used for Newsfeeds) is seriously flawed. Even further, the NNTP protocol provides for getting each header field seperately (xhdr field [range|id]). Thus if you kill for authors, subjects and lines, just go to the group, ask "xhdr Lines -", and the same with "From" and "Subject", and then select the right articles (or just the bodies, if you don't want to get headers). If your news reader doesn't do it right, set up an own newsspool, and write your own news transport agent ;-). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: wykoh@pado.krict.re.kr (Wonyong Koh) Subject: Re: Announcement DOOF-0.1.2 Date: Sun, 19 May 1996 15:18:30 GMT Message-ID: <4nlkk5$qf2@nis.dacom.co.kr> References: <4mng5n$3ob@hkusuc.hku.hk> <4ms7q8$il8@work.smurf.noris.de> <4n78ks$3r9@hkusuc.hku.hk> <4n7qk8$o6s@work.smurf.noris.de> <4n97n5$obc@hkusuc.hku.hk> <3198FCEB.7F4F@ix.netcom.com> <4ncaa6$lul@hkusuc.hku.hk> <319A06CA.7316@ix.netcom.com> <4neusn$3ea@hkusuc.hku.hk> <319EBB59.4EAF@cc.newcastle.edu.au> <4nkqq5$r51@hkusuc.hku.hk> Reply-To: wykoh@pado.krict.re.kr h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >(Even worse that the FILE wordset REQUIRES that the string is copied >to a temporary buffer. I had trouble a couple of times when a have >tried to rename a file in a manner like: >S" name1" S" name2" RENAME-FILE >with not quite the right effect. You can use BL PARSE or CHAR " PARSE instead of S" as: BL PARSE name1 BL PARSE name2 RENAME-FILE CHAR " PARSE name1" CHAR " PARSE name2" RENAME-FILE Wonyong Koh, Ph.D. wykoh@pado.krict.re.kr From: hp@kbbs.org (Holger Petersen) Subject: Re: 8051 microcontroller FAQ Message-ID: <1996May19.080545.23961@kbbs.org> Date: Sun, 19 May 1996 08:05:45 GMT References: <1021@purr.demon.co.uk> <318ecff1.20522122@news.netspace.net.au> <4munpf$170@ite127.inf.tu-dresden.de> <1052@purr.demon.co.uk> <4nd6dn$6q4@ite127.inf.tu-dresden.de> <319A5B4B.2686430D@informatik.tu-muenchen.de> Bernd Paysan writes: >Even further, the NNTP protocol provides for getting each header field There is more between Newsserver and user then nntp... Think of all those people getting their news via uucp! greetings, Holger From: "Bruce R. McFarling" Subject: Re: Forth GUI Date: Sun, 19 May 1996 20:31:41 -0700 Message-ID: <319FE79D.6661@cc.newcastle.edu.au> References: <4nhevm$kig@iaehv.IAEhv.nl> <4ni56s$b0l@hkusuc.hku.hk> <4nini2$b00@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (Win16; I) Marcel Hendrix wrote: > I'd love to have an editor that allows to write documentation and > Forth code together. But HTML codes will confuse Forth, and they > will certainly confuse ME when writing programs. Maybe the solution > is intelligent data, changes to source code automatically change > the HTML on-line document, the glossary etc. (and vv of course). > Maybe this already exists... \ <\pre> \ foo into an interactive textbook for anyone with a forth scripting browser -- whether they are pointing the browser over the net or at their own copy on their hard drive. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Forth GUI Date: 19 May 1996 21:27:50 +0200 Message-ID: <4nnsnm$p2i@iaehv.IAEhv.nl> References: <4nhevm$kig@iaehv.IAEhv.nl> <4ni56s$b0l@hkusuc.hku.hk> <4nini2$b00@iaehv.IAEhv.nl> <319FE79D.6661@cc.newcastle.edu.au> Bruce R. McFarling writes Re: Re: Forth GUI >Marcel Hendrix wrote: >> I'd love to have an editor that allows to write documentation and >> Forth code together. But HTML codes will confuse Forth, and they >> will certainly confuse ME when writing programs. Maybe the solution >> is intelligent data, changes to source code automatically change >> the HTML on-line document, the glossary etc. (and vv of course). >> Maybe this already exists... > >\ <\pre> >\ so you push your parameters on the stack (in "wrong" order, thus from >the last to the first in the C declaration), call the routine, discard >all parameters, and find the result in AX or AX:DX if it is double >(eax/eax:edx in Win32). Typical SI, DI, BP and SP are preserved. If I'm not terribly mistaken, Pascal style is the parameter passing convention Forth uses (It has nothing to do with registers). C-style is the reverse: push "from the last to the first in the C declaration". A bit of practical advice: keep the Forth and C-stacks *completely* separate, that is: switch stacks when you call C (bonus: when you do this the parameter re-ordering comes for free). > The funny thing about this approach is that it works with most modern > OSes on the x86, thus you can write a Forth that is binary compatible > between OS/2, Linux (or other Unixes) and Windows 95, until it starts to > use OS-specific DLLs. If you additionally use only the standard C-libraries, it is possible to port a Linux Forth to Windows 95 with zero changes (that is: only recompile the wrapper program). Unfortunately, I can never resist to incorporate special features of the hardware or system software in my Forths (that is one of the reasons I use Forth at all!). I found that the Linux and Windows 95 dynamic library implementations are *remarkably* similar. I only had to change the names of the system calls. -marcel From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Forth in a window Date: 19 May 1996 21:29:15 +0200 Message-ID: <4nnsqb$p94@iaehv.IAEhv.nl> References: <319E1BC0.55DF@starcenter.com> Robert Tkoch (robert@starcenter.com) wrote Re: Forth in a window > I am using LMI's 32-bit 386 UR/Forth under DOS 6.22, VGA 16-color mode. > When I put it in a window in Windows, all non-graphics functions work > just fine. However, any attempt to run graphics functions causes a > free-up, and I have to reboot. (Assuming that you already tried fiddling with UR's .PIF file) No excuse for the lockups you get, but under Win 3.1 the users of graphics packages that access the hardware directly (not through BIOS calls) are notified that they have to switch to a full screen (alt-enter). Even the Borland graphics BGI is affected by this. With Windows 95 the program is automatically switched to a full screen. Seems LMI has found and exploited some undocumented hardware features (which work against you now). -marcel From: Elizabeth Rather Subject: Re: Low level window hooks? Date: 19 May 1996 19:50:07 GMT Message-ID: <4nnu1g$3eb@guyana.it.earthlink.net> References: <4nco3u$per@mercury.kingston.ac.uk> <4ncpt2$rd2@mercury.kingston.ac.uk> <319A4D44.40FB@austin.finnigan.com> <4nfid2$dve@mercury.kingston.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:4nfid2$dve@mercury.kingston.ac.uk Thomas Worthington wrote: >Andrew McKewan wrote: >>...Could I ask what are your reasons for writing a new Forth? > >To be blunt, the reason I want to write a new Forth is that there >are none available for windows which are not either: £1000 >(polyForth), F-83 (Winforth), or fat (Win32Forth). Small correction: the £1000 system is ProForth for Windows, from MPE Ltd., which is sold and supported in North America by FORTH, Inc. > ... Forth has no chance of gaining in >popularity if potential users are faced with 5000+ words with no >documentation.... The "infamous" £1000 ProForth comes with a 1100+ page manual and extensive on-line helps. Such documentation is extremely costly to produce, but if you value your time you can break even very quickly! > As I say, windows documentation is quite easy to get... It isn't the mission of a Forth system to document Windows; as you note, others are getting rich doing that. However, interfacing to Windows is quite a complex chore, as you will find out, and documenting that interface is both important and at least as complex as writing the code. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: Z80 Fossils and rambling notions Date: 19 May 1996 20:05:59 GMT Message-ID: <4nnuv7$3eb@guyana.it.earthlink.net> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4neb3q$hc@dover-01-16.dialup.bluefin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:4neb3q$hc@dover-01-16.dialup.bluefin.net dvrsn@bluefin.net (Diversion) wrote: >...Not too long ago I was wondering to >myself (while going through edit->compile->edit... sessions, using multiple >windows) how people used to do development effectively without having >multiple windows. The answer is so blantantly obvious that it's easy to >overlook. When people didn't have machines that could recompile and relink >a 10000 line program in under a minute, they would actually think before >coding. Maybe programming was better off when people submitted programs to >be compiled and run overnight and didn't see the results for a day or two. This is actually the environment in which Forth was born (early 70's) and why it achieved its early success: it provided a fully interactive programming environment that could deliver recompiled, ready-to-run code in seconds without the tortuous edit>compile>edit procedures that are still a problem. Even though today's windowed environments relieve much of the pain, we still have a considerable edge in turnaround convenience, which translates directly into programmer productivity. >Of course, compiled languages like C or C-- are inherently better than >languages like FORTH or LISP that are by nature interpreted; even though >the latter have much nicer interactive development environments, it's fairly >easy to graft an interactive development environment to C or C-- with a fast >machine and gobs of memory. FORTH is not interpreted in anything like the same sense as LISP (interpreted BASIC, etc...). In most implementations it is compiled into an object form which executes quite briskly. Many implementations today in fact compile direct to code (e.g., our new Power MacForth) and deliver extremely fast performance. And on other platforms a very efficient multitasker such as our pF/x delivers real-time performance that's hard to beat. If a system is designed from first principles to be interactive without exacting a great run-time penalty -- as is true of Forth -- it will inevitably do so better than something originally designed with a different set of objectives with a user interface grafted on. And it doesn't require "gobs of memory," either! Cheers, Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Bernd Paysan Subject: Re: Z80 Fossils and rambling notions Date: Sun, 19 May 1996 17:29:44 +0200 Message-ID: <319F3E68.3ECB35D@informatik.tu-muenchen.de> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4neb3q$hc@dover-01-16.dialup.bluefin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.99.5 i486) Diversion wrote: > Of course, compiled languages like C or C-- are inherently better than > languages like FORTH or LISP that are by nature interpreted; even though > the latter have much nicer interactive development environments, it's fairly > easy to graft an interactive development environment to C or C-- with a fast > machine and gobs of memory. Not to mention the fact that C-- is inherently > better than C because it's object-oriented, so anything you write in it is > also object-oriented, which is inherently better. ;-). No, I disagree. Forth is both interpreted and compiled, and compiled Forth code (you compile with :) can be as fast as compiled C code. Most actual Forth native code compilers (like bigFORTH or iFORTH) generate slower code than good C compiler (GCC or something like that) by a factor of about two. However, except Watcom or the Intel/SCO compiler, none of the commercial compiler comes close to GCC, so these Forth compilers almost break even. And about two or three years ago Anton Ertl presented a concept of a native code compiler at EuroForth that is able to generate code at the same level of optimization as the best C compiler could do, provided that someone implements the scheduling rules. The current state of RAFTS is, however, "make it work, then make it fast". -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Bernd Paysan Subject: RFI: POSTPONE in interpretation state Date: Sun, 19 May 1996 18:15:52 +0200 Message-ID: <319F4938.76594757@informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b2 (X11; I; Linux 1.99.5 i486) Anton Ertl's postponetest.fs assumes that POSTPONE works even if the compilation of the current definition is suspended with [. This works great (on many Forths) with normal words and with compile-only words, but it doesn't work at all with state-smart words, because those assume to be in interpretation mode. Thus, POSTPONE really added generic execution semantics instead of plain compilation semantics, as is recommended by the standard. However, I disagree that this assumption is correct. Compilation semantics of a normal Forth word is to add the execution semantics to the current definition. [ suspends the compilation of the current definition (3.4.5 Compilation), and ] resumes compilation. IMHO "suspends" should be read strictly that until resuming compilation, there is no way to compile words to the current definition, neither with COMPILE, nor with POSTPONE. There is just a hint that it should be read like that, because COMPILE, has no interpretation semantics, so it's not possible to say, : foo [ ' bar compile, ] ;. The consequence of Anton's interpretation of the standard is that you need to have a special mechanism to implement state-smart words (like S" or TO). This mechanism must allow to determine the compilation-semantics part of a word. If you use two different execution tokens for interpretation and compilation, you have the problem, that FIND and ' will return different xts in different states (or only interpretation semantics). This is allowed by the standard (' has to return interpretation semantics, while FIND can return different xts in different states), but I'm not happy to be forced to implement it like that. So I want the TC to answer the following short question: Is there a valid compilation semantics while compilation is suspended with [, thus is it allowed to call words using POSTPONE or COMPILE, in interpretation mode with suspended compilation? My answer is "no", but I need an official statement. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: Elizabeth Rather Subject: Re: backward compatibility (was: ..fossils..) Date: 19 May 1996 20:15:31 GMT Message-ID: <4nnvh3$3eb@guyana.it.earthlink.net> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4ncv0t$9er@yama.mcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:4ncv0t$9er@yama.mcc.ac.uk Simon Read wrote: >Sounds like there's a fundamental difference of philosophy here. > >One attitude is, "My customers are stupid, *OR* my compilers are >too complex. *OR* I don't want to give my customers that much >control, so I'll never give out source code, I'll just sell >the executable. My customers could never re-compile the source >code for a new machine. Therefore, all my new machines must run >the object code identical to that which the old machines ran." > >Another attitude is, "My customers aren't stupid, and my compiler >is sufficiently simple, and I want to give my customers as much >control as they need, so I'll just sell my source code, then my >customers can re-compile the code on whatever new machine comes along. >Therefore, there is no need to make newer processors code-compatible >with older processors." The issue in my mind was less the intelligence and ability of prospective customers as the nature of the product and its intended use. If you're selling a modifiable system to programmers, you certainly would want to supply a lot of source (as we do with our Forth language products). However, if you're selling an end-user product to folks who just want to run it and are not interested in the hassle of recompiling, it's far more convenient and appropriate to distribute runnable object, which must then have broad compatibility. I assume you aren't in the habit of recompiling, for example, your newsreader program, you web browser, your word processor or your spreadsheets! Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: Suggestions for a good Windoze Editor Date: 19 May 1996 20:36:22 GMT Message-ID: <4no0o6$3eb@guyana.it.earthlink.net> References: <4ncpnu$7to@grissom.powerup.com.au> <319B1A14.3F54BC7E@apg.philips.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:319B1A14.3F54BC7E@apg.philips.co.uk Mike Plummer wrote: >> I'm programming a small controller with forth in it's prom. The editors I >> have been using create some sort of garbage in the files when saved hence the >> programs won't download and hence compile. - Dos vi works just fine - but I >> really need a good Win editor to allow pasting to my termional app.. >> >> Any suggestions? >> >Glen Fry wrote: > >At the risk of starting yet another "my editor is bigger than yours >argument :-)", what about MicroEmacs for Windows. I think you need to >search for mewin.zip or something similar. Our favorite Windows editor is ED for Windows, a product of Soft as It Gets in Australia; contact Neville Franks <100032.522@compuserve.com> for a distributor near you. It has a lot of Forth-specific extensions (e.g., colors for comments, structure words, etc.). Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: Forth in a window Date: 19 May 1996 20:45:39 GMT Message-ID: <4no19j$3eb@guyana.it.earthlink.net> References: <319E1BC0.55DF@starcenter.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:319E1BC0.55DF@starcenter.com Robert Tkoch wrote: >Does anyone know how to make Forth run in a window under Windows 3.11? > >I am using LMI's 32-bit 386 UR/Forth under DOS 6.22, VGA 16-color mode. >When I put it in a window in Windows, all non-graphics functions work >just fine. However, any attempt to run graphics functions causes a >free-up, and I have to reboot. > >Does anyone know how to fix this? I already tried asking LMI. Or perhaps >you might suggest where I could learn about these things? Thanks. Depends. Are you trying to run in a "DOS-box" window? In that case, all that is required is for your underlying Forth to be respectful of the environment and not tamper with interrupts, memory mapping, graphics modes, etc. in a way incompatible with usage by Windows & its other client programs. Our polyFORTH and EXPRESS products work fine in DOS boxes, and both do extensive graphics. To be a real "Windows app" is quite a lot harder. There are only a few such Forths around: LMI has a 16-bit Windows Forth; there's public domain Win32Forth, a complex system with no documentation but a lot of features; and ProForth for Windows by MPE, sold & supported in North America by FORTH, Inc. ProForth is a very full-functioned, well-documented system with many features such as GUIDE, a point-and-click builder of menus, dialog boxes, etc. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://websites.earthlink.net/~forth/ From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: Automatic Version Control System Date: 19 May 1996 19:39:01 GMT Message-ID: References: <4mttjk$hhk_003@cpe.Perth.aone.net.au> In-reply-to: ejc@techrron.com.au's message of Thu, 09 May 96 23:03:16 GMT >>>>> "Erron" == Erron Criddle writes: Erron> For those of you who are interested in setting up your Erron> software so it automatically upgrades itself via the Erron> Internet, please point your browser to: Erron> ftp://ftp.techrron.com.au Erron> The site contains a demo file (auto-installing) that demo's Erron> an automatic version control system for the Internet (just Erron> download and run the program). Erron> Personally, I think it is brilliant :-)...it has an on-line Erron> help file and order-form etc etc that details the complete Erron> product. Erron> I know, I know, I know...I personally hate ads myself, but Erron> believe me, an automatic version control system for AUD Erron> $295!...well, I would probably be glad someone told me Erron> about it. Erron> Regards Erron> PS: A free copy to the first person Erron> who can e-mail me with Techrron's phone number. Erron> Erron Criddle Techrron Holdings ejc@techrron.com.au So why should I pay three hundred bucks for a version control system when I am already running RCS under emacs and NFS over the internet and supporting multiple clients' development efforts with it? It that price a per user price, a per machine price, a per application price, a per company price, a per site price, or what? With RCS and NFS I can install source library sharing and revision control with no license fees at all. Of course, my client pays for my time to set it up for them, but that doesn't take very long, and they can clone it all over a company network with no additional fee. How is your product better for me or my clients than that? -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: Simon Read Subject: Re: Z80 Fossils and rambling notions Date: 19 May 1996 22:20:14 GMT Message-ID: <4no6qu$5v4@yama.mcc.ac.uk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4neb3q$hc@dover-01-16.dialup.bluefin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; OSF1 V3.2 alpha) X-URL: news:4neb3q$hc@dover-01-16.dialup.bluefin.net D: dvrsn@bluefin.net (Diversion) D> Of course, compiled languages like C or C-- are inherently better than D> languages like FORTH or LISP that are by nature interpreted; --> Careful saying FORTH is by nature interpreted. The FORTH process of executing compiled words is just a process of following an address which tells the processor where to continue executing machine code. This is generally equivalent to the time taken to execute the "CALL" and "RETURN" machine instructions. In certain cases (PDP-11, ARM using direct-threaded code) it's actually _faster_. Some may refer to this mechanism as the FORTH "inner interpreter" or "address interpreter" but it's not remotely like a text interpreter. There is an "outer interpreter" which _is_ a text interpreter, but this typically interprets one line at a time as the user types it in. This is identical to a C system - you do still have to type the command to run your (pre-compiled) program, which command has to be interpreted. Show me an operating system _without_ a text interpreter and I'll ask, "How do you tell it what to do?" hehehe D> even though D> the latter have much nicer interactive development environments, it's fairly D> easy to graft an interactive development environment to C or C-- with a fast D> machine and gobs of memory. [...] --> I've seen 32-bit systems running FORTH which use somewhere between 16Kb and 32Kb for the total operating system. These include all development aids. (That's kilobytes, by the way - not a mis-type.) The source code for this would typically fit on one 3.5" floppy disc with plenty of room to spare. How many megabytes are needed for your favorite C/C++ system? Simon From: znmeb@news (Ed Borasky) Subject: Re: Z80 Fossils and rambling notions Date: 20 May 1996 00:26:14 GMT Message-ID: <4noe76$at0@myst.plaza.ds.adp.com> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4neb3q$hc@dover-01-16.dialup.bluefin.net> <4no6qu$5v4@yama.mcc.ac.uk> Quoth the Simon Read (s.read@cranfield.ac.uk): >I've seen 32-bit systems running FORTH which use somewhere between 16Kb >and 32Kb for the total operating system. These include all development >aids. (That's kilobytes, by the way - not a mis-type.) The source code >for this would typically fit on one 3.5" floppy disc with plenty of >room to spare. >How many megabytes are needed for your favorite C/C++ system? Yes, but think how much less you can accomplish in a given time using C/C++! :-) Incidentally, I think I know why Forth programmers are more productive than C programmers. It's simply because there *are* more C programmers than Forth programmers! Since there are more C programmers, they spend more time communicating among themselves and less time programming. In other words, I'm about the same level of productivity on a one-man project whether I use Forth, C, Perl, assembler, FORTRAN, Excel, MATLAB, LISP or any other programming environment. Once I get a library of common things built up, for all practical purposes the languages are interchangeable. But once you require a larger team than one programmer, a kind of Amdahl's law sets in. Productivity drops to slightly above the level of the least productive member of the team, and the language choice by definition is the one best-known among all the team members. -- znmeb@plaza.ds.adp.com (M. Edward Borasky) "Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark to read." -- Marx From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: RFI: POSTPONE in interpretation state Date: 20 May 1996 02:47:46 GMT Message-ID: <4nomgi$k7s@dfw-ixnews5.ix.netcom.com> References: <319F4938.76594757@informatik.tu-muenchen.de> X-NETCOM-Date: Sun May 19 9:47:46 PM CDT 1996 In <319F4938.76594757@informatik.tu-muenchen.de> Bernd Paysan writes: >Anton Ertl's postponetest.fs assumes that POSTPONE works even if the >compilation of the current definition is suspended with [. This works >great (on many Forths) with normal words and with compile-only words, >but it doesn't work at all with state-smart words, because those assume >to be in interpretation mode. Thus, POSTPONE really added generic >execution semantics instead of plain compilation semantics, as is >recommended by the standard. >However, I disagree that this assumption is correct. Compilation >semantics of a normal Forth word is to add the execution semantics to >the current definition. [ suspends the compilation of the current >definition (3.4.5 Compilation), and ] resumes compilation. IMHO >"suspends" should be read strictly that until resuming compilation, >there is no way to compile words to the current definition, neither with >COMPILE, nor with POSTPONE. There is just a hint that it should be read >like that, because COMPILE, has no interpretation semantics, so it's not >possible to say, : foo [ ' bar compile, ] ;. >The consequence of Anton's interpretation of the standard is that you >need to have a special mechanism to implement state-smart words (like S" >or TO). This mechanism must allow to determine the compilation-semantics >part of a word. If you use two different execution tokens for >interpretation and compilation, you have the problem, that FIND and ' >will return different xts in different states (or only interpretation >semantics). This is allowed by the standard (' has to return >interpretation semantics, while FIND can return different xts in >different states), but I'm not happy to be forced to implement it like >that. >So I want the TC to answer the following short question: Is there a >valid compilation semantics while compilation is suspended with [, thus >is it allowed to call words using POSTPONE or COMPILE, in interpretation >mode with suspended compilation? My answer is "no", but I need an >official statement. I don't see that this is ambiguous. First, let's look at the direct case. : FOO [ POSTPONE BAR ] ; This has an environmental dependency because POSTPONE has no defined interpretation semantics. You can make it work any way you want to, but you can't depend on other compiler-writers to make it work your way, or any way. OK, let's try something else. : FOO POSTPONE POSTPONE ; IMMEDIATE : BAR [ FOO SNAFU ] ; FOO's runtime action is to execute POSTPONE . But since POSTPONE has no interpretation semantics, neither does FOO . Again, you can make it work however you like but people who use it are depending on your special compiler. Since COMPILE, similarly has no interpretation semantics, the same logic applies. But my opinion isn't official. It looks so clear to me that I don't see any official ruling is needed, but if you want one I'm sure they'll give you one. OK, what about the other direction? Suppose you're interpreting, and you stop and do ] ?DUP IF . THEN [ or some other code fragment. Is that allowed? Obviously no. There is no current definition unless you've started one with : or :NONAME or DOES> and haven't ended it yet with ; . If there's no current definition, then there's no current definition to append semantics to. There is no standard way to find or execute this code fragment. All of this makes [ ... ] much less useful than it can be in particular systems. There was no good way to standardize the various great tricks you can do with that stuff, so code which uses those tricks is restricted to those particular compilers that allow those particular tricks. About the only useful things you can portably do with [ ... ] are ... [ COMPUTE-MAGIC-NUMBER ] LITERAL .... and ... [ SPECIAL-DEBUG-OUTPUT ] .... and possibly ... [ DO-SPECIAL-TEST [IF] ] ... [ [ELSE] ] ... [ [THEN] ... ; Of course, the code that uses the special tricks is as portable as it ever was. You might be able to call it ANS Standard with Environmental Dependencies if you can document exactly what the dependencies are. I dunno. From: Simon Read Subject: Re: backward compatibility (was: ..fossils..) Date: 20 May 1996 11:16:35 GMT Message-ID: <4npkaj$rjq@yama.mcc.ac.uk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4ncv0t$9er@yama.mcc.ac.uk> <4nnvh3$3eb@guyana.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; OSF1 V3.2 alpha) X-URL: news:4nnvh3$3eb@guyana.it.earthlink.net ER: Elizabeth Rather ER> I assume you aren't in the habit of recompiling, for example, your ER> newsreader program, you web browser, your word processor or your ER> spreadsheets! --> Certainly, a lot of people do use software exactly as it's given. They learn ways to work round things which it doesn't do and they don't ask for things to be different. Personally, I am almost always dissatisfied with other people's software but I suppose that this is because I am a programmer and I am less inclined to accept limitations in software; I am more inclined to do something to improve it. To take your four examples, I would very much like to have one or two extra little abilities in my newsreader, web browser, word processor and spreadsheet. Off the top of my head, I can think of things which I would change in each of them if I had the chance. I'm curious to know how many users feel this way. How many users of word-processors would like a modifiable system? And how many upgrades would companies be able to sell if the customers didn't need them because they could already implement their favorite feature themselves? I suspect that commercial software vendors don't want their customers to have the control, so they don't give out source code. Perhaps it has just been traditional to only give object code and nobody questioned that except FORTH. I have never found the existence of the FORTH compiler to contribute to the complexity of my work. If I don't need extensibility, the FORTH compiler just does its job invisibly and doesn't intrude. I am trying to question the necessity for backward compatibility in microprocessors. I have always found FORTH to provide compatibility at the system level, making object-code compatibility unnecessary. I don't often see object code but compatibility at system level directly affects the way I work. The ability to modify my spreadsheet is one consequence of this. Simon From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: backward compatibility (was: ..fossils..) Date: 20 May 1996 12:18:44 GMT Message-ID: <4npnv4$2re@hkusuc.hku.hk> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4ncv0t$9er@yama.mcc.ac.uk> <4nnvh3$3eb@guyana.it.earthlink.net> <4npkaj$rjq@yama.mcc.ac.uk> Simon Read (s.read@cranfield.ac.uk) wrote: >I'm curious to know how many users feel this way. How many users of >word-processors would like a modifiable system? And how many >upgrades would companies be able to sell if the customers didn't >need them because they could already implement their favorite feature >themselves? I suspect that commercial software vendors don't want >their customers to have the control, so they don't give out source >code. Perhaps it has just been traditional to only give object code >and nobody questioned that except FORTH. Don't forget that software is often answer for a non-existent question, i.e. the manufacturer has to create a need for the product. (E.g. Win95, everyone who did not want to transfer to Linux, Windows NT or OS/2 seemed to be quite satisfied with the old Win3.1. Now, Bill Gates told them that they are all wrong and CREATED a market for a piece of software that nobody needed, which does not work, and which actually decreases the performance of application written for Win3.1. If users would be just a tiny bit less stupid and more conscious what is inside an application (or an OS) the whole Win95 business would have been a huge failure. Secrecy is the best tool to gain power over the user, to squeeze the last cent out of him/her, and to make him/her your permanent renewable asset. (After all, the user is for your company to make a buck and not the other way around. At least many in the computer business think so.) Well, I rather switched to Linux and wrote my own Forth for it, but that is definitly not the way to get rich fast.) As far as I know no businessman has ever lost a single cent by overestimating the stupidity of the potential customers. Treat them as if they were brainless animals who would never ever understand how a net browser works and finally they will loose interest in it, and comply to your claims. 99% will just buy your product anyway [unless someone gives them a similar thing for free with source code, but many will continue to buy your product because your logo is worth for their money, especially if it happens to be ``MS'' :-( ]. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: interpreted 'S"' (was: Announcement DOOF-0.1.2) Date: 20 May 1996 12:25:50 GMT Message-ID: <4npoce$2re@hkusuc.hku.hk> References: <832587132.AA00295@ear.co.at> Ewald Pfau (ehp@ear.co.at) wrote: >h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >The string is valid beyond of the actually valid part of the input stream. It >is not just an argument being consumed by an immediately following interpreter >action. I think this behaviour is introduced in the FILE wordset, if only the CORE wordset is implemented then S" returns the .... (STRING and that is the end of it) which resides whereever (you don't know). >- not to touch PAD memory, This is REQUIRED by the standard. >- to hold at least two entries > (a new entry invalidates the last but one entry) This is not required by the standard so a system might provide it but you cannot depend on it. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Low level window hooks? Date: 20 May 1996 12:30:48 GMT Message-ID: <4npolo$2re@hkusuc.hku.hk> References: <4nco3u$per@mercury.kingston.ac.uk> <4ni5d4$p91@mercury.kingston.ac.uk> <319CFD07.7888@ix.netcom.com> <4nkige$le6@hkusuc.hku.hk> <4npfce$3cm@work.smurf.noris.de> Matthias Urlichs (smurf@noris.de) wrote: >Let's see, MOPS on the Mac does > method1: object method2: object >to call a method of an object; with some special support by the compiler, >I think. >OOF does > object method1 method2 Which OOF does it? (Not mine for sure, that one does Object { Method1 Method2 } [Note the curly braces, they select and de-select the object. Methods are not "sent to an object" as messages but operate on the current object. This is what makes them fast!].) Andras From: Psi Subject: Re: Forth instead of JAVA (RFC) Date: Mon, 20 May 1996 14:44:41 +0100 Message-ID: <31A07749.1CFBAE39@wmin.ac.uk> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <318E3F50.868@blue.nowcom.co.kr> <4mk3r4$kc3@dfw-ixnews4.ix.netcom.com> <4mouq6$sd0@ecuador.it.earthlink.net> <4nagsu$lja@webprod2.lehman.com> <4ncalm$lul@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Hans Bezemer wrote: > > h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: > Forth bytecode in you browser ?- cool idea (wish I'd thought of it a few months sooner that I did) See Stephen Pelc, sfp@mpeltd.demon.co.uk 's response I'd really love to see something other than Micro$oft's VB Script as a viable alternative to Java. seeing would be *real* cool ! I also think you could quite easily port forth to the Java Virtual Machine, though you might run into problems with its auto garbage collection though :) Regards From: Psi Subject: Re: Win95 overhead for native Forth Date: Mon, 20 May 1996 14:52:28 +0100 Message-ID: <31A0791C.3F54BC7E@wmin.ac.uk> References: <4nhf2l$kmk@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Marcel Hendrix wrote: > > Marcel Hendrix wrote: > > > I have ported iForth from Linux to (a 32-bit console) Windows 95 application. [Snip] Yes I have seen many many apps slow down under '95, both in beta and production code (95 that's whats slow) I belive that 95's kernal still has a *lot* of 16 bit code, and as such 32bit code has to 'thunk' between 16bit and 32bit code. Also it does so much undefined 'stuff' in the background which the user has little or no control over you'll get a large performance hit regardless of what you run. It all really depends on your individual setup, are you using 16 or 32bit drivers etc.. etc.. mind you - why dont you do what I do ? use DOS for all your old legacy apps, and use NT workstation for your 32bit and Windows Apps ... Personally though I prefer Un*x (err Linux on my machine) for development work though :) Regards Psi From: Psi Subject: Re: Forth in a window Date: Mon, 20 May 1996 14:58:40 +0100 Message-ID: <31A07A90.FF6D5DF@wmin.ac.uk> References: <319E1BC0.55DF@starcenter.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Robert Tkoch wrote: > > Greetings! > > Does anyone know how to make Forth run in a window under Windows 3.11? > > I am using LMI's 32-bit 386 UR/Forth under DOS 6.22, VGA 16-color mode. > When I put it in a window in Windows, all non-graphics functions work > just fine. However, any attempt to run graphics functions causes a > free-up, and I have to reboot. > > Does anyone know how to fix this? I already tried asking LMI. Or perhaps > you might suggest where I could learn about these things? Thanks. > > Robert Tkoch robert@starcenter.com http://www.starcenter.com Ouch ! Another Reason for this could be that many P-mode apps just don't like windows, especially DOS4GW etc are known to knock out even the most stable setups ! I think its something to do with the Processor trying to change Priv-Rings or something (sorry I dont program in protected mode assembler) - If you were running Win 3.1 you _might_ of gotten away with running windows in standard mode (win /s) From: "Ronald T. Kneusel" Subject: Re: Scripting WWW CGI apps with FORTH Date: 20 May 1996 15:21:29 GMT Message-ID: <4nq2lp$fc@post.its.mcw.edu> References: <31A08957.2595@metamor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (Macintosh; I; 68K) To: calek@metamor.com X-URL: news:31A08957.2595@metamor.com I've been using Forth for CGI apps since last fall. I work on the Mac and use a CGI shell I wrote with Pocket Forth. I use it for my own stuff and to implement a series of online clinical calculators for the division of General Internal Medicine here at the Medical College of Wisconsin. The CGI shell is at http://kreeft.intmed.mcw.edu/cgishell.html Examples are at: http://kreeft.intmed.mcw.edu/physics.html http://www.intmed.mcw.edu/clincalc.html - Ron Kneusel rkneusel@post.its.mcw.edu From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Forth instead of JAVA (RFC) Date: 20 May 1996 14:18:15 GMT Message-ID: <4npuv7$7eh@hkusuc.hku.hk> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> <318E3F50.868@blue.nowcom.co.kr> <4mk3r4$kc3@dfw-ixnews4.ix.netcom.com> <4mouq6$sd0@ecuador.it.earthlink.net> <4nagsu$lja@webprod2.lehman.com> <4ncalm$lul@hkusuc.hku.hk> <31A07749.1CFBAE39@wmin.ac.uk> Psi (oplec@wmin.ac.uk) wrote: >Hans Bezemer wrote: >> >> h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >> >Forth bytecode in you browser ?- cool idea (wish I'd thought of it >a few months sooner that I did) I did not write about ANY bytecode! Something got messed up. Andras From: Art Calek Subject: Scripting WWW CGI apps with FORTH Date: Mon, 20 May 1996 10:01:43 -0500 Message-ID: <31A08957.2595@metamor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Any experience out there using FORTH to script CGI apps? TIA -- Art ======================================================== Art Calek email: calek@metamor.com phone: 312.251.4203 Metamor Technologies, Ltd. fax: 312.251.2999 "If you think you can or you think you can't, you're right!" - Henry Ford From: pfrenger@ix.netcom.com(Paul Frenger) Subject: Re: backward compatibility (was: .. Z80 Fossils .. ) Date: 20 May 1996 14:42:53 GMT Message-ID: <4nq0dd$6ij@dfw-ixnews9.ix.netcom.com> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4n4s0l$ao6@yama.mcc.ac.uk> <4nag7v$mhn@ecuador.it.earthlink.net> <4nagk6$mhn@ecuador.it.earthlink.net> <4neb3q$hc@dover-01-16.dialup.bluefin.net> <4no6qu$5v4@yama.mcc.ac.uk> X-NETCOM-Date: Mon May 20 9:42:53 AM CDT 1996 Simon Read wrote: > >I've seen 32-bit systems running FORTH which use >somewhere between 16Kb and 32Kb for the total >operating system. These include all development >aids. (That's kilobytes, by the way - not a mis- >type.) The source code for this would typically >fit on one 3.5" floppy disc with plenty of room >to spare. > >How many megabytes are needed for your favorite >C/C++ system? > What a delightful thread of conversation we have here! Time for a little nostalgia! I recall building my first microprocessor system in 1976, armed only with a data sheet, some chips and a wire-wrap tool. The processor was the old but venerable RCA 1802. I had the use of a full 256 bytes (not Mbytes, not Kbytes, just bytes) of RAM for programs and data. Programming was done not in a high level language, or even assembler, but in hand-crafted machine code (ie: hexadecimal). I can recall how good it felt to expand that RAM to a full 1 kbytes. In 1983 I built a new 1802 board, with lots of bells and whistles, and 32 kbytes of RAM. I ported fig-Forth to this board and used it for several prototypes and customer demonstrations. Its only operating system was Forth (no disk, no GUI, no OOPS -- except the kind of "oops" you say when the battery-backup RAM died). Elizabeth Rather's Forth Inc. made a polyForth that would compile useful programs into 1 kbytes of RAM on the 1802. Oh, what to do with that wasted 31 kbytes? Why go into this, when the average programmer now uses a 100 MHz-plus Pentium with 16-plus megabytes of RAM and a gigabyte of disk? Simply because there's a lot of "stuff" out there that contains a single chip controller in it, usually 8-bits wide, with as little as 500 bytes of program in it. These's a chip like that in the mouse in your "big computer"; and in your car's braking system; and in your camera .. alarm clock .. radio .. CD player .. etc. etc. ad infinitum. There are plenty more of these little computers running around than all the desktop and laptop computers in the world. I just gave a paper at the US Air Force Academy on: "Nanocontrollers for Biomedical Applications" so I'm very aware of the need for teent-tiny systems and the mindset that programmers need to use them. I appreciate and enjoy big systems too .. but I can't forget where it all came from, and WHERE MOST OF IT STILL IS. Forth had a part in that parsimonious past, has a part in the frugal present, and hopefully will continue to have a role in the efficient future. From: Ken Subject: Re: Z80 Fossils ... Date: Mon, 20 May 96 13:51:45 -0500 Message-ID: References: <319E9641.5929@cc.newcastle.edu.au> <4nl5me$fne@newsbf02.news.aol.com> X-To: Regnirps Regnirps writes: >>Not to mention (but I already did), this really isn't the place for >>a pure 6502 vs Z80 argument! > >How did it get to be a Z80/6502 thing? All I said was I was looking at >reams of "legacy" code and Z80 for the first time and gave a list of >things the Z80 does not do. Some one responded that I was being silly, as >if I was wrong and it really does these things. Well, I looked through >again, and it doesn't. The 6502 was just an example of a processor with >indexing addressing modes. I think that you might have made it a Z80/6502 thing, or at least a Z80 thing. I also think Mr. McFarling is just trying to say that a discussion of which CPU is "better" or "worse" is innappropriate for a Forth news group. Personally, I agree with him. I would much rather read or dicuss how to achieve a clean Forth implementation an a given CPU, instead of oppinions on which CPU is the "best." I suppose in a perfect world, we would all be free to design our systems around the "best" CPU, or even better, design our own CPU. As far as 6502 vs Z80, I have both, and I enjoy them both. Ken From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: Forth GUI Date: 20 May 1996 20:57:55 +0200 Message-ID: <4nqfbj$66g@iaehv.IAEhv.nl> References: <4nhevm$kig@iaehv.IAEhv.nl> <319FE79D.6661@cc.newcastle.edu.au> <4nnsnm$p2i@iaehv.IAEhv.nl> <4np464$eeo@ite127.inf.tu-dresden.de> Achim Gratz writes Re: Forth GUI | Marcel> You simplified it away. I prefer (make that demand) to | Marcel> have only one file with both code and HTML-ed | Marcel> documentation. The HTML dominates the text very soon. [..] | What prevents you from having two words and ? The | former would ignore all input unless it encountered the latter, as ( | does. Definitely better than the previous suggestions. But this would give me "plain text" documentation, with no hyperlinks and no special typesetting. Also not good enough for building a glossary, where you want the word headers with their stack comments, vocabulary names etc. to be included. | Than have another special interpreter that strips those two | words out of the code and formats the source lines suitable for HTML | (i.e.
...
..
and puts it into the documentation tree. May I suggest that you ask Julian V. Noble for his bear stew recipe :-) -marcel From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: backward compatibility (was: ..fossils..) Date: 20 May 1996 20:58:28 +0200 Message-ID: <4nqfck$69i@iaehv.IAEhv.nl> References: <4n3fpg$mtc@newsbf02.news.aol.com> <4nnvh3$3eb@guyana.it.earthlink.net> <4npkaj$rjq@yama.mcc.ac.uk> <4npnv4$2re@hkusuc.hku.hk> Andras Zsoter writes Re: backward compatibility (was: ..fossils..) > Don't forget that software is often answer for a non-existent question, > i.e. the manufacturer has to create a need for the product. How many people begged for the CD-player to be invented. Or television. Or WWW for that matter. > (E.g. Win95, everyone who did not want to transfer to Linux, Windows NT > or OS/2 seemed to be quite satisfied with the old Win3.1. Well, I waited for a simple to use 32-bit OS for two years. If NT wasn't so expensive I'd have switched to it long ago. I also was under the impression there was no documentation for it (that I could afford). From using Win95 for a few weeks I get the impression that all the NT system calls work for Win95 too. SO... Is NT a better OS than Win95? I guess OS/2 is out of the race by now. (Please, I'd really like an honest, balanced, opinion. Why is everybody getting so emotional when Microsoft and / or C/C++ get involved? Use what works for you. I use Linux *and* MS-DOS *and* Win95 *and* Forth *and* C *and* assembler, seeing no reason for *or*, less even *xor*). > Now, Bill Gates told them > that they are all wrong and CREATED a market for a piece of software > that nobody needed, which does not work, and which actually decreases (1) (2) (3) > the performance of application written for Win3.1. The same three things go for Linus's Linux :-) (it depends what you define by "not work"). Linux is clearly technically superior, but only because they could afford to leave out everything they didn't like. Nobody complains about the noise level inside a Porsche. > If users would > be just a tiny bit less stupid and more conscious what is inside [..I don't want to believe you wrote this!..] > logo is worth for their money, especially if it happens to be ``MS'' :-( ]. Where is this bitterness coming from :-( -marcel