From: regnirps@aol.com (Regnirps) Subject: Re: Finding open firmware on a PCI mac Date: 13 Feb 1996 02:07:27 -0500 Message-ID: <4fpdbf$otl@newsbf02.news.aol.com> References: Reply-To: regnirps@aol.com (Regnirps) verec@micronet.fr (Jean-Francois Brouillet) said "I doubt PCI Macs have anything remotely ressembling Forth boot code..." But they do, the OpenBoot is accesible over the serial port only. Charlie Springer From: HblhfoJD@jumbo.com Subject: Forth related files shareware + 64,000 other pgms ! + Date: 13 Feb 1996 05:01:45 -0500 Expires: 27 Feb 1996 Message-ID: <4fpni9$5oo@dev.jumbo.com> All the Forth related files freeware and shareware programs we've been able to find...plus another 64,000 + programs are currently on JUMBO! (http://www.jumbo.com) -- -- Over 1,200,000 links for fast and easy and access to more than 250 sites! AND -- Never any waiting -- PLUS -- full descriptions of every program BEFORE downloading -- PLUS -- Thousands of new programs are being added weekly beginning the week of 01/15! Access us at: http://www.jumbo.com/prog/dos/forth/ From: MABS85B@prodigy.com (Leo Wong) Subject: Re: Game of Life? Date: 13 Feb 1996 21:19:17 GMT Message-ID: <4fqv8l$ahi@usenetw1.news.prodigy.com> References: <4f9tsg$caq@dewey.csun.edu> If we take Wil Baden's LIFE and redefine DEATH: LIVE 2 - CONSTANT DEAD ten-in-row lasts much longer than 15 generations. Is Life cheating Death or merely postponing the inevitable? _I_ quit after 20,000 generations. Considering how mundane was the mutation, I assume that LIFE would eventually have stopped on its own. Wil, could you post the starting pattern that ran for 6 days and 3.4 million generations on the Apple II? - LEO WONG MABS85B@prodigy.com New York State Department of Civil Service Albany, NY 12239 From: japs@netcom.com (Jim Schneider) Subject: Re: Need forth advice Message-ID: References: <4evj5q$g5l@newsbf02.news.aol.com> <4f2ag1$git@news.bellglobal.com> Date: Tue, 13 Feb 1996 21:32:15 GMT In article <4f2ag1$git@news.bellglobal.com> Brad Rodriguez writes: >Other Forths-in-C include Forthmacs, cforth, gforth, ThisForth, pfe, and >atlast... Brad, don't forget tileforth, which is available from: ftp://prep.ai.mit.edu/pub/gnu/tile-forth.* (I think that's correct, but I'm not sure) It's also available from any GNU mirror site. The last time I looked at it, however, I couldn't get it to compile under Linux (using GCC 2.7). I think it's pretty close to the 83 standard, and I don't think they've updated to ANS. Also, I think ThisForth is written in m4, not C. From: gordon@charlton.demon.co.uk (Gordon Charlton) Subject: Re: multi-line comment Date: Sat, 17 Feb 1996 20:41:01 +0100 Message-ID: References: <4g02gf$429@ixnews6.ix.netcom.com> <4g342r$7r2@newsbf02.news.aol.com> X-NNTP-Posting-Host: charlton.demon.co.uk In article <4g342r$7r2@newsbf02.news.aol.com>, lglisle@aol.com (LgLisle) wrote: } Gordon Charlton's recent and rather awesome I'm not sure, but I'll take that to be a compliment. :-) } posting of an } implimentation of heap handling demonstrated to me one of } the problems inherent in multi-line comments. } } Gordon uses the backslash to mark his many comment lines. } Somewhere in the transmisson from him to me, some system } wrapped the lines shorter than he did. This left a plethora of } short little words sitting unprotected by back slashes. } } This leads me to two conclusions. One, it is dangerous to assume } that the format of a text file is firm and unchanging. Transmission } and editing processes may not be smart enough to treat the } file correctly. The second is that the parenthetical comments } are safer, since they don't depend on formatting. Oddly, the conclusion I drew was "silly sod - you forgot to check the line length before posting to usenet" Gordon /\ +----/--\----+ | half way | | to | | happy land | +------------+ From: regnirps@aol.com (Regnirps) Subject: PCI Macs Date: 17 Feb 1996 19:56:34 -0500 Message-ID: <4g5tg2$apc@newsbf02.news.aol.com> Reply-To: regnirps@aol.com (Regnirps) A highly placed White House source tells me: To get into Open Firmware on a PCI Mac you need to have a terminal on the modem port set to 38000,N,8,1. On Boot you need to hold Command-Option OF. From: regnirps@aol.com (Regnirps) Subject: OOForth Date: 17 Feb 1996 19:56:38 -0500 Message-ID: <4g5tg6$aph@newsbf02.news.aol.com> Reply-To: regnirps@aol.com (Regnirps) The latest Forth Dimensions has an article on Object oriented extensions for Forth and where we might want to go and what it should look like, etc. I know most of you out there use PC's so you will not be familiar with Mike Hore's highly modified NEON/Yerk that he calls MOPS. All I can say is that as far as OO Forth goes, it is done, finished, complete. If you are thinking about this now, you are way behind the curve. Not only has Mike achieved metaphysical perfection, but MOPS is a native code generator and runs like optimized 'C'. Find a Mac and try it out, or download the Docs from Taygeta. This is real Forth (ANSI) with objects. You will be stunned. Charlie Springer From: vern_tallman@usa.pipeline.com(Vernon M. Tallman) Subject: Re: Whither Pygmy? (was Writing FORTH systems from scratch) Date: 18 Feb 1996 05:26:07 GMT Message-ID: <4g6d9f$cn9@news1.usa.pipeline.com> References: <4g1t0b$lde@newsbf02.news.aol.com> X-PipeUser: vern_tallman X-PipeHub: usa.pipeline.com X-PipeGCOS: (Vernon M. Tallman) Has Frank or anyone mentioned what new features might be in v1.5? Vern Tallman From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: 99 Bottles of Beer in Froth Date: Sat, 17 Feb 1996 09:18:43 -0500 Message-ID: <4g6idq$aid@sdcc12.ucsd.edu> References: <4eoljm$1cro@usenetw1.news.prodigy.com> <4epbo8$1mcc@navajo.gate.net> <4f1onp$pjc@sdcc12.ucsd.edu> <4f477b$dr0@navajo.gate.net> spc@gate.net (Sean 'Captain Napalm' Conner) wrote to us all: >In article <4f1onp$pjc@sdcc12.ucsd.edu> wtanksle@sdcc15.ucsd.edu (William Tanksley) writes: >>spc@gate.net (Sean 'Captain Napalm' Conner) wrote to us all: >>You did a very nice job. I particularly appreciate the brevity. But... > Uh oh, I was afraid of that ... >>>\ 99 Bottles of Beer on the Wall >>>\ ANS Forth version by Sean Conner >>>: beer ( n -- ) dup 1 > if . ." bottles " else >>> dup 1 = if . ." bottle " else >>> drop ." no bottles " then then >>> ." of beer" >>> ; >>This works, and is certainly readable. I would probably choose to break it >>up a little, though, by using a pluralising scheme. Perhaps a phrase would >>be: >>: .beers DUP .NUMBER DUP ." bottle" .PLURAL ." of beer" ; >>That's just my take, though. I don't see this as breaking any rules. It >>does have too many conditionals for a single word, but "too many" is just >>too vague. > Well, all you did was separate the two conditionals into their own words, >but I guess that's stylistic issues. I wasn't too happy with 'beer' myself, >but for this limited domain, I don't think adding .NUMBER and .PLURAL would The main point is that it changes a multi-line definition without clear boundaries or coherent purpose into several smaller, fully-defined and quite seperate definitions. You're code wasn't wrong by any means, but this is (IMO) better. At least it follows the rule: one action for every name. Now if I wasn't concerned about another rule I might have done this a bit differently. See that .PLURAL? I was tempted to make its usage like this: DUP s" bottle" PLURALISE COUNT TYPE But I remembered rule #8: Eschew sophistication. Thanks for that one, Leo. This change would have made PLURALISE very powerful, capable of being extended to pluralise ANY word, but is that what we need? I didn't think so. >add that much clarity. But in any case, you have that second DUP in the >wrong place (IMHO). It should read: >: .beers dup .NUMBER ." bottle" dup .PLURAL ." of beer" ; > ." doesn't take a numeric parameter, it takes a counted string. I do believe you're right. I had done it this way originally, but decided that it wasn't clear what I was pluralising. I think I like your point, though. I was trying to hide too much information. >>>: onwall ( -- ) ." on the wall." cr ; >>This word is actually poorly named. Its name appears to tell us what it >>does, but actually it does more (cr). In addition, the name actually tells >>us HOW it does rather than WHAT it does. A better name might be ".WHERE", >>and it should omit the cr. Try >>: .WHERE ( -- ) SPACE ." on the wall." ; > Okay, having CR in there was probably a bad mistake on my part, and I >don't think the name I gave it is that bad, but I can live with 'where'. Just a sec-- I didn't say "where", I said ".where". That dot is the important part-- I could live with ".onwall" (although I would be less content). IMO, if you're going to name it something like onwall, you should just put the code straight into the calling word. In this case, the only purpose that I can see for factoring the code out is to induce generality, and if you give it a specific name you give up that purpose. (Of course, this is just a silly example, but I think it's very instructional, and some pretty nice Forth code to boot). >>>: bottles ( n -- ) >> DUP >> 1 swap do >> I .beers .where cr >> I .beers [char] ! emit cr >> ." Take one down, pass it around ... " cr >> I 1- .beers .where cr >> -1 +loop >> ." Go to the store and buy some more;" cr >> .beers .where cr >> ; > I spotted a bug in the code that probably would have shown up if you had >run the code. The next to last line should probably be: > 99 .beers .where cr Gotcha. Look at the stack comment for this word-- we have to use that number of beer bottles throughout the song. That's why I put the DUP in at the top. On the other hand, it also got me-- my code wasn't maintainable, mainly because I didn't document that. So the joke's on me! >>That's the value of writing maintainable code; when someone else knows the >>specifications better they can change your code to fit and say "see, I told >>you so." > So, was my code easy to modify? It was awesome. > -spc (Still concerned about his code maintainability 8-) -Billy From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: Readable-Forth Rules Date: Sat, 17 Feb 1996 09:35:52 -0500 Message-ID: <4g6idt$aie@sdcc12.ucsd.edu> References: <4evfv1$27k@cloner3.netcom.com> <4fdkrn$k04@newsbf02.news.aol.com> <4g1ds9$96c@sdcc12.ucsd.edu> wilbaden@netcom.com (W.Baden) wrote to us all: >With the exception of "Feature the stack machine" -- which I >don't understand -- there isn't any "rule" that is particular to >Forth. That's a facinating observation. I would disagree in at least one case, though: we say that there should be one action per word, while others (in other languages) are quoted as saying "don't combine functions until you know how to do so." The idea of actually combining functions is repellant to a Forther; in fact, we need urgings to not seperate functions until we know how to (which is part of the meaning of the "one action per word"). >The conclusion therefore is that there is nothing special about >making readable Forth. All you have to do is follow general >guidelines good for any language. >If this is so, you should say it. It doesn't seem to me to be true, though. Or at any rate, if it is, the results of saying it is to make programmers that write Pascal-like Forth code (or C-like, or Scheme-like, or...); although none of these languages are bad, Forth DOES have its own style, and that style needs to be observed, at least officially (of course, if your application gets written and maintained better in a Pascal style, then go for it!). I am reminded of some compression code written in Forth-- was that you who wrote it?-- which looked like Pascal. It was set up in HUGE functions. I might have understood it if I already understood the algorithm, but not otherwise. To all appearances, the author had just made a direct translation without any real understanding. No offence, I hope. I'm told you don't offend easily, though. >Procedamus in pace. Wil Baden Costa Mesa, Califoreadable >P.S. What does "Feature the stack machine" mean? That was explained in one of the articles posted with the original rules. To make a long story short, it means that in all your efforts to change the appearance of the language to more closely match your domain, you can't get rid of the deepest feature of the language, the stack. So don't try to hide it; you'll only bury the meaning of your code and hinder readability. For instance, if you normally store a pair of numbers like this ( x y -- x y ), but you have a section of code like this: DOSOMETHING SWAP 1+ SWAP DOANOTHER One natural inclination is to put the SWAPs into that DOnnn words. Wrong. The reader will be decieved, thinking that the y value is being incremented when it's not. On the contrary, be bold! If you're not busy being shy about the stack machine perhaps you'll have time to make it look good. As a parallel example in a completely different language, let me show you something in a specialized hobby language. 7 $^>91+v ?95+vv?94+vv >96+v9>93+v # + ># v<# >>>> >>>.@ 123 >^456#9 ^?^#?#^?^ 7 ^ ## < 8 + > > ^# < ^< That's a random number generator in a language called 'befunge'. Don't you suppose that the author is ashamed of it? Then let me show you an earlier version of the same program (by a different author). v @.< >94+ # ^ v < ^ # >5* >> ^ 2 56 ^ v?vv?v# ?#^?7^ 999999 # 8 ^ 76532 >1 > ^ +++++ v2?4 ^ 3 ^ >>>>>>>>>>>>>^ This language, you see, is two dimensional-- control is directed by those little arrows. The question marks direct control in one of the four directions randomly. This language is a toy, true; its only purpose is to create things like that. Nonetheless, I think that there's something of beauty in there, and I think that the same beauty lies inside Forth. Don't be ashamed of it. Those authors could have been ashamed of their language; they could have made that generator much more linear. They didn't. We shouldn't either. -Billy From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multi-line comment Date: 18 Feb 1996 07:37:53 GMT Message-ID: <4g6l0h$c5v@cloner2.ix.netcom.com> References: <4eovo7$sab@cloner3.netcom.com> <4fjihk$14n8@seminole.gate.net> <4g02gf$429@ixnews6.ix.netcom.com> <4g45em$ksg@hopi.gate.net> X-NETCOM-Date: Sat Feb 17 11:37:53 PM PST 1996 In <4g45em$ksg@hopi.gate.net> spc@gate.net (Sean 'Captain Napalm' Conner) writes: > My code cleaned up a bit: >: input? ( -- f ) >in @ source nip > if refill else true then ; >: get>in ( -- c ) source drop >in @ chars + c@ ; >: advance ( -- ) 1 >in +! input? drop ; >: getchar ( -- [c] f ) input? dup if get>in swap advance then ; >: comment ( -- ) > char begin getchar while over = if drop exit then repeat ; immediate This looks better to me. I have a couple of minor concerns. : input? ( -- f ) begin >in @ source nip < 0= while refill 0= until 0 else true then ; We need to test >IN < #TIB , because the standard doesn't say what happens when >IN > #TIB . That's an ambiguous condition, I don't know what might happen then. Of course with your compiler nothing bad happens. Also, your input? doesn't do REFILL until after you've read one garbage character. That could give you a nasty rare intermittent bug. I made a loop because I don't want to read a garbage character when a line is empty. (Another nasty intermittent bug.) : advance ( -- ) 1 >in +! ; We don't need to do input? twice. Doing it twice does protect you from a single blank line, but that isn't enough. If we've just read a character (which we did or we wouldn't be doing advance) then >IN < #TIB and we can afford to add 1. : comment ( -- ) char begin getchar while over = if drop exit then repeat drop ; immediate Get rid of the delimiter even if you reach the end of the file. Another possible approach: : comment ( -- ) char begin getchar while over = until then drop ; immediate Or if the extra THEN bothers you, : comment ( -- ) char begin getchar while over - while repeat drop ; immediate >>One approach would be to put a dummy value under the flag, >>which you would then solemnly remove when the flag was false. Some >>ways this is silly, but it does have the virtue of keeping the stack >>balanced, which could help if you try to reuse the code for something >>else and it could help when you look at it later. Or not. > I guess this is according to tastes then. I have no problem with >returning a variable number of items, as it's usually either an okay >status with the data requested being returned, OR a failure indication >and some form of error code (or just the failure indication). Yes, it's definitely a matter of taste. I feel like it's better to keep the stack balanced, but sometimes I don't do it. Your way might really be better, I dunno. >>Another approach is to combine the flag and the data. If you know >>you'll never have a 0 character (which seems likely in source code, >>which shouldn't include characters that special) then you can let the >>character itself be the flag. That can cut down on stack noise, but >>sometimes it doesn't. > This is something I don't like, as I get enough of it in C, thank >you very much (and in my opinion, is not a good design factor). You could be right. >>A third possibility is to unfactor. You factored getchar out of some >>other code, and you have to pass a flag to the other code to let it >>make a decision that's already been made. You might put the rest of >>the code _inside_ getchar. >>: char-routine ( -- ) >> input? if get>in advance do-char else no-char then ; > Hmm, that is a thought, but the code you presented above looks >questionable. I assume you have to set what do-char and no-char do >(possibly with Brodie's DOER/MAKE ?), and as is, since char-routine >doesn't take or return anything, any data you pass between >do-char/no-char and the higher code has to be passed (if any) in >global variables. > Or am I reading what you are suggesting wrong? That isn't at all what I meant! Here's the thing -- you make get-char do all the work, and it gets complicated. If we factor it -- >: getchar ( -- [c] f ) input? dup if get>in swap advance then ; : get-char ( -- c ) get>in advance ; we have 2 routines instead, input? which gives us the flag and get-char which gives us the character. Then any place we'd use getchar, we use these. .. getchar if ( c ) .... else ( ) ... then .. input? if get-char ( c ) .... else ( ) ... then .. getchar while ( c ) ... repeat ( ) ... .. input? while get-char ( c ) ... repeat ( ) ... I like it better, but again it's a matter of taste. > My brain hurts 8-) Sorry I led you down that blind alley, I didn't mean to. > And there are instances that I can think of where I would want to >use getchar (say, compiling strings into memory using a different >format than ANS Forth for example). Again, if they come from an input buffer and you want to keep going until you can't refill it, your own program will probably want to do input? to see whether it's done, and then do get-char if it isn't. If you want to stop earlier, then you can still use get-char but you'll have to write a new input? that does what you want. I don't see a problem here. Where I have a problem is that I went all this time without noticing the blank-line bug! And it wasn't until time-before-last that I noticed the end-of-line bug. This stuff is tricky, and I didn't notice. And here's something else -- when I wrote it my own way I _did_ notice those. I struggled with them when I used PARSE . Then I looked at your simple code and I thought you'd just breezed by them, and it took until now for me to see that you didn't. Wicked intermittent bugs, that you could test a whole lot and they'd never show up until you got precisely the wrong source code on the wrong compiler. Say, |last-word| comment | here is a comment that will go on for a number of lines, we just executed the "last-word" command that we can't quote exactly because it would end the comment to do so. But soon we will get back to work. | < serious work here > If there's an "a" command, this code is likely to result in will ? and it would be pretty disconcerting figuring it out, when what you really want is to get your own code running. My standardizer would catch these, but I just looked at your code with my own eyes and I completely missed the problems. Subject: Paisley Forth Page - Updates Message-ID: <312A0C7B.65E@paisley.ac.uk> From: Peter Knaggs Date: Tue, 20 Feb 1996 18:01:31 +0000 X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Access Time: The University of Paisley, which hosts my "Forth Page" has just changed its network link to a new 155Mbit line to ClydeNET (Glasgow), with a 10Mbit line to SuperJANET (the rest of the world), a significant inprovment over the old 48Kbit (JANET) line! Upgraded Server: They have also updated the server software which means that you should now access the page with a fully qualified URL: http://www.paisley.ac.uk/~cis/forth/index.html Please note however, that they are planning a new www server, so this page may well move in the near future. I will post again, when I know more. Forth Bibliography Mirrored: The "Searcable Bibliography" is now mirrored as a part of the "Computer Science Bibliography Collections". This can be accessed from a quite a few mirror sites from Asia, Europe and North America. http://liinwww.ira.uka.de/bibliography/Compiler/forth.html Now Mirror www.forth.org: I have now started to mirror the FIG site (www.forth.org). This mirror is updated at around 0400 GMT and can be accessed from the main Forth page or directly from the URL: http://chaos100.paisley.ac.uk/~cis/mirrors/forth/fig.html (Again, this may be moving in the near future) And Finally... There is still much to do, and much going on, currently related to the Rochester Forth Conference and the Forth Biblography. As always any comments, suggestions and help accepted. -- Peter Knaggs mailto:pjk@paisley.ac.uk http://www.paisley.ac.uk/~cis/forth/index.html http://www.paisley.ac.uk/~cis/staff/pjk.html From: "Paul E. Bennett" Subject: Re: Simple marketing simulation Rationale Date: Tue, 20 Feb 96 12:39:23 GMT Message-ID: <824819963snz@tcontec.demon.co.uk> References: <4e0fus$8rg@ionews.ionet.net> <4ej7o8$2mn@butch.lmsc.lockheed.com> <4gbbtt$5tb@cloner3.netcom.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4gbbtt$5tb@cloner3.netcom.com> JEThomas@ix.netcom.com "Jonah Thomas" writes: > > I supposed that the number of professional programmers who take up > Forth as a hobby is about 200/year. Pure guesswork, comp.lang.forth > gets 10 or so message a year from professionals who want to learn > Forth, and we can figure for every one who asks probably a 2nd one > manages to hunt down the FAQ, that's 20. The number is unlikely to be > more than 200, and the number who pick up enough to get hired to use > Forth is probably less than 80 in one year. This has the gut feel of being about right. > One glaring lack here is that the number of projects is assumed not > to change. That's fixable, of course. One thing that is certain, a higher percentage of projects are getting embedded controllers included. I am uncertain what the rate of change is but it is apparently significant. > All of these numbers are very soft; they're written in Jello. I don't > know anything about the impact of the Forth courses put on by all the > major vendors, for example. Better estimates (or even just alternate > ones) are welcome. Unless someone is prepared to do some survey work it is likely to remain as written in Jello. One or two other considerations: As some Forth programmers or engineers who use Forth get promoted to management positions they will gain influence over how work gets done. This may lead to some projects using Forth rather than any other language. This in turn results in more Forth programmers. With ANS Forth now in place and an ISO/IEC version impending Forth may be gaining a wider acceptance in the world. With that being the case, more programmers may begin to try Forth. A proportion of those that try and like will become more committed to using it. This will also increase the number of hobbyist and professional Forth programmers. I write this as I have just completed a long phone interview, in which a researcher posed a series of questions about our development processes. I stated that, with all the advantages that Forth really gives the developer, I could not understand why everyone developing embedded control systems was not using Forth. I feel a sense of having covered some of this ground before. Perhaps we really do need to look at ways in which Forth can be given a wider exposure. I think that one way is if we all took the greatest care in coding our own applications and were able to offer c-of-c for each word in the application and available to the user with a full audit trail to back it up. This is not so problematic as it at first appears. Perhaps a new thread is needed for this last bit. -- Paul E. Bennett peb@transcontech.co.uk Going Forth Safely From: "Paul E. Bennett" Subject: Re: ESTEREL and? versus? FORTH Date: Tue, 20 Feb 96 20:11:32 GMT Message-ID: <824847092snz@tcontec.demon.co.uk> References: <788@purr.demon.co.uk> <823942200snz@mpeltd.demon.co.uk> <4ga48a$l4d@news-rocq.inria.fr> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4ga48a$l4d@news-rocq.inria.fr> sorel@lully.inria.fr "Yves Sorel" writes: > There have been several posts on this subject these last days. > > Jack Campin made a pretty good (for a newcomer) presentation of ESTEREL and > pointed out that the Forth community may take advantage of the formal methods > promoted by the Synchronous Languages. > Forth and Synchronous Langages should not be seen as competitors in the domain > of embedded reactive systems, but rather as complementary tools. I did not say he didn't make a good case. He admitted that he had not used ESTEREL himself and so he had no real experience of it. What he was expressing was an opinion based on his reading and understanding of a paper by someone else who was involved with ESTEREL in some way. > Forth is very good for interactive debugging of prototype hardware and of > low level software upto "canned modules of know quality". Forth is extremely good at that. It is a very good way of producing equipment with software embedded in it which you can certify as complying to a specification without involving untold mathematical formulae and a computerised proof checker. Forth is essentially so simple that it does not need expensive tools (perhaps thats why it gets up the nose of some software people). > But when it comes to writting and debugging reactive applications with a > lot of different event sources, periodic and aperiodic, with a lot of mode > changes, state machines are heavy to debug extensively with imperative > languages such as Forth, even using MPE's tool boxes. This depends in some part on the system architecture implemented. Many companies producing control systems still have too much of the central processing box view. Taking the Forth philosophy further forward in the design process and applying it to the whole System yeilds an architecture that may involve more individual processors with communications than other techniques might suggest. This has been my experience. > This is the first place where formal reasonning, on automata and more > generally on partial orders, provided by Synchronous Languages, allows an > automated exploration of all reachable states and automated proofs of > intrinsic or specified properties, and all this independently of the target > architecture. These automated verifications made at compile time by > Synchronous Languages save a lot of development time compared with the usual > debugging in Forth. All the supposed benefits listed above usually involve very costly tools. Such expensive tools are normally beyond the budget of many small companies and foster an elitism that begins to lock out new-comers. Forth systems can be obtained easily at low cost. Better Forth tools can be obtained at slightly higher cost. There is a natural progression path of tools from simple hobbyist level to fully professional level. > > Moreover, when it comes to writting and debugging such reactive applications > on multicomponent hardware (parallel, distributed, multiprocessor, > multisensor, multiactuator, distributed data), and furthermore under real > time constraints (reactive + bounded response time) and all this while > trying to minimize hardware resources, the programmer's job becomes a > nightmare with Forth, as with most other imperative languages. I would maintain that such systems are not really that much of a problem with Forth. It is far from being a nightmare. [rest snipped] My point in the last reply was I made was that if, from reading the paper on ETSEREL, Jack Campin thought it was a suitable language for Safety Critical Applications he is welcome to experiment with himself occupying the danger seat. I personally see no need to involve any other software regime in my own systems. My embedded systems have Forth at the base level and an Application Specific Language built using Forth at the user level. It is all certified and is, so far, very resilient. Some of my systems have been working in very harsh environments (including nuclear power plant). I am essentially a hardware engineer who has had to adopt software as an additional skill. This may colour my view slightly. However, I know that I can utilise components in Forth as well as the TTL logic IC's we all know and love. -- Paul E. Bennett peb@transcontech.co.uk Going Forth Safely From: 100647.3306@compuserve.com (PETREMANN Marc) Subject: Re: F68HC11 PROGRAM DEVELOPEMENT Date: Tue, 20 Feb 1996 22:22:31 GMT Message-ID: <4gdhu2$67d@dub-news-svc-4.compuserve.com> References: <4g34bl$vqj@news.computek.net> "William H. Stewart" wrote: >PROGRAMMERS USING NEWMICROS F68HC11 MPU do you want to exchange >programming information I have writing for many years ago a assembler for 68HC11. Here is the listing for TURBO-Forth: LISTING: ECHO OFF \ Suppression �cho �cran en cours de compilation WARNING OFF \ Inhibe message "Existe d�j�" \ Compilation conditionnelle et traitement multi-langue : ?\ NOT IF [COMPILE] \ THEN ; IMMEDIATE : EXIST? ( --- fl) DEFINED NIP IF TRUE ELSE FALSE THEN ; \ Mot de suppression de liens d'un mot du dictionnaire : FORBID ( --- ) BL WORD CAPS @ IF DUP COUNT UPPER THEN CURRENT @ OVER SWAP HASH TUCK @ (FIND) 0= ?MISSING >LINK SWAP BEGIN 2DUP @ = NOT WHILE @ REPEAT >R @ R> ! ; \ oubli vocabulaire ASSEMBLER origine pour ne pas perturber le m�ta-compilateur FORBID ASSEMBLER \ oubli vecteur table traitement codes ASCII <32 : NEW-CC CC ; FORBID CC ECHO @ ECHO ON \ ******************************************************** \ * * \ * A S S E M B L E U R M O T O R O L A 6 8 H C 1 1 * \ * * \ ******************************************************** \ auteur: Marc PETREMANN 18/02/91 \ mis � jour 29/05/94 \ (C) MP7 ECHO ! \ D�finition de , et C, version FORTH en imm�diat : F[C,] COMPILE C, ; IMMEDIATE : F[,] COMPILE , ; IMMEDIATE ONLY FORTH ALSO ROOT DEFINITIONS DECIMAL \ Cr�ation vocabulaire ASSEMBLEUR 68HC11: ASSEMBLER VOCABULARY ASSEMBLER \ D�finition des vecteurs de m�ta-compilation ASSEMBLER DEFINITIONS ONLY ASSEMBLER ALSO FORTH ALSO DEFER C, DEFER , DEFER HERE DEFER ?>MARK DEFER ?>RESOLVE DEFER ? ( ---) \ Adressage �tendu, valeur 1 1 ADRMODE ! ; : ,X ( ---) \ Adressage index� sur x, valeur 3 3 ADRMODE ! ; : ,Y ( ---) \ Adressage index� sur y, valeur 4 4 ADRMODE ! ; : 0ADRMODE! ( --- ) \ remise � z�ro de ADRMODE ADRMODE OFF \ 12 ?TAB ( � supprimer d�s que plus de mode d�bogage) BUFFER COUNT -TRAILING TYPE CR \ ; HEX : DIR>EXT ( opr adr --- opr adr ) \ convertit un adressage direct en adressage �tendu ADRMODE @ 0= \ on teste si le mode d'adressage est nul, IF \ si OUI, on teste la taille de l'op�rande SWAP \ inverse op�rande et adresse DUP 0FF > \ on teste si op�rande num�rique sup�rieur � 0FF IF ,> \ on bascule en adressage �tendu THEN SWAP \ on restaure ordre normal de adresse et op�rande THEN ; : ERROR-ADRMODE ( fl ---) \ message d'erreur sur mode d'adressage ABORT" Mode d'adressage interdit" ; .( .) \ D�finition des mn�moniques travaillant en adressage INHERENT 8 bits : MEM1: ( c --- en compilation | --- en ex�cution) CREATE F[C,] DOES> ADRMODE @ ERROR-ADRMODE C@ A[C,] 0ADRMODE! ; HEX 01B MEM1: ABA \ A+B->A 03A MEM1: ABX \ IX+00:B->IX 048 MEM1: ASLA \ d�calage logique contenu de A � gauche 058 MEM1: ASLB \ d�calage logique contenu de B � gauche 005 MEM1: ASLD \ d�calage logique � gauche 047 MEM1: ASRA \ d�calage logique contenu de A � droite 057 MEM1: ASRB \ d�calage logique contenu de B � droite 011 MEM1: CBA 00C MEM1: CLC 00E MEM1: CLI 04F MEM1: CLRA 05F MEM1: CLRB 00A MEM1: CLV 043 MEM1: COMA \ FF.A->A 053 MEM1: COMB \ FF.B->B 019 MEM1: DAA \ Ajustement d�cimal A 04A MEM1: DECA \ A-1->A 05A MEM1: DECB \ B-1->B 034 MEM1: DES \ SP-1->SP 009 MEM1: DEX \ IX-1->IX 001 MEM1: DUMMY \ SYNONYME DE NOP 003 MEM1: FDIV \ D/IX->IX;r->D 002 MEM1: IDIV \ D/IX->IX;r->D 04C MEM1: INCA \ A+1->A 05C MEM1: INCB \ B+1->B 031 MEM1: INS \ SP+1->SP 008 MEM1: INX \ IX+1->IX 048 MEM1: LSLA \ d�calage logique contenu de A � gauche 058 MEM1: LSLB \ d�calage logique contenu de B � gauche 005 MEM1: LSLD \ idem ASLD 044 MEM1: LSRA \ d�calage logique contenu de A � droite 054 MEM1: LSRB \ d�calage logique contenu de B � droite 004 MEM1: LSRD \ d�calage logique � droite 03D MEM1: MUL \ AxB->D 040 MEM1: NEGA \ 0.A->A 050 MEM1: NEGB \ 0.B->B 001 MEM1: NOP \ pas d'op�ration 036 MEM1: PSHA \ A->STK,SP=SP-1 037 MEM1: PSHB \ B->stk,SP=SP-1 03C MEM1: PSHX \ IX->stk,SP=SP-2 032 MEM1: PULA \ SP=SP+1,A<-stk 033 MEM1: PULB \ SP=SP+1,B<-stk 038 MEM1: PULX \ SP=SP+2,IX<-stk 049 MEM1: ROLA \ rotation contenu A � gauche 059 MEM1: ROLB \ rotation contenu B � gauche 046 MEM1: RORA \ rotation contenu de A � droite 056 MEM1: RORB \ rotation contenu de B � droite 03B MEM1: RTI \ retour d'interruption 039 MEM1: RTS \ retour de sous-programme 010 MEM1: SBA \ A-B->A 00D MEM1: SEC \ 1->C 00F MEM1: SEI \ 1->I 00B MEM1: SEV \ 1->V 0CF MEM1: STOP \ 03F MEM1: SWI \ (voir op�rateurs sp�ciaux) 016 MEM1: TAB \ A->B 006 MEM1: TAP \ A->CCR 017 MEM1: TBA \ B->A 000 MEM1: TEST \ adr bus count 007 MEM1: TPA \ CCR->A 04D MEM1: TSTA \ A.0 05D MEM1: TSTB \ B.0 030 MEM1: TSX \ SP+1->IX 035 MEM1: TXS \ IX-1->SP 03E MEM1: WAI \ reg pile Wait 08F MEM1: XGDX \ IX->D,D->IX \ D�finition des mn�moniques travaillant en adressage INHERENT 16 bits : MEM2: ( u --- en compilation | --- en ex�cution) CREATE F[,] DOES> ADRMODE @ ERROR-ADRMODE @ A[,] 0ADRMODE! ; 0183A MEM2: ABY 04F5F MEM2: CLRD 01809 MEM2: DEY 01808 MEM2: INY 01803 MEM2: PSHY 01838 MEM2: PULY 0163D MEM2: SQRA 0173D MEM2: SQRB 01830 MEM2: TSY 01835 MEM2: TYS 0188F MEM2: XGDY .( .) \ Codes de branchement relatif court \ transforme une adresse cible absolue en valeur relative 8 bits VARIABLE REL? \ Flag bool�en indiquant si valeur indiqu�e d�j� relative : >8REL ( adr | relbr --- relbr) \ Si valeur non relative, la rend relative REL? @ NOT IF HERE - THEN 2- \ soustrait 2 pour tenir compte position opcode + val_br DUP -80 7F BETWEEN NOT \ teste si branchement pas hors limite ABORT" Branchement hors limite" REL? OFF ; \ d�sactive indicateur de branchement relatif : REL ( ---) \ force l'assemblage d'un branchement relatif REL? ON ; : MEM3: ( c ---) \ d�finition des branchements relatifs CREATE F[C,] DOES> C@ A[C,] >8REL A[C,] 0ADRMODE! ; 024 MEM3: BCC 025 MEM3: BCS 027 MEM3: BEQ 02C MEM3: BGE 02E MEM3: BGT 022 MEM3: BHI 024 MEM3: BHS 02F MEM3: BLE 025 MEM3: BLO 023 MEM3: BLS 02D MEM3: BLT 02B MEM3: BMI 026 MEM3: BNE 02A MEM3: BPL 020 MEM3: BRA 021 MEM3: BRN 08D MEM3: BSR 028 MEM3: BVC 029 MEM3: BVS .( .) : MEM4: \ type non d�fini; macros...? CREATE F[,] DOES> @ A[,] 0ADRMODE! ; 04A26 MEM4: NEXTA 05A26 MEM4: NEXTB 00926 MEM4: NEXTX 03820 MEM4: RCVR .( .) : MEM5: \ adressage imm dir ext ind,x ind,y CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF C@ A[C,] A[C,] ENDOF \ Adr. Imm�diat 0 OF C@ 10 + A[C,] A[C,] ENDOF \ Adr. Direct 1 OF C@ 30 + A[C,] A[,] ENDOF \ Adr. Etendu 3 OF C@ 20 + A[C,] A[C,] ENDOF \ Adr. Index� X 4 OF 18 A[C,] C@ 20 + A[C,] A[C,] ENDOF \ Adr. Index� Y ENDCASE 0ADRMODE! ; 089 MEM5: ADCA 0C9 MEM5: ADCB 08B MEM5: ADDA 0CB MEM5: ADDB 084 MEM5: ANDA 0C4 MEM5: ANDB 085 MEM5: BITA 0C5 MEM5: BITB 081 MEM5: CMPA 0C1 MEM5: CMPB 088 MEM5: EORA 0C8 MEM5: EORB 086 MEM5: LDAA 0C6 MEM5: LDAB 08A MEM5: ORAA 0CA MEM5: ORAB 082 MEM5: SBCA 0C2 MEM5: SBCB 080 MEM5: SUBA 0C0 MEM5: SUBB .( .) : MEM6: \ adressage imm dir ext ind,x ind,y CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF C@ A[C,] A[,] ENDOF \ Adr. Imm�diat 0 OF C@ 10 + A[C,] A[C,] ENDOF \ Adr. Direct 1 OF C@ 30 + A[C,] A[,] ENDOF \ Adr. Etendu 3 OF C@ 20 + A[C,] A[C,] ENDOF \ Adr. Index� X 4 OF 18 A[C,] C@ 20 + A[C,] A[C,] ENDOF \ Adr. Index� Y ENDCASE 0ADRMODE! ; 0C3 MEM6: ADDD 0CC MEM6: LDD 08E MEM6: LDS 083 MEM6: SUBD .( .) : MEM7: \ adressage ext ind,x ind,y; pas d'adr imm�diat ni direct CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF TRUE ERROR-ADRMODE ENDOF \ Adr. Imm�diat 0 OF TRUE ERROR-ADRMODE ENDOF \ Adr. Direct 1 OF C@ 10 + A[C,] A[,] ENDOF \ Adr. Etendu 3 OF C@ A[C,] A[C,] ENDOF \ Adr. Index� X 4 OF 18 A[C,] C@ A[C,] A[C,] ENDOF \ Adr. Index� Y ENDCASE 0ADRMODE! ; 068 MEM7: ASL 067 MEM7: ASR 06F MEM7: CLR 063 MEM7: COM 06A MEM7: DEC 06C MEM7: INC 06E MEM7: JMP 068 MEM7: LSL 064 MEM7: LSR 060 MEM7: NEG 069 MEM7: ROL 066 MEM7: ROR 06D MEM7: TST .( .) : MEM8: \ adressage dir ext ind,x ind,y; pas d'adr imm�diat CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF TRUE ERROR-ADRMODE ENDOF \ Adr. Imm�diat 0 OF C@ A[C,] A[C,] ENDOF \ Adr. Direct 1 OF C@ 020 + A[C,] A[,] ENDOF \ Adr. Etendu 3 OF C@ 010 + A[C,] A[C,] ENDOF \ Adr. Index� X 4 OF 18 A[C,] C@ 010 + A[C,] A[C,] ENDOF \ Adr. Index� Y ENDCASE 0ADRMODE! ; 09D MEM8: JSR 097 MEM8: STAA 0D7 MEM8: STAB 0DD MEM8: STD 09F MEM8: STS : STX ( ---) \ pas de MEM9: pour un seul mn�monique DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF TRUE ERROR-ADRMODE ENDOF \ adr imm 0 OF 0DF A[C,] A[C,] ENDOF 1 OF 0FF A[C,] A[,] ENDOF 3 OF 0EF A[C,] A[C,] ENDOF 4 OF 0CDEF A[,] A[C,] ENDOF ENDCASE 0ADRMODE! ; : STY ( ---) \ pas de MEM10: pour un seul mn�monique DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF TRUE ERROR-ADRMODE ENDOF \ adr imm 0 OF 018FF A[,] A[,] ENDOF 1 OF 018DF A[,] A[C,] ENDOF 3 OF 01AEF A[,] A[C,] ENDOF 4 OF 018EF A[,] A[C,] ENDOF ENDCASE 0ADRMODE! ; : MEM11: ( ---) \ CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF C@ A[C,] A[,] ENDOF \ adr imm 0 OF C@ 010 + A[C,] A[C,] ENDOF 1 OF C@ 030 + A[C,] A[,] ENDOF 3 OF C@ 020 + A[C,] A[C,] ENDOF 4 OF 0CD A[C,] C@ 020 + A[C,] A[C,] ENDOF ENDCASE 0ADRMODE! ; 08C MEM11: CPX 0CE MEM11: LDX : MEM12: ( ---) CREATE F[C,] DOES> DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF 018 A[C,] C@ A[C,] A[,] ENDOF \ adr imm 0 OF 018 A[C,] C@ 010 + A[C,] A[C,] ENDOF 1 OF 018 A[C,] C@ 030 + A[C,] A[,] ENDOF 3 OF 01A A[C,] C@ 020 + A[C,] A[C,] ENDOF 4 OF 018 A[C,] C@ 020 + A[C,] A[C,] ENDOF ENDCASE 0ADRMODE! ; 08C MEM12: CPY 0CE MEM12: LDY : CPD ( ---) \ pas de MEM13: pour un seul mn�monique DIR>EXT \ conversion adressage direct -> �tendu �ventuel ADRMODE @ CASE 2 OF 01A83 A[,] A[,] ENDOF \ adr imm 0 OF 01A93 A[,] A[C,] ENDOF 1 OF 01AB3 A[,] A[,] ENDOF 3 OF 01AA3 A[,] A[C,] ENDOF 4 OF 0CDA3 A[,] A[C,] ENDOF ENDCASE 0ADRMODE! ; eof \ provisoire \ Macros de branchements pour structures de contr�le \ 70 CONSTANT 0= \ 70=code de JNZ \ 60 CONSTANT 0<> \ 60=code de JZ \ 50 CONSTANT CS \ 40=code de JNC \ : NOT ( cond --- not-cond.) \ inverse la condition 0=, 0<> ou CS \ 10 XOR ; .( .) \ Cr�ation des mn�moniques de branchements relatifs .( .) \ Cr�ation des structures de contr�le d'assemblage : IF A[C,] ?>MARK ; : THEN ?>RESOLVE ; \ : ELSE (SJMP) IF 2SWAP THEN ; : BEGIN ? References: <4f1onp$pjc@sdcc12.ucsd.edu> <4f477b$dr0@navajo.gate.net> <4g6idq$aid@sdcc12.ucsd.edu> <4g8be0$clc@navajo.gate.net> X-NETCOM-Date: Tue Feb 20 2:47:31 PM PST 1996 In <4g8be0$clc@navajo.gate.net> spc@gate.net (Sean 'Captain Napalm' Conner) writes: >In article <4g6idq$aid@sdcc12.ucsd.edu> wtanksle@sdcc15.ucsd.edu (William Tanksley) writes: >>The main point is that it changes a multi-line definition without clear >>boundaries or coherent purpose into several smaller, fully-defined and quite >>seperate definitions. You're code wasn't wrong by any means, but this is >>(IMO) better. At least it follows the rule: one action for every name. > Okay, I can live with that. Although I've noticed some of the other BEER >entries have about twice the number (if not more) words than mine, and it >seemed to obscure an otherwise simple program. There may be a point where >having too many words is just, too many words. Yes. >>I do believe you're right. I had done it this way originally, but decided >>that it wasn't clear what I was pluralising. I think I like your point, >>though. I was trying to hide too much information. > Which is another interesting point. I have a friend who codes in C, and >while we share a similar coding style (indentation, brace placement, >whitespace usage) he tends to be more verbose and attempts to hide the >implimentation details at EVERY level (to the point where it looks like he's >trying to hide the implimentation details from the implimentation!). > At what point is hiding information a bad thing? When it makes coding, debugging, documentation and maintenance harder. There are general rules that generally work, and it's important to notice when they fail (or when they're being misapplied, which may be the same thing). I'm not completely clear on this, but it's starting to gel a little. I have a friend who used to do assembly routines using the Amiga OS. He memorized lots of special addresses that did important things. When he got into Forth, he _wanted_ to keep using his magic numbers, because for him they were more expressive than (longer) names. He _knew_ the numbers, and he'd have trouble remembering the names. I told him he should make up names and use them so other people could read his code, and to ease changes. He said no. AmigaDOS was _not_ going to change the numbers. And the kind of people who'd look at his code would know the magic numbers. Looking back on it, I think maybe he was right. And if I ever need to follow his code, I can look up each magic number once, the first time I need it, and find-and-replace it in my scratch copy. I'll only have trouble if the same magic number has 2 different meanings. It likely won't be a big deal. But it would have been a very big deal for him to remember a lot of new names. It isn't good when information hiding slows down production. Better when you can find ways to get the code working and tested fast, and still do the information hiding that's worth doing, and also make it easy to do more, later. Information hiding that increases the complexity too much, is worthless. The best information hiding simplifies the code. When you hide information, it needs to be done so you can describe the result simply, though maybe at a higher level of abstraction. If you can't say instantly what it is you've hidden, you're heading for confusion. That's what I've got now. Maybe more will come together later.