From: Eugen Leitl Subject: a threaded-code WSI-suitable CPU Date: Tue, 28 Mar 1995 21:43:13 +0200 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: ui22204@sun2 In-Reply-To: <3kid07$k2m@ixnews4.ix.netcom.com> Hi 4th.netters, when I happened to play around designing an WSI (wafer-scale-integration)-suitable CPU/computer I took a close look at Novix... I ended up with an integrated CPU/RAM/Router die with hypergrid topology and a bad-word DRAM software remap, but that's not the point. Since die size is way of limited because of die complexity/defect density, only a small RAM area is available..., Taos is a 12 kByte nanokernel OS all right, but code density becomes quite a problem when only 1-2 MByte RAM are available in toto. Direct support of threaded code by the (very RISCish) core machine becomes quite an argument, then. Additionally, very broad buses as additional boundary condition make an emergent bi-stack threaded-code machine (with SRAM-based 4th kernel) quite obvious... Caching _both_ the data and the return stack with code segments as well and providing a (small) SRAM area for the kernel appear quite naturally to me. (The CPU/router seem not to surpass 1 MTransistor/die complexity, though). Estimations seem to indicate the memory bandwidth to be about 400 times of that of a Pentium.. Since WSI allows about 64 dies/wafer with over 90% yield the resulting performance seem to be quite _spectacular_... I'd like to discuss some design issues (it's all bullshit, anyway) here, provided there is any interest. Comments, please? -- eugene From: s1476@rfhs0002.fh.uni-regensburg.de (Dieter Meidenbauer) Subject: 68020 Assembler? Date: 28 Mar 1995 20:25:59 GMT Reply-To: dieter.meidenbauer@rz.fh-regensburg.d400.de Hi folks, does anybody knows about sources for an free available 68020 Forth-Assembler (preferably post-fix) ? Dieter. From: PS@chocolat.demon.co.uk (Paul Shirley) Subject: Re: Interfacing stack-framed languages Reply-To: PS@chocolat.demon.co.uk X-Posting-Host: chocolat.demon.co.uk Date: Tue, 28 Mar 1995 23:30:47 +0000 brmcf@utkux1 "Bruce McFarling" writes: > I think this is a great idea; the implementation of a >C-frame and a Pascal-frame will have the order reversed and disagree on >who cleans up afterwards, but until someone says otherwise, I'll continue >to believe that most stack frame languages use on approach or the other, >and don't mix and match. So two vocabularies could co-exist with the >same syntax, one for C-frame languages, and one for P-frame languages. ...not if you use Windows... which uses both C and Pascal calling mode (and possibly a third one...not sure?). What would be nice is some code to read a C header file, decode the function prototypes in it and build the correct interface code automagically. (I can almost hear the shocked gasps...) -- Paul Shirley: SemiProfessional Coffee & Chocolate Taster Date: 29 Mar 1995 00:56:00 +0100 From: Dusan@vukic.forth-ev.de (Dusan Vukic) Subject: Re: Need Opinions X-Charset: ISO-8859-1 I have developed some products with New Micros 68hc11 . I found it quite good in all too. But it is big handicap that kernel is in mu-P's ROM , and it is not possible to take mu-P with non multiplext address with higher clock as 68HC11F1. ## CrossPoint v3.02 ## From: rdr@sydney.DIALix.oz.au (Richard de Rozario) Subject: Re: Pygmy Date: 29 Mar 1995 18:23:53 +1000 NNTP-Posting-User: rdr sa435@utb.shv.hb.se (Tommy Hallgren) writes: >Hi! >I ftp'd Pygmy some days ago and tried it this morning. I find it very strange >that DO and FOR doesn't work when I start Pygmy.com. What to do? Can you give some particulars? The following should work: : TEST 10 FOR I . NEXT ; It should print 10 integers in descending order. RdR From: bevan@cs.man.ac.uk (Stephen J Bevan) Subject: Re: Single-stack forth Date: 29 Mar 1995 08:51:42 GMT <3kkmfd$lp8@lastactionhero.rs.itd.umich.edu> In-reply-to: Hasdi R Hashim's message of 20 Mar 1995 19:53:17 GMT In article <3kkmfd$lp8@lastactionhero.rs.itd.umich.edu> Hasdi R Hashim writes: In article Stephen J Bevan, bevan@cs.man.ac.uk writes: >Could you expand on why the use of two stacks makes efficient code >generation difficult? 80x86 example. Double stack. adding two integers ( 10 20 add_em output_i ) [ code deleted ] Any other questions? If your claim is specific to the 80x86 architecture then no (since I don't know enough about it to comment). If your claim covers other architectures (SPARC, 68K, ... etc.) then I would like to see your argument phrased in terms of those architectures. From: bevan@cs.man.ac.uk (Stephen J Bevan) Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: 29 Mar 1995 08:57:01 GMT <3k72cn$sqj@transfer.stratus.com> <3k9mv7$sqj@transfer.stratus.com> In-reply-to: nick@sw.stratus.com's message of 16 Mar 1995 15:54:15 GMT In article <3k9mv7$sqj@transfer.stratus.com> nick@sw.stratus.com (Nicolas Tamburri) writes: That is certainly workable. I wish I'd thought it up when I was working on it. (That is the problem with approaching a Forth problem with a C attitude.) Now the "->" would need to be replaced with another token, since "->" is almost universally used to store into local variables or VALUES. I thought TO was used in ANS Forth, not "->". From: herren@alcatel.ch (Andreas P. Herren) Subject: Forth to C Compiler/Preprocessor Date: 29 Mar 1995 10:59:07 GMT Reply-To: herren@alcatel.ch Keywords: Forth C Compiler I am looking for a Forth to C compiler or preprocessor. Does anybody know anything about such a compiler. Are there such compilers in the public domain? Thanks --- Andreas P. Herren | Internet : andreas.herren@alcatel.ch Dipl. Informatikingenieur ETH | X.400 : c=CH a=arCom p=Alcatel Member of the ACM and IEEE | s=Herren g=Andreas | +-------V-------+ Alcatel STR | Phone : +41 1 465-3642 | A L C A T E L | Friesenbergstr. 75 | FAX : +41 1 465-2698 +---------------+ CH-8055 Zuerich | From: fs07675@nyssa.swt.edu (Frank Sergeant) Subject: Re: 68020 Assembler? Date: 29 Mar 95 09:49:40 CST In article <3l9rcnINNpen@rrzs3.uni-regensburg.de>, s1476@rfhs0002.fh.uni-regensburg.de (Dieter Meidenbauer) writes: > does anybody knows about sources for an free available > 68020 Forth-Assembler (preferably post-fix) ? I appreciate beautiful Forth assemblers. When I had a similar question about the 68000, someone pointed me to Michael Perry's "A 68000 Forth Assembler" in _Dr. Dobb's Journal_, September, 1983, Volume 8, Issue 9, so I'll pass it on to you. I especially liked Mike's assembler. -- Frank Frank Sergeant fs07675@swt.edu (fast) f.sergeant@GEnie.geis.com (more permanent?) From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 29 Mar 1995 17:05:33 GMT In-reply-to: hbezemer@vsngroep.nl's message of Fri, 24 Mar 1995 16:16:18 GMT >>>>> "Hans" == Hans Bezemer writes: Hans> Hasdi R Hashim wrote: >> One feature of FORTH that I DO NOT plan to put in MY VERSION of >> FORTH is the existence of two different stacks: the primary >> (info) stack and secondary (system) stack. (I apologize for not >> using the correct terms). The system stack is primarily used, >> among other things, to keep track of the caller's last position >> when a primitive is called. Hans> I work with only one stack too. Only the return stack grows Hans> downward and the parameter stack upward. Forth is a unique language in that procedures ("words") have no formal parameters. It is object oriented in that all procedures are methods that manipulate the primary object of Forth: the stack, or more precisely, the parameter stack. Every Forth word has direct access to the stack, and leaves the result of its execution as a side effect to that stack. The set of Algol like block structured languages, of which Forth is not a member, typically use stack frames to implement local, or "automatic" variables. Because the scope of these variables is limited to the dynamic scope of the execution of a lexical block of source code, this stack frame mechanism works well for the semantics of these languages. Forth is radically different in this respect. It is an utterly simple language as regards its compilation and execution model; it has almost no syntax whatsoever, except that all tokens are delimited on the left and the right by whitespace, and that all non-whitespace delimited on both sides by whitespace forms a source token. The semantics of the language is such that execution proceeds in the lexical order of occurance of source tokens, and compilation can be over-ridden by immediate words to provide a very sophisticated macro facility where the macro language and the run-time language are the same exact language. This is the key to Forth's extensibility. Forth is not unique in this regard: Lisp also shares this powerful innovation. Lisp, however, does pass formal parameters to functions, and therefore it typically uses an executiomn model that looks more like a stack frame based implementation to the new programmer. But Lisp really uses a complex data structure known as the binding environment, which consists of the active binding environment, and a binding environment history implemented as a tree-like structure. This is called shallow binding. Early Lisps used deep-binding, which is almost identical to the way Forth words are compiled into the dictionary. Deep binding and shallow binding were once thought to be 2 different ways to implement the same thing, but there are subtle differences that occur related to the binding of formal parameters passed to functions. Since Forth does not have such parameters to bind, the problem does not arise in Forth, and Laboratory Microsystems' Forths use a hashed dictionary scheme that is reminiscent of a shallow bound Lisp system. >> Frankly, that's a kind of a turn off for me because it would be >> difficult for FORTH to be converted into machine language >> efficiently. I am sure that there is a FORTH compiler that can >> do that but it must be pretty ugly. Okay, some microprocessors >> support double stacks but I do not think 80x86 microprocessors >> support that. I could probably emulate the second stack on >> 80x86. Again, it would probably look ugly. The typical implementations use the normal machine hardware stack to implement the return stack (what you have been calling the system stack) and then the parameter stack is implemented using pre/post-increment/decrement modes of registers used as pointers to memory locations holding the actual stack itself. On machines that do not have auto-increment/decrement, an extra instruction will be required, but most modern machines have these modes in a single instruction, or they are RISC architectures which will execute a memory fetch or store concurrently with a register increment or decrement, so there really is no time penalty. >> C,C++,Pascal, FORTRAN, all use single stack - the information >> and the return address are pushed on the same stack. The way I >> see it, the only reason why Forth cannot afford to do that, is >> because Forth interpreter/compiler does not parse parameter >> types and the return type. If Forth does this, it can use that >> information to built a proper stack frame. I am willing to find >> a way to parse that information without too much complication; >> Forth is a simple compiler and I want to keep it that way. To >> make things worse, my Forth compiler should have the ability to >> check the types pushed on the stack. In Algol-like languages (such as Pascal, Ada, Modula, C, PL-1, etc.) the operands are typed. In Forth, the operators are typed. In fact, Forth really has no operands except the stack itself, and the stack is always implicit. A variable is a verb, not a noun. Executing the word FOO defined by VARIABLE FOO causes the address of the memory location holding the value of FOO to be pushed onto the top of the parameter stack. FOO causes an action to occur -- it is a verb. In Lisp, operands are typed, but the type can change during execution. This si called dynamic typing. In Pascal or C, the typing is static: once the type is declared in the source file, it remains constant throughout the execution of the program. This permits the compiler to be simpler, and permits a lot of error checking to be done at compile time. Lisp permits, but does not require, type declarations. When they are present, the compiler can usually perform more thorough compile time type checking, and it can also generate more efficient code. If type declarations are absent, then the compiler assumes that dynamic typing is permissible for that object, and then run-time tests are available to determine the type of an object when the program is executing. On Lisp machines (cpus that execute Lisp as the machine language) dynamic type checking is performed by hardware in the most common cases, so it incurrs no execution time penalty. Hans> That could prove to be very hard. Let's say you push a value Hans> onto the stack. Then you call another word. The Hans> return-address will be put on the stack too. If the word Hans> pops a value from the stack, it will be (part of) the return Hans> address, instead of the parameter. >> So there are two new features here, a single all-purpose stack >> and type-checking. I think this can be done, assuming that >> Forth programmers have a good habit of always returning only >> one type of information (e.g. integer, float or char) upon >> completion of a function. What I would get is a mix of Pascal >> and Forth. How would the Forth community take it? Hans> Ugh! I like languages who do not pose any restrictions on Hans> the programmer. Strong typing does pose restrictions. I Hans> agree that a warning should be issued. But a programmer Hans> should also be able to signal his compiler that he does this Hans> on purpose (like casts). I think your vision of Forth does Hans> refelect more of Wirths ideas than Chuck Moores! Hans> Hans. Lisp gives these capabilities already, but it is not as lean or fast or deterministic or agile as Forth is hard real-time applications. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 29 Mar 1995 17:08:13 GMT In-reply-to: JEThomas@ix.netcom.com's message of 19 Mar 1995 19:54:28 GMT >>>>> "Jonah" == Jonah Thomas writes: Jonah> In <3kg81q$pks@srvr1.engin.umich.edu> Hasdi R Hashim Jonah> writes: >> So there are two new features here, a single all-purpose stack >> and type-checking. I think this can be done, assuming that >> Forth programmers have a good habit of always returning only >> one type of information (e.g. integer, float or char) upon >> completion of a function. What I would get is a mix of Pascal >> and Forth. How would the Forth community take it? Jonah> Many standard Forth commands already return multiple types Jonah> of information at different places on the stack. For Jonah> example, SOURCE returns an address (start of an input Jonah> buffer) and a nonnegative number (# of characters in the Jonah> input buffer). I hope this isn't a problem to you. Forth Jonah> programmers seldom write routines that return either of a Jonah> single or a double number on top of the stack -- the Jonah> different variable types are usually at different Jonah> locations. Jonah> On the other hand, sometimes a datatype is kind of mutable. Jonah> It isn't uncommon to return, say, either an address or Jonah> zero. Is this address or flag? There's no distinction in Jonah> Forth, anything can be a flag. Jonah> The single stack would be no problem at all to me provided Jonah> I don't have to think about it. If my routines can treat Jonah> their data as if they're on a separate stack, then great! Jonah> And datatyping is no particular problem provided I don't Jonah> have to declare types myself. If the compiler does the Jonah> work of declaring types and it doesn't mind a minor amount Jonah> of mutability (anything is a flag, anything is a Jonah> bit-pattern, the type that a variable holds can change Jonah> provided the size doesn't change, etc) then great! Jonah> If you make a compiler that lets people program in Forth, Jonah> lots of people will be interested and if they find Jonah> something it's particularly good for, they'll want to use Jonah> it. Do you think a single-stack Forth would be faster? Jonah> Would it be easier to integrate into a C environment? Jonah> There could be something valuable here. For a language that deduces the type of a variable (more properly, "object") and still permits mutable types, check out Standard ML. There is a newsgroup, comp.lang.ml, that discusses this amazing language. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 29 Mar 1995 17:09:33 GMT In-reply-to: Keith@wootten.demon.co.uk's message of Sun, 19 Mar 1995 20:03:29 +0000 >>>>> "Keith" == Keith Wootten writes: Keith> In article <3kg81q$pks@srvr1.engin.umich.edu> Keith> hasdi@umich.edu "Hasdi R Hashim" writes: >> So there are two new features here, a single all-purpose stack >> and type-checking. I think this can be done, assuming that >> Forth programmers have a good habit of always returning only >> one type of information (e.g. integer, float or char) upon >> completion of a function. Keith> Good Habit?? Why?? Return what you want to, when you need Keith> to, as best suits you. It's only sand. Keith> -- Keith Wootten With a dynamic typing system, you can do this, but you can also look at something a determine what its type is, even though it can be different at different times. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: gml@ag.pu.ru Subject: Re: Return stack shenanigans Date: 29 Mar 1995 16:38:54 GMT > >: ENTER >R ; > >: SUCC COMPILE R@ COMPILE ENTER ;I > >: FAIL COMPILE RDROP COMPILE EXIT ;I > >: 0..0F > > 0 begin succ 1+ dup $0F > until drop fail ; > >: .chars > > 0..0F CR 0..0F 2dup swap $10 * + emit space ; > I find this very confusing. No doubt with practice I'd learn to see it > easily. It looks like the first 0..0F leaves 0 1 ... 0F on the stack > and 16 returns, and the 2nd 0..0F does the same. No. 0..0F calls the residue of .chars' code 16 times. It works - I tried it before sending. > Very tricky. So is Forth. > >> We're better off not trying to standardize R> DROP though. > >This technique is not the only good thing that may be done using the > >return stack manipulations. > What are some of the others? B.J.Rodriguez' BNF Parser (1983, published in SIGForth (1991?)) and "Rules Evaluation through Program Execution" (1990?) , G.Charlton's FOSM (EuroForth 90-91?, 92 (2 papers)), P.Koopman's "Combinator Graph Reduction" (he also used self-modifying code, though), V.A.Tuzov's data activation (1989?). Finally, just defining control structures. Almost forgot: V.Kirillin's work on compiler creation (about 10 years ago). Not all of them are so heavily based just on R-stack manipulations, but they use them. --- Michael L. Gassanenko, gml@agspbu.spb.su or gml@ag.pu.ru A parable. One man heard that Practice is the best way to enlightement, and that all our life is Practice, but he didn't know what is NOT-Practice. He tried meditation, etc. and Buddha jeered at him, saying that Practice is still better. From: forthrl@aol.com (ForthRL) Subject: Re: sstack Forth Date: 29 Mar 1995 13:00:59 -0500 Reply-To: forthrl@aol.com (ForthRL) >1..6 Snipped (because they simply demonstrate his does not know Forth) On the contrary, the nature of these questions shows that he is struggling to obtain a fundemental understanding of the theoretical underpinnings of the language. Just the fact that he is thinking so hard about the nature of the data vs return stack shows that he understands them better than most of the students I have tought in 5 years of teaching classes at FORTH Inc. I would much rather program with the person who asked these questions than with the person who so casually and rudely blew him off as ignorant, without bothering to attempt correction of any of the alleged ignorance. Regarding the questions themselves, We do tend to use the return stack as a local variable stack, and I aggree with the person who suggested a real local variable stack would be nice. I might still play the occasional flow of control game with the return stack, but I've got a feeling that CATCH & THROW will cure me of that eventually. I believe that an essential part of Forth is allowing words to choose how many parameters they will consume and return. A given word should consume a fixed number of parameters, and return a fixed number. There are a few exceptions, and I would not be loath to hearing an argument for killing them. Still, I really like ?DUP. Of course we tend to point to arrays.... NOTE: not everybody uses pick and roll. Lets start a new thread if we are going to argue this one... It seems odd that we are called inflexible for wanting (at least) two stacks ( which actually increases the programmers flexibility) but then it is suggested that we ought to return a fixed number of paramenters for all words... This is flexible? Or do I misunderstand? I wish Hasdi R. Hashim well.... Randy Leberknight, FORTH Inc. forthRL@AOL.COM RSL@forth.com (soon) From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: questions about new ANS Forth Date: 29 Mar 1995 18:27:00 GMT <3kf56d$5m@news.tuwien.ac.at> In-reply-to: anton@mips.complang.tuwien.ac.at's message of 18 Mar 1995 17:27:41 GMT h9290246@hkuxb.hku.hk (Zsoter Andras) writes: |> Anton Ertl (anton@mips.complang.tuwien.ac.at) wrote: |> > 2) What do you mean by "writing more efficient code"? Is "1+" more |> > efficient code than "1 +"? Why? On an optimizing implementation both |> > fragments have the same speed, so why would you call one more |> > efficent? Isn't it better to write readable code than to optimize code |> > for dumb compilers? |> |> Although it is discouraged by the ANSI standard Forth is still not just a |> programming language but also a computer program. |> Sometimes a "dumb" compiler is more useful than a "smart" one because the |> former does not mess up your program so you can follow what you are |> doing. |> Some trick words like 1+ instead of 1 + don't affect the readability of the |> program but they really cause some speedup. |> I like them. True, In the case of "1+" and "1 +", there's no difference in readability or maintainability. However, if you have : field create ( offset -- ) , does> ( addr1 -- addr2 ) \ note that this is the stack comment of words defined with field @ + ; 1 field foo there is a big difference between writing "foo" and writing "1+". Unfortunately, an optimizer will have an extremely hard time compiling a reference to foo into the code compiled for "1+", but I hope you get my point anyway. Actually, this is exactly the kind of code that an optimizer works very well on. The lexical and semantic portions of the compiler generate a strip of machine language instructions, and the machine code that gets generated for 'foo' might be: ; This is pdp-11 code, for lack of a better cpu... add field,R4 ; the '@ +' in the CREATEd part of 'foo' But the compiler knows that the CREATEd word 'foo' has a data area that is constant, perhaps in a cross-compiled situation, because it is in rom, or in a native situation, because analysis shows no stores to the data field of the created foo. This example shows how more information in the declaration of an object allows better compiler optimization. If the compiler does not know that the 1 in the data part of foo never changes, then it cannot move it into a literal immediate kind of machine instruction. If it knows it is constant, such as in C by declaring it 'const int foo.data = 1;', or by using the Forth word CONSTANT instead of CREATE (I know I am straining here...) then an optimizer can generate: add #1,R4 instead. This is more efficient since it saves a memory cycle. Furthermore, the compiler can issue warning messages if any code tries to modify the value of an object that has been declared to be constant. It cannot do this if it doesn't know. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 29 Mar 1995 18:32:36 GMT In-reply-to: spqr@ruth.uucp's message of Wed, 22 Mar 95 16:40:27 CST >>>>> "Will" == Will Baguhn writes: Will> regnirps@aol.com (Regnirps) writes: | Before everyone jumps Will> in, here are a few thoughts. First, most modern | Will> microprocessors with pre and post indexing addressing modes Will> let you use | registers as stack pointers in a very fast Will> simple way. Second, consider | multiple stack pointers, say Will> for Data, Return, and Loops, and keeping the | top of each Will> in a register. Thats only six registers and very fast Will> access. | For ops that do not push or pull there is no Will> external memory reference at | all. | | Charlie Springer Will> well obviously. a three-stack forth is a great idea; always Will> has been. that way, you're less likely to mess up your Will> subroutines with return stack references, and can use the Will> return stack across subroutine calls (if you're careful). Will> now then, as long as you never need to change the "where do Will> i go back to" pointer that used to be on the return stack Will> (but is now on the third stack), you're fine.... When I wrote the Dreams object oriented metaphor for Forth, I added a whole handful of additional stacks to control dynamic binding and moving around between differend environments. There is nothing magic about any particular number of stacks -- just use the minimum number required to do the job efficiently. For the semantics of Forth, as opposed to Forth-like languages, 2 stack is the minimum number required to do the job effeciently. Actually, life would be easier sometimes if DO loops used a stack separate from the Rstack for loop control variables. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: tanksley@san_marcos.csusm.edu (Billy Tanksley) Subject: Re: Stack manipulations (about 100 lines) Date: 29 Mar 1995 11:23:08 -0800 JEThomas@ix.netcom.com (Jonah Thomas) wrote to all: _>Did anyone do some more work on things like this? Is it still _>'thinking Forth' to engage in such formalizations? I guess, it is on _>some borderline, but has to be dealt with in some cases of building _>systems. I think it's a great idea! Looks like fun. In fact, I think Chuck would approve. Actually, he would probably undefine SWAP and all the others and just use these. I would change the way you do that, though; it would be more generally portable if the S: words were not anonymous. Like so: : S: CODE ( define a word, prepare to assemble ) BL WORD COUNT CHECK-- ( just check for leading "--" and skip it) POPALL, ( assemble code to pop all four elements in registers or mem) ( addr count) FOR ( addr) COUNT register ( do error checking here!) @ PUSH, ( compile an assembly push to that register) NEXT C@ [CHAR] } = NOT ABORT" Bad syntax" ; Naturally, this should be factored better (and is in my code); as soon as I finish debugging I'll present a working version in Pygmy Forth that provides S: and R:. Here's some sample words: S: NIP --013} R: R>DROP --012} _I made a notation for the top four stack items: ( 3210 -- nnnn) _so ROT would be ( 3210 -- 3102) _and 2OVER would be ( 3210 -- 321032) and so on. Then I wrote a quick _Forth routine which, given the right-hand part of one of those, would _compile an assembly routine that did the work. With 4 registers free _it's easy, scan the numbers with [CHAR] 3 WORD and if there's one _someplace other than the 4th item, compile code to copy the 4th item _to a register, and so on. I didn't do exchanges, so it wasn't as _efficient as it could have been, but it got reasonably fast stack _routines whenever I wanted them. S: --3232) made a single routine _that did 2DROP 2DUP . I could have made mnemonics for each one, but _it seemed simpler to call them things like --3232) so the assembler _could just scan the name. Those commands ended comments too soon so _I renamed them --nnn} . (Oh, the students didn't like it. They _decided they liked the dumb mnemonic names better.) I like it! I would implement that in assembler; just load all four elements into the registers and select (at compile-time) which PUSHes to do. Should be elementary! Best of all, it would be easy to rename words so created in a way which fits with YOUR purposes: S: SWAP --0132} Compiled code for that: POP all four PUSH #0,#1,#3,#2 DONE That seems pretty elegant to me. There are some optimisations that need to be made: the code should only pop the elements that actually change. This should be simple, actually, but the code I just slapped together doesn't do that yet. Well, I should mention that the code I slapped together doesn't quite WORK yet, but hey, it's only been an hour. ;) _I probably don't have the shortest command sequences here. I noticed _that things would go somewhat smoother if there was a command to do _ROT DROP and also if there was one to swap the 2nd and 3rd elements. _But I never seem to need them when I actually write code. I think _Forth programmers learn to produce code that works with the stack _words they have. Learning to do that is one of the frustrations of _learning Forth -- at first it seems like things are always in the _wrong place and stack jockeying seems like a problem. You mean you were compiling to Forth code? Why? This is a time for assembler! Do you mind if I attempt to implement your suggestion (I will anyways, but I won't release it without your OK). -Billy An end to stack noise! At least as long as programmers are careful with their names. (Yeah, right. And now Forth will rise and crush C and C++. ;) From: tanksley@san_marcos.csusm.edu (Billy Tanksley) Subject: Re: Single-stack forth Date: 29 Mar 1995 11:23:12 -0800 <3kqvn1$ntt@srvr1.engin.umich.edu> Hasdi R Hashim wrote to all: _I am not. That will be insane. I would rather do what you just did: _inserting inline assembly code. What bugs me about Forth is that if it _knows that its target machine supports single hardware stack, and _parameters and return size are fixed, it would eliminate the need for _swapping sp and bp with respect 80x86 on some of the primitives. The _overhead would be minor, but it could have been avoided. Again, this only _applies to certain primitives. Others would be an overkill. The overhead is almost non-existant, really. You're overlooking the large overhead of your plan, which would require a full scale memory access over the top of the stack (skipping the return address left by CALL) instead of a simple POP. _That is why I have two immediates for compiling, namely, ":"..";" for _normal-double-stack-is-needed-here primitive and "::"..";;" for _stack-frame-lovers-only primitive. I have a choice here. Using "::"..";;" _would discourage the use of >R and R>. Sometimes, building stack frames _is preferable. Sometimes no. I don't know how you would implement the _example I have shown before in normal Forth. By the way, I have found _some bugs. Stack frames have their advantages; how about providing a word to construct and another to destroy them? Make them seperate from the compiling words, though, cause I'll want to use them in calling C. : use-ssforth FRAME{ parm a1 parm a2 ( and so on) }FRAME ( do some more in 'normal' Forth) FRAME{ C-call" c:\bin\stdio.obj/fopen/(f,"wb")//" }FRAME ; _I have been spending a lot of time designing the work around for single _stack. I hate to see it go wasted. No doubt, programming styles with _ssForth will be different to Forth as C is different to C++ (Arrrgghhh!). _OTOH, programming with ssForth shouldn't be difficult if you have some _understanding in both procedural oriented language and basic Forth. In _ssForth, you can mess around with your basic Forth skills within "::" and _";;". Beyond that, it is off limits, unless of course you want to do _another work around. Well, let's see a demo. _Using stack frames permit the programmer to include a complex order and _considerable number of parameters and locals. Vectors (Pascal array) can _also be included as well as Arrays (C array or pointer). I don't know _about you but sometimes I wished that C has built-in vector generator. _Have you seen C++ work around on generating vectors? Right, but these things are not overly hard in normal Forth either. _Should we include "::"..";;" as well as ":"..";" in our Forth compiler? _Smells like C and C++ dilemma to me. I'd like to see : and ; left alone, but some new words added (such as FRAME{ and }FRAME) that support and encourage your usages. I don't quite see their advantages, but hey, that's why you're doing this! _Hasdi -Billy From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 29 Mar 1995 18:53:32 GMT In-reply-to: jfox@netcom.com's message of Fri, 24 Mar 1995 16:27:51 GMT >>>>> "Jeff" == Jeff Fox writes: Jeff> In article <3kqvuo$ntt@srvr1.engin.umich.edu> Hasdi R Hashim Jeff> writes: >> In article <795907295snz@chocolat.demon.co.uk> Paul Shirley, >> PS@chocolat.demon.co.uk writes: >> >>> Why not just call it C? ;-) >> Why not call it ssForth?;^D >> >> Hasdi Jeff> A while back we had a thread called "parameter passing (and Jeff> a lot else)" where I expressed my opinion that since a stack Jeff> is accessed (mostly) from one end, a stack (in memory) that Jeff> contains stack frames or arrays is not really a stack. Actually, it *IS* a stack, just not a stack of *WORDS*, but rather a stack of *STACK-FRAMES* ! Jeff> Nonetheless, I like the way Forth encourages experimentation Jeff> and rethinking of ideas. It seems to me that you are NOT Jeff> just creating a C with some things from Forth. I say keep Jeff> exploring and see where ssForth leads you. Jeff> Jeff Fox -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Signal Processing Forth? Date: 29 Mar 1995 18:57:41 GMT In-reply-to: elvey@hal.COM's message of 24 Mar 1995 18:35:08 -0800 >>>>> "Dwight" == Dwight Elvey writes: Dwight> In article Dwight> <1995Mar22.110724.7779@ucsvc.ucs.unimelb.edu.au>, Mark Dwight> Harrison wrote: >> Hello World, I was wondering if there are any flavours of Forth >> intended for Digital Signal Processing applications (ie handle >> fixed point or floating point and complex numbers). If so, do >> any of them run on DSP chips such as the Motorola DSP-56001 >> series? >> >> Mark Harrison Australian Bionic Ear and Hearing Research >> Institute Melbourne, Australia Email: >> harrisonm@mail.medoto.unimelb.edu.au LMI has a DSP Forth for the TI 320 series DSP chips. I have never used it though. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: You don't need forth to run forth Date: Wed, 29 Mar 1995 22:20:33 GMT Why 4t-H and how does it work 1. Prologue ----------- Like Forth, 4t-H is a compiler *and* a interpreter. Unlike Forth you cannot switch between the two. Like Forth, 4t-H runs Forth-programs. Not all of them but some. But in a quite different way. Most things have already been written. There have been Forths written in a high level language. There have been portable Forths. There have been Forths that could interface with C. Different architectures have been used to implement Forth. There have been Forths that were 16 kB or even less. Well, all of that has been done. But here is a language-interpreter that's all of the above. And none of them either. It sounds like an ancient Greek riddle, but it isn't. It's 4t-H. 2. History ---------- To understand 4t-H you have to know how it came to be. As most things in life, 4t-H developed slowly. It's predecessor was a C-function called strcalc(). This function implemented a RPN calculator in one very small function (6 kB source, 1.5 kB object). It worked on signed 16 bit integers (on MS-DOS; 32 bits integers on some Unixes) and had about 20 commands and 1 single variable. This variable could be preloaded from C and worked a lot like the memory-function on a simple hand-calculator. Well, although primitive it was very useful. It was an easy way to implement a RPN calculator as an extra in user-programs and could also be used to calculate user-defined functions, e.g. in a formatting and printing-utility to implement PostScript. Most of its usefullness resulted from the speed, the size and the way it interfaced with C: you could send a C-variable to the function and get the result of your calculation back. Using the stack-command you could write small programs like this: a ROT in strcalc(): ! swap @ swap Which could easily be abbreviated to: ! s @ s Since only the first character of the command was significant. Note that there is no need to throw an address on the stack when there is only one single variable. A command in strcalc() was separated by white-space. The interpreter was very simple: a) Skip all white space b) Get the next command c) Is it known: execute it; if it isn't: convert it to a number and throw it on the stack. d) If there are more words and no errors so far go to a) e) Pop the last value from the stack and return it A command in strcalc was very simple too. There were two static functions in strcalc(): push() and pop(). Every command could be translated to push() and pop() calls e.g. '+': pop (&a); pop (&b); push (a+b); But we were not satisfied. We wanted to create some successor to strcalc() that: - Would be able to receive a number of C-variables - Worked with long datatypes (signed 32 bit or more) - Had a number of userdefined variables - Had the same advantages as strcalc(): small and fast A very long time, we just didn't get the right ideas. Then we did. And it did everything strcalc() did. And more: - Arrays - Constants - Flow-control statements - Sub-routines - Vectored execution Well, add them together. These features and 'Reverse Polish Notation'. What was the best choice for a language doing all this? Forth. There were a few advantages and disadvantages to that approach. First, if it looked like Forth, it had to be compatible with Forth up to a certain point. Second, if it looked like Forth, we wouldn't have to write thick manuals, explaining how to use the language. Third, if it looked like Forth, could we make it crash-proof? A user can easily crash a Forth-system. A few bad addresses and you're there. We don't like core-dumps, especially when they're coming from our own programs. Even when the user made the actual error. So we had to think of a mechanism to achieve that goal. And we had still to put up with the original specifications about speed, size and portability.. So we had to make a few concessions somewhere. The answer was a Forth that separated all the areas without limiting the user too much. Here's our answer. 3. H-code --------- Long before the dawn of the original IBM-XT there was a language called UCSD Pascal. It was also a compiler and an interpreter. In fact, it didn't compile source into objectcode for a certain processor, but it compiled to P-code. So if you wanted to execute it, you needed a P-code interpret- er. Such an interpreter can run faster than an ordinary interpreter since it doesn't interpret source-statement, but optimized P-code. The 4t-H compiler works the same way. First the source is compiled into H-code. Then the H-code interpreter is run. H-code is very simple. It's got a single byte instruction and an optional argument. Here's a sample of disassembled H-code: CR (0) NOOP (0) VARIABLE (0) @ (0) 1- (0) DUP (0) VARIABLE (0) ! (0) 0BRANCH (62) (...) This is the compiled version of this little piece of code: cr repeat times @ 1- dup times ! while (...) One can clearly see that everything is actually compiled. Flow-statement are compiled into BRANCH and 0BRANCH instructions pointing to addresses in the virtual memory-space. Same for variables, constants, etc. This code-format means that 4t-H is not built to handle strings efficient- ly. True. Strings can only be handled if the source is kept in memory. If it isn't all string processing statements will be ignored. 4. Memory layout ---------------- Large chunks of memory are allocated for the following entities: - Return stack - Parameter stack - Variables - Compiled code - Source (optional) The returnstack, parameterstack and variables are allocated in one large array of signed 32 bit integers. However, the instructionset of H-code limits the access. This makes 4t-H a very safe environment: you *cannot* store the value of a variable in the parameterstack area. This Forth (if you want to call it that way) cannot be crashed by a userprogram. The stack/variable area looks like this: =============== <- end of variable area =============== <- begin of user variables =============== <- preloaded variables (by C-programmer) <- begin of return stack (grows downward) =============== <- begin of parameter stack (grows upward) The sizes and borders of these areas can be determined by the C-program- mer. He can also transfer C-variables to the userprogram. These variables can be used like any other variable. Combining return- and parameterstack means the C-programmer only has to worry about the size of the stack and not the sizes of both stacks, thus allowing to build a compiler that matches a wider range of user-applica- tions. The compiled code is an array of a structure that contains a unsigned byte (for the instruction) and a signed long integer (for the optional argument). The size is determined by the size of the source. True, it contains a lot of redundancy, but inventing a more clever scheme means that the compiler/interpreter have to be smarter to build and interpret it, thus adding milliseconds to execution time and bytes to the size. So 4t-H is kept straightforward. 5. H-code compiler ------------------ The H-code compiler looks a lot like any conventional compiler or assembler. Basically it is a simple two-pass compiler. In order to understand the workings of 4t-H you have to know that not all H-code instructions are equal. Simple words: these are words like DUP, ROT, 2+, etc. These words have only relations to their interpreter equivalents. Complex words: these words depend on other words before of after the actual instruction like '. Symbol words: like VARIABLE, CONSTANT, colon-definitions, etc. Flow words: like BEGIN, REPEAT, IF, ELSE, THEN Compiler words:like ALLOT BASE words: like DECIMAL, HEX, OCTAL In the first pass all simple words are compiled into their code equiva- lents. Furthermore, all symbol words are added to the symbol table. Everything that is not a simple word is labeled as PENDING. That means all symbols and literals. Flow words are treated like simple words. Compiler directives like ALLOT are executed. BASE words are treated like simple words, but also like compiler directives. E.g. when a source contains something like: hex 1A variable test 10 allot decimal we want to add 16 more variables to test and not 10. BASE words also work in the second pass since then we resolve the values of the literals. E.g. when you consider this code: hex 12 decimal We want the H-code to contain the instruction: HEX (0) LITERAL (18) DECIMAL (0) and not 'LITERAL (12)'. If 4t-H meets a PENDING instruction it will first search the symboltable, then it will try to interpret it like a literal. If the compiler encounters code like this: : funny hex ; : jim decimal ; : prog decimal funny 1A jim ; it will not be able to find '1A' in the symboltable. It can't convert it to a decimal number either. So as a last resort it will try to convert it to a hexadecimal number. Which works and is perfectly legal. However, if you replace it with '12' the decimal conversion will work. And the H-code will contain a wrong instruction. One would need a lot of code to resolve this one. So the H-code interpret- er can either work in FAST or SLOW mode. The default is slow. It will then reinterpret all literals during execution (if the source is still present). When the user adds the word FAST to his code, the H-code interpreter will switch into fast mode and not reinterpret literals. So the user can determine which code can run in fast mode and which can't. A kludge, I agree, but I hope an elegant one. ;) During the second pass the compiler also resolves all flow words. It simply matches the correct instruction and enters the jump-address into the argument of the BRANCH, +LOOP, CALL or 0BRANCH instruction, which replaces the original instruction. It may sound strange, but colon-definitions are also treated like flow words. The colon simply compiles into a BRANCH instruction that skips the colon definition. When the user calls a colon definition, it simply compiles into a CALL instruction that puts the current address on the return-stack and jumps inside the colon definition. The semi-colon works like a RETURN instruction that pops the return address from the return stack. Yes, like a subroutine in BASIC or assembler! 6. Error handling ----------------- When 4t-H finds an error during compilation or execution it stops and sets the C-variable ErrNo4th. It works like 'errno' in C. You can optionally link in an array of errormessages. ErrNo4th is an index to this array, which makes issuing the correct error message very simple. 7. Interfacing with C --------------------- A minimal compiler would take only a few lines of C-code. The C-programmer can determine the complexity of the programs the user can execute by determining the size of - the symbol table - the return/parameter stack - the number of variables - the number of preloaded variables E.g. a compile takes this statement: object = comp_4th (source, 256); Which would allocate a symboltable of 256 different symbols. Executing a program is easy too: if (! ErrNo4th) ReturnVal = exec_4th (object, source, stdout, 512, 1024, Var1, Var2, Var3, LONG_MAX); Which would sent all I/O to stdout, allocate a return/paramaterstack of 512 elements, allocate 1024 variables and preload variables Var1, Var2 and Var3. You need to terminate the list of preloaded variables with LONG_MAX. The value returned by exec_4th() and stored into ReturnVal is the final value on the stack. So you always need to leave a value on the stack when returning. If an error occurs exec_4th() will return LONG_MAX. 7. Contacting me ---------------- If you are interested in 4t-H, you can email me: hbezemer@vsngroep.nl May be you want to beta-test or just more information. Please note that of this writing 4t-H is still in development so specifications or behaviour can change. 4t-H will be released as shareware. Some statistics: Source: about 60K Execsize: between 15K and 35K Speed: between 4 to 8 times slower than F-PC V3.x (fast mode) Price: about $10, fl. 15, DM 15 From: ragsdale@netcom.com (William Ragsdale) Subject: Forth programmer wanted Summary: Employment in Northern California Keywords: Forth, Motorola, embeded Date: Thu, 30 Mar 1995 06:30:23 GMT I'm looking for a Forth programmer in the Northern California area, Hayward, to be specific. We make data collection devices using the Motorola family: 68HC11, 68HC05. All the work is done in Forth, as is our emulator system. We have about one project a month. Each project runs 4 to 20 hours. I have a brand spanking new development started with completion scheduled for early June. This is you chance to get in with full control. A (dubious) fringe benefit is you get to hang out with one of the Grand Old Figgies: Bill Ragsdale, a legend in his own mind. Call Bill Ragsdale at 510.429.8000, email ragsdale@netcom.com Dorado Systems Corp., 721 Sandoval Way, Hayward, CA 94540. BCNU -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Ragsdale | ragsdale@netcom.com | days 510-429-8000 Dorado Systems | | fax 510-429-8090 From: kvinson@mercury.interpath.net (Kenneth M Vinson -- Shade Tree Systemware) Subject: Re: sstack Forth Date: 30 Mar 1995 13:39:41 GMT ForthRL (forthrl@aol.com) wrote: -cut : We do tend to use the return stack as a local variable stack, and I aggree : with the person who suggested a real local variable stack would be nice. : I might still play the occasional flow of control game with the return : stack, but I've got a feeling that CATCH & THROW will cure me of that : eventually. -cut I also agree about another stack for careful local use. A third (local) stack is on my immediate list of things add to the forth that I am using. It seems like it would me a very convenient thing to have and would be handy inside DO LOOP's especially. This should keep the return stack cleaner for its intended purpose and make the system a little more forgiving. I have not yet begun to think too much about exactly how I want to code this, or even if it is the best of ideas. Some of the negative aspects I forsee is: 1. It could get messy (if abused, as with all stacks). I don't want to routinely have to write a second stack notation just to keep up with the silly thing. 2. It could be a little slow but probably no slower than accessing dedicated local variables. 3. Many in this group will add to this list (as well as to the possitive aspect list). Please do. When writing CODE definitions, I have often wished that the 8086 had an extra stack just for saving registers before POPing from the parameter stack if for nothing else. Ken Vinson From: MABS85B@prodigy.com (Leo Wong) Subject: Two MuP21 Riddles Date: 30 Mar 1995 14:19:36 GMT These are intended as banter, since I wish Charles Moore the best. What do Computer Cowboys sell? ANS. Cow chips. Why is the MuP21 so cheap? ANS. Because it's Chuck, not filet mignon. (Come to think of it, ANS is itself funny in this context.) - LEO WONG MABS85B@prodigy.com New York State Department of Civil Service Albany, NY 12239 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Two Chucks Date: 30 Mar 1995 14:52:43 GMT In article <3l5j62$dls@news1.delphi.com>, lkaplan@BIX.com (Leonard Kaplan) writes: |> Several years ago I was involved in rewriting the code generator for an |> expert development system. The previous version (which I had also written) |> was partially table driven and all of that good stuff, but it was still a |> real bear to add new operands, for instance. I recommended that we make the |> generator _completely_ programmable, using a Forth-like interpreter |> (embedded within the application). I felt that it gave us the flexibility |> to do pretty-much anything we'd ever need to do, and would be compact and |> "fast enough" for the job at hand. |> |> Management went slightly weird at the mention of the F-word. What's wrong |> with C, we don't need another language syntax and interpreter to maintain, |> it's going to be hard for people to use, all the usual stuff. Ultimately, I |> was given permission to do it, with the warning that my a*s was on the line |> for the success of the project (all the usual stuff). In contrast, at one of my jobs I had to implement a 4GL. At one point, I was asked to add a report generation language to what we had. I proposed generating C code, since the rest of the compiler already generated C. But I was told by my boss to use an interpreter, so we did not have to recompile for every machine if a report changes. Not surprisingly, the interpreter I implemented was quite similar to Forth's (well, some Forths') virtual machine (the language, however, was quite Algol-like). The funny result was that the 4GL compiler generates C code for the data structures and a portable intermediate code for the code. Maybe they fixed this in the meantime. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen From: MABS85B@prodigy.com (Leo Wong) Subject: Forth Bon Mot Date: 30 Mar 1995 14:59:40 GMT I have used: +1-1 ( n1 n2 - n1+1 n2-1) I had occasion to use a more general version in a recent application: : +N-N ( n1 n2 n3 - n1+n3 n2-n3) DUP NEGATE +UNDER +UNDER ; - LEO WONG MABS85B@prodigy.com New York State Department of Civil Service Albany, NY 12239 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Stack manipulations (about 100 lines) Date: 30 Mar 1995 15:58:56 GMT On a related note, some time ago I wrote a short Prolog program that finds the shortest stack manipulation sequences for a given stack effect. Or, alternatively, the shortest sequences equivalent to a specific sequence. E.g., to find sequences reversing the top three stack items, I can make the query: | ?- findbest(X,[1,2,3],[],[3,2,1],[]). X = [swap,rot] ? ; X = [rot,rot,swap] ? ; X = [tuck,drop,rot] ? yes What I typed in was "findbest(X,[1,2,3],[],[3,2,1],[])." and the ";"s. This query asks for lists X of stack manipulation words that have the data stack effect ( 3 2 1 -- 1 2 3 ) and the return stack effect ( -- ). Note that the top stack items are leftmost in Prologs list, in contrast to Forth (i.e. ( a b ) corresponds to [b,a]). The Prolog system produced solutions, strarting with the shortest one, "swap rot"; I asked for two more solutions using ";", then hit return to ignore the other solutions. Similarly, one can ask for the best sequence equivalent to a given one: | ?- find([nip,over,tuck,drop],[1,2,3,4],[],X,[]),findbest(L,[1,2,3,4],[],X,[]). L = [nip,over,swap], X = [1,3,3,4] ? ; L = [swap,drop,over,swap], X = [1,3,3,4] ? ; L = ['>r',drop,dup,'r>'], X = [1,3,3,4] ? ; ... Here, I first asked for the data stack effect ( 4 3 2 1 -- X ) of the sequence "nip over tuck dup drop", then searched for the list L of stack manipulation word with the same stack effect. As a result, the data stack effect is ( 4 3 2 1 -- 4 3 3 1 ); the shortest list is "nip over swap". And here's the Prolog program. It should be obvious how to add or remove descriptions of stack manipulation words. And I'm sure Micheal Gassanenko will come up with a (Bac)Forth version:-). ---------------------------------------------------------- %eff(Word,Data_Stack_in, Return_Stack_in, Data_Stack_out, Return_Stack_out). eff(swap,[A,B|D],R,[B,A|D],R). eff(dup,[A|D],R,[A,A|D],R). eff(drop,[A|D],R,D,R). eff('>r',[A|D],R,D,[A|R]). eff('r>',D,[A|R],[A|D],R). eff('r@',D,[A|R],[A|D],[A|R]). eff(rot,[A,B,C|D],R,[C,A,B|D],R). eff(over,[A,B|D],R,[B,A,B|D],R). eff('2dup',[A,B|D],R,[A,B,A,B|D],R). eff(nip,[A,B|D],R,[A|D],R). eff(tuck,[A,B|D],R,[A,B,A|D],R). %delay find(nonvar,any,any,any,any). find([],D,R,D,R). find([Word|Words],Din,Rin,Dout,Rout):- eff(Word,Din,Rin,D1,R1), find(Words,D1,R1,Dout,Rout). findbest(L,Din,Rin,Dout,Rout):- genlist(L), find(L,Din,Rin,Dout,Rout). genlist([]). genlist([_|T]):- genlist(T). ---------------------------------------------------------- - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen From: spqr@ruth.uucp (Will Baguhn) Subject: Re: sstack Forth Date: Wed, 29 Mar 95 21:42:36 CST Reply-To: spqr%ruth.uucp@fullfeed.com Hasdi R Hashim writes: | Forth programmers! Defend yourself! | --------------------------------------------- | 1. It has come to my understanding that Charles Moore original forth | design was a single-stack. The second-stack was added later and was | considered a breakthrough. Is the separation between information and | return stack made because someone is to lazy to parse parameter and | return information from the command-line? | which is easier? saying "go do this and come back here" and "go do this on your way back to place came from" or "go do this, go here"? simplicity is beautiful. | 2. After the double stack implementation was made, it seems to me that | Forth programmers start to take the existence of the double stack for | granted. This is evidend in the number of commands that directly | manipulate the return stack, like >R and R>. Do you think this is wise? | Have anybody ever thought about what happens when somebody jumps in and | wants single- stack or even quadruple stack implementation? | any software being ported will take this into account. single stack forth? not bloody likely anytime soon. | 3. Referring back to question number 2, FORTAN, Pascal, and C, as | somebody has mentioned, do not specifically require one, two or three | stacks. THis gives flexibility in the implementation. Why does Forth must | make a restriction on having two stacks? Doesn't this make the | implementation of the language inflexible? | forth does not require two stacks; it requires a minimum of two stacks (by "current standards"). more are perfectly legal, provided you tell the programmers that they're there and if/how they should/can be used and how not to step on them. | 4. What happens when you have a lot of parameters passed? In my | understanding, you only have "dup", "swap", "rot", and "-rot" to manage | the processing of parameters. What happens when you have 12 cells to | manipulate like 3x4 matrix? Do you avoid it and use pointers instead? | a lot of parameters to be passed? there should never be more than three. however, there are "pick" and "roll" to be looked at. a matrix? obviously it is handled by a pointer and some offset(s). | 5. Does Forth also pose a restriction on the size of cells for various | types? Do you take for granted that a pointer is made out of a single | cell? Doesn't that pose some restrictions on dropping into other | languages without making use of a 'wrapper' function/primitive? | golly no. cell width is implementation-specific; an 8bit cell or a 64bit cell is perfectly legal... so long as you're consistent. 16bit is a nice medium. not too big, not too small... just right (for most things). obviously, if the hardware was more happy with it, an 18bit cell is possible, or a 24bit cell. however, it seems that most modern computers use the plain old powers of two... 8, 16, 32, 64... so that's the most logical way to build the forth. | 6. Who is OJ Simpson? Why is he getting more coverage that I do? | if it makes you feel better, i'm paying more attention to this than to OJ. | 7. C/C++ is an evolving language (don't argue with me on this one). To | adapt to new situations, modifications have been made. If double stack | implementation is so great, why is it I can't I find the use of "extern | FORTH" in Turbo C/C++? Why do we see "extern PASCAL" instead? What makes | PASCAL interface so great that C/C++ has to provide some work around for | interfacing into PASCAL? | anybody can link a language to itself. the people who want to link to forth can; the people who don't want to program can do whatever they want and still keep their Microsoft job. | 8. Why is it necessary for the parameter cells and return cells to be | allowed to change in numbers anytime in a primitive? Is it really to much | to ask for primitives to have fixed number of cells that need to be | passed and fixed number of cells that will be returned. If it is really | necessary for the data to be variable in length, why can't pointer be | used? | i assume you mean "?DUP". it's an obvious simplification of code and an optimization. it is difficult to comprehend at first, but these two code samples are equivalent... : FOO ( X--) ?DUP IF . ELSE ." Zero" THEN ; : SLOWFOO ( X--) DUP IF . ELSE DROP ." Zero" THEN ; the first is faster, because the DROP is executed at the same time as the DUP, but only if it is necessary. One less call to a primitive decreases size and increases speed. | 9. Is George Michael really gay? What about Cindy Crawford? | who cares? | Thanks. | | Hasdi | | ****Let the flames begin!**** --- email: uwvax!gorgon!ruth!spqr Mispeling: the plag of our thyme. From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Forth meeting at UMd Date: 30 Mar 1995 17:22:04 GMT Wednesday, March 29, MFIG staged another Forth talk, this time at University of Maryland for their student IEEE chapter. Originally the student IEEE representative estimated 25-100 attendees, but in the last week he scaled that estimate down a lot. He couldn't get either of the big conference rooms because they were already booked, so he arranged a classroom in the basement of the Math building. The day before he wasn't sure he could get a video projector, but he could get a monitor and everybody could cluster around it. He'd asked his instructor, Bill Hawkins, to make an announcement about the meeting and Bill gave a Forth lecture too. Paul Gammell was out of town, so the presentation would be done by Bob Caffrey and myself. Bob was involved in an ongoing crisis at work and didn't have time to practice his talk. He offerred to meet me for lunch Wednesday to go over it. I misunderstood his directions to the restaurant and was 30 minutes late and missed him. We had a brief phone discussion later. "Bob, the important thing is to share yourself and your experience. Pick someone who seems interested and look them in the eye occasionally, and speak to them. People will forgive you if you stumble over the words." "Jet, things are going crazy here and I can't think. Don't _start_ with me." I got to the place about 4:35, for the meeting at 5:00. There were several people standing in the hall. Our room was in use. They had the projector and discussed whether to take the monitor back. A woman who used to use Forth for motion picture special effects talked about that some. Bob got there and talked with her. The IEEE coordinator told me that two other engineering organizations were having their meetings at the same time. "They don't coordinate with us." About 4:50 they figured the room wouldn't be ready and we moved into the room next door. They tried to set up the projector and couldn't get it to communicate with their computer. At 5:05 Bob started his talk. By that time there were 11 people present, plus Bob and me. One more came in a few minutes later. Bob did a great job! He discussed the microprocessor class he took at UMd years ago, and a beautiful Indonesian woman showed him the rig they use now -- she brought it in a tupperware box. "We didn't have anything like that." He made the point repeatedly that Forth isn't a religion, it's just a tool that you use when you do things that aren't routine. He looked out at the audience. I followed his eyes and he was spending some time looking back at a beautiful blonde woman who seemed fascinated with him. He described his work at NASA using Forth, and glossed over dozens of other Forth projects in space. He gave an overview of Open Firmware and generally gave the impression that Forth does get some use in the real world. People asked questions. "Why isn't Forth more popular?" "Well, people write papers about that. What I run into is people don't want to use it because they can't hire Forth programmers, because there aren't enough people who know it. And there aren't more Forth programmers because managers don't want to use it." Before he finished, the pizzas arrived. When he finished it was 5:45. Then it was my turn. They set up the monitor and copied my files to a temporary directory. I managed to cut my 16 minute talk down to 9 minutes, but I should have skipped it completely and just asked for questions. I could see that at the time, but I had too much forward momentum to stop. Afterward I asked how many people thought they wanted to learn Forth and 10 of them raised their hands. 9 had signed the mailing list for MFIG, indicating that they didn't mind getting meeting notices. I suggested that if anyone wanted to start a UMd FIG chapter or ACM SigForth Chapter or whatever, we'd support them. Afterward we ate pizza and talked. "I don't understand why I've never heard of this before. I'm a senior." "Is Forth anything like P-SPICE?" "I'm not starting any groups, come May and I'm out of here." "There's a new chess program that plays at GrandMaster level, but it can't beat the best human beings yet. They're talking about building one that has a different processor for every square." Bob and I talke a little on the way to the parking lots. "Bob, you did great! They really liked it and they liked you!" "Jet, this is the last talk I'm giving. They always come at the worst time and I don't want to do any more." "OK, and if you _do_ decide you'd like to do another one you'll be welcome." We still don't have enough feedback. I gather lots of marketing has this problem. We could pass out a questionnaire asking audiences what they liked. We can see whether anybody new shows up at meetings, and ask them how they heard about us. If a small group of UMd students calls to ask for a tutorial session I'd count this meeting a full success. But lots of our results or lack of results will be invisible to us. Every student who puts Forth on his resume is a success, but we won't see the resumes. When we don't even know what our results are, it's hard to improve. We need to get more immediate feedback from our audiences, make it more interactive, more Forthlike. From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: Stack manipulations Date: 30 Mar 1995 17:29:06 GMT In tanksley@san_marcos.csusm.edu (Billy Tanksley) writes: >I would change the way you do that, though; it would be more >generally portable if the S: words were not anonymous. Like so: I didn't make them anonymous. I made the stack diagram be the name. So --32} is the same as 2DROP --32101} is the same as OVER --321032} is the same as 2OVER and so on. >Naturally, this should be factored better (and is in my code); as >soon as I finish debugging I'll present a working version in Pygmy >Forth that provides S: and R:. I did mine in Pygmy too. The central thing is to do SWITCH, which lets you do things like 4 [BP] AX MOV, So first you use the diagram as a name. Then the first pass, you look for each of the four items anywhere other than their original spots. For each one that gets copied, you copy to a register first. Then for the 2nd pass, you look at the bottom 3 spots and assemble a move from register for each one that changes. Then for the 3rd pass, you SWITCH, again. You look at any extra stack items and PUSH, the appropriate register. Or if any are missing you POP, that many. Then you're done and can do NXT, . There are a lot of cases where this isn't optimal. Sometimes a series of exchanges would work better. But this method works pretty well, for minimal cleverness. Exactly the same strategy will work on 68000, except I think there are even better choices it misses -- I vaguely remember a memory/memory exchange which might do in one step what this method does in 4. >Compiled code for that: > POP all four > PUSH #0,#1,#3,#2 > DONE >That seems pretty elegant to me. There are some optimisations that >need to be made: the code should only pop the elements that actually >change. This should be simple, actually, but the code I just >slapped together doesn't do that yet. Well, I should mention that >the code I slapped together doesn't quite WORK yet, but hey, it's >only been an hour. ;) POPing them all _is_ more elegant conceptually. I guess you'd POP them down to the last one that changes or gets copied elsewhere. So for OVER --32101} you'd POP the top two and do 3 PUSHs. You can do a lot better than that, but once you start optimising it's hard to decide when to quit. Maybe easier to hand-optimise the ones you really care about. _I probably don't have the shortest command sequences here. I noticed _that things would go somewhat smoother if there was a command to do _ROT DROP and also if there was one to swap the 2nd and 3rd elements. >You mean you were compiling to Forth code? Why? This is a time for >assembler! No, I mean I didn't work hard to find the shortest series of Forth commands that would get each stack effect. And I didn't care that much. Like, how would you do --22201} ? In Forth using just the data stack it might look like 2SWAP-NIP-DUP-2SWAP-ROT-DUP-2SWAP-SWAP but there might be a much better way. Maybe 2>R-NIP-DUP-DUP-2R>-SWAP ? I don't need to solve that problem now, I can wait until I actually do need it. >Do you mind if I attempt to implement your suggestion (I will >anyways, but I won't release it without your OK). Go ahead, you might see something I missed. I had a vague idea of dusting my old paper off and sending it to ACM SigForth and I still will, but they probably don't want it after this. >An end to stack noise! At least as long as programmers are careful >with their names. (Yeah, right. And now Forth will rise and crush >C and C++. ;) I left the thing in my compiler for a couple of years and never used it. When I had a stack jam it meant I hadn't understood the problem. A rewrite always cleared it up better than a new stack juggle. And when I didn't use it for awhile I started avoiding it because I might want to port my code to some other compiler and I didn't want a few weird nonportable stack commands to get in my way. It's a solution looking for a problem. I _like_ using the stack diagram as the name. It's more intuitive for me than "mnemonic" names. DUP DROP SWAP OVER are good. ROT is fair, and you learn it early. NIP, OK. NUP is a bad pun. It goes downhill from there -- the less I use the word the less intuitive it looks. 8-) From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Need Opinions Date: 30 Mar 1995 18:33:34 GMT In-reply-to: regnirps@aol.com's message of 26 Mar 1995 01:02:35 -0500 >>>>> "Regnirps" == Regnirps writes: Regnirps> THe first and biggest problem I had with the New Micros Regnirps> 68HC11 with Forth was finding a way to download Forth Regnirps> source. I had to write a weird program on my PC to send Regnirps> lines and look for 'OK's -- unless between a : and ; Regnirps> etc. I guess you are just supposed to type in your code Regnirps> a line at a time each time you fire it up. Regnirps> Charlie Springer I have used MaxForth before, and all I did was use ProComm's ascii upload function, along with tailoring the timing in the config menu for ascii upload so that each line was followed by a suitable delay. If you are working with really big source files, though, you should consider getting a metacompiler and a rom simulator for the 68HC11 instead. This will permit you to use a standard 68HC11 cpu chip instead of one with teh New Micros Forth kernel in it, and will save you the extra cost (actually a license fee) associated with the New Micros chip. I used the LMI metacompiler for the 68HC11 and found it excellent. I also used the ROM simulator they sell that is designed by Klaus Flesch in Germany. I found it a much more productive way to work than send source files and compiling on the slow 68HC11. With the metacompiler, you are commpiling on the PC and targeting to the 68HC11. Because the metacompiler has the sources for a complete Forth system with it, you do not loose the feature of debugging on the target with a full Forth interpreter, but if you do not ship your product with a functioning Forth outer interpreter, then there is no licsence fee. I save a client company thousands of dollars is license fees this way, as well as many thousands more in increased productivity siomply because the recompile time was so greatly reduced: 30 minutes to 3 minutes! -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Arith Shift Date: 30 Mar 1995 18:45:49 GMT <3km5v2$93@minnie.informatik.uni-kiel.de> <3ksg4j$ac7@wu.labs.tek.com> <3l66mi$ma0@minnie.informatik.uni-kiel.de> In-reply-to: uho@informatik.uni-kiel.d400.de's message of 27 Mar 1995 13:14:26 +0200 >>>>> "Ulrich" == Ulrich Hoffmann writes: Ulrich> Here are two general ANS Forth definitions, which work Ulrich> when 1's or 2's complemement or sign/magnitude Ulrich> representation is used. Ulrich> : floored-2/ ( n1 -- n2 ) DUP 0< IF NEGATE 1- 2/ NEGATE 1- Ulrich> ELSE 2/ THEN ; Ulrich> : Tom_Almy's_intuitive_2/ ( n1 -- n2 ) DUP 0< IF NEGATE 2/ Ulrich> NEGATE ELSE 2/ THEN ; Ulrich> : symetric-2/ ( n1 -- n2 ) Tom_Almy's_intuitive_2/ ; Ulrich> We've seen the definition of Tom_Almy's_intuitive_2/ Ulrich> before. It works because a) NEGATE negates the top of Ulrich> stack item corresponding to the system in use b) 1- always Ulrich> does decrementing right and c) on the positive branch an Ulrich> arithmetic shift right (ANS Forth 2/) is appropriate to Ulrich> implement division on all of the three number Ulrich> representations in focus. Ulrich> Ulrich -- Ulrich Hoffmann, Uni Kiel WWW: Ulrich> http://www.informatik.uni-kiel.de/~uho/ Institut Ulrich> f. Informatik, email: uho@informatik.uni-kiel.de Ulrich> Preusserstr 1-9, D-24105 Kiel, Germany Tel: +49 431 560426 Ulrich> Fax: 566143 Unfortunately, if we are really trying to eliminate *ANY* restrictions on the computer architecture at all, then we need to consider even more number representations than just 2's comp & signed mag. I remember that the Cray machines cause considerable constenation in the X3-J14 ANS Technical Committe for Forth because they do not have integer arithemetic -- just floating point. Most Forth programmers intuitively use 2/ as a shift, not as division. If a program based on such a [false] assumption were to run on a Cray, then bit shifting the word was desired, not division by 2, and these two operations produce *VERY* different results. Also, consider a decimal arithmetic machine such as the veritable IBM 1401, or the old Intel 4004... Should the "intuitive" 2/ really be a / (fill in radix with the applicable value for your machine). If so, then consider that the IBM 360 and 370 machines were marketed as *HEXADECIMAL* machines -- even their floating point was hexadecimal, not binary, an unfortunate choice, as it tended to make round-off error *MUCH* worse than programmers were accustomed to. What about *ANALOG* architectures? We gotta draw the line *SOMEWHERE* !!! -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Arith Shift Date: 30 Mar 1995 18:57:35 GMT <3km5v2$93@minnie.informatik.uni-kiel.de> <3ksg4j$ac7@wu.labs.tek.com> <3l66mi$ma0@minnie.informatik.uni-kiel.de> In-reply-to: uho@informatik.uni-kiel.d400.de's message of 27 Mar 1995 13:14:26 +0200 >>>>> "Ulrich" == Ulrich Hoffmann writes: Ulrich> In <3ksg4j$ac7@wu.labs.tek.com> toma@wu.labs.tek.com (Tom Ulrich> Almy) writes: >>>> but nobody has pointed out that if you don't like what 2/ >>>> does, you can always enter: : 2/ 2 / ; >>> And then if your system uses symmetric division, 2/ does not >>> any longer behave as required by ANS Forth, since on negative >>> numbers it does not arithmetic shift right. [Now we're back >>> where we started :-] >> Ah, is it more important to have it work the way you want or >> meet the standard? If you use vocabularies (ANS aka wordlists) properly, you can have it both ways. Just create a vocabulary for your own stuff, and put it before FORTH in the search order, then you can override all the standard definitions you want. When you load code from other people, put FORTH first and your vocabulary second, or do not use your vocabulary at all in this case. I just showed it with yours second so you could access your words that did not violate the standard when you were hacking on other peoples code. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Arith Shift Date: 30 Mar 1995 19:11:31 GMT <3kflgu$etv@utkux1.utk.edu> <3kvu7k$51v@civic.hal.COM> In-reply-to: elvey@hal.COM's message of 24 Mar 1995 18:13:08 -0800 >>>>> "Dwight" == Dwight Elvey writes: Dwight> In article , Christopher John Dwight> Rolfe wrote: >> brmcf@utkux1.utk.edu (Bruce McFarling) writes: [Still curious >> about needing centred division] >> >> I could, of course, be wrong but -- I'm using a DFT to analyze >> and process audio files; that's 16 bit input, 32 bit >> coefficients, and a signed 32 bit sin LUT for the angles. >> >> I noticed large DC components in the output, which I ascribe to >> the cumulative effect of multiplying components by 32 bit sin >> and cos, and simply discarding the lower 32 bits of the >> product. There was even occasional clipping when the output >> exceeded the theoretical log2(#points) limit. >> >> Since then, I've found the same errors in other gain >> calculations due to using floored division. >> >> Chris rolfe@sfu.ca >> >> >> -- Dwight> Hi Chris is making a common mistake. In not using floored Dwight> math and continuing to use truncation a more insidious Dwight> error will occure. Instead of getting an offset he will Dwight> see distortion of the values around zero. As with all Dwight> things using a more correct method will give better Dwight> answers. He should be rounding his numbers and not Dwight> truncating. Even though rounding with integers is not Dwight> perfect it does produce very usable numbers. Truncation Dwight> with non-floored math has given him a false sense of Dwight> security that he is getting good results while he Dwight> accumulates an error that isn't obvious. Dwight It is also very easy to do that sort of rounding: after the multiplication, if the most significant bit of the least significant half of the product is non-zero, then increment the most significant half, discard the least significant half, and there is your result. Division also needs rounding. After an integer division, if the most significant bit of the remainder is set, then increment the quotient. A further refinement is worth mentioning here. If the remainder, or the least significant half of the product, is *EXACTLY* 10000...0, then only increment the quotient, or most significant half of the product, if it is odd. Do not increment it if it is even. This is called odd-even half-rounding, and is even superior to the simpler half-rounding because it avoids successive accumulation of rounding errors caused by always favoring the 0.5 situation by choosing the higher value. This odd-even half-rounding is the X3-J13 (Common Lisp) ANS standard way to round. Lispers tend to be real perfectionists. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: draperda@uvsc.edu (DAVID DRAPER) Subject: ATLAST Date: Thu, 30 Mar 1995 19:22:53 GMT Does any one know of John Walker and some code called "ALAST" (Autodesk Threaded Language System Toolkit). From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Interfacing stack-framed languages Date: 30 Mar 1995 20:10:09 GMT In-reply-to: Bruce McFarling's message of Tue, 28 Mar 1995 10:07:30 -0500 >>>>> "Bruce" == Bruce McFarling writes: Bruce> On 28 Mar 1995 gml@ag.pu.ru wrote: >> Q: Have we to interface TWO DIFFERENT mainstream laguages from >> Forth? >> >> Requirements: >> >> It should be implementable on existing Forths It should allow >> very eficient implementation in case we design Forth from >> scratch. It should be usable and useful for Forth internal >> purposes (e.g. for implementing locals). Bruce> IMHO it would also make sense to borrow words from the Bruce> scientific library data-structure vocabularies for Bruce> specifying types. That would ease the introduction of C Bruce> programmers to FORTH almost as much as a standard way to Bruce> call their old code would. >> It must enable us to: 1) build a stack frame 2) call a function >> with it, and receive the value returned 3) access the stack >> frame passed from the mainstream language 4) return a value to >> it 5) ?? call the same procedure from both Forth and mainstrean >> languages Several years ago I wrote a local variable extension to Forth that places the stack frame on the return stack, not on the parameter stack. This package is available on the LMI Forth board, and is licensed under the terms of the GLP. It was not really designed to interface to other languages, but rather to provide lexically scoped local variables in Forth. The syntax is like this: : FOO | arg1 arg2 arg3 ... -- result1 result2 ... & temp1 temp2 ... | blah blah ; It uses vertical bars instead of parentheses to delimit the stack effect, and the stack effect is no longer a comment, but generates code to create, manage, and remove the stack frame and its local variables. It should not take a great deal of effort to adapt this to calling foriegn functions in C or Pascal. My implementation of this was done in 1991, before the ANS standard, so it does not use the ANS Forth words for handling local variables, but it could use them if need be. I wrote it using LMI 386-UR/Forth. Bruce> Bruce McFarling, Knoxville, brmcf@utkux1.utk.edu -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 30 Mar 1995 20:25:02 GMT <3kkq8f$4el@utkux1.utk.edu> <795752884snz@chocolat.demon.co.uk> <3kphkm$hta@lastactionhero.rs.itd.umich.edu> In-reply-to: Hasdi R Hashim's message of 22 Mar 1995 16:01:26 GMT >>>> Hasdi R Hashim writes: Consider the following program to draw a box on the screen. (I am using "::" and ";;" to make distinction.) :: drawbox ( x1,y1,x2,y2,box_string ---- ) pointer parm box_string integer parm y2 integer parm x2 integer parm y1 integer parm x1 x1 load dup y1 load gotoxy boxstring loadc outchar dup x2 load minus negate 1 minus boxstring 1 adjch loadc swap ( workspace for char and integer, same size) do dup outchar loop drop boxstring 2 adjch loadc outchar y2 load y1 load minus 1 minus do_upwards (1 to dy-1) x1 load dup y1 load i add gotoxy boxstring loadc 3 adjch outchar x2 load minus negate 1 minus boxstring 4 adjch loadc swap ( workspace for char and integer, same size) do dup outchar loop drop boxstring 5 adjch loadc outchar loop dup y1 load gotoxy boxstring loadc 6 adjch outchar x2 load minus negate 1 minus boxstring 7 adjch loadc swap ( workspace for char and integer, same size) do dup outchar loop drop boxstring 8 adjch loadc outchar ;; This is *NOT* typical Forth coding style at all! It *IS* typical coding style for languages like C and Pascal. Forth style is towards *MUCH* shorter definitions, and a *LOT* more subroutine calls. This is *WHY* Forth has 2 stacks: so that subroutine calling in almost free. Your implementation of ssForth and the techniques for getting 2 stacks and all the thrashing you do, which is about 8 machine instruction per word, may not seem like much if you code in the C style, but in the Forth style, with a native machine language compiler, your overhead would often be greater than the code to perform the actual operation of the word (subroutine). When I wrote my local variable implementation, I used it on a real world project. I found myself being *FORCED* to code much longer word definitions in order to gain access to lexically scoped local variables. I even resorted to nested procedure definitions (a cute trick in itself!) so that subroutines called from a word using locals could have access to those locals without having to pass them back and forth all the time. YECH! It turned into a mess, but it was better than block copying the code in those subroutines several times so that I could access the locals. I actually did that on my first attempt, but I was nauseated by it -- total absence of factoring. There are several reasons why many short words are to be preffered over a few long ones. I will not open that can of worms in this thread, because it is heavily influenced by one's personal coding style and software development strategy. Suffice it to say that with many short words, the opportuinties for code re-use are greatly multiplied, and the burden of testing and debugging is greatly eased. If anyone wants me to substantiate that statement, please start a new thread; this one is for ssForth. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: spc@news.gate.net (Sean 'Captain Napalm' Conner) Subject: Re: Interfacing stack-framed languages Date: 30 Mar 1995 16:38:23 -0500 In article <796433447snz@chocolat.demon.co.uk> PS@chocolat.demon.co.uk writes: > brmcf@utkux1 "Bruce McFarling" writes: > >> I think this is a great idea; the implementation of a >>C-frame and a Pascal-frame will have the order reversed and disagree on >>who cleans up afterwards, but until someone says otherwise, I'll continue >>to believe that most stack frame languages use on approach or the other, >>and don't mix and match. So two vocabularies could co-exist with the >>same syntax, one for C-frame languages, and one for P-frame languages. > >...not if you use Windows... which uses both C and Pascal calling mode >(and possibly a third one...not sure?). > The Pascal convention is to push the parameters from left to right, and the callee clears the stack (on an 80x86 this is a 'RET n' instruction). The C convention is to push the parameters from right to left (thus it can handle variable number of parameters) and the caller clears the stack (on an 80x86, this is usually 'CALL foobar / ADD SP,n'). I suspect that Microsoft has combined the two, where the parameters are still pushed right to left (ala C) but the callee clears the stack (ala Pascal). This convention can only be used on functions that take a fixed number of arguments, but that's most functions anyway, and it does produce smaller code. -spc (Who's surprised it wasn't done sooner ... ) From: elvey@hal.COM (Dwight Elvey) Subject: Re: Arith Shift Date: 30 Mar 1995 21:27:45 GMT In article , rolfe@beaufort.sfu.ca (Christopher John Rolfe) writes: |> elvey@hal.COM (Dwight Elvey) writes: |> |> > Chris is making a common mistake. In not using floored math |> >and continuing to use truncation a more insidious error will |> >occure. Instead of getting an offset he will see distortion |> >of the values around zero. As with all things using a more correct |> |> Right and not right. It's true that a good think |> improved my results. However a little noise around zero is |> in audio is never too offensive since it's 96 dB down. Dither, |> for instance, is the practice of ADDING random noise to a signal in |> order to improve the practical quantization error. |> Actually there are two froms of distortion added by using round or truncate towords zero. One is the random or dither that you speak of that is typical of most any form of rounding or truncation including floored. I'm supprised at this. The towards zero truncation causes what is known in the HiFi world as zero crossing distortion. When doing DSP work with a signal and also doing truncate to zero, the error accumalates over operations much as the DC offset accumalates with the floored math. This distortion is famous for it's ability to cause the much dreaded TIM. The problem is made worse when one uses phase linear filtering such as is common in DSP. The distortion always happens at the same spot in the cycle. The choice of using floored math was not arbitrary. It was desided that DC offsets were easier to compensate for then TIM. Some compensation of DC offset can be made by periodically inverting the signal or if the offset is farely constant to just subract it. One should not be running their signal full out so that a little offset will cause clipping. Also one can used one form or the other of hi pass filter. This is what the Hi Fi people have been doing for years. The purest do go for the DC amplifiers but I can't remeber when I last heard 5v DC. |> Music signals and sound, and processing, aren't arbitrary. |> Numerical analysis which would yield the best method for arbitrary |> signals often fails to account for certain predictable characteristics |> of audio. The radix-2 DFT itself is a bit silly, since fully half the points |> are gathered in the highest octave, leaving the lowest octave with |> only one. |> Yes you are write about DFT/FFT being used for analysis of music signal. This is why people are playing with things like waveletes. There is much opening in this field for better tools for both music and voice. Dwight Zero is not unique but I think I am! From: sibit@datasrv.co.il (Russ Hersch) Subject: 8051 microcontroller FAQ Supersedes: Date: 30 Mar 1995 22:41:24 GMT Approved: news-answers-request@MIT.EDU Expires: 14 May 1995 22:39:04 GMT Summary: This article is a collection of information sources on the Intel 8051 family of microcontrollers (and variants). X-Last-Updated: 1995/03/30 Originator: faqserv@bloom-picayune.MIT.EDU Archive-name: microcontroller-faq/8051 Posting-Frequency: monthly Last-modified: Mar. 30, 1995 This article is a collection of information sources on the Intel 8051 family of microcontrollers (and variants). The following topics are addressed: 0) Rantings and ravings (to make the FAQ zero-based) 1) ABOUT THIS FAQ 1.1) Who put this FAQ together? 1.2) How can I contribute to this FAQ? 1.3) What newsgroups will this FAQ be posted to? 1.4) May I distribute this FAQ or post it somewhere else? 1.5) How about FAQs on other microcontrollers? 2) ABOUT THE 8051 2.1) The 8051 microcontroller 2.2) 8051 Flavors 2.3) 8051 representatives and approximate prices 2.4) Advantages realized in implementing control applications on this family of microcontrollers 3) SOURCES OF INFORMATION ON THE 8051 3.1) FTP sites 3.2) BBSs 3.3) Help available! 4) 8051 PRODUCTS 4.1) Free languages and development tools 4.2) Free C compilers 4.3) Commercially available products 5) 8051 DOCUMENTATION 5.1) Periodicals 5.2) Books 5.3) Miscellaneous documentation 0) Rantings and ravings Disclaimer: Just so it is understood, the "rantings and ravings" are my rantings and raving. My readers are refined and sophisticated and would never rant or rave. I, on the other hand, sit in front of the TV in torn underwear and drink beer out of the bottle. This is the one year anniversary edition of this FAQ. I just happen to run across my original file in a forgotten corner of my hard disk and I noticed it had a March date on it. Hard to believe, but it was only 5K! My sincerest apologies to anyone that wrote to me, and didn't get a reply. I was inundated this time, and I'm afraid that I wasn't too careful in keeping track of my email. Also, some of those I did respond to didn't hear from me because their email addresses were invalid (or, at least my system thinks so). So, if you feel neglected, or you submitted some information that didn't make it into this month's update, please drop me a note and let me know. A thousand pardons! Well, the verdict is in. No, I'm not talking about OJ - I'm talking about one-part FAQs versus multi-part. The response has been nearly unanimous to keep the FAQs in one piece. So, one piece it is. Thanks to Hans Schou who is adding his name to the "help available" list. Although not an expert, he has experience with the Standard Microsystems Corp COM20051 integrated microcontroller and network interface. Philips Semiconductor / CEIBO DS750 Devolopment Tools A good way to learn about 8051 programming, this kit is based on the 8xc7xx series which are very low-end, inexpensive micros. They are offered with less memory (1k, 2k, etc.) and fewer features. In fact the 83c750 sells for only $1 in very high OEM volumes. The kit includes a DS750 board, source level debugger, and utilities. Both DOS and Windows versions of the software are included on the diskette, and installation is a snap. I don't understand why, but no assembler is included! A number of assemblers and C compilers are compatible with (or adaptable to) the source level debugger, including: Keil/Franklin, IAR, and Micro Computer Control. If you're on a budget, the Micro Computer Control package is only $100 - the prices of the other packages are a bit more creative :-). Philips also has the MetaLink assembler available for free on their BBS. Besides being a very nice platform for testing your code real-time, the enclosed manual makes this package really worthwhile. In addition to the obligatory startup and operation information, the book includes schematics and theory of the board's operation. Five experiments guide the user on understanding the workings and capabilities of the 8051 family. Priced at only $100, a truckload of these have already been sold, and for good reason. If you're interested in learning how to use an 8051, you can't go wrong by buying this kit. Thanks to Carl Giles for the following information. He fills us in on a chip that can make almost any 8051 variant do what the Dallas DS5000 does: Xicor has some interesting chips that wire up directly to an 8051 (they have similar chips for the 68HC11 flavor.) They need no glue logic, and they contain: 8K x 8 EEPROM in individual 4K segments 2 8-BIT I/O ports 16 8-BIT RAM registers Integrated Interrupt Controller Module Internal programmable address decoding Code loaded at the factory that will allow users to download programs into EEPROM (one 4K segment can be written to while the processor executes out of the other 4K segment), and test the program, rewrite, and retest until development is finished. 2 These are referred to as SLIC E Microperipherals. If you program the SLIC for a different address, multiple SLICs may be gluelessly wired to a single 8031, 32, 51, 52. One of the ports can be programmed to latch out the lower address bits so that standard byte-wide peripherals may be used without further decoding! These are neat chips! Xicor sells a Development Support package that includes a DATA BOOK, a SAMPLE of the CHIP (PDIP or PLCC, your choice) and PC compatible software for downloading and testing your programs. The development package is $15 from Xicor in Milpitas CA. The development system is a lot more, $180 for the populated board. I got in touch with some distributors, to get small QTY. pricing, and there wasn't any. If you ordered at least 40 parts, they could get them for around $12.50. I think I would just get extra kits ($15 @ QTY. 1) and bypass the distributors at that price. The SLIC with the ports comes in a 48 pin PDIP or a 44 pin PLCC. Xicor also offers a memory only solution (which should be cheaper) in a 24 pin PDIP, but the SLIC EEPROM Development Support package doesn't come with the portless 24 pin chip. Take care, Uncle Russ 1) ABOUT THIS FAQ 1.1) Who put this FAQ together? I was prompted to put this FAQ together in response to my own frustration in searching for information, and to the constant occurrence of requests for information on this subject in various newsgroups. Hopefully others won't need to go through what I did. Normally, I spend all day programming in assembler on an IBM PC. With my hobbyist hat on I decided to try my hand at a little microcontroller project design. When it came time to start, I had no idea what to do. I had nothing to start with - no assembler, no programming language, no simulator. I cobbled together a simulator to help me learn about the workings of the chip. It's not being made available to the public since I'm afraid the simulator isn't very good. It was for my own use, so the user interface (there is none) really sucks eggs. I decided to search the net for information on the 8051. This list was compiled the hard way, logging onto every anonymous ftp site I could find and looking around. I also used Archie, other FAQs and lists, and every reference to the 8051 that appeared in the various news groups. It took a long time till stuff finally started popping up. I saved all of my notes and the result was the first version of this FAQ. Responses have been poured in, and the result is a much more complete and thorough FAQ. 1.2) How can I contribute to this list? I please ask that if you have any suggestions or additions, or you would like to correct any of the information contained herein, please send me a note. My Email address is: sibit@datasrv.co.il My Snail-Mail address is: Russ Hersch HaVradim 11 Ginot Shomron ISRAEL The list of individuals who have sent suggestions and encouragement has finally overflowed. I hope it suffices to say "Thank you to all who have contributed to this FAQ - we all appreciate it." Special thanks to: Carl Wall Dave Dunfield (Dunfield Development Systems) Olaf Pfeiffer (Hitex) Dave Heller Kevin Gardner (Philips Semiconductor) Victor Weiman (CEIBO) Clyde Smith-Stubbs (Hi-Tech Software) Bo Frederiksen Hans Schou Ahmad Ibrahim Carl Giles Ken Tindall (IAR) I hope that those of you who know of interesting items for the 8051 will share with everyone by contributing to this list. A good amount of stuff is turning up thanks to everyone's help. If you are a manufacturer and have an anonymous ftp site or BBS available that supports the 8051, please let me know by EMail so that I can add it to this FAQ. Also, please feel free to update me on new products. 1.3) What newsgroups will this FAQ be posted to? This FAQ will be posted to the following newsgroups: comp.sys.intel comp.realtime comp.robotics comp.lang.forth sci.electronics These newsgroups often contain discussions, announcements, or information on the 8051. Check them out from time to time. The schedule for posting will be once a month. I can't promise that it will be on time, but I hope to post it on the 26th of each month. You might also want to check out the following newsgroups, since they occasionally have items of interest for you 8051 fans. comp.lang.misc alt.comp.hardware.homebuilt A bit farther afield, but still of possible interest: comp.ai.fuzzy comp.dsp sci.engr.control sci.engr.semiconductors 1.4) May I post this FAQ to my local BBS? I am putting no restrictions on the use of this FAQ except - It must be distributed in its entirety with the copyright notice, and no financial gain may be realized from it. After all, I have spent, and continue to spend, a lot of time on this. The only thing that I intend to gain from it is more information on the 8051, and getting to know my fellow 8051 groupies better. For this reason I have appended a copyright statement to the end of this FAQ. I feel pretty silly doing this, but I just want to protect myself. The copyright does not limit the use of this list for noncommercial purposes. I hereby give my permission to one and all to pass this list around and post it wherever you want - as long as it is not for financial gain. Thank you. 1.5) How about FAQs on other microcontrollers? If anyone wishes to start a FAQ on another microcontroller, please feel free to copy the format of this FAQ - I don't intend on copyrighting the look and feel ;-). With a common format, we will all benefit when trying to find information on a particular microcontroller. Other Microcontroller FAQs Subject: PIC microcontrollers Newsgroups: comp.realtime comp.robotics sci.electronics Maintainer: Tom Kellett Tom@takdsign.demon.co.uk Subject: 68hc11 microcontrollers Newsgroups: comp.realtime comp.robotics sci.electronics Archive: rtfm.mit.edu : /pub/usenet/comp.answers/microcontroller-faq/68hc11 /pub/usenet/sci.answers/microcontroller-faq/68hc11 /pub/usenet/news.answers/microcontroller-faq/68hc11 Maintainer: Russ Hersch Email: sibit@datasrv.co.il Subject: Microcontroller primer and FAQ Newsgroups: comp.sys.intel comp.realtime comp.robotics sci.electronics alt.comp.hardware.homebuilt Archive: rtfm.mit.edu : /pub/usenet/comp.answers/microcontroller-faq/primer /pub/usenet/sci.answers/microcontroller-faq/primer /pub/usenet/news.answers/microcontroller-faq/primer Maintainer: Russ Hersch Email: sibit@datasrv.co.il Additional FAQs of interest Subject: Robotics Newsgroups: comp.robotics Maintainer: Kevin Dowling (412)268-8830 Email: nivek@ri.cmu.edu Smail: Carnegie Mellon University The Robotics Institute Pittsburgh, PA 15213 Subject: Electronics Newsgroups: sci.electronics Comments: There are a number of FAQs available in this newsgroup on various subjects. Among some of the subjects covered are: LCDs, stepper motors, etc. FAQ subject: Real-time Newsgroups: comp.realtime, comp.answers, news.answers Archive: rtfm.mit.edu : pub/usenet/comp.realtime Maintainer: Mark Linimon Lonesome Dove Computing Services Roanoke, Virginia Email: linimon@nominil.lonesome.com. Subject: Motorola 68K microprocessor line Newsgroups: comp.sys.m68k Archive: bode.ee.ualberta.ca : pub/motorola/general ftp.luth.se : /pub/misc/motorola/faq file name of archive is m68kfaq?.zip (? is version) Maintainer: Robert Boys - Ontario, Canada Email: r.boys@genie.geis.com or fboys@uoguelph.ca For more detailed information on various 8051 microcontroller parts, see the article posted to comp.robotics and sci.electronics which provides a tabular cross reference of features and pin counts on a wide range of microcontrollers (including the 8051 family). This list was compiled and is being maintained by Roger Nelson . For more information on various microcontrollers and their features, refer to the Microcontroller primer and FAQ listed above. 2) ABOUT THE 8051 2.1) The 8051 microcontroller The 8051 is an 8 bit microcontroller originally developed by Intel in 1980. It is the world's most popular microcontroller core, made by many independent manufacturers (truly multi-sourced). There were 126 million 8051s (and variants) shipped in 1993!! A typical 8051 contains: - CPU with boolean processor - 5 or 6 interrupts: 2 are external 2 priority levels - 2 or 3 16-bit timer/counters - programmable full-duplex serial port (baud rate provided by one of the timers) - 32 I/O lines (four 8-bit ports) - RAM - ROM/EPROM in some models The 8051 architecture is a tad bizarre, but then so are the architectures of most microcontrollers due to their specialization (check out the PIC for creativity). One vexing problem with the 8051 is its very non-orthogonal instruction set - especially the restrictions on accessing the different address spaces. However, after some time programming the chip, you can get used to it - maybe even appreciate it. One strong point of the 8051 is the way it handles interrupts. Vectoring to fixed 8-byte areas is convenient and efficient. Most interrupt routines are very short (or at least they should be), and generally can fit into the 8-byte area. Of course if your interrupt routine is longer, you can still jump to the appropriate routine from within the 8 byte interrupt region. The 8051 instruction set is optimized for the one-bit operations so often desired in real-world, real-time control applications. The boolean processor provides direct support for bit manipulation. This leads to more efficient programs that need to deal with binary input and output conditions inherent in digital-control problems. Bit addressing can be used for test pin monitoring or program control flags. 2.2) 8051 Flavors The 8051 has the widest range of variants of any embedded controller on the market. The smallest device is the Atmel 89c1051, a 20 Pin FLASH variant with 2 timers, UART, 20mA. The fastest parts are from Dallas, with performance close to 10 MIPS! The most powerful chip is the Siemens 80C517A, with 32 Bit ALU, 2 UARTS, 2K RAM, PLCC84 package, 8 x 16 Bit PWMs, and other features. Among the major manufacturers are: AMD Enhanced 8051 parts Atmel FLASH and semi-custom parts Dallas Battery backed, program download, and fastest variants Intel 8051 through 80c51gb / 80c51sl Matra 80c154, low voltage static variants OKI 80c154, mask parts Philips 87c748 thru 89c588 - more variants than anyone else Siemens 80c501 through 80c517a, and SIECO cores SSI 80x52, 2 x HDLC variant for MODEM use Advanced Micro Devices (AMD) AMD has a number of enhanced variants including such features as: dual data pointers, slave interface with arbitration unit, dual port RAM, FIFO buffers, and others. Atmel The smallest current device is the ATMEL 89c1051, a 20 Pin FLASH variant with 2 timers, UART, 20mA. ATMEL was the first with standard pinout FLASH, and with more program cycles than other custom pinout FLASH. These parts compete with OTP and MASK product on price, but eliminate inventory problems and the hidden costs of OTP development. This will put real pressure on "vanilla" micros like PIC and ST6. Dallas Soft Microcontrollers - DS5000(T), DS5001(T), DS2250(T) The Dallas Soft Microcontrollers have standard 8051 cores with on-chip non-volatile RAM instead of ROM. This gives the user the ability to easily alter the system and is perfect for data logging. These processors are available in both chip and module solutions. Among the features included in this family of products: - on-chip non-volatile RAM - loader in ROM for downloading programs (eliminates the hassle of EPROM erase/program/install cycle) - built in real time clock option - watchdog timer - software security (program and data encryption) The DS500x is a standard 40 pin DIP package (well, mostly standard, it is really a BOX which is about double the height of a normal chip). The DS225x is a SIP version which is functionally identical to the DS5000 but usually a bit less expensive. The nice thing about having the RAM on-chip, is that the I/O ports are unaffected. When the RAM is configured as CODE memory, the DS5000 behaves exactly as a single-chip 8051. The NV-RAM is static with a built-in lithium battery, and has no limitations on the number of writes. You can download your code as many times as you like without damaging the device. The DS5000 also includes a loader in ROM, which permits you to bootstrap code into the RAM to get underway. The loader and on-chip RAM have an encryption feature with which you can protect your code from being read back from the device if you wish. Dallas High-Speed Micros - DS80c320, DS87c520, DS87c530 Real barn-burners - performance up to 10 MIPS! Dallas was the first to speed up the core. Wasted clock and memory cycles have been removed using a redesigned processor core. As a result, every 8051 instruction is executed up to 3 times faster than the original for the same crystal speed. Clock speeds from DC to 33MHz! High performance doesn't just mean speed. High integration gives the user 2 full-duplex hardware serial ports, 13 total interrupt sources (6 external), watchdog timer, power management, power-fail reset, and other features. Intel MCS-51 Introduced in 1980, it has become the industry standard for embedded control. Intel offers a wide variety of 8051 versions with different configurations of on-board EPROM/ROM. Also low power, high integration, and specialized parts are also offered. OKI OKI makes an 85c154 piggyback - an 8751 but with an EPROM socket on top! Great with an EPROM emulator. Philips Philips has more 8051 variants than anyone else. Among the derivatives that they have: 40MHz, 24 pin skinny DIP, low voltage, quad flat pack (QFP) versions for saving board space, OTP, I2C bus, and so on. The c5xx line features high integration, with many built-in features including built-in EMI/RFI suppression. The c7xx series are very low-end, inexpensive micros. They are offered with less memory (1k, 2k, etc.) and fewer features. In fact the 83c750 sells for only $1 in very high OEM volumes. Siemens sab80c517a The 80c517a is one of the most powerful 8051 variants available. It features high clock speed (40 MHz), and high integration with 32 Bit ALU, 2 UARTS, 2K RAM, PLCC84 package, 8x16 bit PWMs, and more. Standard Microsystems Corporation SMC COM20051 The COM20051 is an integrated microcontroller and network interface. Features: - high performance and low cost - based on popular 8051 architecture - drop-in replacement for 80C32 PLCC - network supports up to 255 nodes - powerful network diagnostics - maximum 512 byte packets - duplicate node ID detection - self-configuring network protocol - retains all 8051 peripherals including Serial I/O and 2 Timers - utilizes ARCNET(R) Token Bus Network Engine - requires no special emulators - 5 Mbps to 156 Kbps data rate - network interface supports RS-485, twisted pair, coaxial, and fiber optic interfaces - receive all mode allows any packet to be received 2.2) 16-bit 8051 parts A joint project between Intel and Philips Semiconductors has resulted in two new excting products - 16 bit 8051s! Due to a disagreement between the parties, they each went their separate ways. Intel developed the MCS-251, which was originally called the ZX (this name can still be found on one of the Intel slide shows). Philips came out with the eXtended Architecture (XA) line. The Intel MCS-251 is a drop-in replacement for the 8051, and is also binary compatible. The XA is more of a 16 bit micro which also happens to be source code compatible. One can argue the merits of which approach is better. Pin compatible parts allow instant performance upgrades for existing designs, and the binary compatibility truly preserves users investment in code and tools. By staying firmly in the 80x51 camp, Intel allows users transparent access to an enormous horsepower range. To further improve throughput in numerically intensive areas, users can use INTEGER, LONGINT, and FLOAT libraries written for the MCS-251. The Philips XA is not a drop-in replacement for the 8051. Binary code compatibility is nice, you can move right up to a more powerful engine without having to bust a gut (We all know the Intel binary compatible success story with their 80x86 microprocessors). But if you're working on a new design, how necessary is binary compatibility? If you're just looking for a souped up '51, Dallas already has the 320. If you need the advanced features, you'll need to recompile or rewrite your software anyhow. You'll also have to drag along some compatibility baggage with you in order to use the 16 bit operations - these are preceded by an escape code (A5H), the only instruction not used in the 8051 instruction set. With source code compatibility, you have to recompile your code (with a new set of development tools), since the instruction set has been recrafted to allow the biggest bang for the buck. This process isn't 100% transparent, but then again, binary compatibility isn't either. If you're upgrading an existing design, the 251 is probably your only reasonable choice (although you might also want to consider the Dallas 320). On new designs, you'll have a tough decision to make. Whichever path you choose to take, the 8051 will never be the same again. Intel MCS-251 The Intel MCS-251 is 100% binary and pin compatible with the 8051, but with a 5-15 times boost in horsepower. This is achieved by a six fold gain in bus cycles, and further hardware improvements to avoid wasted bus cycles. Further performance gains are possible by recoding critical sections to take advantage of the new features: powerful 8/16/32 bit instructions, flexible 8/16/32 registers, 16MB linear address space, 16-bit stack pointer, enhanced BIT manipulations, and improved control instructions. In addition to extra 16/32 bit instructions, the 251 includes 40 registers with Accumulator and Index functions overlayed as 16x8, 16x16, 10x32. Philips 8051XA By tossing compatibility out the window, Philips was able to develop a true 16 microcontroller while at the same time preserving the basic 8051 instruction set (source). The benefits of this break with tradition result in a chip that has dual 16MB address spaces (data and code), multitasking support with task protected memory segments, a separate SFR bus, fast context switching, and optimized code efficiency. Other features include: hardware divide and multiply (over 100 times faster than an 8051), 32 vectored interrupts, 16 hardware exceptions, and 16 trap instructions. 2.3) 8051 representatives and approximate prices (in USD $) There are many, many varieties of 8051 out there. This is only a small sampling of typical prices on Intel chips. 8031 (128 bytes RAM)...................................3.59 80C31 (CMOS version of previous).......................6.95 8051AH (256 bytes RAM).................................6.95 8051AHBASIC (w/Basic interpreter built in)............29.95 8751 (4K EPROM, 128 bytes RAM)........................26.95 87C51 (CMOS version of previous)......................39.95 2.4) Advantages realized in implementing control applications on this family of microcontrollers Popular - readily available and widely supported, a full range of free and commercial support products is available Fast and effective - the architecture correlates closely with the problem being solved (control systems), specialized instructions mean that fewer bytes of code need to be fetched and fewer conditional jumps are processed Low cost - high level of system integration within one component, only a handful of components needed to create a working system Wide range - ONE set of tools covers the greatest horsepower range of any microcontroller family, other suppliers handle a number of DIFFERENT and INCOMPATIBLE (and often single-sourced) cores to cover the same power range as the 80x51, the 8051 provides a real cost savings in tools, training, and software support Compatibility - opcodes and binaries are the SAME for all 80x51 variants (unlike most other microcontroller families) Multi-sourced - over 12 manufacturers, hundreds of varieties, something for everyone with the security of ready availability Constant improvements - improvements in silicon/design increase speed and power annually, 16 Bit models coming from several manufacturers, low cost skinny DIP models now available 3) SOURCES OF INFORMATION ON THE 8051 3.1) FTP sites The following is a list of the various anonymous ftp sites that have 8051 source code and programming languages. There are many others that are not listed here that contains bits and pieces. Usually you can find them using Archie and searching for "8051", "AS31", "ASM51", "MCS-51", "MCS51", and stuff like that. ftp.pppl.gov (formerly lyman.pppl.gov) - this is a great source of 8051 stuff /pub/8051 /pub/incoming - check this out for new untested/unsorted items ftp.funet.fi (nic.funet.fi) - this is a great one, too /pub/compilers/8051 /pub/microprocs/MCS-51 other subdirectories in /pub/microprocs include: 1802, 6805, 6811, 8048, 8096 and many other microprocessors ftp.intel.com - this ftp site is pretty good now, and getting better all the time! - send comments to: ftp-admin@intel.com /pub/mcs51 /pub/mcs51/tools - contains various development tools nctuccca.edu.tw - mirror of ftp.intel.com - /vendors/Intel Philips-News@InetBSystems.us.com - Email (not ftp) - send Email with "subscribe" in the subject field to be put on list for newsletter Philips-archive@InetBSystems.us.com - Email (not ftp) - send Email message with the word "help" in the subject line to learn how to access the archive Philips-forum-request@InetBSystems.us.com - Email (not ftp) - send an Email message with the word "subscribe" in the subject line to participate in the forum, and receive usage instructions and guidelines Philips-Info@InetBSystems.us.com - Email (not ftp) - send Email message to get information on all of Philips Email services ftp.mcc.ac.uk - this is a new 8051 ftp site - soon to be improved info@circellar.com - Email (not ftp) - send Email to get information file on services available - all Circuit Cellar INK and BYTE related files available ftp.ee.ualberta.ca /pub/cookbook/digital - circuits of all types - prog51.zip is a programmer for the ATMEL 89C51 flash part by Werner Terreblanche ftp.luth.se /pub/languages/assembler asterix.inescn.pt - FORTH archive /pub/forth/8051 hpcsos.col.hp.com /mirrors/.hpib0/forth/8051 /misc/ns32k/beowulf/a-8051 /mirrors/.hpib0/forth/eForth ftp.armory.com (Steve Walz) /pub/user/rstevew/8051 /pub/user/rstevew/TB8051 /pub/user/rstevew/incoming ftp.oak.oakland.edu - has information and software for a wide range of microprocessors and microcontrollers, you may have to look around a bit 130.123.96.9 giovanni/51forth.zip ftp.kulnet.kuleuven.ac.be /pub/MCS-51/keil-demo ai.uga.edu /pub/hardware - stuff on the Philips 87C750/1/2 microcontrollers - assembler, an update for the software in the DS-750 kit, notebook of some early experiences and code - responses welcome, Michael A. Covington (mcovingt@ai.uga.edu) csd4.csd.uwm.edu - no longer supports 8051, don't even try awaiting final corporate approval... Philips Semiconductor ftp site 3.2) Web pages S. Joel Katz's web page - address is http://www.panix.com/stimpson/micro.html - information about 8051 and related microcontrollers - not much information yet, but it is increasing rapidly Automation and Process Control (Olaf Pfeiffer) - http://www.ba-karlsruhe.de/automation/home.html - http://www.ba-karlsruhe.de/automation/ctrl/FAQ/microFAQ/microFAQ.html 3.3) BBSs The following BBSs have 8051 information: AM Research - (916)652-7117 Blue Earth Research - support for their line of microcontroller boards - (507)387-4007 Circuit Cellar, Inc. - contains code from their magazine articles and from the original Circuit Cellar articles in Byte magazine, also contains many other interesting items - GOOD STUFF HERE! - The BBS is mentioned in the masthead of each issue (on the table of contents page). Excerpts from the BBS appear in Ken Davidson's ConnecTime column in every issue with a description of how to access the system at the end of every column. - (203)871-1988 - Voice: (203)875-2751 - Fax: (203)872-2204 Crossware Products - +44 763 261716 Dallas Semiconductor - Support for their line of innovative products Dunfield Development Systems - support for their Micro-C compiler and development tools - includes a lot of nice goodies - CHECK THIS OUT! - (613) 256-6289 Electronics Now - contains code from their magazine articles - (516)293-2283 - 1200/2400, 8N1 Intel American Marketing Applications Support Bulletin Board System - 16 lines, hi-speed modems (14.4K) - Lots of useful info and files (including design examples)! - Full ANSI-BBS with color is recommended, but support for just about all terminal types is provided - (916)356-3600 (24 hours) Auto config: 1200 thru 14.4K Baud 8 data bits, no parity, 1 stop Iota Systems, Inc. - Support for their line of hardware and software products - 15 application notes which show how to hook up such things as clocks, A/D, D/A, and special chips to the 8051 - (702)831-4732 Micro Computer Control Corporation - (609)466-4117 Philips Semiconductor - Europe - support for: standard logic, programmable logic, in-car electronics (now open), 8 and 16 bit microcontrollers, I2C software, third party software, discrete semiconductors, cross assemblers (general), RF (planned) - PHIBBS is located in the Netherlands: +31-40-721102 - maximum 21600 baud / V42bis / HST/Vterbo - 24 hours a day available - Help desk: +31-40-722749 (9.00 AM - 16.00 PM CET) Philips Semiconductor - North America - support for their 8051 variants - contains many good source code items - partially mirrored on ftp.pppl.gov and nic.funet.fi - (800)451-6644 or (408)991-2406 PseudoCorp - support for their line of simulators and assemblers - (804)873-4838 Realtime Control & Forth Board (RCFB) - Forth and assembly for the 8051 - 300 through 14.4 baud - (303)278-0364 (24 hours) Systronix Inc. - support for their line of development tools - (801)487-2778 3.4) Help available! This is a new feature in the FAQ. Listed here are individuals who have expressed interest in helping others with hardware and software problems for 8051 systems. Does any one else out there think that they can help? Just let me know what your areas of specialization are and I'll add your name to the list. Thanks! Dick Barnett Specializes in 8051 (core processors), 80C552, and 87C751 applications. Daniel Drennan or He claims his electronics knowledge is very rudimentary and self-taught (what a modest guy!). He'll probably be able to point you in the right direction. Mark Hopkins Mark is the author of the CAS assembler and of the 8051.ZIP programs. He's now working on JOLT, a code generator with a C-like syntax. His areas of specialization include: multitasking, interrupts, basic stuff (like addressing, memory spaces), the 8052 BASIC chip, interfacing the chip with external inputs and outputs Hans Schou Hans is offering his assistance to users of the Standard Microsystems Corp. COM20051. He's not an expert, but he has some experience with it. 4) 8051 PRODUCTS This section includes descriptions and references to free and commercial software for the 8051. FTP sites and BBSs contain many quality packages and code samples for free. For heavy duty use, you might prefer the many commercial packages that are available. With the public domain (or free) stuff, you're usually on your own. The commercial packages usually provide extensive documentation and support. 4.1) Free languages and development tools The following is a list of the languages and development tools that I could find on the net. Nearly all of them include source code, however not all are public domain. Assembler Program: ML-ASM51.ZIP Description: MetaLink's 8051 family macro assembler Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: A51.ZIP Description: PseudoSam 8051 Cross Assembler Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: AS31.ZIP Description: C source for an 8051 assembler, and a simple monitor Author: Ken Stauffer Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs ftp.uu.net oak.oakland.edu : /pub/msdos/crossasm/as31.zip many other locations (use Archie to find) Program: CUG292WK.ZIP Description: C source for a cross assembler, includes 8051 Author: Alan R. Baldwin Location: oak.oakland.edu : /pub/msdos/crossasm pc.usl.edu : /pub/msdos/systools many other locations (use Archie to find) Program: Frankenstein Description: C source for a cross assembler, includes 8051 Author: Mark Zenier Location: ftp.njit.edu : /pub/msdos/frankasm/FRANKASM.ZOO lth.se : /pub/netnews/alt.sources/volume90/dec ftp.uni-kl.de : /pub1/unix/languages/frankenstein.tar.Z many other locations (use Archie to find) Program: CAS 8051 assembler Description: Experimental one-pass assembler for the 8051 with C-like syntax. Includes assembler, linker and disassembler. Author: Mark Hopkins Location: ftp.pppl.gov : /pub/8051/assem ftp.funet.fi : /pub/microprocs/MCS-51/csd4-archive/assem Program: a51 Description: Portable cross assembler (source in C), other processors available Author: William C. Colley, III Location: hpcsos.col.hp.com : /misc/ns32k/beowulf/a-8051 Basic Program: BASIC52.ZIP Description: Source files for original BASIC 52 interpreter Author: Intel Corporation, Embedded Controller Operations Location: ftp.intel.com : /pub/mcs51 Program: BAS051.ZIP Description: Converts IBM BASIC to 8051 assembly (compiler) Author: Winefred Washington Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/8051/signetics-bbs Program: BASIC-52.ZIP Description: Source files for BASIC-52 interpreter Author: Intel Corporation, Embedded Controller Operations Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: BASIC31.ZIP Description: BASIC-52 interpreter for 8031/8051 in external EPROM Author: Intel w/ changes by Dan Karmann Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: TB-51.ZIP Description: TinyBASIC for 8031 Author: JHW (from Intel InSite library) w/ fixes by Tom Schotland Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: TB51ML23.ZIP Description: MetaLink ASM compatible tiny BASIC Author: adapted for MetaLink assembler by Jim Lum Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Forth Program: EFORTH51.ZIP Description: eFORTH environment for the 8051 Author: C. H. Ting Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs asterix.inescn.pt : /pub/forth/8051 hpcsos.col.hp.com : /mirrors/.hpib0/forth/eForth Program: FORTH51.ZIP (FORTH86.ZIP used as host) Description: FORTH development system for 8051 with PC host Author: William H. Payne, the author of "Embedded Controller Forth for the 8051 Family" Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs asterix.inescn.pt : /pub/forth/8051 hpcsos.col.hp.com : /mirrors/.hpib0/forth/8051 Program: XD8051.ZIP Description: Development environment for use with F-PC Forth Author: Paulo A.D. Ferreira Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs Program: 51FORTH.ZIP Description: Subroutine threaded Forth Author: Scott Gehmlich Location: hpcsos.col.hp.com : /mirrors/.hpib0/forth/8051 130.123.96.9 : /giovanni/51forth.zip Program: FORTH552.ZIP Description: A Non-Standard Forth System for the Signetics 80C552 Author: Alberto Pasquale Location: hpcsos.col.hp.com : /mirrors/.hpib0/forth/8051 Development systems Program: 8051.zip Description: Many development tools including: debugger, monitor, LCD and stepper moter driver, communications, host client, and much more. This is a great collection of tools. Author: Mark Hopkins Location: ftp.pppl.gov : /pub/8051/signetics-bbs ftp.funet.fi : /pub/microprocs/MCS-51/csd4-archive Program: RISM and IECM51.EXE compatible host system Description: RISM is a reduced instruction set monitor and IECM51.EXE is its compatible host system for a PC Comments: These two programs together constitute a bare-bones method of developing 80C51 system code without an emulator. RISM51X is installed in the target system and connected to a host PC system through a serial port. The host PC runs the debugger IECM51.EXE. Once the system has been debugged, RISM can be removed and the target can be run in stand-alone mode. Author: Intel Location: ftp.intel.com : /pub/mcs51/tools Program: ApBUILDER 2.0 Description: Development system for the Intel MCS-51(R) family (also for the MCS-96(R) family, 80x186, and 80x386 embedded microcontrollers). Comments: Requires Windows 3.1 APBUILDR.TXT - description in ASCII APBDISK1.EXE - binary self-extracting file for disk 1 APBDISK2.EXE - binary self-extracting file for disk 2 Author: Intel Location: ftp.intel.com : /pub/mcs51 and /pub/mcs96 Program: FXDSMAN.EXE Description: 8xC51Fx data sheets and manual in Windows 3.1 hypertext style Comments: binary self-extracting file for one diskette Author: Intel Location: ftp.intel.com : /pub/mcs51/80c51 Program: sim51d Description: Shareware Simulator in German DM 50 to register for full version Author: Werner Hennig-Roleff Location: ftp.pppl.gov : /pub/8051/hannover Program: sim552vq.zip Description: 80C552 simulator (Freeware) Comments: Program is capable of reading .HEX and .S19 records, or saving memory to a file. It supports both code and data. Written in Turbo Pascal for XT and upwards. Author: Brian Brown Location: cscnt.cit.ac.nz : /pub/msdos/sim552v1.zip 4.2) Free C compilers Several commercial C compilers have evaluation versions available. These are not too useful (even for hobbyist projects) since they usually don't include libraries. However, they do afford the user the chance to inspect the quality of the code generated. Among those currently available: An evaluation version of COMPASS is available from Production Language Systems. This package includes a C compiler, assembler, debugger, simulator, etc. and runs under Windows 3.1. This package can be downloaded from the IntelC Compuserve forum or from their BBS: (817)599-8363 Enter YY8051 as password for first-time login (In case of difficulty, contact manvillec@aol.com) The Keil C compiler evaluation package is available as a freeware C compiler. It can be downloaded from: ftp.kulnet.kuleuven.ac.be : /pub/MCS-51/keil-demo Thanks to Christofe Huygens for setting this up. You can now get the freeware version of the Hi-Tech C compiler from their own (rather modest) ftp site: ftp.hitech.com.au. They are also working on a Web setup too, but it's not ready yet. It will be the expected www.hitech.com.au when it's up. Mark Hopkins has changed the goal of his compiler project. Instead of implementing a C compiler, he is working on an implementation of JOLT for the '51. Its main characteristic is the complete and seamless integration of functional and imperative programming into one language. The language envisioned essentially has a C syntax and could probably be mistaken as being a dialect of C. More on this as it develops. However, the good news is that Ahmad Ibrahim informs me that he's well on his way to putting together a C compiler which will be released as freeware. The initial offering will generate code only for the 8051. By making the compiler table driven, it will be adaptable for other processors. Other features are in the works including a simulator/debugger. In most cases, it makes more sense to invest a bit, and get something serious. Also, by buying a commercial package, you have the advantage of having the documentation, and being able to get technical support. There are two low-cost C compilers currently available for 8051 development. I've been using the Dunfield Development System, and its really quite nice. I've also heard many good things about it from others. For $100 you get a near ANSI-C compiler, run-time library with source, assembler, ROM debugger, integrated development environment, monitor with source, utilities, and other extras. A high quality simulator for only $50 is also available separately. The simulator has an option allowing you to interface to your target by using an on-chip monitor. Although not freeware, the low price, the features, all of the extra goodies, and the good reviews make this a package worth looking at. Also, if you're interested in working on more than one family of microcontroller, Dunfield supports a wide range. This means only needing to learn one system, instead of many. Another low priced ($100) C compiler comes from Micro Computer Control. Cross compilers running under DOS are available for the 8051 and the Z8 (including Super-8). This package includes a C compiler, assembler, linker, librarian, and extensive printed documentation. A simulator/source code debugger is available for an additional $79.95. The simulator is completely configurable, so much so that you don't even need the target hardware to test with. You can configure all I/O and other features of your target chip or environment. Micro Computer Control Corporation PO Box 275, 17 Model Ave., Hopewell, NJ 08525 (609)466-1751 Fax: (609)466-4116 BBS: (609)466-4117 Email: 73062.3336@compuserve.com 4.3) Commercially available products Many firms (large and small) offer a variety of 8051 microcontroller variants, programming languages, support packages, and development systems. No endorsement is implied by inclusion in this list. I apologize to anyone I left out; It's only because I didn't know about you. If you want to be included in this list, just drop me a line - please. Any corrections and additions appreciated. C compilers ($$$ - high, $$ - medium, $ - low priced) - 2500 A.D. - Archimedes Software $$$ compiler, assembler, debugger, real-time kernel, ROM monitor, libraries for special 8051's to set SFR, embedded I/O devices, A/D, etc. - Avocet Systems $$ repackaging of the Hi-Tech Software C compiler - BSO/Tasking $$ - Crossware Products - Dunfield Development Systems $ Complete C compiler development system for MS-DOS includes: compiler, run-time library with source, assembler, ROM debugger, integrated development environment, monitor with source, utilities, and other extras low price: $100 good reputation and good support works well with the Dallas DS5000/DS2250 - Franklin Software $$$ same as Keil Electronics C compiler, assembler, debugger, real-time kernel, ROM monitor, libraries for special 8051's to set SFR, embedded I/O devices, A/D, etc. - IAR Systems IAR tool kit comes with a C-Cross compiler, assembler, Xlink linker, Xlib librarian, C-SPY simulator, editor, make utility and a real-time kernel formerly licensed for distribution in the US and Canada under the Archimedes brand name - Hi-Tech Software $$ high compliance to ANSI C available for DOS and soon for SUN - Intermetrics Microsystems Software, Inc. Whitesmith's compiler, assembler, and C source level debugger - Keil Electronics - Mandeno Granville Electronics, Ltd SYS51C - ANSI C Cross Compiler - Micro Computer Control $ Developer's kit includes "C"-like compiler, assembler, linker, librarian, extensive printed documentation low cost ($99.95) - Nohau Corporation sells and supports Franklin C - Okapi Systems - Production Languages Corporation DOS- and Windows- based compilers Integrated development environment includes ANSI C compiler, assembler, linker, librarian, debugger - Signum Systems Basic interpreters/compilers - Binary Technology, Inc. - Iota Systems, Inc. Basic-752 interpreter (simulator also available) Basic-52 Plus interpreter - Micro Future Basic-52 development system - Systronix Inc. (Basic compiler) Pascal - Mandeno Granville Electronics, Ltd PASCAL51 - Advanced Turbo PASCAL compliant cross compiler - Scientific Engineering Labs Modula-2 - Mandeno Granville Electronics, Ltd Mod51 - optimizing Modula-2 Compiler, smallest program is 14 bytes, ideal for both very tight/fast projects and very large ones with multiple modules, produces smaller/tighter code than C, has extensive libraries and working examples - Vail Silicon Tools, Inc. PL/M - BSO/Tasking Board level products - Ackerman Computers Sciences (ACS) - AM Research complete FORTH based system with PC based host system - Binary Technology, Inc. - Blue Earth Research - Blue Ridge Micros (8031 and 8052-BASIC based boards) - Circuit Cellar Inc. - DataCraft International - Dunfield Development Systems - EE Systems - Forth, Inc. - HiTech Equipment Corp. - Iota Systems, Inc. (line of development packages, boards, peripherals, and components) - J & M Microtek, Inc. - L.S. Electronic Systems Design - Mandeno Granville Electronics, Ltd - Parallax, Inc. - Prologic Designs - Rigel Corporation - Software Science - Suncoast Technologies - URDA, Inc. Assemblers - 2500 A.D. - Archimedes Software - BSO/Tasking - Crossware Products - Custom Computer Consultants - Cybernetics Microsystems - Dunfield Development Systems Supports both Intel and Motorola style syntax - Intel Corporation - Keil Electronics - Lear Com Company - Metalink - Micro Computer Control - Microtek Research - Nohau Corporation - Okapi Systems - Onset Computer Corporation (8051 Assember for MAC) - Parallax, Inc. - PseudoCorp - Raven Computer Systems - Signum Systems - Speech Technology Inc. - Sysoft SA - Universal Cross Assemblers CROSS32 supports 40-50 different processors Forth - AM Research Development system, features kernel of less than 700 bytes - Forth, Inc. A cross-development product for the 8051 family which includes a board and extensive documentation. - Forth Systeme - MPE: MicroProcessor Engineering Ltd. A cross-development system for the 8051 family extensive documentation interactive single chip development, multitasking, bank switching for more than 64k code - Offete Enterprises 8051 eForth (C. H. Ting -- $25.00). "A small ROM based Forth system ... Source code is in MASM IBM 5.25 disk with 8051 eForth Implementation Note." ROM Monitor-based Debuggers - ChipTools (ChipView-51 looks like turbo debugger) - Dunfield Development Systems Can be used with DS5000 for single-chip in-circuit emulation Simulators - 2500 A.D. - Avocet Systems - ChipTools on a 33 MHz 486 matches the speed of a 12 MHz 8051 - Cybernetic Micro Systems - Dunfield Development Systems Low cost $50.00 500,000+ instructions/second on 486/33 Can interface to target system for physical I/O Includes PC hosted "on chip" debugger with identical user interface - HiTech Equipment Corp. - Iota Systems, Inc. - J & M Microtek, Inc. - Keil Electronics - Lear Com Company - Mandeno Granville Electronics, Ltd - Micro Computer Control Corporation Simulator/source code debugger ($79.95) - Microtek Research - Production Languages Corp. - PseudoCorp Emulators ($$$ - high, $$ - medium, $ - low priced) - Advanced Micro Solutions $$ - Advanced Microcomputer Systems, Inc. $ - American Automation $$$ $$ - Applied Microsystems $$ - ChipTools (front end for Nohau's emulator) - Cybernetic Micro Systems $ - Dunfield Development Systems $ plans for pseudo-ice using Dallas DS5000/DS2250 used together with their resident monitor and host debugger - HBI Limited $ - Hewlett-Packard $$$ - HiTech Equipment Corp. - Huntsville Microsystems $$ - Intel Corporation $$$ - Kontron Electronics $$$ - Mandeno Granville Electronics, Ltd full line covering everything from the Atmel flash to the Siemens powerhouse 80c517a - MetaLink Corporation $$ $ - Nohau Corporation $$ - Orion Instruments $$$ - Philips $ DS-750 pseudo-ICE developed by Philips and CEIBO real-time emulation and simulator debug mode source-level debugging for C, PL/M, and assembler programs 8xC75x parts low cost - only $100 DOS and Windows versions available - Signum Systems $$ - Sophia Systems $$$ - Zax Corporation - Zitek Corporation $$$ Real-time - Byte-BOS Integrated Systems small, prioritized, preemptive real-time kernel - Embedded System Products (formerly A.T. Barrett and Associates) ROMable embedded-system kernel: source provided. Provides programming interface identical on all target platforms. Basic, advanced, and extended library packages available. - Intellimap Engineering DCE51 real time operating system - JMI Software Systems, Inc. small, prioritized, preemptive real-time kernel - U S Software SuperTask! - multitasking executive Trainers - Advanced Educational Systems (AES) complete learning system (board, LCD, keypad, A/D, D/A, etc) - Sun Equipment Corp. trainers Miscellaneous - Creative Applications Engineering, Inc CheepTools (integrated environment) - Dallas Semiconductor evaluation/development kit for their DS5000 (very nice) - Data Sync Engineering (disassembler) - Educational Laboratories development courses: 8051 Microcontroller Based Computer Design Programming 8051 Based Computers each course $19.95, both $29.95 - Electronic Product Design, Inc. development system (integrated package with assembler, project manager, text editor, programmer) - Exor Inc. (ladder logic compiler) - Iota Systems, Inc. integrated environment system - Mandeno Granville Electronics, Ltd PIC to 8051 conversion program - Parallax, Inc. programmers - Quantasm Corp. ASMFLOW - produces flowchart and tree diagrams from source code, register usage analysis, Xref, timing info - U S Software USNET - TCP/IP networking suite USFiles - file system GOFAST - floating point library 2500 A.D. 109 Brookdale Ave., Box 480, Buena Vista, CO 81211 (719)395-8683 Ackerman Computer Sciences (ACS) 4276 Lago Way, Sarasota, FL 34241 (813)377-5775 Fax: (813)378-4226 Advanced Educational Systems (AES) 1407 North Batavia Street, Orange, CA 92677 (800)730-3232 (714)744-0981 Fax: (714)744-2693 Advanced Micro Devices 901 Thompson Place, PO Box 3453 Sunnyvale, CA 94088-3000 (408)732-2400 Advanced Microcomputer Systems, Inc. 1321 NW 65th Place, Fort Lauderdale, FL 33309 (305)975-9515 Fax: (305)975-9698 Advanced Micro Solutions 1033 S Imperial Dr., Hartland, WI 53029 (414)367-3577 American Automation 2651 Dow Avenue, Tustin, CA 92680 (714)731-1661 AM Research 4600 Hidden Oaks Lane, Loomis, CA 95650 (800)949-8051 (916)652-7472 Fax: (916)6642 BBS: (916)652-7117 Email: sofia@netcom.com Applied Microsystems 5020 148th Ave. N.E., PO Box 97002 Redmond, WA 98073-9702 Archimedes Software 2159 Union St., San Francisco, CA 94123 (415)567-4010 Ashling Microsystems Ltd Ireland Plessey Technological Park Limerick, Ireland +353 61 334466 Fax: +353 61 334477 United Kingdom Butler House 19-23 Market Street Maidenhead, Berkshire, UK +0628 773070 Fax: 0628 773009 Atmel Avocet Systems 120 Union St., Rockport, ME 04856 (800)448-8500 (207)236-9055 Fax: (207)236-6713 Binary Technology, Inc. PO Box 541, Carlisle, MA 01741 (508)369-9556 Fax: (508)369-9549 Blue Earth Research 165 W. Lind Ct., Mankato, MN 56001-0400 (507)387-4001 Fax: (507)387-4008 BBS: (507)387-4007 Blue Ridge Micros 2505 Plymouth Rd., Johnson City, TN 37601 (615)335-6696 Fax: (615)929-3164 BSO/Tasking International 333 Elm Street, Dedham, MA 02026-4530 (800)458-8276 (617)320-9400 Fax: (617)320-9212 Europe Tasking Software BV P O Box 899, 3800 AW Amersfoort, Netherlands +31 33 558584 Fax: +31 33 550033 Business Data Computers P.O. Box 1549, Chester, CA 96020 Byte-BOS Integrated Systems P.O. Box 3067, Del Mar, CA 92014 (800)788-7288 (619)755-8836 ChipTools Inc (905)274-6244 Fax: (905)891-2715 Email: chiptool@hookup.net Circuit Cellar Inc. 4 Park St., Vernon, CT 06066 (203)875-2751 Fax: (203)872-2204 Creative Applications Engineering, Inc Ed Carryer (415)494-2363 BBS: (415)494-8463 Crossware Products 2 The Lawns, Melbourn, Royston, Herts SG8 6BA, UK +44 763 261539 Fax: +44 763 262983 BBS: +44 763 261716 Email: sales@crossware.com Custom Computer Consultants 1807 Huron River Drive, Ypsilanti, MI 48197 Cybernetic Micro Systems Box 3000, San Gregorio, CA 94074 (415)726-3000 Dallas Semiconductor 4401 S. Beltwood Parkway, Dallas, TX 75244-3292 (214)450-0448 Fax: (214)450-3715 International: (214)450-5351 Orders: (800)336-6933 Email: self@dalsemi.com (Kevin Self, appl. engineer) (great email address! right?) DataCraft International 2828 Ione Dr., San Jose, CA 95132 (800)873-3709 (408)259-4866 Data Sync Engineering POB 146, E. Stroudsburg, PA 18301 (717)421-1977 Dunfield Development Systems P.O. Box 31044, Nepean, Ontario Canada K2B 8S8 (613)256-5820 Fax: (613)256-5821 BBS: (613)256-6289 Email: ddunfield@bix.com EE Systems 50935 Hill Dr., Elkhart, IN 46514 (219)296-1754 Fax: (219)522-4271 Electronic Product Design, Inc. 6963 Bluebelle Way, Springfield, OR 97478 (503)741-0778 Embedded System Products (formerly A.T. Barrett and Associates) 11501 Chimney Rock, Houston, TX 77035-2900 (800)525-4302 (713)728-9688 Fax: (713)728-1049 Exor Inc. 4740T Interstate Dr., Cincinnati, OH 45246 (513)874-4665 Fax: (513)874-3684 Forth, Inc. 1-800-55FORTH Forth Systeme P.O. Box 1103, Breisach, Germany 7767-551 Franklin Software (408)296-8051 HBI Limited 6F, 1 Fleming Road, Hong Kong 852-891-3673 Fax: 852-834-9748 Hewlett-Packard 1501 Page Mill Rd., Palo Alto, CA 94304 HiTech Equipment Corp. 9400 Activity Rd., San Diego, CA 92126 (619)566-1892 Fax: (619)530-1458 Hi-Tech Software PO Box 103, Alderly QLD 4051, Australia (+61-7) 300 5011 Fax: (+61-7) 300 5246 Email: hitech@hitech.com.au Hitex (UK) Ltd Sir William Lyons Road, Science Park Coventry CV4 7EX +0203 692066 Fax: +0203 692131 Huntsville Microsystems 4040 S. Memorial Parkway, PO Box 12415 Huntsville, AL 35802 IAR Systems Software North America One Maritime Plaza, Suite 1770 San Fransisco, CA 94111 USA (415)765-5500 Fax: (415)765-5503 Sweden IAR Systems AB Box 23051 S-750 23 Uppsala, Sweden +46 18 16 7800 Fax: +46 18 16 7838 Germany IAR Systems GmbH Brucknerstrasse 27 D-81677 Munchen, Germany +49 89 470 6022 Fax: +49 89 470 9565 United Kingdom IAR Systems Ltd 9 Spice Court Plantation Wharf, York Rd London SWII 3UE, England +44 71 924 3334 Fax: +44 71 924 5341 Intel Corporation 3065 Bowers Ave., Santa Clara, CA 95051 Technical Help: (800)628-8686 (USA/Canada only) 5 am to 5 pm PST Email: james_sampson@ccm.hf.intel.com Faxback support: (800)628-2283 (USA/Canada) touch tone phones only Will only FAX to USA/Canada locations English or Japanese support is available BBS: (916)356-3600 24 Hr. Auto config: 1200 thru 14.4K Baud Intellimap Engineering 1140 Morrison Dr., Suite 222 Ottawa Ontario Canada K2H 8S9 (613)829-3196 Fax: (613)820-1773 Intermetrics Microsystems Software, Inc. 733 Concord Ave., Cambridge, MA 02138 (617)661-0072 Fax: (617)868-2843 Iota Systems, Inc. 924 Incline Way, Suite N / POB 8987 Incline Village, NV 89452-8987 (702)831-6302 Fax: (702)831-4629 J & M Microtek, Inc. 83 Seaman Rd., W Orange, NJ 07052 (201)325-1892 Fax: (201)736-4567 JMI Software Systems, Inc. P.O. Box 481, 904 Sheble Lane, Spring House, PA 19477 (215)628-0840 Fax: (215)628-0353 Keil Elektronik GmbH Bretonischer Ring 15 D-85630 Grasbrunn b. Muenchen, Germany 089-465057 Fax: 089-468162 Kontron Electronics D-8057 Eching/Munich Oskar von Miller Str. 1, Germany (0 81 65) 77-0 Lear Com Company 2440 Kipling St. Suite 206, Lakewood, CO 80215 (303)232-2226 Fax: (303)232-8721 Logical Systems Corporation (Disassembler, Simulator) Micro Dialects, Inc. POB 30014, Cincinnati, OH 45230 (513)271-9100 Logisoft Box 61929, Sunnyvale CA 94086 (408)773-8465 Fax: (408)773-8466 L.S. Electronic Systems Design 2280 Camilla Rd., Mississauga, Ontario Canada L5A 2J8 (905)277-4893 Fax: (905)277-0047 Mandeno Granville Electronics, Ltd 128 Grange Rd., Auckland 3, Australia +64 9 6300 558 Fax: +64 9 6301 720 Matra Semiconductor 2840-100 San Tomas Expressway, Santa Clara, CA 95051 (408)986-9000 MetaLink Corporation North America 325 E. Elliot Road, Chandler, AZ 85255 (800)638-2423 (602)926-0797 Fax: (602)926-1198 Europe MetaLink Europe GmbH Westring 2, 8011<85614> Kirchseeon-Eglharting, Germany (08091)2046 Fax: (08091)2386 Micro Computer Control Corporation PO Box 275, 17 Model Ave., Hopewell, NJ 08525 (609)466-1751 Fax: (609)466-4116 BBS: (609)466-4117 Email: 73062.3336@compuserve.com Micro Future 40944 Cascado Place, Fremont, CA 94539 (510)657-0264 Fax: (510)657-5441 BBS: (510)657-5442 MicroMint 4 Park St., Vernon, CT 06066 (203)875-2751 Fax: (203)872-2204 Microtek International, Inc. North America Microtek International, Inc. 3300 N.W. 211th Terrace, Hillsboro, OR 97124 (503)645-7333 Fax: (503)629-8460 Europe Microtek Electronics Europe GmbH Starnberger Strasse 22, 82131 Gauting bei Munchen Germany +49(89)893139-30 Fax: +49(89)893139-50 MPE: MicroProcessor Engineering Ltd. 133 Hill Lane, Shirley, Southampton SO1 5AF U.K. +44 1703 631441 Fax: +44 1703 339691 Email: mpe@mpeltd.demon.co.uk sales@mpeltd.demon.co.uk 70730.3576@compuserve.com Nohau Corporation 51 E. Campbell Ave., Campbell, CA 95008 (408)866-1820 (408)378-2912 (24 hr. information center) Fax: (408)378-7869 Offete Enterprises, Inc. 1306 South B Street, San Mateo, CA 94402 (415) 574-8250 Okapi Systems (206)258-1163 Onset Computer Corporation 199 Main St., P.O. Bos 1030 North Falmouth, MA 02556-1030 (508)563-9000 Fax: (508)563-9477 Orion Instruments 180 Independence Drive, Menlo Park, CA 94025 (800)729-7700 Fax: (415)327-9881 Parallax, Inc. 6200 Desimone Lane, #69A, Citrus Heights, CA 95621 (916)721-8217 Philips Microcontroller Product Group 811 East Arques Ave. / POB 3409 Sunnvale, CA 94088-3409 Technical documentation: Sunnyvale, CA - (800)447-1500 Fax: (408)991-3773 Eindhoven, Netherlands - Fax: 31-40-724825 Technical questions: Sunnyvale, CA - (408)991-3518 Production Languages Corporation P.O. Box 109, Weatherford, TX 76086 (800)525-6289 (817)599-8365 Fax: (817)599-5098 Prologic Designs PO Box 19026, Baltimore, MD 21204 (410)661-5950 Fax: (410)661-5950 PseudoCorp 716 Thimble Shoals Blvd., Newport News, VA 23606 (804)873-1947 Fax: (804)873-2154 BBS: (804)873-4838 Quantasm Corporation 19672 Stevens Creek Blvd. Cupertino, CA 95014 (800)765-8086 (408)244-6826 Fax: (408)244-7268 Raven Computer Systems PO Box 12116, St. Paul, MN 55112 (612)636-0365 Rigel Corporation P.O. Box 90040, Gainesville, FL 32607 Scientific Engineering Labs 255 Beacon St., Suite 3D, Somerville, MA 02143 (617)625-0288 Siemens Components, Inc. Integrated Circuit Division, 10950 N. Tantau Ave. Cupertino, CA 95014 (800)777-4363 Fax: (708)296-4805 Signetics Corporation (see Philips Microcontroller Product Group) Signum Systems Mountain View, CA (415)903-2220 Thousand Oaks, CA (805)371-4608 Software Science 3570 Roundbottom Rd., Cincinnati, OH 45244 Sophia Systems NS Bldg. 2-4-1, Nishishinjuku, Shinuku-ku Tokyo 160, Japan 03-348-7000 Speech Technology Inc., Software Division 837 Front Street South, Issaquah, WA 98027 (206)392-8150 Standard Microsystems Corporation 80 Arkay Dr., Hauppage, NY 11788 (516)435-6000 Fax: (516)231-6004 Sun Equipment Corporation Lodestar Electronics Corp. 616 Hawick Rd., Raleigh, NC 27615 (800)870-1955 (919)881-2141 Fax: (919)870-5720 Suncoast Technologies PO Box 5835, Spring Hill, FL 34606 (904)596-7599 Sysoft SA 6926 Montagnola, Switzerland (091)543195 Systronix Inc. 555 S. 300 E., Salt Lake City, UT 84111 (801)534-1017 Fax: (801)534-1019 BBS: (801)487-2778 URDA, Inc. (800)338-0517 (412)683-8732 US Software 14215 N.W. Science Park Drive, Portland, OR 97229 (800)356-7097 (503)641-8446 Fax: (503)644-2413 Product information available by ftp - ftp.netcom.com : pub/ussw Universal Cross Assemblers Canada (506)849-8952 Fax: (506)847-0681 Vail Silicon Tools, Inc. Box 165, Pompano Beach FL 33069 (305)491-7443 Fax: (305)974-8531 Zax Corporation 2572 White Road, Irving, CA 92714 (800)421-0982 (714)474-1170 Zitek Corporation 1651 East Edinger Ave., Santa Ana, Ca 92705 (714)541-2931 5) 8051 DOCUMENTATION 5.1) Periodicals that cover the 8051 Various magazines and journals (journals seems to be THE popular name for magazines these days) provide articles from time to time on the 8051 family of microcontrollers: The Computer Applications Journal (Circuit Cellar Ink) - programming and construction articles - POB 7694, Riverton, NJ 08077-8784 - FAX: (203)872-2204 - Voice orders: (609)786-0409 - On-line orders (BBS): (203)871-1988 - Email orders: ken.davidson@circellar.com - $21.95, $31.95 surface Canada and Mexico, $49.95 air all other countries Computer Design - industry announcements and trends - One Technology Park Drive, P.O. Box 990, Westford, MA 01886 - (508)692-0700 The Computer Journal - programming and construction articles - PO Box 535, Lincoln 96648 Dr. Dobbs Journal - programming articles, concepts, and designs - 411 Borel Ave., San Mateo, CA 94402 - (415)358-9500 Electronic Engineering Times - industry announcements and trends - FREE to qualified engineers and managers involved in engineering decisions - Fulfillment Dept., PO Box 9055, Jericho, NY 11753-8955 - FAX: (516)733-6960 Electronics Now - construction articles - Box 55115, Boulder, CO 80321-5115 - $19.97 one year Elektor Electronics - programming and construction articles - World Wide Subscription Service Ltd Unit 4, Gibbs Reed Farm, Pashley Road Ticehurst TN5 7HE, England - 27 UK pounds or - Old Colony Sound Lab, P.O. Box 243, Peterborough, NH 03458 - Tel. (603)924-6371, 924-6526 - Fax: (603)924-9467 - $57 USA and Canada per year Embedded Systems Programming - programming and systems design articles - Miller Freeman Publications - 500 Howard St., San Francisco, CA 94105 - (415) 397-1881 Inquisitor Magazine - If you're the type that watched Gilligan's Island for its socio-political insights, then you'll love a new 'zine that just crossed my desk - Inquisitor Magazine. It's general philosophy seems to be ... well, it seems to be ... uh, yeah! Technical in nature, bizarre, tongue in cheek, eclectic, electric, did I mention bizarre(?), and lots of fun. Worth looking at if you like the out of the ordinary. The moving force behind this magazine is Daniel Drennan, who seems to have suffered from an overdose of radiation from his computer monitor ;-). - Planetarium Station, P.O.Box 132, New York, NY 10024-0132 - (212)595-8370 - Email: inquisitor@echonyc.com - $16 per year (4 issues) Microcomputer Journal (formerly Computer Craft) - programming and construction articles - 76 N. Broadway, Hicksville, NY 11801 - $29.70 one year Midnight Engineering - 1700 Washington Ave., Rocky Road, CO 81067 - (719)254-4553 MW Media - Product Directories - 8051 Product Directory (survey of various 8051 products) - Intel Development Tools Handbook (survey of commercial development tools for the 8051, 8096, and 80186 lines of Intel microprocessors) - This documents could very well be a "must" if you're into serious development using one of these chips. If you are "just" a hobbyist, see how the "other half" lives. - other guides on Intel development tools, Embedded Intel 386, Intel 486/Pentium, 8051 products, Hitachi microcontroller development tools, AMD FusionE86, AMD 29K; low power products, DSP, multimedia CD - FREE to qualified developers - MW Media - Fairmont Plaza, 50 W. San Fernando, #675, San Jose, CA 95113 - (408)288-4721 and (408)286-4200 - FAX: (408)288-4728 Nuts & Volts Magazine - A National Publication for the Buying and Selling of Electronic Equipment - 430 Princeland Court, Corona, CA 91719 - Mailed third class, USA only: $17.00 one year $31.00 two years - Mailed first class, one year only: $34.00-USA $35.00-Canada/Mexico - Foreign/Air Mail - $70.00; Foreign/Surface - $39.00 - (800)783-4624 - Email: 74262.3664@compuserve.com 5.2) Books on the 8051 5.2.1) List of books I don't have information on all of these, only that they exist. I would greatly appreciate it if someone could provide a short synopsis and the complete book name if you are familiar with any of these titles. The 8051 Family of Microcontrollers -Richard H. Barnett -Prentice-Hall, 1995 -ISBN 0-02-306281-9 8051 Interfacing and Applications - Applied Logic Engineering - 13008 93rd Place North, Maple Grove, MN 55369 - (612)494-3704 The 8051 Microcontroller - I. Scott MacKenzie - Macmillan Publishing Company, 1992 - includes schematics for a single-board computer, assembly-language source code for a monitor program, and interfaces to a keypad, LEDs, and loudspeaker. The 8051 Microcontroller - James W. Stewart - Regents/Prentice-Hall, 1993 - $27.50, 273 pages - includes many interfacing examples (switches, solenoids, relays, shaft encoders, displays, motors, and A/D converters) and a chapter on top-down design method The 8051 Microcontroller: Architecture, Programming and Applications - Kenneth J. Ayala - 241 pages, soft cover - 5.25" diskette with assembler and simulator - ISBN 0-314-77278-2, Dewey 004.165-dc20 - West Publishing Company - P.O. Box 64526, St. Paul, MN 55164 - (800)328-9352 - see review in next section Assembly Language Programming (for the MCS-51 family) - F. A. Lyn - L. S. Electronic Systems Design Basic-52 Programmer's Guide - Systronix, Inc. (they also sell a Basic compiler) Beginner's Guide - Suncoast Technologies C and the 8051 - Thomas W. Schultz - Prentice Hall - ISBN 0-13-753815-4 Data book / Handbook / Users' Guide - Advanced Micro Devices - Dallas (User's guide for the DS5000) - Intel - Philips - Siemens Embedded Controller Forth for the 8051 Family - Academic Press (I think) - William H. Payne - uses a Forth development system available on the Internet (see above in the Forth software section) Embedded Systems Programming in C and Assembler - John Forrest Brown - Van Nostrand Reinhold, 1994 - 304 pages, $49.95 - ISBN 0-442-01817-7 - covers Motorola and Intel processors - includes diskette with code from the book - book review in Dr. Dobb's Journal, November 1994, page 121 Experimenter's guide - Rigel Corporation Introduction to Microcontroller Design, Based on the 8051 family of Processors - Business Data Computers - P.O. Box 1549, Chester, CA 96020 The Microcontroller Idea Book - Jan Axelson (of Microcomputer Journal fame) - features the 8052-BASIC microcontroller - hands-on guide with complete plans (schematics, design theory, program listings, construction details, etc) - explains how to use sensors, relays, displays, clock/calendars, keypads, wireless links, and more - 1994, 273 pages, $31.95 + shipping - Lakeview Research, 2209 Winnebago St., Madison, WI 53704 (608)241-5824 Internet: 71163.3555@compuserve.com - contact the author at janaxel@aol.com 5.2.2) Book reviews Jan Axelson's review of her book: The Microcontroller Idea Book This is a hands-on guide that presents designs for use in data loggers, controllers, and other small-computer projects. It includes complete circuit schematics and parts lists, design theory, example program listings, construction and debugging tips, and vendor listings. Example circuits and programs are based on the 8052-BASIC microcontroller. The book is loosely based on a series of articles I wrote for ComputerCraft magazine (now The Microcomputer Journal). Chapter titles: microcontroller basics, inside the 8052- BASIC, powering up, saving programs, programming, inputs and outputs, switches and keypads, displays, using sensors to detect and measure, clocks and calendars, control circuits, wireless links, calling assembly-language routines, running BASIC-52 from external memory, related products Richard H. Barnett's summary of his book: The 8051 Family of Microcontrollers The book covers basic micros through complete projects using the 8051 family as examples. It is designed as a "lots of meat, very little filler" type of text, but is very well-suited for use as a handbook of project development using 8051 family parts. The book stresses examples, both hardware and software. The hardware examples are real working items including 3 complete projects in the last chapter. Software examples are presented in both C and assembly code. All of the program listings and other software examples were imported electronically to the text eliminating errors. For more info contact the author - barnettr@mace.cc.purdue.edu Richard Kendrick's review of the book: 8051 Interfacing and Applications from Applied Logic Engineering IN BRIEF An excellent collection of interfacing circuits and well commented source code in assembly. This is not a book for beginners as it assumes the user is very familiar with the architecture of the 8051 and its registers. A disk of assembly source code listings is included. CHAPTERS 1 - 8051 Interfacing and Applications 1.1 - Introduction 1.2 - Main System Core 1.3 - Simple Methods of User Input 1.4 - Interfacing a 16 digit keypad to the 8031 1.5 - Centronics Parallel Input Port 1.6 - Centronics Parallel Output Port 1.7 - Interfacing to the built-in Serial Port 1.8 - Interfacing to a Dual Channel UART 1.9 - Interfacing to an LCD 1.10 - Bank Selection of Memory - Appendix A: List of Vendors - Appendix B: Connection to an External Computer 0.1 RS-232 Serial Connection 0.2 Centronics Interface Cabling COMMENTS This spiral bound book is thin (74 pages) but manages to cover a lot of information. All of the sub-chapters have excellent code listings with full comments, partial schematic diagrams, and an occasional timing diagram. The chapter on using the serial port is based on the MAX232 chip becoming so popular. A table of timer reload values is provided to get standard baud rates but the book only mentions the required clock frequency of 11.0592 mHz in the first chapter. It also doesn't explain why a seemingly non-standard crystal frequency was chosen. The dual UART channel features the 2681 chip. The LCD chapter gives a small but adequate explaination of the Hitachi controller chip usage on LCD displays and a tiny fragment of data on display characteristics of LCDs. The bank selection of memory is useful showing code and schematic using five 62256 chips for 160K bytes of read/write memory. Richard Kendrick's review of the book: Microprocessor/Controller Design by Wayne P. Lichti of Business Data Computers A lame little book better bypassed. As an introductory text, Kenneth Ayala's book is the winner hands down. This book is a poor rehash of the same information in Intel's or AMD's data book. There is one code listing in the book and does little more than tell the reader that the 8051 family of processors exist. This book is 134 pages of wasted time. The schematics were printed on a dot matrix printer and poorly reproduced. Many of the sections are just a table or a paragraph with two or three sentences. Use Ayala's book, you'll learn a lot more useful information. John Little's review of the book: The 8051 Microcontroller: Architecture, Programming and Applications by Kenneth J. Ayala IN BRIEF A good book for those who are already moderately familiar with assembly language programming and wish to learn more about 8051 specifics. Has many example listings, all of which are very well documented in terms of comments and explanations in the text. NOT a book for absolute beginners OR hardware hackers looking for circuits and applications. CHAPTERS 1 - Microprocessors and Microcontrollers. 2 - The 8051 Architecture. 3 - Moving Data. 4 - Logical Operations. 5 - Arithmetic Operations. 6 - Jump and Call Opcodes. 7 - An 8051 Microcontroller Design. 8 - Applications. 9 - Serial Data Communication. A - 8051 Operational Code Mnemonics. B - How to Use the Assembler. C - how to Use the Simulator. D - The 8255 Programmable I/O Port. E - Control Registers. COMMENTS In his preface to the book, Mr Ayala states that that it is intended for "... a diverse audience. It is meant for use primarily by those who work in the area of electronic design and assembly language programming of small, dedicated computers". Later, he goes on to refer the reader to the manufacturer's data books for more information on hardware issues. This sets the tone for the whole book, which is very much software orientated. Anyone buying the book expecting to find reams of circuit diagrams and details on how to build their own 8051 driven, automated car assembly plant will be disappointed. In fact, most of the circuits and applications shown are very much conceptual, with generic, black-box outlines for most of the components. The single exception to this is a fairly complete system (8031, EPROM & RAM, jumper selectable memory sizes) in the chapter on microcontroller design. Even then, there's no I/O shown (the txd/rxd are unconnected). Having said that, Mr Ayala does do a fairly thorough job of working through the peculiarities of the 8051, with detailed coverage of memory organisation, bit/byte level operations, timers, interrupts and, at the end of the book, a complete chapter on 8051 communication modes. Each area has relevant assembly language listings, along with a detailed explanation of the workings of the code. Each section also has highlighted "comment" passages which point out common pitfalls and reinforce critical points. Each chapter ends with a summary of the important points covered and a series of ten to twenty pertinent problems for the reader to solve. For the most part, the answers to the problems can be found in the text. In later chapters though, the reader is asked to elaborate on various programming themes and to write assembly language programs of their own to perform various tasks. The problems range from the bland "Name twenty items which have a built in microcontroller" (Chapter 1), to the more esoteric "Compose a 40-value lookup table that will generate a sawtooth wave using a D/A converter" (Chapter 8). It should be noted that the book is not aimed at the complete novice. For instance, although assembly language listings are used throughout, it is not until Appendix B that the reader finds out what the assembler actually does and how the listings relate to machine code. Even then, the complete neophyte will be left with a rather empty feeling, as there are pages and pages of code, the schematic for a (more or less) complete system and instructions on how to use the assembler, but no information at all on how the object code should be utilised (other than with the included simulator - see below). If you don't already know how to blow an EPROM, you're in trouble. The diskette which accompanies the book contains the PseudoSam assembler (which is used throughout) and an 8051 simulator. Both being intended for use on a PC (it's a measure of how fast the computer industry is evolving that a 5.25 inch diskette seems a little archaic just three years after the publication date of the book). The PseudoSam assembler ran fine on my system and I was able to assemble several of the examples from the book and successfully run them on a small, home-brew 8031 system. I was totally unable to get the simulator to run. However, as it failed on several different systems I'm prepared to believe that my particular copy of the diskette was at fault. SUMMARY All in all, a recommended book for those who have previous assembly language experience and wish to get to know details relating to the 8051 microcontroller. While the internal architecture of the chip is covered in detail, external hardware and peripheral interfacing is not. Only the basic 8051/31 is covered, with little mention of the other variants available. There are extensive listings in the text, covering routines for handling keyboards and displays, as well as timing loops and communications. A large, clear typeface ensures that all of the listings are completely legible. The layout and presentation of the book is excellent, with a consistent, unambiguous style used throughout. Tim McDonough's review of the book: C and the 8051: Programming for Multitasking by Thomas W. Schultz Schultz's book provides a brief overview of the 8051 architecture but is primarily a discussion of multi-tasking software in an 8051 environment. He presents quite a few code examples. The examples and the accompanying text show comparisons of how to accomplish things in assembler, PLM, and C. The C examples presented are based on Version 3 of the Franklin compiler but should be easily understandable by anyone already familiar with C. Later chapters in the book deal with more advanced topics. Chapters are devoted to Real-Time Ideas, Timing and Scheduling, Communications and Synchronization, Interrupts, Priority, and Context, and Distributed Systems. The Real-Time Ideas chapter briefly discusses six Real Time Operating System (RTOS) kernels offered by several vendors. Later in the book some examples are given to simple applications with and without using a RTOS. All in all, a useful addition to my technical library. It is one of the few 8051 books that goes beyond the basics and would be particularly of interest to those contemplating their first non-trivial 8051 design. 5.3) Miscellaneous documentation on the 8051 Advanced Micro Devices - application notes Intel Corporation - application notes L.S. Electronic Systems Design - application notes (source code on diskette and schematics) Philips Semiconductors (Signetics) - application notes Software Science - application notes __________________________________________________________ I disclaim everything. The contents of this article might be totally inaccurate, inappropriate, misguided, or otherwise perverse - except for my name (hopefully I got that right). Copyright (c) 1995 by Russell Hersch, all rights reserved. This FAQ may be posted to any USENET newsgroup, on-line service, or BBS as long as it is posted in its entirety and includes this copyright statement. This FAQ may not be distributed for financial gain. This FAQ may not be included in commercial collections or compilations without express permission from the author. ----------------------------------- Russ Hersch - sibit@datasrv.co.il From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 30 Mar 1995 22:35:39 GMT In-reply-to: gml@ag.pu.ru's message of 23 Mar 1995 12:20:01 GMT >>>>> "Michael" == gml writes: Michael> A compromise (rough idea): Michael> You may make the calls of Forth words THAT USE LOCALS Michael> compatible with the C stack frames. Michael> You will need 3 pointers: SP, RP and FP (candidates: ESP Michael> ESI EDI EBP). To call a C function, you will have to Michael> create a local frame and call the C code. You will not Michael> need to create a frame for +es, *s, etc. Michael> Forth data stack will be separated from the C stack. Michael> Or you may have, say, 2 call methods (2 code fields) - Michael> for a Forth call and for a C call. Michael> If you want a C function to call your Forth code, you Michael> will have to either: Michael> - introduce everywhere 2 call methods and use the C call Michael> method Michael> - declare your : definition as external and build a Michael> C->Forth caller for this word. "Non-exportable" error if Michael> the definition cannot be called from C. Michael> E.g. Michael> : CallMeFromC { a b c -- d } ; \ code built: Michael> (LOCAL{) [number-of-locals] ... addr: ; Michael> EXPORT CallMeFromC { int int int } int \ build a C Michael> function that calls the code at addr (see above) with the Michael> C frame. Michael> Probably, I've missed something and you will have to Michael> think more to bring the ends together. Michael> --- Michael L. Gassanenko, gml@agspbu.spb.su or Michael> gml@ag.pu.ru A parable. One man heard that Practice is Michael> the best way to enlightement, and that all our life is Michael> Practice, but he didn't know what is NOT-Practice. He Michael> tried meditation, etc. and Buddha jeered at him. Yes, I think you have missed something. I wouldn't attempt a C interface for Forth without including C++ in the bargian, at least not nowdays. In C++, yoou have CATCH and THROW, which greatly expands the old C setjump/longjunp routines. Furthermore, CATCH and THROW are part of the ANSI Forth standard now. Any attempt to interface between teh 2 languages will need to address the issue of called foriegn language routine raising exceptions that must pass through routines of the other language and ultimately be caught by exception handlers in either of the languages. This is a nasty problem. I ran into it with exceptions in a mixed system using Ada and C++, but the multi-language exceptions handling problem is basically the same when Forth is one of the languages. It is *NOT* an easy problem... :( -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Single-stack forth Date: 30 Mar 1995 22:50:46 GMT <3kqvn1$ntt@srvr1.engin.umich.edu> In-reply-to: Hasdi R Hashim's message of 23 Mar 1995 05:07:45 GMT >>>>> "Hasdi" == Hasdi R Hashim writes: >> As far as locals, I and J are already in the return stack. To >> the extent that scoping implies that locals are synchronous >> with call Hasdi> and >> return, I like adding locals to the return stack, but some >> people that like to play fun R> tricks would complain. Maybe >> that's for a language extension built on top of FORTH rather >> than FORTH itself? (like types, Hasdi> IMHO). When I wrote my locals package for LMI-386-UR/Forth, I deliberately designed it so that R>, >R, etc. would still be useful, but not to the extent of messing with stuff that the current word did not put on the return stack. This is required by the ASN Forth standard now anyway. I keep a frame pointer, FP, as a global, but in a multi-tasking situation, it would have to be a USER variable so that it got saved and restored across context switches. All locxal variables, be they parameters input from the calling word, values returned to the calling word, or temporaries private to the called word, are kept in the stack frame. The frame pointer gets pushed onto the Rstack as the first element of a stack frame. The address of a clean-up routine get pushed after the stack frame, so that when the word exits, the clean-up routine is called. This routine copies the returned values from the Rstack to the Pstack and then pops the entire stack frame off the Rstack, restoring the saved FP in the process. Then , when the clean-up routine exits, it actually returns via the return address the the original word was called with. All locals are accessed as quans, not variables. This was necessary so that names could be resolved at compile time and proper code generated to access the entries in the stack frame as efficiently as possible. I will be glad to post the source code here, just as soon as I get my Linux system talking via uucp with email and usenet news. I used to use Interactive Unix, but "upgraded" to Linux for a number of reasons. The upgrade is just not yet complete, and probably will not be until after 4/15/95 -- tax day. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: jfox@netcom.com (Jeff Fox) Subject: Re: corrections, was Two Chucks Date: Fri, 31 Mar 1995 05:01:18 GMT Before I get any more email from people who were confused or concerned by the mis-information recently posted by Ran Talbot about MuP21 I would like to make a few corrections and comments here. 1. There is not a "requirement" that P21 use and external 20 bit memory, this is an option. It can boot and run from 8 bit memory at speeds up to 25mips. But it cannot generate video from 8 bit memory. 2. MuP21 is a microprocessor, not a microcontroller, and as most people realize most microprocessors don't include on chip timers or serial ports. Most also do not include on chip video coprocessors, but this is available on P21 at the cost of a couple of pins. 3. P21 development costs were kept low by using the "tiny" option at Orbit which limited the chip to 40 pins. The requirement was to provide the platform for a vlsi cad workstation. (a non-trivial application) Adding a single pin for any purpose such as an external interrupt to P21 would have meant going to the next level costing four times as much to prototype. $120,000 is a lot to pay for one pin when one is funding development out of pocket. Most people realize that adding an external interrupt is trivial compared to designing a vlsi cad system and complete chip from scratch. The next chip will have three types of interrupts. External interrupts, interrupts from the analog i/o processors, and remote cpu interrupts from the network coprocessor. 4. As a "proof-of-concept" chip MuP21 did demonstate several things: Chuck's vlsi cad tools work and can be used to design working chips. Chuck's approach does make it possible to make 100+ megahertz cpu chips that require fewer transistor than the 4004. Chuck's approach makes it possible to make a complete cpu that will at three to four times the industry accepted speed of a flipflop for a given manufacturing process. Chuck's approach does make it possible to make 100+ megahertz chips with integrated cpu and on chip coprocessors that are hundreds of times smaller and cheaper to manufacture than conventional designs. 5. Mr. Talbot has stated in comp.lang.forth that he immediately dismissed MuP21 and any future work by Chuck because he saw that I had posted information about it. (for his own personal reasons) Mr. Talbot does not have a P21 development system in front of him, and should not be considered an authority on what it can or can't do for both of these reasons. 6. Mr. Talbot likes to tell other people what they can't do. He has told people in other newsgroups that they can't program interrupts in Forth, that they can't compile their source to machine code in Forth, etc. But Mr. Talbot does not like to be corrected and as result.... 7. Mr. Talbot has resorted to such personal attacks on me in other newsgroups as labeling me a "cultist", "liar", "forth nut", or to resorting to comments about personal hygiene. Perhaps some people remember his post in c.l.f saying "If there is anyone in this newsgroup over thirty they should tell Jeff about Crest." I appologize to readers of c.l.f for cross posting one of my replys to one of Mr. Talbot's in c.l.f last year and apparently inviting him here to expand his smear campaign to include Chuck. I would like to warn readers to remember that Mr. Talbot has some sort of personal axe to grind with me, that has apparently spilled over to P21, Chuck, and others. Sorry about that. Jeff Fox From: jfox@netcom.com (Jeff Fox) Subject: comp.arch.embedded Date: Fri, 31 Mar 1995 05:18:51 GMT I have followed the new newsgroup comp.arch.embedded for a while now. It is now up to 214 messages, and the word Forth has not yet appeared. The biggest subject so far has been "Does anyone remember PL/M?" and the rest of the traffic has been evenly split between people talking about embedded processors, and people talking about using old PC motherboards for embedded processors. I had some hope that it might be more interesting or useful. Today there was a request for a quick survey of embedded applications, that will be compiled and posted to this group. It might be of some service to others to send a short email message to Mr. Tench if you have ever done any embedded applications in Forth. :-) So far Forth has had 0% of the traffic in this group, and it would be a chance to get some positive publicity about the success of Forth in embedded applications. I realize that some people have such vast experience that it may be difficult to sumarize. This is a copy of Mr. Tench's post. From ix.netcom.com!howland.reston.ans.net!pipex!warwick!news.wlv.ac.uk!not-for-mail Thu Mar 30 18:22:44 PST 1995 Article: 214 of comp.arch.embedded netcom.com!ix.netcom.com!howland.reston.ans.net!pipex!warwick!news.wlv.ac.uk !not-for-mail From: cm5585@scitsc.wlv.ac.uk (J.Tench) Subject: Quick survey Date: 29 Mar 1995 17:00:10 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi I'd be interested to know what kind of software approaches the real world is using at the mo, in embedded systems. Along the lines of Task being preformed (in one sentence) CPU being used Language programmed in Program method, ie, real time, state machine, small one off etc... If replies are directed to me I'll post the results. Thanks Jim T -- ~)~. ~)~ _ _ |_ || || ||\ || || || \\ // (_/ / /') / (' / ) (_ | ) || || ||\\|| || || )X( Wolverhampton Polyversity ||__| || || \|| \\_// // \\ E_MAIL cm5585@scitsc.wlv.ac.uk UNIX++ From: jwoehr@nyx.cs.du.edu (jack woehr) Subject: Re: 68020 Assembler? Date: 31 Mar 1995 00:09:24 -0700 s1476@rfhs0002.fh.uni-regensburg.de (Dieter Meidenbauer) writes: >Hi folks, > does anybody knows about sources for an free available > 68020 Forth-Assembler (preferably post-fix) ? > Dieter. There are several Forths for the 680x0's up on ftp sites and on small BBSes, such as mine, number in .signature below. =jax= -- / Jack Woehr ; Thunder resounds from the earth: / jax@well.com ; The image of ENTHUSIASM. / jwoehr@nyx.cs.du.edu ; Thus the ancient kings made music / SYSOP RCFB (303) 278-0364 ; In order to honor merit (Yi Qing) From: aph@atml.co.uk (Andrew Haley) In-reply-to: <3kf26j$5m@news.tuwien.ac.at> (anton@mips.complang.tuwien.ac.at) Subject: Re: Arith Shift X-Posting-Host: gatekeeper.atml.co.uk Date: Fri, 31 Mar 1995 11:25:51 +0000 > From: anton@mips.complang.tuwien.ac.at (Anton Ertl) > Date: 18 Mar 1995 16:36:35 GMT > In article <3kafi4$3om@godzilla.zeta.org.au>, mikeh@zeta.org.au (Michael Hore) writes: > |> On all current hardware that I know anything about (using > |> 2's complement integer arithmetic), dividing by 2 is the same > |> as a 1 bit right shift. > > All hardware that implements signed division that I know of, > implements symmetric division. Symmetric division by 2 is not the same > as an arithmetic shift right, for negative numbers. [ ... ] > Right, this was discussed a few weeks ago in comp.compilers in a > thread on optimization. C does not specify division, but most > compilers implement symmetric division (because often the hardware > does and it's also easier in software). ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think that this is false. I've heard this said many times, but all that has to be done to perform a floored division [*] is to add the divisor into the high part of the dividend if the dividend is negative. As in: : M/ ( d n - n) OVER 0< IF DUP >R + R> THEN UM/ ; Or (in ARM assembler; dividend in r1&r2, divisor in r0) cmp r1, #0 addlt r1, r0 This is usually faster than doing a negation, remembering the fact that one has been done, and later on doing another negation. The above is just two instructions longer than unsigned division, with no pipeline breaks. Andrew. [*] The case is slightly more complicated if the divisor is negative, in which case both operands need to be negated before entering this routine. However, the negative divisor case is rare, as many divisors are positive constants. From: aph@atml.co.uk (Andrew Haley) In-reply-to: (buck@satyr.sylvan.com) Subject: Re: Two Chucks X-Posting-Host: gatekeeper.atml.co.uk Date: Fri, 31 Mar 1995 11:46:01 +0000 > Newsgroups: comp.lang.forth > From: buck@satyr.sylvan.com (Michael Butler) > > Christophe, what do you think of the AT&T Hobbit (CRISP) architecture? > The intent seems somewhat parallel to what you describe. For those not > familiar with the Hobbit, the basic observations that led to its design > were (based on profiling & measurement, but probably originally by "gut > feel"): > > 1) it's mostly the case that what you want to get at is on or near the > top of stack (AT&T's focus was C function calls, but it's true of FORTH > as well). > > 2) Complexity decreases reliability and/or increases expense. Standard > RISC-plus-cache architectures increase complexity: > a) Compilers that can optimize the use of tons of registers tend to be > harder to develop and validate. In the worst (and depressingly real- > world) case, the compiler complexity is such that the compiler never > *is* validated. If you're not using all the registers, why have them? > b) High-speed associative caches are also expensive and can be tricky to > integrate. > > 3) An architecture that dynamically fills its "registers" with the top n > elements of the stack ought to lead to a cheaper, higher performance product > with a less-complex, easier-to-validate compiler being required. > > (This is my recollection off the top of my head of the arguments of the > CRISP/Hobbit proponents). As one of the fairly small nuber of people in the world who has programmed the Hobbit in assembly language I suppose that I'm qualified to comment here. The Hobbit stack architecture is designed to solve what is primarily a language problem in C. This problem is caused by the fact that many C "functions" use call by reference to return parameters. This causes lots of accesses to memory. If C had a more sensible parameter passing mechanism this wouldn't be necessary, and multiple values could be returned in registers. Hobbit solves this problem by making its internal register bank addressible. Therefore, there is no "register variable" allocation problem, and the "stack cache" is easy to design because there's no tag file, just a top and bottom pointer. The business of making the stack addressible as ordinary memory, however, is a language specific design decision and wouldn't help many other languages. Andrew. From: hs@4thware.winnet.de (Hanno Schwalm) Subject: Re: Interfacing stack-framed languages Reply-To: hs@4thware.winnet.de Date: Fri, 31 Mar 1995 09:24:28 GMT In article <3l8vfl$fu9@hq.pu.ru>, gml@ag.pu.ru (you) wrote: > I think we could have a wordset for interfacing stack-framed languages, > such as C and Pascal. There is a thing called "interface compiler" in the Forthmacs world. It knows about string-conversion, dummy parameters, constant-parameters, producing flags ... Its syntax looks like new_word { par1 "string1 "string2 2 -- ?flag) > 2) The mainstream language implementation > but I hope we could invent a _syntax_ that will work with all the maintream > languages (since they are almost the same). Remember that some languages/computers don't use stacks but registers for parameters instead. -- Hanno Schwalm hs@4thware.winnet.de Forthmacs support support@4thware.winnet.de From: Mayes@d-m-g.demon.co.uk (Mayes uk) Subject: Re: Single-stack forth Reply-To: Mayes@d-m-g.demon.co.uk X-Posting-Host: d-m-g.demon.co.uk Date: Fri, 31 Mar 1995 09:12:54 +0000 In article brownrj@cig.mot.com "Robert J Brown" writes: > In article <3kg81q$pks@srvr1.engin.umich.edu> > hasdi@umich.edu "Hasdi R Hashim" writes: > > >> So there are two new features here, a single all-purpose stack > >> and type-checking. I think this can be done, assuming that > >> Forth programmers have a good habit of always returning only > >> one type of information (e.g. integer, float or char) upon > >> completion of a function. > > Keith> Good Habit?? Why?? Return what you want to, when you need > Keith> to, as best suits you. It's only sand. > > Keith> -- Keith Wootten > > With a dynamic typing system, you can do this, but you can also look > at something a determine what its type is, even though it can be > different at different times. Yes, you can choose to ignore type checking if you wish, but I would question it's inherent value in a Forth system. The Forth programmer's first duty is to his/her stacks, and awareness of their contents is essential. Type checking *could* alert the programmer to errors here, but maybe this would erode some of the necessary thinking and scribbling. As all here know, thinking stacks is hard at first but soon becomes second nature; it seems to me that type checking could slow down this learning process as well as being 'something else to go wrong'. I should point out that all my Forth experience is with embedded real-time applications and I know very little of other Forth implementations. There may well be instances where type checking in Forth is a genuinely useful tool ...? Keith Wootten -- Mayes uk From: Mayes@d-m-g.demon.co.uk (Mayes uk) Subject: Re: one FP stack example ( was Re: FIG Directors ) Reply-To: Mayes@d-m-g.demon.co.uk X-Posting-Host: d-m-g.demon.co.uk Date: Fri, 31 Mar 1995 12:21:49 +0000 In article <3l8vfj$fu7@hq.pu.ru> gml@ag.pu.ru writes: > > Software stack words other than the obvious Push Pop Sdepth, include > > useful things like Shove (slips a cell in underneath the bottom of > > the stack), Snoop (copies the bottom of the stack to Top) and Pull > > (pulls a cell from the bottom of the stack). > > Could you, please, write the stack comments for them? > > --- > Michael L. Gassanenko Surely .. User stacks are circular buffers with the following format: Top_Ptr c, Size c, Bottom_Ptr c, 0 c, data , ... data , Create ... Does could be used here. For small data structures I find that explicitly allocating memory is easier to re-visit after some time away. Data stack diagrams follow. There are *no* stack diagrams for the user stacks; I tried to think of a good way to do this and came to the conclusion that a simple text comment was adequate. After all, these are only simple data structures, there is very little user stack manipulation, and you wouldn't comment I/O to an array? addr is the address (name) of the appropriate stack. TOP refers to the top of the data stack. \ copy top of user stack to TOP : |COPY| \ addr -- n ; \ push TOP to user stack : |PUSH| \ n addr -- ; \ pop user stack to TOP : |POP| \ addr -- n ; \ copy nth deep cell from user stack to TOP : |PICK| \ n addr -- n2 \ 'lose' n cells from user stack : |NDROP| \ n addr -- ; \ obvious : |DUP| \ addr -- ; \ push TOP under bottom of user stack : |SHOVE| \ n addr -- ; \ copy cell from bottom of user stack to TOP : |SNOOP| \ addr -- n ; \ pull cell from bottom of user stack to TOP : |PULL| \ addr -- n ; \ return user stack depth : |DEPTH| \ addr -- n ; \ stack structures Create SEQ_STACK 0 c, $10 c, 0 c, 0 c, $20 allot Create TEMP_STACK 0 c, 4 c, 0 c, 0 c, $08 allot \ etc .... \ some example words ... : >TEMP Temp_Stack |push| ; : TEMP> temp_stack |pop| ; : TEMP@ temp_stack |copy| ; \ etc .... These are very simple structures, but I would be lost without them. They're particularly useful for: Passing data from time critical routine to background. In this case they are generally used as queues. Keeping a track of I/O routing, menu paths etc and temporary storage between different stages of state machines. In this case they are generally used as stacks. Keith Wootten. -- Mayes uk From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Return stack shenanigans Date: 31 Mar 1995 17:32:10 GMT In-reply-to: ehp@ear.co.at's message of Tue, 21 Mar 1995 20:29:16 JEThomas@ix.netcom.com (Jonah Thomas) wrote: JT> : A 10 0 DO JT> I GET-ITEM B? IF JT> C? IF JT> PROCESS-ITEM ELSE JT> DISCARD-ITEM JT> THEN ELSE JT> DISCARD-ITEM JT> THEN JT> LOOP ; [... variations and ideas about return stack handling left out] Why not like the following? : DO-ITEM ( n --) GET-ITEM B? IF C? IF PROCESS-ITEM EXIT THEN THEN DISCARD-ITEM ; : A ( --) 10 0 DO I DO-ITEM LOOP ; If you wanted to insert 'D?', so it would be one more line in 'DO-ITEM'. In factorizing, I put a level for its own between the 'running loop' and single instances. But I see this now, after I wrote the above. But what I did, was, putting it graphically, to have a look: | ----> | | | | = = = = = = = = = = = | | | ( n) get-it | | | < B? >------->-- | | | | < C? >------->-- | | | | do-it discard-it | | | | = = = = = = = = = = = | | | | | --<--------- | | -<-- | Just for an idea... Ewald What you have done is more properly implemented under the ANS standard with CATCH and THROW. In ANS Forth, you cannot rely on the Return stack to hold the return addresses :( -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: Interfacing stack-framed languages Date: 31 Mar 1995 17:39:34 GMT In-reply-to: brownrj@cig.mot.com's message of 30 Mar 1995 20:10:09 GMT >>>>> "Robert" == Robert J Brown writes: Robert> Several years ago I wrote a local variable extension to Robert> Forth that places the stack frame on the return stack, not Robert> on the parameter stack. [ Following up to my own post... ] I had written another attempt at local variables around 1987-88, but this one passed structures on the parameter stack. The fields in the structures could be reffered to symbolically as long as the structure was on the top of the stack. It really wasn't a local variable system, but rather more like passing a struct by value instead of by name in C (copying instead of pointing to it). This package is called SHEETS, and is also available on the LMI Forth board. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: sstack Forth Date: 31 Mar 1995 17:56:04 GMT In-reply-to: skip@taygeta.oc.nps.navy.mil's message of Fri, 24 Mar 1995 20:46:28 GMT >>>>> "Skip" == Skip Carter writes: Skip> In article , Skip> Bruce McFarling writes: |> I just want to Skip> mention that for someone like me with a small |> collection Skip> of C code that I have written myself for my personal use, I Skip> |> *really* want to be able to drop into FORTH from C, so Skip> that any polishing |> I do of a user interface in FORTH can Skip> be added to my prior C code, as well Skip> If by this you mean that you want a FORTH interpreter Skip> running inside a C program, try Norm Smith's UNTIL. I use Skip> it frequently as the "scripting language" within my Skip> interactive C/C++ programs. Skip> You can get UNTIL from my WWW page or via anonymous Skip> ftp to taygeta.oc.nps.navy.mil (in pub/Forth/Reviewed). Skip> -- Everett (Skip) Carter Phone: 408-656-3318 FAX: Skip> 408-656-2712 Naval Postgraduate School INTERNET: Skip> skip@taygeta.oc.nps.navy.mil Dept. of Oceanography, Code Skip> OC/CR UUCP: ...!uunet!taygeta!skip Monterey, CA. 93943 WWW: Skip> http://taygeta.oc.nps.navy.mil/skips_home.html You may also wish to look at TILE -- Threaded Interpretive Language Environment. It is written in C and aimed at Unix environments, although I ported it to a stand-alone 68040 multi-cpu VME bus system in less than a single morning. It is not terribly fast, but it is terribly portable. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: Bruce McFarling Subject: Re: Interfacing stack-framed languages Date: Fri, 31 Mar 1995 13:25:43 -0500 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: On 30 Mar 1995, Robert J Brown wrote: > >>>>> "Bruce" == Bruce McFarling writes: > [some stuff that I wrote, omitted because too many '>>>>>>>'s snag in my phone lines 8-># ] [Robert J Brown, now] > Several years ago I wrote a local variable extension to Forth that > places the stack frame on the return stack, not on the parameter > stack. This package is available on the LMI Forth board, and is > licensed under the terms of the GLP. It was not really designed to > interface to other languages, but rather to provide lexically scoped > local variables in Forth. The syntax is like this: > > : FOO | arg1 arg2 arg3 ... -- result1 result2 ... & temp1 temp2 ... | blah blah ; > > It uses vertical bars instead of parentheses to delimit the stack > effect, and the stack effect is no longer a comment, but generates > code to create, manage, and remove the stack frame and its local > variables. > OK, its starting to come into focus. Now I hide the 'return' stack away out of sight, claim that the 'R' in all of those R-words stands for 'Repetition Stack', and implement a byte stack/queue for the bytestream pipe, and I might be heading in the direction I want to go. Thank bunches, Tah, Bruce McFarling, Knoxville brmcf@utkux1.utk.edu From: s1476@rfhs0002.fh.uni-regensburg.de (Dieter Meidenbauer) Subject: 68020 Assembler? Date: 31 Mar 1995 19:38:59 GMT Reply-To: dieter.meidenbauer@rz.fh-regensburg.d400.de Hi folks, does anybody knows about an free available 68020 Forth-Assembler? Please don't suggest me Michael Perry's one -- i need a real 020, with ext. addr-modes etc. Dieter. From: forthrl@aol.com (ForthRL) Subject: Re: Need Opinions Date: 31 Mar 1995 12:26:38 -0500 Reply-To: forthrl@aol.com (ForthRL) Brief commercial msg in response to: > From Robert J. Brown >I used the LMI metacompiler for the 68HC11 and found it excellent. I >also used the ROM simulator they sell that is designed by Klaus Flesch >in Germany. FORTH Inc. ( thats us) has an interactive cross compiler called chipFORTH. > I found it a much more productive way to work than send >source files and compiling on the slow 68HC11. With the metacompiler, >ou are commpiling on the PC and targeting to the 68HC11. Because the >metacompiler has the sources for a complete Forth system with it, you >do not loose the feature of debugging on the target with a full Forth >interpreter, In the interactive mode FORTH Inc.'s 68HC11 chipFORTH system downloads the compiled version of each word to the tagets RAM as it is compiled. This means you can build a word and test it immediately, as we all like to. > but if you do not ship your product with a functioning >Forth outer interpreter, then there is no licsence fee. I save a >client company thousands of dollars is license fees this way, The chipFORTH target has no interpreter, so there is never a royalty for the target system. >as well >as many thousands more in increased productivity siomply because the >recompile time was so greatly reduced: 30 minutes to 3 minutes! While chipFORTH compiles very fast ( we use a 386 or later) sometime you don't even have to recompile. chipFORTH saves the compiled code on the PC, so if you crash the target, the whole application can be downloaded from the PC without recompiling! It only takes seconds. All heads reside on the PC, so the target code is small. P.S. No ROM emulator is needed. Its all done though a serial port. We do need a serial port available for this. Also, FORTH Inc. supplies the source for the nucleus, so can recompile with changes, or leave out unneed portions. Gee, this wasn't as brief as I thought it would be... ForthRL@aol.com (Randy Leberknight) From: jfox@netcom.com (Jeff Fox) Subject: Re: Forth meeting at UMd Date: Fri, 31 Mar 1995 20:52:02 GMT In article <3lepbs$k2q@ixnews3.ix.netcom.com> JEThomas@ix.netcom.com (Jonah Thomas) writes: >Wednesday, March 29, MFIG staged another Forth talk, this time at >University of Maryland for their student IEEE chapter. > > \ snip \ >Afterward we ate pizza and talked. "I don't understand why I've never >heard of this before. I'm a senior." "Is Forth anything like >P-SPICE?" "I'm not starting any groups, come May and I'm out of >here." "There's a new chess program that plays at GrandMaster level, >but it can't beat the best human beings yet. They're talking about >building one that has a different processor for every square." FYI: Earlier today at the 12th Maryland Theory Day a man machine chess match was staged between Grandmaster Gennady Sagalchik (rated 2568) and an 1800 node Intel Paragon running *Socrates. Machine won in 56 moves. Socrates is a very clever chess program with some human like strategy design, and *Socrates is a parallel port of this commercial chess program. The Intel Paragon used has 1800 i860s and made Grandmaster Sagalchik eat his words that it was very unlikely that a machine could beat a grandmaster this year. *Socrates running on this machine can evaluate 2 million moves per second. For more info get the whole story at http://www.cs.umbc.edu/conferences/mtd95/mm_match/ Jeff Fox From: fs07675@nyssa.swt.edu (Frank Sergeant) Subject: Re: 68020 Assembler? Date: 31 Mar 95 23:08:27 CST In article <3lhlojINNcoi@rrzs3.uni-regensburg.de>, s1476@rfhs0002.fh.uni-regensburg.de (Dieter Meidenbauer) writes: > does anybody knows about an free available 68020 Forth-Assembler? > Please don't suggest me Michael Perry's one I already did suggest Michael Perry's assembler. > -- i need a real 020, with ext. addr-modes etc. At least Mike's would be a hell of a good start. What wouldn't it do that you need it to do? -- Frank Frank Sergeant fs07675@swt.edu f.sergeant@GEnie.geis.com From: jfox@netcom.com (Jeff Fox) Subject: Re: corrections, was Two Chucks Date: Sat, 1 Apr 1995 05:19:14 GMT > Chuck's approach does make it possible to make 100+ megahertz cpu chips > that require fewer transistor than the 4004. I have been told that I may have confused the transistor count on 4004 with that on 8008. I will check into it. My point was that multiple execution units, 12 stage pipelines, branch prediction, and large multimegatransistor on chip caches are not the only path to 100+ mip operation. I believe that by 8008 things were already up to three times the transistor count on MuP21. Jeff Fox From: mckewan@netcom.com (Andrew McKewan) Subject: Re: Forth to C Compiler/Preprocessor Date: Sat, 1 Apr 1995 06:28:33 GMT Andreas P. Herren (herren@alcatel.ch) wrote: : I am looking for a Forth to C compiler or preprocessor. Does anybody know : anything about such a compiler. Are there such compilers in the public domain? Look for the TIMBRE compiler by Rob Chapman. It translates Forth code into C. Andrew. -- Andrew mckewan@netcom.com From: snf_dw@debet.nhh.no Subject: Re: Forth meeting at CUA (a bit long) Date: 1 Apr 95 10:49:09 MET In article <3l607b$s63@ixnews4.ix.netcom.com>, JEThomas@ix.netcom.com (Jonah Thomas) writes: > > For me it was worse. I regarded marketing as pernicious. I chased > after technical excellence, and figured that the best technical > solution was the one that _ought_ to prevail. Marketing appeared to > be a grab-bag of techniques to influence buying decisions independent > of technical excellence. That is, it was a system for injecting > noise into the feedback. I disapproved. > That is sales, not marketing (cf. my next-to-last posting, Intel thread). Marketing is based on enhancing and using the feedback. Sales gets in the way, as you very neatly describe, because it often involves deception. But if sales is preceded by good marketing, it does not need to be deceptive, because the product is right for the customer. > It looked like salesmen typically didn't know what they were talking > about, technically, but they'd try to make technical claims anyway. Well, often the customer is no better, and they do have to communicate with the customer. > They acted fake friendly. It is not a crime to be an extravert, but equally you don't have to like the way they behave. > And after any setback -- a technical claim > disproved, a lie exposed, etc -- they'd change the subject and keep > going. They didn't seem respectable. They aren't, by and large. But the very best ones are, and they only sell worthwhile products. That is, they can pick and choose what they sell, and of course they choose to sell good products (unless they are basically swindler types, e.g. time-sharing apartment selling). > Now I find myself wanting to > persuade people, and the first thing I need is a sympathetic hearing. > If I get them wanting me to be wrong, they'll look for flaws and > they'll be disappointed if they don't find any. I mostly know what > I'm talking about, but I won't understand their particular contexts > until they tell me. And I have to be careful not to make claims > they'll think are impossible. Unless you can demonstrate their truth, with apparatus that is concretely visible in from of them. That is effective. Claims are not, because you are doing a sales job and salesmen often lie. > They come to Forth meetings and complain about it. In general I > don't know what people will disbelieve. It's hard. > They will disbelieve what you cannot demonstrate to them in the space of about 10 minutes, at their own business site, if it is out of line with what the competition offers. Forth lends itself well to small practical demonstrations (not the programmer productivity aspect, but things like the live interpreter in the production equipment, or devices that were developed more rapidly than the competition could manage, so that they are plainly ahead of the game. Regards, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks (Intel answer) Date: 1 Apr 95 09:17:10 MET In article <3l4vf0$6jn@newsbf02.news.aol.com>, erather@aol.com (Erather) writes: > ...two that I've found to be not only appropriate to the > kind of guerrilla warfare Forthers engage in but also quite readable and > entertaining are both by Guy Kawasaki: "The Macintosh Way" and "Selling > the Dream." Both deal with ways of communicating the advantages of some > unorthodox technology or idea with a minimal budget. > Great, and the story of the Macintosh (and Apple II) is a classic of true marketing. But "communicating the advantages of some unorthodox technology or idea with a minimal budget" is not marketing in the sense of the vast majority of university level courses on marketing, it is sales or sales management or sales support. It is very common in industry to call sales "marketing" because sales people don't like to be labelled as such. But when the benefits of the product are fixed by management, plugging them is selling, not marketing. Marketing investigates what the customer wants and influences product development and all other aspects of the selling company in order to meet the customer needs that are discovered in that process, in a profitable way (standard text book definition). Marketing brings information *from* the market *to* the selling & producing companies, whereas selling moves information *from* the seller *to* the potential buyers. Furthermore, salesman are generally extraverted personalities in Jung's sense (not the media's perversion of "extravert"), whereas marketing specialists are of all kinds, plenty being introverted creative types. I don't just mean "creative" in the ad agency sense but also in the sense of contributing to product development. Marketing should therefore be much nearer to the heart of most Forthers than sales is, given that Forthers are more creative and less into selling their own mothers than your average salesman. Jeff Fox's problem is possibly that he has behaved in such a way that he is perceived as a salesman, and has in fact not done any marketing. Sales that is not preceded by marketing, is the same as trying to sell a non-existent product with no support. To be a little provocative: Maybe quite a lot of people *would* buy a better mousetrap, but mousetrap design processes rarely take into account the customer's genuine mousetrap needs. (Not an easy marketing task, and different in every epoch: After demonstrating about Norwegians killing baby seals, do you really want a mousetrap that efficiently wallops your mice across the back with a piece of heavy steel wire and breaks their back or neck? Perhaps you would prefer one that traps them in a little room, leaving you to do what with them when you find them there? Or do you want to use Warfarin poison and risk your own child secretly eating the pellets 7 days in a row and your doctor misdiagnose the results? These are the issues of the mousetrap, and while they may raise technical issues they do not revolve about them.) Building the perfect mousetrap and then telling the right people about it in the best way, is a contradiction in marketing terms. Apple's Macintosh was incidentally not sold with a minimal budget, see well known material about Scully's takeover (that I have forgotten the name of -- was it a section in "Soul of a New Machine" by Tracey Kidder, or did Scully write it himself, or what?). They blew $1 million on a single 1 minute ad that fell flat, at a major football game. I hope I don't appear overly critical here. Ms Rather's comments I see as very useful and worth listening carefully to, my point here is to focus on what they leave out, which is not just a question of terminology ("sales" or "marketing") but of what the standard marketing courses call "market orientation" i.e. taking the customer's part when dealing with the rest of your own company. The usual terminological misunderstanding (based on the lies told by sales executives to their new recruits, that they will be marketing not selling) is unfortunate because it inhibits an understanding of the concept of "market orientation". Extreme market orientation would mean giving up selling Forth whenever sufficient customers thought that would be a good idea, and selling C or Visual Basic instead. I disagree strongly with the extreme forms of market orientation and I think the elementary marketing texts that purvey it are out of sync with recent strategy research, which emphasizes that the only way to make money is to build on your unique resources, which means you put your own unique resources in the driving seat and influence the market. A diagram may help here. Information flows shown by arrows below: ======================================= Customers,markets Selling/producing/designing company SALES <--------------------------------o fixed benefit list MARKETING BY THE BOOK O--------------------------------> make new benefit list (STANDARD): and operate SALES separately as above. RESOURCE-BASED MARKETING <---------------------------------O make new market or niche STRATEGY that only you can service (NEW) and operate SALES separately as above and modify STANDARD MARKETING above (because it would otherwise fail to make use of the company's *unique* resources) to become a negotiation or interaction instead of a one-way flow (new benefits must be based on unique company resources). INTEL STRATEGY: Manage all three information flows above at same time (as in resource-based marketing), but instead of emphasizing that the company's resources are unique, relying instead on high pace and volume of information flows (to outpace leakage due to copying by competitors), and building unique longlasting relations with particular customers to protect sensitive info. HONDA STRATEGY: Rather like Intel's but instead of emphasizing information flows (e.g. application notes) a string of new models is introduced instead. (Thus Intel's unique advantage is to manage the information flows and customer relations; Honda's is to manage the introduction of many new models; both based on a historical development that makes it hard for competitors to match their pace of development. These advantages are *new in kind* because they are dynamic, unlike niche strategies which are based on static assessments of the company's unique advantges.) TRADITIONAL <---------------------------------- given benefit list JAPANESE O---------------------------------> make new benefit list STRATEGY 0---------------------------------> develop service organization to put market pressure on production methods and build unique longlasting relations with particular suppliers TOYOTA STRATEGY (tqm) As traditional, plus a socially-based reorganization of production engineering: 1) No separation of design and production engineering staff, all designs are tested immediately by production engineers. 2) Empowerment of the production line worker to take responsibility for quality: - spontaneous "quality circle" meetings (not led by management) - the right to stop the assembly line on observing any quality problem whatsoever - sabbaticals with machine tool suppliers to influence design of equipment used on the line and to learn how to service it. NB: Point 2 is important because the production line worker is multi-skilled and responsible, reducing later problems of unemployment when he is forcibly retired at age 50 and goes to work for the equipment suppliers. 3) The principle behind point 2 means that customer complaints permeate all the way back up to design engineers but in a way that has interacted withe the company's technological possibilities and is not dictated by the customers. Best wishes, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks Date: 1 Apr 95 10:28:43 MET In article <3l5j62$dls@news1.delphi.com>, lkaplan@BIX.com (Leonard Kaplan) writes: > > Anyway, even with the tremendous track record that the software has, > management there _still_ won't call it Forth! I was under _strict_ orders > not to use that word around customers (even one whom I knew used Forth > regularly, and with whom that knowledge might have been mutually > beneficial). > > -Len In the heyday of my Forth multi-user business software (mid 80's), I was careful to say it was written in assembly language. Why? Because it is a strategic disadvantage to have to admit that you are not using one of the three largest (or best known) suppliers for an essential input to your development/production. Unless you are able and willing to take the initiative and argue for the unique customer benefits of using Forth. I had no reason to do that in dealing with leadership of small wholesale distributers, fish products factories, and accounting bureau leadership. There was no way they would every understand the benefits of Forth, and there is a limited bandwidth available, which should be used for communicating the benefits of my own product that was selling, which was not Forth development systems. Regarding that strategic disadvantage, see the book about PIMS recommended by someone else in this thread (from Boston Consulting Group). The claim is based on regression analysis of a data base of many companies and their profitability. If it matters, you should be able to turn any disadvantage to an advantage. But in my case and in Len's case, the advantages of Forth were not customer benefits and therefore should not be communicated to the customer. The customer is not in business to donate money to crusades and is very sensitive about supposed "benefits" that he cannot relate to his own bottom line (profit, market share). My belief is that there do exist customers who can benefit from the strategic advantages of Forth. This group does not include fish product factories and other purchasers of ready made and customer business software. If Forth is cheaper and more productive, then the appropriate customer benefit to name is that your product is cheaper, has been developed more rapidly and is thus ahead of the competition in useful features, etc. The reason why that might be so should be uninteresting to the customer. The product's advantages can be demonstrated. My product was multi-user at a time when the competition said it was impossible. It was easy for my customers to see that it really was, and that the competition was mistaken. The use of Forth was irrelevant to that evaluation. My customers sometimes knew that assembly language programs were faster than programs written in e.g. Commodore Basic. My programs were *very* fast in user response to keyins. I had mucked around a bit with assembly language portions of my Forth system, and realized that to a non-Forth computer scientist, Forth was an assembly language program with a whole lot of table entries and pointers in its dictionary. No lie was needed to see that the customer benefit of rapid response to keyins could be expressed by saying the program's superior speed was because it was written in assembly language. Although the customer did not really know what assembly language was, they knew that only the most advanced programmers could write it, because the competition was unable to offer such a fast program. Regards, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks (embedded applications) Date: 1 Apr 95 13:54:19 MET In article , jfox@netcom.com (Jeff Fox) writes: > > I am not ignoring amoritization of R & D costs or other organizational > costs in estimates of the minimal prices that include profit. It is > however dependent on volume. If you sell a few chips the amoritization > of those costs is a much larger percentage than in higher volumes. > I had in mind (but did not explain fully) that whether or not higher volumes were going to be possible or not, they weren't going to be profitable (perhaps we will get on to that eventually). For higher volumes, of course you are right. > These are not a big factor however given even moderate volume. If Intel > invests 5000 man years of R & D in a design (as they have in some cases) > this is $500,000,000 that must be recovered on sales. There have been > several man years invested so far in Chuck's work, but his approach has > required thousands of times less than conventional designs. You are onto a valid point here, but you are I feel also missing one: Chuck seems to be doing research, not development. For every man-year of research you need about 4 man-years of development, that includes working with customers and writing the app. notes, and many other adjustments to inputs from a marketing function that Chuck doesn't seem to have. Development means here "developing a product for a market" and I feel that neither the market nor the product has been defined yet. But my original feeling here was that you were naming figures which did not even cover Chuck's (and Dr Ting's, and your) man-years on such projects which run back to perhaps 1983 or so? Also, that the figures you named did not include development for market because none had been done or was planned that I could see. Your phrase "even moderate volume" worries me. I don't think you have done any market research or creative marketing that would point to any volume at all. The validity of the point you make here is I think this: I think Chuck is pursuing a form of minimalism with respect to code and silicon. While this takes time, it takes only Chuck's time and avoids many other organizational and marketing costs. To the extent that this research succeeds, it will then vastly reduce the cost of developing products for market, for reasons that I think need a good deal more discussion. The 3 of you seem to be unable to formulate this strategic advantage in a meaningful way, because - you seem to ignore the need for product development in the marketing sense, concentrating instead on technical development which is not the same thing - you don't have time for product development - your mind is fixed on selling volumes of chips - like Chuck Babbage, Charles Moore may well be more interested in the next round of research, thus killing the development of of the previous round for the market -- this is not so much a weakness of his approach as a strength provided you are looking for genuine benefits instead of selling hardware at low prices, which I think is very unlikely to be profitable. > Once he > has a library of working components to drop into designs the R & D costs > should drop by another order of magnitude. > I doubt that the R&D costs have ever dropped in terms of $ per chip, because you are not selling the increased volume that would imply. I think you are referring to improvements in Chuck's own productivity, but since that is not being translated into higher sales then the annual imputed R&D costs of his labor (to his household) are more naturally considered as being perhaps a constant sum per year. > I am not suprised since the Novix was never a low-cost chip. The Right, but Novix were feeding me with arguments to the effect that its cost/performance ratio was outstanding. It was, during a period in which the technical doc. was inadequate, then it was no longer by the time the documentation arrived. The problem lay in the organization, not the chip. > Chuck's design approach is quite different. Not only are development > costs (that need to be amoritized) thousands of times lower, but the die > size is hundreds of times smaller. This results in a much higher yield. > Manufacture cost for Chuck's die or in some cases the entire chip can be > under ten cents! So what -- you can't sell it for that and still make a profit. You are I think misinterpreting Intel's market strategy completely, taking as your guide uninformed media accounts of the microprocessor revolution. Now you know more about the industry than the average hack, sensationalist journalist. What you have to do is to apply some original thinking to your basic assumptions as to who the potential customers are, what they need, and what you are doing to meet those needs. Does anyone really need cheaper and cheaper MuPs ? I doubt it. Does anyone really need dramatic reductions in their own product development time? Sure. So I think you should study *other people's* product development (which is a marketing exercise) since you don't have the time to do your own. There are many points of strategic value that you can squeeze out of your knowledge. The greater simplicity and elegance of Chuck's design should for instance make it much easier to avoid such embarrassing problems as Intel's Pentium problem on floating point. There are many benefits of elegance and simplicity. They translate into cash for the informed customer. But so far you have not demonstrated any understanding of the informed customer's product development process, which is driven by marketing. You are thinking as follows: - technical features that the 3 of you like - low cost. That is not a successful marketing strategy. It went out with the model T Ford. Henry Ford was nearly destroyed by General Motors, because he did not make the needed adjustment. > Maybe the chips should be marketed for $400 to $4000 so that people take > them seriously, but it should be possible to market them for less than > chips that cost 1000 times as much to manufacture. I just don't see > why you doubt that Chuck's work has much to do with chip prices. > I have no doubt at all, especially given your useful further information on the higher yields due to minimalism, that Chuck's work can be used to produce cheaper chips, that you could program to replace almost every microprocessor product on the market. Admittedly, it would still take you about a million years to do all that programming. Because, you still haven't thought seriously about the question: Why will anyone buy (or program) the chips ? You are taking for granted a false "reason": that they are better and cheaper. People don't buy things because some inventor thinks they are better and cheaper, even if it is true. They buy things that meet their own perceived needs. If you have something new that they don't perceive yet, you have to alter their perceptions, not cut the price. Only by altering their perceptions will they ever pay a good (i.e. *high*) price for your product, and that is the only way you will even cover your costs, let alone make any money. Face it, Jeff, you are trying to be a salesman, but no one has been doing the necessary marketing. The responses you have described show that your performance as a salesman is unfortunate. Your repeated return to low price as an argument (actually you return to low cost, but you imply low price) is the hallmark of a salesman who has not been given any sales training at all. I don't think you should give up your desire to be able to sell this stuff. What you have to do to succeed at it is: - someone has to do some marketing before there is any question of selling anything, because until then there is no product to sell - the result of such marketing is a well-defined product that offers benefits to a recognizable group of customers, so to succeed what you do is to prove these benefits by concrete demonstrations at customer sites, and repeat them when the prospect's memory is confused by your competitors. The problem of selling the stuff is a purely mechanical one if the marketing stage results in a saleable product. The same goes for finding investors. The first step above is the real challenge, but you haven't addressed it. You have put the cart before the horse. Perhaps the first step can be solved right here on Internet. Because what Chuck is doing is far from ordinary, there is no simple mechanical formula that tells you how to develop it for a market. But, marketing can tell you what questions to ask. Then, both yourself and others will eventually be able to find some answers to those questions, based on your knowledge of the industry. Best regards, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks Date: 1 Apr 95 14:29:11 MET In article , rockwell@nova.umd.edu (Raul Deluth Miller) writes: > > For what it's worth, I've gotten one of these MuP21 development kits, ... [snip] > Fortunately, the underlying design is wonderfully easy to comprehend. > I've not mucked around much with electronics for something like a > decade, but even with partial docs I'm having no trouble figuring out > the system (it's just slow for me). I know the material I have deleted here was a plea for more and better documentation, including an interesting and useful statement of in what areas, and in what ways. And for a service phone (that would perhaps be less relevant if the documentation were better, and would it really help if it only uncovered further problems with the doc.?). The reason I selected the above quote is that it illustrates a strategic paradigm due to Michael Porter, the most well known strategy theorist who takes about $10,000 for each lecture and is based at Harvard. About 15 national studies have been done around the world based on his ideas, e.g. in Norway the study involved the 20 largest companies as participants, main labor union organization and the main employers' organization (full pot) and the result is now official govt. policy. So Michael Porter is not an absent-minded professor, although he is a professor at Harvard. The paradigm is this: overcoming difficulty produces strength, having life too easy produces weakness. Ergo, the main reason why Raul is not entirely happy with the doc. and phone service is that the underlying design is wonderfully easy to comprehend. The elegance of the design means that Chuck actually almost gets away with not spending enough time on documentation. But not quite. Vice versa, the producers of incomprehensible microprocessor designs (no names, please) have to be world champions at good documentation and customer support, or they don't survive in the market. The role of the marketing strategist is various in such circumstances, but the natural thing to do is to make the right people in the producing/selling/designing company aware that there is a difficulty with the documentation. That may not mean the inventor, but someone is going to have to improve the documentation if there is going to be any success. Remember Glen Cunningham, one of the few Americans to have won an Olympic Gold medal in distance track events. His legs were badly scarred by fire when he was about 6 years old. The doctors said he would never walk again. His response was to set a world mile record and win the 1500m at the 1936 Olympics. Strength results from adversity. But, to motivate people you need to set goals so that they succeed about 80 per cent of the time. So I suppose the answer is to focus on the issue of better doc. and app. notes, and try to arrange a resulting success so that this does not become discouraging. More easily said than done -- encouraging stories of how Joe Blow did this and that and look how he succeeded as a result, all tend to make people think: Ok, but what if I did things the right way, like Joe Blow, and *still* fail ? That would mean that I really aren't good enough. So success stories are not always a good idea. I think Raul makes it plain in the (unqoted) part of his posting that with better documentation he would do something very interesting with his kit, MUCH FASTER than seems currently possible. The main strategic advantage I see for Forth and Chuck's chips is the ability to tackle new projects faster than the competition. Lack of app.notes and appropriate doc. is preventing this key advantage from being put into practice, I believe. Best regards, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks Date: 1 Apr 95 14:48:21 MET In article , jfox@netcom.com (Jeff Fox) writes: > > I think your first sentance is a better description of the problem. People > seem unwilling to invest because they are suspicious that no one else has > already invested. Many have expressed that they are waiting for someone > else to make the first move. > I think they are being polite. No one has convinced them that they are going to make money by investing. The *real* investors are of course looking to make a real killing by investing *precisely* in something that no one else understands or knows about. Then, they get a larger slice for the same investment, and can resell bits of it to the "followers" you describe, at an enormous profit, very early in the game. There is ultimately only one criterion, and you have not taken up the challenge of trying to meet it at all: show an investor that he/she will make money by investing. There are ways of doing this, but then you need to meet criteria that presuppose a marketing approach. The criteria are a checklist and you have to work to more or less meet them all, and be particularly strong in some. You already meet some, but you have some big gaps there, particularly regarding marketing and product definition. Investors are currently very short of opportunities. Money in the bank yields low interest and high exchange rate risk in many cases, bonds inflicted unprecedented losses on merchant banks in London last Fall (e.g. loss of 50% of value in 12 months), property seems dodgy if not very central and problemfree and no one wants to sell any of that so you can't buy it, and the share market seems to have peaked. There is very little sensible stuff you can invest in and risks are high all round. So there is plenty of money out there waiting to be convinced about good, well-documented, creative and well-conceived business projects. But no one in their right mind will invest in a business project in which the marketing groundwork has not been done and the main questions have not been asked. It is like building a house. You first need a block of land, you clear it, you build foundations and install utilities, then build upwards (or do the roof next and build downwards with a wood frame if it rains a lot where you are). The point is, you cannot skip any of these steps. If you do, the bank that finances you will call in the loan immediately. If you follow through with all the steps, it will be very clear quite early that you are going to be able to build a decent house. If you do all the steps and are creative and knowledgeable about your stuff, you will succeed and grow like Apple and Compaq if you want to. Some experience helps, but sooner or later you have to do something new. It's a lot of work. Question is, can we all do some of that work here on Internet (and benefit from the resulting legitimacy and very high personal productivity that would result, each in our own way)? And, you need to gather the variety of knowledge and experience that is needed to meet the checklist. The originality seems already to have been taken care of by Chuck. Regards, David Walker snf_dw@debet.nhh.no From: snf_dw@debet.nhh.no Subject: Re: Two Chucks (Intel answer) Date: 1 Apr 95 14:55:06 MET In article <3l6un3$60g@kelly.teleport.com>, znmeb@teleport.com writes: > Erather (erather@aol.com) wrote: > : David Walker has recommended numerous scholarly-sounding books on > : marketing strategy... > One must-read book in this category is "The PIMS Principles" by Buzzell > and Gale (Free Press, 1987, ISBN 0-02-904430-8). > -- > znmeb@teleport.COM (M. Edward Borasky) > That book is a good basis for the "checklist" approach I mentioned in my previous posting just before this one. You also need some financial analysis and active, original marketing that can draw out and identify the customer benefits in what is after all a very unusual product (MuP21). The Buzzell and Gale book claims to have "proved" statistically a whole lot of conclusions. Truth is always relative, you will find exceptions to any of their conclusions. But, if your project is an exception to almost all of their conclusions (cf. Jeff Fox's accounts) then it is time to make some changes. Modern strategy theorists are a bit sick of Buzzell, Gale and the Boston consulting Group because they have purveyed a number of somewhat oversimplified, cookbook approaches. But if you don't know how to cook, a cookbook is a great place to start, then you can get original soon after. What I mean is, the book is useful but do not view it as a bible. Regards, David Walker snf_dw@debet.nhh.no From: lkaplan@BIX.com (Leonard Kaplan) Subject: Re: Two Chucks Date: Sat, 01 Apr 1995 10:05:13 > Not >surprisingly, the interpreter I implemented was quite similar to >Forth's (well, some Forths') virtual machine (the language, however, >was quite Algol-like). DEC and Data General, at various times over the years, have done the same kind of thing. For portability reasons (different PDP-11 capabilities), DEC sometimes generated threaded code with their FORTRAN compiler - I remember seeing "JSR $POLSH" in assembly listings. I may be mistaken, but I believe that it was confined to math-related functionality. DG Algol generated threaded code, at least under RDOS about 1978 or so. I hadn't heard of Forth at that time, so it just seemed to me like an interesting way to do things (it still is, or I wouldn't be up here I suppose!) I generally try to stress to people that Forth is useful as a _concept_, even if the language per se doesn't fit a particular situation. This seems to sit fairly well in general. >The funny result was that the 4GL compiler >generates C code for the data structures and a portable intermediate >code for the code. Maybe they fixed this in the meantime. That is odd. I'd think your boss would have wanted you to define the data structures in your IL also. Unless there were other issues (as far as interfacing to other systems?), wouldn't it have been better to have the structures in a form the interpreter could use directly? By the way, did your boss care how you implemented your interpreter, or did he just want to see results? -Len From: snf_dw@debet.nhh.no Subject: Re: Forth meeting at UMd Date: 1 Apr 95 17:39:42 MET In article <3lepbs$k2q@ixnews3.ix.netcom.com>, JEThomas@ix.netcom.com (Jonah Thomas) writes: > Wednesday, March 29, MFIG staged another Forth talk, this time at > University of Maryland for their student IEEE chapter. > [snip]... Sounds like you're doing pretty well at this now. Think of the fan-out if you really convince a relatively small number of students. > We still don't have enough feedback. I gather lots of marketing has > this problem. We could pass out a questionnaire asking audiences > what they liked. We can see whether anybody new shows up at > meetings, and ask them how they heard about us. Right on target. Work to get the feedback and then use it, that is true marketing. I am impressed that you see your role in these vividly described contacts as more marketing than sales. What about a working rig to take with you to these meetings to demonstrate ? > If a small group of > UMd students calls to ask for a tutorial session I'd count this > meeting a full success. But lots of our results or lack of results > will be invisible to us. Every student who puts Forth on his resume > is a success, but we won't see the resumes. When we don't even know > what our results are, it's hard to improve. We need to get more > immediate feedback from our audiences, make it more interactive, more > Forthlike. > You said you found yourself trying to make your presentation in too short a remaining time, when you should have been asking for questions, due to momentum. This is one of two big things to work on in such live situations: even if you are invited to talk, try to raise your listen/talk ratio, consciously. Use pauses to encourage others to say something. The other big thing in many groups where the people mainly know each other is, try to find which are the dominant (trendsetting or actual bosses) people that influence opinion, and sell directly to them. Sometimes it is revealed by body language of the others. The behavior of the person him/herself is less reliable as a guide. The second device also tends to make you more part of the group and less of an outsider. It is embarrassing for the group if you focus on selling one or two individuals whom the rest of the group regard as peripheral. This might sound a bit fascist, but there it is. Fight fire with fire. Regards, David Walker snf_dw@debet.nhh.no From: ehp@ear.co.at (Ewald Pfau) Subject: Single-stack forth Date: Sat, 01 Apr 1995 18:39:15 X-FTN-To: Hasdi R Hashim Hasdi R Hashim wrote: [...] HRH> Okay, after all my work trying to work around the use of HRH> single stack, is it all for naught? Is it??!!!! Hmmmm. There HRH> are advantages to building up stack frame like using the HRH> parameters that you want without "dup"s, "swap"s or "rot"s. HRH> You can also create automatic variables so you can safely do HRH> recursion as often as you want! HRH> Consider the following program to draw a box on the screen. HRH> (I am using "::" and ";;" to make distinction.) HRH> :: drawbox ( x1,y1,x2,y2,box_string ---- ) HRH> pointer parm box_string HRH> integer parm y2 HRH> integer parm x2 HRH> integer parm y1 HRH> integer parm x1 HRH> x1 load HRH> dup y1 load gotoxy HRH> boxstring loadc outchar HRH> dup x2 load minus negate 1 minus HRH> boxstring 1 adjch loadc HRH> swap ( workspace for char and integer, same size) HRH> do HRH> dup outchar HRH> loop HRH> drop HRH> boxstring 2 adjch loadc outchar HRH> y2 load y1 load minus 1 minus HRH> do_upwards (1 to dy-1) HRH> x1 load HRH> dup y1 load i add gotoxy HRH> boxstring loadc 3 adjch outchar HRH> HRH> x2 load minus negate 1 minus HRH> boxstring 4 adjch loadc HRH> swap ( workspace for char and integer, same size) HRH> do HRH> dup outchar HRH> loop HRH> drop HRH> boxstring 5 adjch loadc outchar HRH> loop HRH> dup y1 load gotoxy HRH> boxstring loadc 6 adjch outchar HRH> HRH> x2 load minus negate 1 minus HRH> boxstring 7 adjch loadc HRH> swap ( workspace for char and integer, same size) HRH> do HRH> dup outchar HRH> loop HRH> drop HRH> boxstring 8 adjch loadc outchar HRH> ;; HRH> Can I use two stacks for this? Yes, but why bother? This HRH> will work on single stack just as well. You cannot use the HRH> coding I have shown in the beginning for double stack HRH> implementation of the above Forth code on 80x86 machine. HRH> This is because bp is already used to build up a stack frame HRH> not as a pointer to return stack. Therefore, in 80x86, it is HRH> better to use single stack implementation (IMHO). I really do not understand where your problem is except perhaps at Intel company or the amount of work you invested. But Intel 80x86 CPUs have two stack pointers. So what? Motorola 680x0 CPUs have nine of them... Parameters in Forth are in "single cell width" representation on stack. Why not? You could read a lot of arguments giving reason for that. The only one perhaps missing: it is not 'C', neither Pascal style. But this is no Forth problem. Typical Forth instances of code are late bound to whatever kind of data, this seems to me the biggest advantage: stepping thru layers of abstraction to high level interfaces should be quite easy then. (For comparison: in building houses, you only ask for rooms inside them, instead for THE living room and THE sleeping room and so on ;) ). If this is not as easy in 'C' or Pascal (and each one of such layers is in frozen readymade state with one shared denominator only for those states: to fit into algebraic expressions -, da capo :) ) so this is no Forth problem... Since I found a piece of code for the same job like you have shown above, you are invited to do a comparison. Following code is in everyday use inside a block file editor. Border of a box is drawn, using one of several data sets of chars. Each set consists of eight chars, four each for lines and for corners. Following char values are for IBM machines, making border drawings of different taste. Invoking the name of one char set will bind this to the action of "+Boxchar". "-Boxchar" will use a char set consisting of blanks. Invoking the name of "+Boxchar" or "-Boxchar" will bind the action to "Boxchar" which is called from the box drawing routine. create 'BOXCHAR 2 cells allot : BOXCHAR ( x y #field --) 'boxchar @ 2swap at-xy + c@ emit ; : BOXCREATE create 8 chars allot here 8 0 do 1 chars - tuck c! loop drop ; : BOX-STYLE boxcreate DOES> 'boxchar cell+ ! ; $da $bf $d9 $c0 $c4 $b3 $c4 $b3 box-style BOX0 201 187 188 200 205 186 205 186 box-style BOX1 3 4 5 6 30 16 31 17 box-style BOX2 $db $db $db $db $df $de $dc $dd box-style BOX3 bl bl bl bl bl bl bl bl box-style BBOX : -BOXCHAR ( --) ['] bbox >body 'boxchar ! ; : +BOXCHAR ( --) 'boxchar cell+ @ 'boxchar ! ; ( initialize binding:) box1 +boxchar : N-N- ( a b c d -- [a-c] [b-d]) rot swap - >R - R> ; : BOX ( left/x top/y right/x bottom/y --) ( ** box is drawn clockwise) 2over n-n- 2>R 1- swap 1- swap 2dup 0 boxchar swap 1+ swap 2R@ drop 0 do 2dup 4 boxchar swap 1+ swap loop 2dup 1 boxchar 1+ R@ 0 do 2dup 5 boxchar 1+ loop 2dup 2 boxchar swap 1- swap 2R@ drop 0 do 2dup 6 boxchar swap 1- swap loop 2dup 3 boxchar 1- R@ 0 do 2dup 7 boxchar 1- loop 2drop 2R> 2drop ; Ewald From: ehp@ear.co.at (Ewald Pfau) Subject: Need Opinions Date: Sat, 01 Apr 1995 20:25:09 X-FTN-To: Robert J Brown brownrj@cig.mot.com (Robert J Brown) wrote: RJB> I have used MaxForth before, and all I did was use ProComm's RJB> ascii upload function, along with tailoring the timing in RJB> the config menu for ascii upload so that each line was RJB> followed by a suitable delay. Without wanting to interfere in pros and contras of host or target based developpement, just let me state, that the problem you mention could be solved very well and in an elegant way by using (parts of) ZModem protocoll. But since as many implementations exist as applications (?) (yes that's me as well) ;) , such a fine and widely distributed tranfer protocol is not available in Forth afaik. Ewald If someone wants to engage in that, so please write - I did XModem and batched YModem some good while ago - but for now, I HATE those timeout thingies ... CRC32 and CRC16 are quite easy (perhaps a 'C'-programmer will tell you otherwise? ) - let me post them here, it is not that many. Could be optimized. Written for 16 bit implementation (32 bit should use cell size but could do it by 2* half cell size; 'DU2/' is masked for 16 bit). Given are as well table driven (C..X+) as direct (C..+) calculation, meaning: accumulate new value into given value. The first ones have to be initialized (C..FILL). ( Common:) 256 constant #TBL 8 constant #B/B : 8SHL ( n -- n) #b/b lshift ; : 8SHR ( n -- n) #b/b rshift ; : D8SHL ( d -- d) over 8shl rot 8shr rot 8shl or ; : D8SHR ( d -- d) tuck 8shl swap 8shr or swap 8shr ; : DU2/ ( d -- d) d2/ $7fff and ; : DXOR ( d d -- d) rot xor >R xor R> ; : S>B ( n -- n) $ff and ; : T+@ ( n a -- n) swap cells + @ ; : T!+ ( a n -- a) over ! cell+ ; : DT+@ ( n a -- d) swap dup + cells + 2@ ; : DT!+ ( a d -- a) rot >R R@ 2! R> 2 cells + ; ( CRC16:) $1021 constant CR1 create CRCTBL #tbl cells allot : CRCDIV ( n -- n) 8shl #b/b 0 do dup 0< if 2* cr1 xor else 2* then loop ; : CRCFILL ( --) crctbl #tbl 0 do i crcdiv t!+ loop drop ; : CRCX+ ( n n -- n) over 8shr xor crcdiv swap 8shl xor ; : CRC+ ( n n -- n) over 8shr xor crctbl t+@ swap 8shl xor ; ( CRC32, 1st method:) $7707.3096 2constant CR3 create CR3TBL #tbl 2* cells allot : CR3DIV ( n -- d) 8shl 0 swap #b/b 0 do 2dup d0< if d2* cr3 dxor else d2* then loop ; : CR3FILL ( --) cr3tbl #tbl 0 do i cr3div dt!+ loop drop ; : CR3X+ ( d n -- d) over 8shr xor cr3div 2swap d8shl dxor ; : CR3+ ( d n -- d) over 8shr xor cr3tbl dt+@ 2swap d8shl dxor ; ( CRC32, 2nd method; more common to use this one:) $EDB8.8320 2constant CB3 create CB3TBL #tbl 2* cells allot : CB3DIV ( n -- d) 0 #b/b 0 do over 1 and if du2/ cb3 dxor else du2/ then loop ; : CB3FILL ( --) cb3tbl #tbl 0 do i cb3div dt!+ loop drop ; : CB3X+ ( d n -- d) >R over s>b R> xor cb3div 2swap d8shr dxor ; : CB3+ ( d n -- d) >R over s>b R> xor cb3tbl dt+@ 2swap d8shr dxor ; From: erather@aol.com (Erather) Subject: Customer benefits of Forth (was Two Chucks) Date: 1 Apr 1995 18:13:56 -0500 Reply-To: erather@aol.com (Erather) snf_dw@debet.nhh.no (David Walker) writes: >If it matters, you should be able to turn any disadvantage to an >advantage. But in my case and in Len's case, the advantages of Forth >were not customer benefits and therefore should not be communicated >to the customer. I agree that customers don't always perceive the benefits, but I disagree that they don't exist for the end user. In my experience, end users of software systems (i.e., folks not expected to know anything about programming or have any expectation of doing so) either (a) don't know or care what language the system is programmed in, or (b) have heard just a little about various techniques (possibly enough to recognize some familiar names). Generally, I don't think it's useful or appropriate to bring up language when discussing an end-user software product. If asked, I assume the person falls in "category b" and say it's Forth. If asked further, I explain that Forth is a specialized language developed specifically for applications like this, and that it has the following advantages: it's very efficient, which means this program is going to give great performance on less expensive equipment than might otherwise be required; and it's very flexible, which means it will be easy for us to add enhancements in the future, or even customize it to this customer's special needs if that seems desirable. These are very real benefits that most people understand and respond quite positively to. Elizabeth D. Rather "Forth-based products and FORTH, Inc. services for real-time 111 N. Sepulveda Blvd. Suite 300 applications since 1973" Manhattan Beach, CA 90266 800-55FORTH -- 310-372-8493 310-318-7130 FAX From: jfox@netcom.com (Jeff Fox) Subject: Re: corrections, was Two Chucks Date: Sat, 1 Apr 1995 23:04:36 GMT In article jfox@netcom.com (Jeff Fox) writes: >> Chuck's approach does make it possible to make 100+ megahertz cpu chips >> that require fewer transistor than the 4004. According to a Scientific American Article Sept 78 the 8080 had roughly the same number of transistors as P21. It appears that I referred to the wrong chip. Oh well, I didn't get involved with micros till the 8080, I was still using mainframes back in the 4004 days. Still when I got my first 8080 it was $175 in 1975 dollars, and a system with 1k of ram was about $1000. :-) From: erather@aol.com (Erather) Subject: Re: Two Chucks (Intel answer) Date: 1 Apr 1995 18:36:46 -0500 Reply-To: erather@aol.com (Erather) >Apple's Macintosh was incidentally not sold with a minimal budget, >see well known material about Scully's takeover... Scully was brought in several years after the Mac was introduced. Kawasaki was focussing on a somewhat earlier phase. Elizabeth D. Rather "Forth-based products and FORTH, Inc. services for real-time 111 N. Sepulveda Blvd. Suite 300 applications since 1973" Manhattan Beach, CA 90266 800-55FORTH -- 310-372-8493 310-318-7130 FAX From: erather@aol.com (Erather) Subject: Re: Two Chucks Date: 1 Apr 1995 18:23:02 -0500 Reply-To: erather@aol.com (Erather) >>... Many have expressed that they are waiting for someone >> else to make the first move. > >I think they are being polite. No one has convinced them that they are >going to make money by investing. The most negative think you will ever hear an investor say is "That's a teriffic idea, you've done a great job and that was a fine presentation. Unfortunately, I'm not in a position [specious reason here] to invest..." Translation: "I see nothing of any value here, I've just wasted my time, and I'm running screaming for the door." If he really meant what he said, he'd volunteer the names and phone nos. of three of his best friends that might be interested. If he was personally interested, he wouldn't leave without making an appointment to take the next step in evaluating your great opportunity. Which means your best strategy is to test his sincerity by asking for some names of friends if he says no, and setting up a next appointment if he says maybe. Elizabeth D. Rather "Forth-based products and FORTH, Inc. services for real-time 111 N. Sepulveda Blvd. Suite 300 applications since 1973" Manhattan Beach, CA 90266 800-55FORTH -- 310-372-8493 310-318-7130 FAX From: jfox@netcom.com (Jeff Fox) Subject: Re: Two Chucks (embedded applications) <1995Apr1.135419.3904@debet> Date: Sun, 2 Apr 1995 02:47:23 GMT In article <1995Apr1.135419.3904@debet> snf_dw@debet.nhh.no writes: > >You are onto a valid point here, but you are I feel also missing one: > Chuck seems to be doing research, not development. I have heard Chuck say this himself. > / / > >Face it, Jeff, you are trying to be a salesman, but no one has been >doing the necessary marketing. The responses you have described >show that your performance as a salesman is unfortunate. Your >repeated return to low price as an argument (actually you return >to low cost, but you imply low price) is the hallmark of a salesman >who has not been given any sales training at all. You make many very interesting points about sales and marketing. But I don't know if I would agree that I have been trying to be a salesman. Maybe I should, but at this point, and for the foreseeable future I really don't have anything to sell. I don't know that I ever will. I have said for a long time that if all I ever get out of this project is some chips myself that I will quite happy. :-) I never thought that I could get something like F21 even at the prices I will paying for the smallest quantities possible from MOSIS. I have really enjoyed working with Chuck, and have been content to fund my project out of pocket. I have never asked anyone else to invest in this project, and have never tried to sell stock or chips that have not yet even been prototyped. I am not selling MuP21 or Chuck's design services, although it may look that way to other people. I am just excited about what Chuck is doing for me. I do think that Forth is a very misunderstood subject. There are those who feel strongly that it is just a tool. Others feel it is more of an approach or mindset than a static computer language. Some people attach metaphysical signifigance to Forth (or other things in their life) and some don't. I happen to think that the development of computer technology is a signifigant thing for human evolution, not unlike the development of writing or speech. I also think that Chuck is doing the same thing in hardware now that he did in software twenty years ago. It is very analogous to what my martial arts teachers and Zen masters have told me for thirty years, "Focus, economize, and throw out that which is not essential." I also think that few people have been aware of what it is that Chuck is trying to do. And I have been suprised that there have not been more people doing market research and figuring out a way to take advantage of what Chuck is doing today. But at the same time I must admit that I feel sort of lucky to have been able to get in while the line was still short, and when there were not people offering Chuck sums of money that would have precluded me from having any place in line at all. I like to talk in public, and I like to spout off about my opinions, but I have never thought of myself as a salesman. Maybe someday I will become one, who knows. I have always thought of myself as a researcher with a very technical orientation. My training was in physics not sales, and I have earned my living for twenty years doing programming not sales. My real goal on this project is to able to have access to a computer system that will have hundreds of billions of instruction per second capabilities. I am not really that interested in trying to sell it to someone else, unless they make me an offer I can't refuse. My longer term goal is to write AI software that is orders of magnitude more efficient that what is available now, that will run on computers that are orders of magnitude faster than what is available now, and that can be produced for orders of magnidute less expense than what is available now. Of course I have been quoted as saying that "if your are not frustrated you have not set your goals high enough." Contentment and complacency are not the same thing. Jeff Fox P.S. Q: What is the difference between a car salesman and a computer salesman? - A: The car salesman knows when they are lying. :-) From: rant@ix.netcom.com (Ran Talbott) Subject: Re: Two Chucks Date: 2 Apr 1995 05:14:51 GMT In <1995Mar30.075954.3865@debet> snf_dw@debet.nhh.no writes: >Hasn't it occurred to you that there are customer benefits in >a processor that is > (a) so fast and > (b) so easy to programm and > (c) cheap enough >so that you can do timing, serial ports, and poll and interrupt >line in software on one or several of the same chip ? Yes. Since one of the things I do for a living is design products based on embedded microcontrollers, I'm well aware of the benefits. I'm also aware of the costs. In NRE, certainly, but especially in continuation and system reliability. Which is why I find it screamingly hilarious that someone who gets his knickers in a knot over the alleged "reliability problems" engendered by named local variables would advocate this type of system design, and suggest that it's "easy to program". >You are confusing your needs with means of satisfying them. >You need to have an interrupt line serviced. You need to >keep track of time to a given resolution. You need to >connect to a serial line. "an" interrupt line? "a" serial line? What's with this singular nonsense? Have you ever designed a hard real-time system? Even the simplest applications I design frequently have more than one interrupt source and/or multiple timers. >You do not *need* to service your interrupt line with >hardware, you do not *need* to use hardware for your timer, >and you do not *need* to implement your serial port in >hardware. (You left out the part about how you walked 9 miles through the snow to school when you were a kid. Uphill in both directions...) You have no idea of what I need, David. Nor, obviously, what most embedded developers need: if you did, you wouldn't be using these sorts of unqualified generalizations. >Viewed as a customer, you are trespassing on the sovereign >right of the marked-oriented inventor to offer to satisfy >your needs in ways that you have not thought of. Nor do you have any idea what I've thought of. I've been doing software for over 25 years, as have others who've looked at the P21's "paradigm". We've been there, done that, and worn the T-shirts for so long we're using them for paint rags now. The P21's *implementation* is very clever. But it's "philosophy" is not some revolutionary new concept that people are having difficulty grasping: it's been done before, had its heyday, and is now settled into a few niches where it works and is cost-effective. As for your accusation that I'm somehow infringing on Chuck's "rights": I was going to let you slide on this one, but we do have world-wide distribution here. So, for the edification of the 5 or 6 people who didn't immediately recognize this as a load of fertilizer (and, perhaps, the amusement of those who did...), would you be so good as to present your rationale? >In doing so, the marketing information that is spread has to >take issue with your claims that you need to do these things >in hardware. I'll look forward to it: this sort of subtle (albeit unintentional) humor is hard to find... Ran From: flacy@dip.eecs.umich.edu (Mark A Flacy) Subject: Re: Two Chucks Date: 02 Apr 1995 07:05:28 GMT <3l55um$i4o@ixnews4.ix.netcom.com> <1995Mar30.075954.3865@debet> <3llbsb$qon@ixnews2.ix.netcom.com> In-reply-to: rant@ix.netcom.com's message of 2 Apr 1995 05:14:51 GMT In article <3llbsb$qon@ixnews2.ix.netcom.com> rant@ix.netcom.com (Ran Talbott) writes: [stuff deleted] > >Nor do you have any idea what I've thought of. I've been doing >software for over 25 years, Yeah, yeah, when men were men and the sheep ran like hell. > as have others who've looked at the P21's >"paradigm". We've been there, done that, and worn the T-shirts for >so long we're using them for paint rags now. The P21's *implementation* >is very clever. But it's "philosophy" is not some revolutionary new >concept that people are having difficulty grasping: it's been done >before, had its heyday, and is now settled into a few niches where it >works and is cost-effective. > OK, let's have some specifics. >As for your accusation that I'm somehow infringing on Chuck's "rights": >I was going to let you slide on this one, but we do have world-wide >distribution here. So, for the edification of the 5 or 6 people who >didn't immediately recognize this as a load of fertilizer (and, perhaps, >the amusement of those who did...), would you be so good as to present >your rationale? > If you weren't so busy being a smart-ass on the 'net, you would have noticed that David was pointing out that you have _functional_ requirements rather than _physical_ requirements. Any means that fulfill your functional requirements fall into the possible solution set. So, what company _do_ you work for? (I'm job hunting and don't want to send my resume there by mistake...) >>In doing so, the marketing information that is spread has to >>take issue with your claims that you need to do these things >>in hardware. > >I'll look forward to it: this sort of subtle (albeit unintentional) >humor is hard to find... > Alas, jerks like you are not... >Ran > -- / ------------------------------------------------------------------------ \ / Mark Flacy "There's a lot to be said for a blow to the head" \ / flacy@eecs.umich.edu - Blue Oyster Cult \ / "I guess ya had to be there." - Me \ From: gordon@charlton.demon.co.uk (Gordon Charlton) Subject: Re: WANTED: Good multiplier for a 16-bit random number generator X-Nntp-Posting-Host: charlton.demon.co.uk Date: Sat, 1 Apr 1995 01:10:00 GMT In article , wilbaden@netcom.com (W.Baden) wrote: >Today if I had to work in 16-bits and needed a RNG-Lite I would >pirate the default RNG from the C Standard. It is widely used, has >reasonable properties, and is easy to implement. Hi Wil, Press, Teukolsky, Vetterling and Flannery (Numerical Recipes in C, The Art of Scientific Computing, Second Edition, Cambridge University Press, ISBN 0-521-43108-5, page 276) are rather dismissive of the default C RNG. Press et al give the distinct impression that they know what they are talking about, and supply a broad selection of RNGs to fit most applications. Recommended, if pricey. (I forget how much, it's one of those books that does not have the price printed on it, which usually means "a lot!". I think it was in the L40+ region) bcnu, _____Forth______| |_____ Gordon / ___Interest____| |____/ / /____Group _ _| | __ / __/ / __ /| | | | |/ / / / / / /_/ / | \_| | < /_/ /_/___ / \_____|_|\_\ __________/ /United Kingdom /___________/ Chapter gordon@charlton.demon.co.uk (L, as in L.S.D. - Librae Solidi Denarii - Pounds Shillings and Pence. That funny UK pound sign is a curly L. I dislike the use of the # to mean pounds, as I cannot think of any relationship between hash and LSD, offhand ;-) From: sfp@mpeltd.demon.co.uk (Stephen Pelc) Subject: Re: Single-stack forth Reply-To: sfp@mpeltd.demon.co.uk X-Posting-Host: mpeltd.demon.co.uk Date: Sun, 2 Apr 1995 21:28:49 +0000 > Hans> Hasdi R Hashim wrote: > >> One feature of FORTH that I DO NOT plan to put in MY VERSION of > >> FORTH is the existence of two different stacks: the primary > >> (info) stack and secondary (system) stack. (I apologize for not > >> using the correct terms). The system stack is primarily used, > >> among other things, to keep track of the caller's last position > >> when a primitive is called. > > Hans> I work with only one stack too. Only the return stack grows > Hans> downward and the parameter stack upward. I rather think that there is some confusion here. The C "stack" is a frame stack which is assumed to be in memory. The Forth stacks are not directly addressable, and conceptually cannot be assumed to be in data memory. However, there is a separate argument as to how many pointers are required by C compilers. In practice nearly all C compilers require a stack pointer and a frame pointer - two pointers. Forth simply requires two different pointers - the conceptual model is different. Implementing a C virtual machine on Forth requires some compromises, and implementing a Forth virtual machine on C requires a different set of compromises. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: tbushell@fox.nstn.ns.ca (tbushell) Subject: Code for ANS "(local)" for F-PC? Date: 2 Apr 1995 22:28:44 -0300 Mime-Version: 1.0 Can anyone send me or point me to an implementation of the ANS Forth Locals Word set? Couldn't find it on Taygeta or the site in Portugal. There was a nice implementation of named local variables in SIGPlan Notices for Forth a couple of years back, and I'd like to try it, but it uses "(local)". Thanks, -Tom From: wilbaden@netcom.com (W.Baden) Subject: Re: WANTED: Good multiplier for a 16-bit random number generator Date: Mon, 3 Apr 1995 02:40:56 GMT Gordon Charlton (gordon@charlton.demon.co.uk) wrote: : Press, Teukolsky, Vetterling and Flannery (Numerical Recipes in C, The Art : of Scientific Computing, Second Edition, Cambridge University Press, ISBN : 0-521-43108-5, page 276) are rather dismissive of the default C RNG. : Press et al give the distinct impression that they know what they are : talking about, and supply a broad selection of RNGs to fit most : applications. The key word of my last post (after I got the finger fumbles straightened) was `Lite'. This is what I thought the original poster was looking for. For heavy work I'd use Knuth's improved recommended subtractive RNG as given in _The Stanford Graphbase_. I have Forthed it for ThisForth in the sample code. : Recommended, if pricey. (I forget how much, it's one of those books that : does not have the price printed on it, which usually means "a lot!". I : think it was in the L40+ region) I have the first edition, which I think is good enough for me. I don't know why they needed a second edition to the C version -- couldn't they have gotten the bugs out from the Pascal version before releasing C? -- Procedamus in pace. Wil wilbaden@netcom.com From: tommy.hallgren@p5.reptile.ct.se (Tommy Hallgren) Subject: WANTED: Good multiplier for a 16-bit random number generator Date: Mon, 03 Apr 95 23:09:00 +0100 Reply-To: tommy.hallgren@p5.reptile.ct.se In-Reply-To: C. T. Nadovich's message Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: uugate 0.40 (SunOS 4.1.3) (Fidonet Gateway) C. T. Nadovich wrote: CTN> I like the additive generators, but I don't have a lot of CTN> RAM. Are there additive generators that don't have a large CTN> buffer requirement? How bad is something more like a CTN> Fibonacci series? Knuth says it's a classic "bad example". I got an old computer, a c64. :-) It has a very nice soundchip that has noisewaveforms. I'm not 100% sure but I think they used something like this. +-->| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | v v | | | | \ / +-----------------------------|XOR| That is, bit 0 = bit 6 XOR bit 7. And to get a new value you just shift all bits to the right = bit 7 is destroyed and bit 0 gets the XORed valued. Using more bits makes the pattern longer, using 16-bits should be more than enough for your need, I think. Warning, I haven't tried this, it may not work at tall. ;-) Tommy, liksom ( UUCP Dialup connection ) From: PS@chocolat.demon.co.uk (Paul Shirley) Subject: Re: Two Chucks Reply-To: PS@chocolat.demon.co.uk X-Posting-Host: chocolat.demon.co.uk Date: Mon, 3 Apr 1995 03:41:38 +0000 In article <1995Mar30.075954.3865@debet> snf_dw@debet.nhh.no writes: >In doing so, the marketing information that is spread has to >take issue with your claims that you need to do these things >in hardware. Plainly, the customer is not always right. >And the view of sales and marketing that is current in the >media and many industrial companies is not adequate to meet >that challenge. This is perfectly true... if your name is Intel. Otherwise the customer is king. People who forget that don't get far. -- Paul Shirley: SemiProfessional Coffee & Chocolate Taster From: snf_dw@debet.nhh.no Subject: Re: Jeff Fox's corrections, a question Date: 3 Apr 95 07:58:39 MET In article , jfox@netcom.com (Jeff Fox) writes: >> Chuck's approach does make it possible to make 100+ megahertz cpu chips >> that require fewer transistor than the 4004. > > I have been told that I may have confused the transistor count on 4004 > with that on 8008. I will check into it. My point was that multiple > execution units, 12 stage pipelines, branch prediction, and large > multimegatransistor on chip caches are not the only path to 100+ mip > operation. I believe that by 8008 things were already up to three > times the transistor count on MuP21. > > Jeff Fox I think your thoughts are now right on target. An exercise: (a) Is the MuP21 actually competing against the following (mythical) competitor ? Mythical competitor: Develops a device that takes the logic of the MuP21 (the hardware logic) and the logic of an application program for it (the software logic) and reduces the two together to a single gate logic diagram, boils it down more or less to the theoretical minimum, and then spits out a gate array chip that does the whole application in hardware ? (I.e. a minimal ASIC that is in practice the logically simplest way to implement the application.) Imagine such a competitor, scenarios, make up stories about it. (b) When you have completed part (a), ask yourself, is Chuck trying to do the same, but using a mixture of hardware and software instead of a pure hardware solution ? In particular, by alternately developing the hardware and software sides, is he developing and pursuing a minimization algorithm ? (c) Assume Chuck reaches/has reached nearly the minimum solution for a variety of interesting applications and is reasonably confiddent that most applications will yield rapidly to his minimization technique. What benefits does his approach have for product developers in industry, govt. research labs, universities, etc, when it is compared with the mythical device of part (a) above ? What disadvantages ? (d) Do you think what Chuck is doing is a route to the device of part (a), or do you think it is a somewhat separate line of development that is likely to have permanent benefits ? (e) Based on your answers to a,b,c,d above, is Chuck going to have to meet a short "window of opportunity" after which the device/system/method (your choice) he is designing would be out of date and no longer of any benefit ? Or is there a long term market for it (cf. Intel still in *their* market and developing it after 25 years)? (f) Do you still think Chuck is competing with Intel and Motorola and AMD etc ? Can you devise alternative mythical competitors different from the one in (a) ? Best wishes, David Walker snf_dw@debet.nhh.no PS: There is no answer that I know of to the above question yet, so this is not an exam. From: uho@informatik.uni-kiel.d400.de (Ulrich Hoffmann) Subject: Re: Arith Shift Date: 3 Apr 1995 10:38:46 +0200 In brownrj@cig.mot.com (Robert J Brown) writes: > Unfortunately, if we are really trying to eliminate *ANY* restrictions > on the computer architecture at all, then we need to consider even > more number representations than just 2's comp & signed mag. Sure I'm aware that 1's & 2's complement and sign/magnitude number representations are not the only choices you have. I wrote the 2/ definitions in relation to ANS Forth which explicitely restricts to these. It surely has its charme to think of other representations though. May be it would have been better to name shifts different from 2/ and 2*. The only path I can see, if this causes real trouble, is a replacement in the next standard turn making 2/ and 2* obsolescent and then freeing their names in another turn. Meanwhile every one not satisfied with the current names should start his programs with: : ASH ( n1 -- n2 ) 2/ ; : SHR ( n1 -- n2 ) 2* ; and continue using exclusively the new names in the application code... Ulrich -- Ulrich Hoffmann, Uni Kiel WWW: http://www.informatik.uni-kiel.de/~uho/ Institut f. Informatik, email: uho@informatik.uni-kiel.de Preusserstr 1-9, D-24105 Kiel, Germany Tel: +49 431 560426 Fax: 566143 From: duncan@nic.cerf.net (Ray Duncan) Subject: Re: Two Chucks (Intel answer) Date: 3 Apr 1995 21:51:38 GMT In article <1995Apr1.091710.3900@debet> snf_dw@debet.nhh.no writes: > ... they blew $1 million >on a single 1 minute ad that fell flat, at a major football game. If you are referring to the "1984" advertisement that kicked off the Macintosh sales campaign, I think this was one of the best $1 million ever spent. It didn't sell many Macs at the time, that is true, but it became an indelible part of the Apple public image and has been referred to, adapted, and parodied endlessly in the decade since. From: jfox@netcom.com (Jeff Fox) Subject: Re: gcc on stack machines, was Re: sstack Forth Date: Mon, 3 Apr 1995 19:21:23 GMT In article brownrj@cig.mot.com (Robert J Brown) writes: > >Incidently, changing the target machine for the GNu compiler >automatically permits cross compilers to be generated, and also >automatically supports C, C++, Module, Ada, and Fortran, with Pascal >soon to come. All these other languages are changes to the front end >of the gcc compiler. The back end determines the instruction set it >runs on; the front end determines the source language it compiles. I looked into writing a machine description for MuP21 for the gcc compiler. I felt sort of lost looking at 25megs of source code. But I decided that it was not really the way to go when I got to the warnings that: gcc is designed to run on a machine that can run GNU, and wants/needs at least 4 megabytes of ram. P21 has 2.5 megabytes of dram. gcc really likes byte addressing hardware, and will need extra work to implement on word addressing machines. But if you have a word addressing machine it will be easier if it has power of 2 wordsize. gcc really wants a large number of (general purpose) registers, which does not describe P21. I took one more look at the 25 megabytes of source and decided that the project was a little more than I was willing to do myself for no up front money. It also seemed to me that gcc was perhaps not the best way to approach a C compiler for MuP21. I have learned that there are a couple of retargetable C compilers that seemed like a better fit to P21. But I have not had the time or the money to take C any further there. Perhaps someone who has written a new target machine description for gcc could work around the documented warnings that scarred me off. I would like to have access to a C for MuP21, but I have not been in a position to write/buy/fund development of such a beast. Jeff Fox P.S. Can you tell me how GNU stands for Its Not Unix (recursive)? From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: questions about new ANS Forth Date: 03 Apr 1995 22:20:47 GMT In-reply-to: Bruce McFarling's message of Fri, 24 Mar 1995 18:43:21 -0500 >>>>> "Bruce" == Bruce McFarling writes: Bruce> On Fri, 24 Mar 1995, Julian V. Noble wrote: >> anton@mips.complang.tuwien.ac.at writes: >> >> [ stuff deleted ] >> >> [ some stuff from another poster, re: technology approaching >> miniaturization limits, to which Anton replied ] >> >> > Another myth. I have heard this since I came into contact >> with > computers. It has not happened yet. There's no guarantee >> that it won't > happen, but there's no guarantee that it will. >> >> Let me put this in perspective: feature sizes in thin layers >> will generally have 10^7 or so atoms, in the 0.5 micron >> technology. >> >> The constraint is then noise, or rather, statistical >> fluctuations that are tolerable in a usable system. Bruce> ... >> .... The ultimate limit will arise from this: to overcome the >> increased frequency of bit-errors in the individual switches, >> one must increase redundancy, use error correction, etc. When >> the rate of fluctuations gets too high (because of too-small >> feature-size), the amount of chip real-estate devoted to error >> correc- tion will reach the point of diminishing returns. At a >> rough guess this will happen somewhere between 0.05 and 0.1 >> microns. >> Bruce> But, of course, just as LSI led to VLSI led to Bruce> microporcessors led to these question about how many Bruce> transisters you put in a (factor x) square micron 8-)# , Bruce> the next step is parallel execution which may involve Bruce> simpler unit connected in a useful way. I think that when Bruce> you think about dataflow from inside a particular processor Bruce> which essentially wakes up and has to perform a task on the Bruce> information it finds at hand, and then pass it on to the Bruce> next chip, I think of a chip with modest dedicated static Bruce> RAM and/or EEEPROM, and switched access to the relevant Bruce> section of dynamic RAM in which the current dynamic data Bruce> lives. When you multiply processors, the proving out of Bruce> FORTH in the microcontroller environment becomes very Bruce> relevant indeed. Also, re the seperated stacks / single Bruce> stack FORTH thread, the operand stack lives out there in Bruce> dynamic RAM, and asynchronous operand and return stacks is Bruce> a critical advantage compared to third generation stack Bruce> frame languages like Fortran, C and Pascal. And of course, Bruce> when this gets going, its potential will eventually hit its Bruce> limits, at which time some other approach will break those Bruce> barriers, etc. etc. The limitations to a particular Bruce> approach to more processing power are never limitations on Bruce> more processing power in general: as in the pony express, Bruce> when this horse gets too tired, we'll just have to ride Bruce> another one. For those of you who are *REALLY* interested in this parallel stuff, I encourage you to get a copy of Danny Hillis' book "The Thinking Machine", which describes a dataflow fine grained parallel architecture on which a dialect of Lisp (Xector Lisp) is the primary language. I point out to you the previous posts I have made to this group showing the common heritage between Forth and Lisp, and the similar architectures of the machines designed to run these languages as their native tongue. Also very worthy are the papers by Jim Dorband of NASA on MPP Forth, a Forth developed for the Massively Parrallel Processor at Goddard Spaceflight Center in Greenbelt MD. This parallel machine was primarily designed to do image processing, and was developed by Goodyear Aerospace Corporation in Akron Ohio, now called Loral Defense Systems Inc. Akron. These 2 machines have different topological architectures, yet the MPP ran Forth very well, and the TM runs Lisp well, so it should also run Forth well, if only someone would implement a Forth for it. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: Eugen Leitl Subject: whatever happened to Novix & Co.. Date: Tue, 4 Apr 1995 21:22:03 +0200 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: ui22204@sun3 Hiya 4th.netters, whatever happended to those 4th chips (Novix' kin)? There was the RTX and some (obscure?) 32-bit 4th chips, but one never heard anything new since then... Is the market dead/no demand for it? With the emergence (and demand) for nanokernel OSses as Taos suitable for networks/WSI computers one should think small=beautiful should be en vogue again.. Doesn't threaded code provide the highest code density for the buck??? Am I so wrong/too ahead of the time? -- eugene From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: Forth to C Compiler/Preprocessor Date: Mon, 3 Apr 1995 18:17:41 GMT mckewan@netcom.com (Andrew McKewan) wrote: >Andreas P. Herren (herren@alcatel.ch) wrote: >: I am looking for a Forth to C compiler or preprocessor. Does anybody know >: anything about such a compiler. Are there such compilers in the public domain? >Look for the TIMBRE compiler by Rob Chapman. It translates Forth code >into C. And where can we get it? Under waht name? I'm curious since it sounds very interesting. Hans. From: jfox@netcom.com (Jeff Fox) Subject: Re: Jeff Fox's corrections, a question <1995Apr3.075839.3909@debet> Date: Mon, 3 Apr 1995 17:57:02 GMT In article <1995Apr3.075839.3909@debet> snf_dw@debet.nhh.no writes: > (a) Is the MuP21 actually competing against the following (mythical) > competitor ? > Mythical competitor: Develops a device that takes the logic > of the MuP21 (the hardware logic) and the logic of an > application program for it (the software logic) and reduces > the two together to a single gate logic diagram, boils it > down more or less to the theoretical minimum, and then > spits out a gate array chip that does the whole application > in hardware ? (I.e. a minimal ASIC that is in practice > the logically simplest way to implement the application.) > Imagine such a competitor, scenarios, make up stories about it. Of course you can't compete against a mythical competitor, but I know what you mean.... P21 was designed as a VLSI cad platform and although you could put OKAD in ROM that is advantage to being able to change the code, and you still need ram to hold a chip layout. P8 (in its present form) is a good example of the above however. The obvious alternative the client would have had for P8 would have been an ASIC. And in fact the P8 is an ASIC with on-chip rom. (no external ram) The reason that Chuck was interested in custom vlsi is that he has been down the gate array road. With gate arrays you have to pay for a lot more transistors than you need because the way you can interconnect them is severly limited, and the number is fixed before you start design. Also you cannot adjust size of each transistor to get higher performance or lower transistor count. In a sentance the reason Chuck moved from gate array to custom vlsi was to get an order of magnitude increase in performance and two orders of magnitude reduction in manufacturing cost. As with P8 many clients want 0 cost or 0 power or both. (the client for P8 wants to make a million of them and litteraly give them away) You can get much closer to 0 cost and 0 power with Chuck's approach than you can with a gate array ASIC. :-) > (b) When you have completed part (a), ask yourself, is Chuck trying > to do the same, but using a mixture of hardware and software > instead of a pure hardware solution ? In particular, by alternately > developing the hardware and software sides, is he developing and > pursuing a minimization algorithm ? Yes, Yes I would say so. > (c) Assume Chuck reaches/has reached nearly the minimum solution > for a variety of interesting applications and is reasonably > confiddent that most applications will yield rapidly to his > minimization technique. What benefits does his approach have > for product developers in industry, govt. research labs, > universities, etc, when it is compared with the mythical device > of part (a) above ? What disadvantages ? 0 cost and 0 power can open up markets, or make products possible that you just can't get to any other way. Or it may increase the profit margin. The disadvantage is that Computer Cowboys is not a big company with thousands of people waiting on the line to take your call and sell you products off the shelf. Chuck is seeking clients who are willing to get in at the early stage where there are admittedly more risks. Chuck has licensed OKAD, but at the moment he is the only person actually using it to design chips, this is a risk in itself. > (d) Do you think what Chuck is doing is a route to the device > of part (a), or do you think it is a somewhat separate line of > development that is likely to have permanent benefits ? Yes, but there is of course a benefit to programmable hardware in some cases. > (e) Based on your answers to a,b,c,d above, is Chuck going to > have to meet a short "window of opportunity" after which the > device/system/method (your choice) he is designing would be > out of date and no longer of any benefit ? Or is there a long > term market for it (cf. Intel still in *their* market and developing > it after 25 years)? Well yes and no. Windows are smaller and smaller. Chuck has had to learn a lot about vlsi design and fab processes through an iterative process that has taken more time than he expected. As he moves from 1.2 to .8 to .6 to .35 ... he will no doubt learn more things through trial and error since at the cutting edge there seems to be few people who can answer questions for him. Funding is an issue, if no one is paying him to do design work, he will have to spend his time seeking clients rather than working for them. If a client has no money for a prototype run this delays every project in the pipeline because answers are needed to move on. Big clients may get to cut in line at fab houses, or they can just buy the company to ensure they get every spot in line etc, or there can always be other delays. Still few are trying to take the high ground with a 0 cost 0 power approach. If a product is well thought out it should be able to maintain an advantage for a reasonably long window. > (f) Do you still think Chuck is competing with Intel and Motorola > and AMD etc ? Can you devise alternative mythical competitors > different from the one in (a) ? > >Best wishes, David Walker snf_dw@debet.nhh.no > >PS: There is no answer that I know of to the above question yet, > so this is not an exam. I think Chuck has made an effort to go in a different direction than Intel, Motorola, or AMD etc. I see very little effort or interest to go in the direction where Chuck is headed by those companies. History has shown that Intel feels they own the market that they are in. Sure Chuck could make a 200 mhz 8051 compatible, but Intel owns that design and is very well known for guarding their territory with legal action. Chuck does know better than to go head-to-head with a company like Intel when they have valid claims on territory and nearly unlimited resources. I think your last question deserves a separate answer. :-) Jeff Fox From: jfox@netcom.com (Jeff Fox) Subject: Re: Two Chucks Summary: Computer Cowboys Chip Design Service Menu Date: Mon, 3 Apr 1995 18:04:12 GMT Two years ago Chuck gave me the following menu. It is a bit old now, but gives a pretty good idea of what he is trying to do. ----------------------------------------------------------------------------- Computer Cowboys 1993 February Chip Design Service Computer Cowboys has validated unique design tools and is developing a library of macrocells. These cells can be combined to form a variety of chips. This variety is so great that it is unlikely an existing chip will suit a different application. Our business is to provide optimal chip designs and prototypes, quickly and inexpensively. We can combine several specialized processors on the same chip. This factors the problem onto multiple processors instead of interrupts and multiple tasks. The result is increased through-put and reduced complexity. Thus a typical chip will include: 1- a central processor for calculation 2- co-processors to move and format data 3- a memory processor to prioritize limited bandwidth. This approach reduces parts count, cost, power and size and improves reliability and programmability. Some of the option available are listed below. Each has a cost in area, bandwidth and power. The goal is to optimize some application- dependent cost/benefit equation. A reasonable chip has 10K transistors, an area of 5-10 sq mm and 28-64 pins. A chip project has 3 phases: Design and Layout 1.2 or .8 um CMOS CIF or GDS flattened output (2 Mbytes) 4-8 weeks Cost $10,000 - $20,000 Prototypes MOSIS or Orbit mosaic wafers 5-8 week fabrication Packaged in DIP or PGA Cost: $2,500-$10,000 for 12-24 parts Production Layout rescalable to fabricator's design rules Cost: perhaps $50,000 for 50K parts Royalty: perhaps 5% (volume dependent) It is important to remember that computers require software. The instructions of our processor are the primitives of the Forth high-level language. This provides the simplest and most efficient programming available. None-the-less, unless the application is extremely simple, a significant programming effort will be required. MENU MEMORY 1, 4, 16Mbit DRAM - optimized for page-mode access (15-50 ns) Multiple banks of DRAM Various cached or video DRAM SRAM (12-250 ns) PCMCIA memory card 2-8 power pins CPU Self-timed 50-200 Mips (memory limited) Word width of 16, 20, 24, 32, 64 bits Memory bus of 4, 8, 16, 20, 24, 32, 64 bits Instructions of 4, 5, 6, 8, 16 bits (1-16 instructions/access) On-chip data stack of 6, 8, 16, 32 words On-chip return stack of 4, 7, 15, 31 words 1 or 2 stack pointers into memory Register file of 1, 2, 4, 8, 16, 32 words On-chip ROM of 16, 32, 64, 128 words Multiply instruction format (10x10=20 bits, 8x8=8, 16x16=32, etc.) 1 or 2-bit multiply algorithm Divide instruction Square-root instruction IEEE Floating-point (5-10 Mflops) CRC instruction Pseudo-random-number generator Barrel-shifter Long and/or short jump instructions Conditional jumps on sign, carry, odd, zero Interrupt CO-PROCESSOR Serial Synchronous or asynchronous Half or full-duplex Multiple channels Rates to 150 Mbit/s 7 to 20-bit tokens Signal levels of 0-5V, RS232, RS422, optical Signal pass-thru Format or rate conversion Network protocol Bus Bus width of 8, 16, 32 bits Master or slave Rates to 50M words/sec On-chip or off-chip drivers Disk Interface Decompression Audio Digital of 16, 18, 20 bits Analog of 1, 4, 8 bits Sample rates of 6, 20, 44, 48 KHz De-compresssion MIDI input and/or output Video Digital or analog Pixels of 4, 8, 16, 24 bits External sync NTSC, RGB, LC output Signal mixing Analog Samples of 4-8 bits Rates from 0-4 MHz On or off-chip D-A, A-D, op-amp Digital 1-16 bits on-chip Off-chip latches/buffers 10-100 mA drive Programmable input/output External sync Watchdog Power monitor Activity monitor ------------------------------------------------------------------------------- This menu is two years old now, and should be updated with things Chuck has learned since then. For one thing until he has a macro-library with all of the above options already done and tested he will have to charge more for design services. Unless you own a foundry you are at the mercy of other peoples schedules. Both MOSIS and ORBIT recently had to reject prototype runs (which they say is a rare occurence), but this means if they tell you it will take an extra five weeks there is little you can do. MOSIS says they will soon offer a .6 micron fab service for even faster parts. Chuck now says the upper limit for 1.2 micron is 150mips, .8 micron is 300mips, and .6 micron 500mips. He has revised the upper limit for serial i/o from 150mbps to 1gbps. He has raised the speed of .8 micron analog i/o from 4msps to 14msps. But basically the ideas are the same. Jeff Fox From: ouversonm@aol.com (OuversonM) Subject: Re: Forth Programmers, DoExis Date: 3 Apr 1995 15:56:27 -0400 Reply-To: ouversonm@aol.com (OuversonM) If you are looking for Forth programmer, I suggest that--in addition to the measures you have already taken--you contact the Forth Interst Group and ask for assistance. They do not have a formal placement service, but have been able to assist employers several times over the past couple of years. You can contact FIG at: Forth Interest Group P.O. Box 2154 Oakland, California 94621 telephone: 510-893-6784 fax: 510-535-1295 From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Two Chucks Date: 3 Apr 1995 14:08:42 -0400 <1995Apr1.142911.3905@debet> In-reply-to: snf_dw@debet.nhh.no's message of 1 Apr 95 14:29:11 MET David Walker: I know the material I have deleted here was a plea for more and better documentation, including an interesting and useful statement of in what areas, and in what ways. And for a service phone (that would perhaps be less relevant if the documentation were better, and would it really help if it only uncovered further problems with the doc.?). Here's the problems that occurred, in chronological order: (0) in the release notes, I found a circuit diagram which had a "video out" pin on the MuP21 -- but there was nothing documented about how the processor manipulates video. (1) the manual which was supposed to be shipped with my order was not shipped. (2) the phone number I had was for ordering, and not for product questions. (3) I attempted to use a defunct email address to clear up the problem. I've since received a copy of the manual (as well as some other supporting documentation) and am quite happy with how things are progressing. It turns out that the MuP21 has a built-in video coprocessor, with its own instruction set, and a built-in memory coprocessor (with no instruction set, just a configuration register). Raul D. Miller From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Jeff Fox's corrections, a question Date: 3 Apr 1995 15:47:22 -0400 <1995Apr3.075839.3909@debet> In-reply-to: snf_dw@debet.nhh.no's message of 3 Apr 95 07:58:39 MET David Walker: (a) Is the MuP21 actually competing against the following (mythical) competitor ? Mythical competitor: Develops a device that takes the logic of the MuP21 (the hardware logic) and the logic of an application program for it (the software logic) and reduces the two together to a single gate logic diagram, boils it down more or less to the theoretical minimum, and then spits out a gate array chip that does the whole application in hardware ? (I.e. a minimal ASIC that is in practice the logically simplest way to implement the application.) Imagine such a competitor, scenarios, make up stories about it. Actually, this is documented in the programming manual. Basically, Chuck is interested in vlsi design and fabrication. However, the available tools were too slow and clunky to be useful (e.g. problems with parameter fitting, capacitive load is difficult to extract, the process was optimized for random logic rather than for microprocessor design, simulation is very slow, resulting designs waste an order of magnitude in chip real-estate, and an order of magnitude in speed, as well as several orders of magnitude in other arenas (such as man-years and power)). The point of the MuP21 was as much to validate Chuck's VLSI simulator as it was to be a host processor for this software. Unfortunately, this dual purpose created a problem which made the MuP21 rather slow to produce: when problems occurred, were they defects in the simulator or in the production process? It's rather difficult to examine the inside of a non-working chip to locate design defects. So, there's some rules checking in the simulator and a few new design constraints have been revealed (e.g. inductance from plastic packaging). David Walker: (d) Do you think what Chuck is doing is a route to the device of part (a), or do you think it is a somewhat separate line of development that is likely to have permanent benefits ? I'm not sure I understand this question. However, rephrased from my point of view, the question is something like: "Do you think that this effort is an attempt at optimizing random logic or do you think that there would be other benefits?" I trust I have addressed this issue. (e) Based on your answers to a,b,c,d above, is Chuck going to have to meet a short "window of opportunity" after which the device/system/method (your choice) he is designing would be out of date and no longer of any benefit ? Or is there a long term market for it (cf. Intel still in *their* market and developing it after 25 years)? Hmm.. I think I read somewhere that Chuck's hoping that some company which is interested in vlsi design will snap him up, based on this work. In other words, he's very aware that there are other issues that need to be dealt with but doesn't feel that he's necessarily the right person to deal with them. Personally, I'm seriously considering switching jobs so that I can be in the position of "snapping him up." [Of course, this shouldn't be my only reason for switching...] Raul D. Miller From: brownrj@cig.mot.com (Robert J Brown) Subject: Re: WANTED: Good multiplier for a 16-bit random number generator Date: 04 Apr 1995 19:22:23 GMT In-reply-to: wilbaden@netcom.com's message of Mon, 3 Apr 1995 02:40:56 GMT >>>>> "Wil" == W Baden writes: Wil> Gordon Charlton (gordon@charlton.demon.co.uk) wrote: : Press, Wil> Teukolsky, Vetterling and Flannery (Numerical Recipes in C, Wil> The Art : of Scientific Computing, Second Edition, Cambridge Wil> University Press, ISBN : 0-521-43108-5, page 276) are rather Wil> dismissive of the default C RNG. Wil> : Press et al give the distinct impression that they know Wil> what they are : talking about, and supply a broad selection Wil> of RNGs to fit most : applications. Wil> The key word of my last post (after I got the finger Wil> fumbles straightened) was `Lite'. This is what I thought the Wil> original poster was looking for. Wil> For heavy work I'd use Knuth's improved recommended Wil> subtractive RNG as given in _The Stanford Graphbase_. I have Wil> Forthed it for ThisForth in the sample code. Wil> : Recommended, if pricey. (I forget how much, it's one of Wil> those books that : does not have the price printed on it, Wil> which usually means "a lot!". I : think it was in the L40+ Wil> region) Wil> I have the first edition, which I think is good enough Wil> for me. I don't know why they needed a second edition to the Wil> C version -- couldn't they have gotten the bugs out from the Wil> Pascal version before releasing C? Wil> -- Procedamus in pace. Wil wilbaden@netcom.com If the CPU is tiny, and without a multiply instruction, you could also look into feedback shift register sequences as a source of random numbers. These are generated with shift and exclusive or operations instead of division, which is essentially shift and subtract. I believe that the software for FSR implementation is a bit less complicated, flow of control wise, than for regular integer division. Multiplication should be just as fast, however. -- --"Hear now my reasoning, and harken to the pleadings of my lips." [Jb 13:6]-- Robert J. Brown (Bob/Rj) rj@eli.wariat.org 1 606 567-4613 (voice & fax) Elijah Laboratories Inc; 201 West High Street; PO Box 833; Warsaw KY 41095 Consultant to Motorola: brownrj@cig.mot.com; Modeling the Methods of the Mind From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Two Chucks Date: 3 Apr 1995 16:19:05 -0400 <1995Apr1.142911.3905@debet> In-reply-to: rockwell@nova.umd.edu's message of 3 Apr 1995 14:08:42 -0400 Raul Miller: Here's the problems that occurred, in chronological order: (0) in the release notes, I found a circuit diagram which had a "video .. (1) the manual which was supposed to be shipped with my order was not shipped. Oops, got those out of order. Raul From: skip@taygeta.oc.nps.navy.mil (Skip Carter) Subject: Re: Forth to C Compiler/Preprocessor Reply-To: skip@taygeta.oc.nps.navy.mil (Skip Carter) Date: Tue, 4 Apr 1995 19:24:49 GMT In article , hbezemer@vsngroep.nl (Hans Bezemer) writes: |> mckewan@netcom.com (Andrew McKewan) wrote: |> |> >Andreas P. Herren (herren@alcatel.ch) wrote: |> >: I am looking for a Forth to C compiler or preprocessor. Does anybody know |> >: anything about such a compiler. Are there such compilers in the public domain? |> |> >Look for the TIMBRE compiler by Rob Chapman. It translates Forth code |> >into C. |> |> And where can we get it? Under waht name? |> I'm curious since it sounds very interesting. |> TIMBRE is available via anonymous FTP on taygeta.oc.nps.navy.mil in pub/Forth/Reviewed. It can also be found on WWW by looking at my Forth page. -- Everett (Skip) Carter Phone: 408-656-3318 FAX: 408-656-2712 Naval Postgraduate School INTERNET: skip@taygeta.oc.nps.navy.mil Dept. of Oceanography, Code OC/CR UUCP: ...!uunet!taygeta!skip Monterey, CA. 93943 WWW: http://taygeta.oc.nps.navy.mil/skips_home.html From: jfox@netcom.com (Jeff Fox) Subject: Re: Two Chucks Summary: fairly long and broad overview Date: Mon, 3 Apr 1995 18:13:02 GMT The question that is always most difficult to answer about what Chuck is doing is "What could you do with this technology?" Twenty five years ago many many people said "What could you do with a microprocessor?" They would say, "They are too slow to do anything useful, they can't run the software we are using now, they can't replace the mainframe we are using now. What could you possibly do with those things?" Well you could tell them "Because they can be cheap they will create a whole new niche. They could be used to make personal computers so that millions and millions of people could own their own computer. They could be used to replace non-programmable hardware solutions to achieve lower up front costs and much lower maintenance costs as upgrades are needed. They could be used to make consumer devices smarter and easier to use. They could be used in your desktop personal computer, your automobile, your tv, your oven, your toaster :-) , your kids toys." As a physics student when the microprocessor was invented I completely changed my opion of computers. I had really disliked punching holes in cards and waiting for results from batch runs on the mainframe to get results (and bugs) out of astrophysics programs. When I learned about the development of CMOS electronics and microprocessors I signed up for an electronics course in the physics department. I thought my teacher put it in a nutshell when he said, "with recent developments like the microprocessor we will see a trend where someday it will be cheaper to install a computer between two points than it will be to use a mechanical switch!" By the time I could afford my own personal computer in 75 the price had dropped to $1000. You could buy the latest, hottest CPU from Intel for $175. Not exactly down to the price of a $1 mechanical switch yet. Yet I still believed that my physics teacher had been right about the trend. Who really imagined twenty five years ago that micros would expand to the level that billions were made every year like they have? Today I can go out and buy the latest, hottest CPU from Intel, but it costs more than $175. (what does a P6 cost anyway?) But the price of mid range microcomputer still is around that 1K mark. (sure I know it is bigger and faster than the little old ones, hell, it is bigger and faster than the old mainframes!) As the micros have gotten faster so have the low end machines gotten cheaper. The high end micros have not gotten cheaper, just much much faster and more powerful. You still can't use a $4000 microprocessor in too many consumer grade embedded applications. But there is a market today for billions of cheap micros. What limits that market is not really cost. It is performance. Can a $4000 micro do things that a $2 micro can't do? Sure like tackle problems that require 100,000 times more computing power. Can a $2 micro do things that a $4000 micro can't do? Sure like tackle consumer applications to the tune of billions of units a year! So this brings me to the question I hear so often. "What could you do with a $2 micro that was 10,000 times faster than the one I have now?" "Make a list of exactly what it could do!" Even when you explain your ideas in detail of the almost innumerable things that you could do with such a device the next question usually is, "Will I be able to run all the software I have now on it without any changes?" Fortunately there were people twenty years ago who realized that not running mainframe software was an advantage not a handicap. There were people who realized that there were opportunities to develop products that would be better and cheaper because they could use these inexpensive micros. It is hard to imagine what is really possible. Many science fiction writers thirty years ago thought it would take hundreds of years to get our computers to where they are today. What will machines that are smarter than we are be able to do? This is a hard question to answer. What could you do with a 1 billion instruction per second $1 computer? This is also a hard question to answer. I think it will take a lot of different people with different knowledge who have done different market research to even begin to answer a question like that. The most popular micros today are much more highly integrated than those of the past, but only moderately faster. 8051 or 68hc11 instruction sets look alot like things did twenty years ago. Clocks have gone up a little. Most of the effort has gone into making desktop mainframe computers, not embedded supercomputers. For most people on this planet (and many in this country) the idea that $1000 micros are cheap, that memory is cheap, that it doesn't matter if software is wasteful etc etc is just not very realistic. As long as there is a big market for screen savers or while people can sell Pentium PCs to retired people as a good way to balance their checkbook these things will continue to have momentum. The big corporate market to pad budgets has shifted from unneeded mainframes to unneeded PCs. (complete with all the latest unneeded screen savers) We have seen big changes in the computer industry in the last twenty years, but it is still only the beginning. No one can say where it will go or what will really be possible. The medium is the message. Writing didn't make human speech disappear, but it did replace thousands of years of oral history with something new. How could people have known what it meant for human evolution? Intelligent media has already surpassed our written record. Where will this lead us, what will it make possible? These are not questions that anyone can answer in a definitive list today. I can't answer questions like that, I don't think anyone can. Jeff Fox Ultra Technology From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: gcc on stack machines, was Re: sstack Forth Date: 3 Apr 1995 16:50:50 -0400 In-reply-to: jfox@netcom.com's message of Mon, 3 Apr 1995 19:21:23 GMT Jeff Fox: I looked into writing a machine description for MuP21 for the gcc compiler. I felt sort of lost looking at 25megs of source code. But I decided that it was not really the way to go when I got to the warnings that: ... Most of the work that gcc does is to make efficient usage of a bank of registers. [It doesn't matter so much that gcc is big, if you can live with cross compiling.] lcc is probably better for the MuP21. Or, maybe writing one from scratch would be better. The kinds of optimizations you need to do on the '21 are instruction scheduling, data flow optimization through the stack, and perhaps page access. If any of these are "new enough" you might be able to convince some academic types to tackle the problem. Jeff Fox: P.S. Can you tell me how GNU stands for Its Not Unix (recursive)? Try "GNU's Not Unix" Raul D. Miller From: erather@aol.com (Erather) Subject: Re: Code for ANS "(local)" for F-PC? Date: 3 Apr 1995 14:46:00 -0400 Reply-To: erather@aol.com (Erather) tbushell@fox.nstn.ns.ca (tbushell) writes: >Can anyone send me or point me to an implementation of the ANS Forth >Locals Word set? Couldn't find it on Taygeta or the site in Portugal. > >There was a nice implementation of named local variables in SIGPlan >Notices for Forth a couple of years back, and I'd like to try it, but >it uses "(local)". The TC assumes that implementation of (local) will require intimate knowledge of the internals of the system, and therefore should be provided by the system implementor or someone with this knowledge. That is, the implementation of (local) itself is unlikely to be (and probably should not be) itself written in ANS Forth. The approach you describe from SIGPlan Notices (although I haven't actually seen it) is the sort of thing we would expect: an application-level implementation of locals using this standardized "hook." If there is sufficient market demand for (local), implementors will provide it! Elizabeth D. Rather "Forth-based products and FORTH, Inc. services for real-time 111 N. Sepulveda Blvd. Suite 300 applications since 1973" Manhattan Beach, CA 90266 800-55FORTH -- 310-372-8493 310-318-7130 FAX From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: Return stack shenanigans Date: 3 Apr 1995 22:47:01 GMT In <3lc2eu$3lf@hq.pu.ru> gml@ag.pu.ru writes: >> I find this very confusing. No doubt with practice I'd learn to see it >> easily. It looks like the first 0..0F leaves 0 1 ... 0F on the stack >> and 16 returns, and the 2nd 0..0F does the same. >No. 0..0F calls the residue of .chars' code 16 times. It works - I tried >it before sending. I figured that out, eventually. I didn't doubt you -- it was just hard for me to read. >> >This technique is not the only good thing that may be done using the >> >return stack manipulations. >> What are some of the others? >B.J.Rodriguez' BNF Parser (1983, published in SIGForth (1991?)) and >"Rules Evaluation through Program Execution" (1990?) , G.Charlton's I wasn't looking for backup that there were such things, so much as some sort of idea about patterns among the applications. here's my problem -- Using your technique, I might do CREATE LATER 1000 CELLS ALLOT VARIABLE LAST-LATER LAST-LATER OFF : SAVE-FOR-LATER HERE LAST-LATER @ CELLS LATER + ! 1 LAST-LATER +! ; IMMEDIATE and then I could put SAVE-FOR-LATER anywhere at all in any routine, and while it compiles it saves an address to come back to later. If what stays on the return stack isn't addresses but something else, it can probably still be done -- this is just my first approach. We wind up with an array of entrance points inside routines. We can say something like 1000 RND CELLS LATER + @ ENTER in one routine and land anywhere in the middle of some other routine. This is dramatically more unstructured than GOTO. This may be the ultimate in unstructured programming. It looks potentially useful, but I'd like to see some sort of structure put on it to help me keep track of what's going on. So if it isn't enough to provide special commands to do your data-flow structures, what else should we provide? From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: Stack manipulations Date: 3 Apr 1995 22:51:46 GMT In tanksley@san_marcos.csusm.edu (Billy Tanksley) writes: _I didn't make them anonymous. I made the stack diagram be the name. _So --32} is the same as 2DROP _and so on. >I mean in the technical sense: the code sequence " ' --32} " will give an >error, thus they are anonymous. Or did I misread your specifications? I didn't make that clear enough. No, --32} would become just another word in the dictionary, a redefinition of 2DROP . The point was to be able to make any stack command efficient, and use whatever seemed most useful. >I'm also thinking of changing the syntax to >S: DROP ab--b >or >S: DROP 01--1 >In other words, inputs as well as outputs are specified (and the redundant >'}' is ommitted). That could be good. I like having the smallest number on top, but that's an esthetic thing. I started out with (-####) which was part of a stack diagram, and then got away from that. If you give peculiar names to the commands then it doesn't much matter how your syntax goes after the S: since it only gets used a few places. If the commands get scattered through the code then it matters a lot and I thought it was very good for them to look like stack comments -- the question is how best to do that. _downhill from there -- the less I use the word the less intuitive it _looks. 8-) >Well, perhaps the reason you don't use them is that you see them as >noise-- if you were "forced" to find a name for each one you developed >rather than being able to refer to them as --6754 :) perhaps there would >be more sense to their use. I dunno. Try this test -- how intuitive is the word if you don't already know it? SNIP SNAP TRUP PUNT PIT TUG GRAB TILT PAT PUTTER AWAY MROT DROAP DRAP DRIP FLING FINESSE FLIP HAUL NUP TROT UROT CUT CLIP CHURN SLIT CHUCK CHOP SET DSET POKE -POKE FLOP SLIDE SLAP TIP DIG UNDER STAB STUB INSERT LOP Can you even tell which words have really been used as stack words? My method is much clearer. However, it doesn't give any way to tell whether a particular stack word has already been compiled into your particular dictionary. If they have special names, you at least notice when you see one that's unfamiliar. From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: questions about new ANS Forth Date: 3 Apr 1995 22:54:23 GMT In brownrj@cig.mot.com (Robert J Brown) writes: >Would it be possible, for instance, for you to do the same sort of >analysis on the probability of noise effects on the proper functioning >of chromosomal reproduction during meiosis and mitosis? The >structures involved are considerably smaller, if I am not mistaken, >yet life has successfully managed to go on processing this kind of >information for considerably longer than electronic digital >semiconductor technology has ;) Something like this has been done. The probability of errors during replication is about 10^-4/base-pair. In an organism with about 10^8 bases, that's 10,000 errors. These errors are corrected using a variety of mechanisms. Sometimes the DNA polymerase detects a recent error and backs up, destroying its recent work, then continues. There are a lot of repair mechanisms. Some of them involve comparing the other replicated strand or even the other homologous chromosome and copying from the correct version. DNA gets chemically modified with methylation and such, and so the old strand (which is more often correct than the new one) will stay modified while the new strand waits to be modified -- so if they're different it's the new strand can be preferentially changed. The result is that the whole genome can be copied with an error rate of about 0.5% per genome per generation. This process takes 10 minutes to 2 hours, depending on species. Nevertheless it's been estimated that the DNA helix rotates at somewhere between Mach 1 and Mach 3 during the process. Only faithful replication is involved, the precedures that change DNA on purpose are slower still. There are probably biochemical approaches that might yield fast computations. Doing it with genes would take a tremendous amount of development work that mostly hasn't been started. I doubt we'll see it in the next 10 years. From: skip@taygeta.oc.nps.navy.mil (Skip Carter) Subject: Forth Scientific Library status Reply-To: skip@taygeta.oc.nps.navy.mil (Skip Carter) Date: Mon, 3 Apr 1995 22:28:37 GMT Status of the Forth Scientific Library Project 2 April 1995 Participants: chrismc@eecs.umich.edu Chris McCormack erather@aol.com Elizabeth Rather ghaydon@forsythe.stanford.edu Glen Haydon JimBrakefd@aol.com Jim Brakefield jvn@virginia.edu Julian Noble skip@taygeta.oc.nps.navy.mil Skip Carter richard.beldyk@mecheng.fullfeed.com Richard Beldyk tstark@cix.compulink.co.uk Tony Reid-Anderson chergr@lure.latrobe.edu.au Richard Rothwell NLeonard@aol.com Leonard Morgenstern Gus_Calabrese@onenet-bbs.org Gus Calabrese ac021@cleveland.Freenet.Edu Gary Bergstrom 74354.2532@compuserve.com Munroe C. Clayton warren@ross.com Warren Bean chihyu@starbase.neosoft.com ChihYu Jesse Chao cgm@utphya.panet.utoledo.edu Charles G.Montgomery mhx@iaehv.iaehv.nl Marcel Hendrix mumwp1@uxa.ecn.bgu.edu Michel W Pelletier gordon@charlton.demon.co.uk Gordon Charlton andrejs@crl.com Andrejs Vanags mlists@digalog.com Stephen Sjolander penev@venezia.rockefeller.edu Penio Penev johns@oslonett.no John Svae fabrice.pardo@bagneux.cnet.fr Fabrice Pardo znmeb@plaza.ds.adp.com M. Edward Borasky reaves@mlml.calstate.edu Richard Reaves Mail to: scilib@taygeta.oc.nps.navy.mil will be automatically distributed to all the participants listed above. Code contributions: Reviewed and accepted: (reviewed code is available via anonymous FTP at taygeta.oc.nps.navy.mil/pub/Forth/Scientific or via WWW at http://taygeta.oc.nps.navy.mil/scilib.html) 1. Real Exponential Integral (ACM #20) Skip Carter 2. Complete Elliptic Integral (ACM #149) Skip Carter 3. Polynomial evaluation by the Horner method Skip Carter 4. Logistic function and its first derivative Skip Carter 5. Cube root of real number by Newton's method Julian Noble 6. Solution of cubic equations with real coefficients Julian Noble 7. Regula Falsi root finder Julian Noble 8. Fast Hartley (Bracewell) Transform Skip Carter (with supplemental utilities and tests by Marcel Hendrix) 9. Aitken Interpolation (ACM #70) Skip Carter 10. Hermite Interpolation (ACM #211) Skip Carter 11. Lagrange Interpolation (ACM #210) Skip Carter 12. Forward and Backward divided differences Skip Carter 13. Newton Interpolation with Divided differences (ACM 168 & 169) Skip Carter 14. Factorial Skip Carter 15. Shell sort for floating point arrays Charles Montgomery 16. Exponentiation of a series (ACM # 158) Skip Carter 17. Polynomial and Rational function interpolation and extrapolation Marcel Hendrix 18. The Gamma, LogGamma and reciprocal Gamma functions Skip Carter 19. Adaptive Integration using Trapezoid rule Julian Noble 20. Parabolic Cylinder functions and related Confluent Hypergeometric functions Skip Carter 21. Special Polynomial (Chebyshev, Hermite, Laguerre, Generalized Laguerre, Legendre and Bessel) Evaluation Skip Carter 22. Conversion between calendar date and Julian day (ACM 199) Skip Carter 23. R250 (also minimal standard) Pseudo-random number generator Skip Carter 24. RAN4 Pseudo-random number generator Gordon Charlton 25. Finite segment of Hilbert Matrices, their inverses and determinants Skip Carter 26. FIND nth element of an unsorted array (ACM #65) Skip Carter 27. Gauss-Legendre Integration Skip Carter Currently being reviewed: Rootfinder (ACM #2) Skip Carter Stochastic Differential Equation solver (scalar version) Skip Carter Box-Muller transformation (polar form) Skip Carter Quadratic Equation solver Skip Carter Fast Walsh Transform Skip Carter Four methods for Direct Fourier Transforms Skip Carter Radix-2 Fast Fourier Transform routines Skip Carter (5 versions one, two, and three butterflies, tabular, non-tabular) Complete Elliptic Integral of the first kind (ACM #55) Skip Carter Complete Elliptic Integral of the second kind (ACM #56) Skip Carter Complete Elliptic Integrals of 1st and 2nd kinds (ACM #165) Skip Carter Tridiagonal solver, using the Thomas algorithm Skip Carter First derivative of a function by Richardson extrapolation Skip Carter Regular spherical Bessel functions jn(x), n=0-9 Julian Noble Reversion of Series (ACM # 193) Skip Carter LU Factorization of square matrices Skip Carter Back-substitution solution for LU factored linear systems Skip Carter Inverse of an LU factored matrix Skip Carter Determinant of an LU factored matrix Skip Carter 4th order Runge-Kutta solver for systems of ODEs Skip Carter Contributed but not reviewed: Quasi-Random number generation Skip Carter Monte Carlo Row inverse (ACM 166) and related algorithms Skip Carter Telescope 1 (ACM 37) (reduction of degree of polynomial approximations) Skip Carter Telescope 2 (ACM 38) Skip Carter Coefficient Determination (ratio of polynomials) (ACM# 131) Skip Carter Weibull PDF and Weibull Random variables Skip Carter Linear and Circular (discrete) Convolution Skip Carter Complex math operations (magnitude, power, multiplication and division) Skip Carter Polynomial transformer (ACM #29) Skip Carter Jacobian elliptic functions Skip Carter Nonlinear transformation of series (SHANKS) (ACM #215) Skip Carter Solution of linear Fredholm equation of the second kind Skip Carter Solution of a set of Volterra equations of the second kind Skip Carter Square root of a square symmetric matrix Skip Carter Adjustment of Matrix inverse when an element is perturbed (ACM #51) Skip Carter Eigenvalues and Eigenvectors of a real symmetric matrix Skip Carter Basic arithmetic and conversions for rational numbers Gordon Charlton Permutations and Combinations Gordon Charlton 16-bit Cyclic Redundancy Checksums Gordon Charlton Gauss-Seidel iteration solution to linear systems Skip Carter Gauss probability function Skip Carter Solution of banded linear systems Skip Carter Tools to use polynomial interpolation with a large table Marcel Hendrix Basic statistics of a floating point array Skip Carter Simulated Annealing using Cauchy cooling Skip Carter (weighted) least-squares projection onto orthogonal polynomials Skip Carter -- Everett (Skip) Carter Phone: 408-656-3318 FAX: 408-656-2712 Naval Postgraduate School INTERNET: skip@taygeta.oc.nps.navy.mil Dept. of Oceanography, Code OC/CR UUCP: ...!uunet!taygeta!skip Monterey, CA. 93943 WWW: http://taygeta.oc.nps.navy.mil/skips_home.html From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: Two Chucks Date: 3 Apr 1995 22:59:33 GMT In jfox@netcom.com (Jeff Fox) writes: Jeff, I want you to understand that David Walker is on your side, and so am I. When he offers you advice, it isn't intended as a way to hurt your feelings. For that matter, Elizabeth Rather has offered useful information. Her relationship with Chuck is long and complex and it might not be 100% predictable by an outsider that she'd offer help, and she has done so. In this context, I want to tell you that you have monumentally missed the point. You're trying to deal with a collection of people who don't speak your language, and a couple of bilingual friends have been giving you help, and you just aren't accepting it. Let me try to spell some of it out (from my own limited perspective, translating the translators): For all I know this guy Ron Talbott is just an isolated nutcase who torments you for the fun of it. But maybe he's the competition. He says he is; he likely thinks he is. Of _course_ he'll try to discourage you and make you look bad in front of potential clients on the net. If that's so, (and for all I know it isn't, maybe he just likes to pretend he knows something about computers) then your interpretation of his remarks is completely offbase. Every time he slams you, he's telling you "Jeff, you guys are still dangerous enough that I'm paying attention to you." If somebody came on and said "I don't know much about chip design but I got a book on it from the library and I want to build a CAD system with Visual Basic as soon as I learn VB and can anybody help me get development money" do you think he'd bother to insult them? >The question that is always most difficult to answer about what >Chuck is doing is "What could you do with this technology?" >Twenty five years ago many many people said "What could you do with >a microprocessor?" They would say, "They are too slow to do >anything useful, they can't run the software we are using now, they >can't replace the mainframe we are using now. What could you >possibly do with those things?" Your mission, should you choose to accept it, is just that. Or more specifically, you need to answer the question of one first person with money, "How can I reliably make money in the next 9 months by investing in this?" Or if you won't do it, you need to find somebody who will. You need to somehow create the same sort of interactive interface with an investor that Forth gives you with hardware, so you can quickly learn what he wants from you. If your compiler gave you the message PROFIT ? you'd quickly find the missing semicolon or the undeclared variable or whatever. You wouldn't complain that the compiler lacked the vision to see how wonderful your program would be once it compiled. If you want investment money, you have to learn the language and speak it well. Or find someone to do it for you. If that doesn't happen, you won't get development money. Maybe Dr. Ting will invest his retirement money in the project. Any chance of selling the results? It will be a few years down the road by that time. You've sold a few development boards, right? It wouldn't surprise me at all if 6-12 of those boards have gone indirectly to companies that hope to outcompete you. Imagine this: 2 years from now Intel announces a new series of chips that sound suspiciously like Chuck's stuff. They run a tenth as fast, and cost $10 each. They're carefully crippled so they can't be used as main CPUs for big computers. And they're carefully designed to be incompatible with Chuck. Languages? They have a $10,000 development system built around a proprietary Tiny-C. The series of chips is labeled the RT series, for Ron Talbott. None of them are ready yet, and won't be ready for another 2 years. But any time Chuck tries to sell something the question comes, "Is it RT-compatible? No? Well, maybe we'll get back to you." By the time the RTs get to market, Chuck has something 100 times faster that could sell for ten cents apiece. And he can't sell it, what he has is a cheap knock-off of the Intel RT and nobody trusts it. Ron leaves you one last message, "Jeff, it's been a pleasure doing business with you. Be sure and tell me if you get involved in another project." OK, Chuck just wants to do research. Great. If he found the right company, he could take his P21 and OKAD and a resume and get a good job, and they'd let him play with really nice hardware. They'd own the result, but he'd get to do his research. If Chuck can't find somebody to come up with a game plan, that's what he ought to do. From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: Two Chucks Date: 3 Apr 1995 23:02:03 GMT In jfox@netcom.com (Jeff Fox) writes: Jeff, remember that I'm on your side too. If I tell you you're being stupid it's because I think you can do better and I want you to do better. David and others told you at some length that selling on low price doesn't work well in the short run. But that's what you're still stressing! It's as if you didn't hear them. You ask what could be done with a penny processor. My immediate thoughts: A mousetrap. It has 2 or 3 little cheap microphones and it listens carefully, and when it hears a mouse going by (not a child or a kitten or even a large cockroach, unless you want to trap cockroaches too) it kills it. A kite controller. You put 5 or 6 of them on a kite and they control various little flaps and things. They interpret your commands that come modulated over kitstring vibrations. People can have kite-downing contests like the chinese ones, but different. A burglar alarm. Again, little speakers. The things can be in all the hallways and along the edges of rooms about 2 feet apart and they listen and report noises. The house's central computer interprets the result to keep track of who's where. Or you could have a network of the sensors do it. A dishwashing detergent dispenser. You plug it into the faucet, and when you want to wash dishes it monitors how much soap is there and adjusts it for you. A paintball burster. People who play paintball say the things hurt when they hit a sensitive place or hit at short range. Each paintball could have its own little processor that monitors when the paintball is about to hit something and breaks it an instant before. Painless. A birdfeeder. It senses squirrels and keeps them away. (Or traps them, for dinner. Yum.) The thing is, when I imagine something that isn't too far out, the cost of the processor is a small part of the total cost. Why use new untried technology to save a few pennies when you can use trailing-edge instead and the bugs are already worked out? And when I imagine things where the processor is a major part of the cost, it isn't anything I'd consider investing in this year. Take the paintball thing -- it looks almost impossible without something advanced, but do I really believe it would sell? Not enough to put a lot of money in upfront. People can't afford to invest in projects where cost is such an issue that nobody but Chuck can do it. They put money into things that they hope will give a big profit. A great product that people will pay a premium for, that's the ticket. If they put a $175 Pentium in it along with $1325 of other parts, they hope to make a lot off of it. If they aren't sure they can break even and you offer them a penny chip so they can make $175 (until the market price goes lower), that isn't a very good deal. If you talk about costs coming down, that's exciting, in the long run. You're excited, I'm excited. Tell an investor about it over drinks and he might get excited too. It may affect his long-term stock market choices. It won't get him to buy into Chuck this year. You need a use that's valid before the Revolution. Otherwise it will be somebody else's Revolution and they won't do it right and they'll name it after Ron Talbott. You need omething where you can offer better performance, easier. If it's a high-volume application you desperately need a second source. If it's a low-volume application then development speed and development cost are both vastly more important than chip cost. But maybe something else is more important still. You need a way to get people to tell you what they think their problems are, so you can give them solutions. If you can tell them what their problems _really_ are so they _believe_ you, that's even better. Your P21 simulation looks good -- could you find a way to make quick simulations to persuade investors? "Here's what you say is going on. Here's another way to look at it. See, this way includes what you said and it has these extra things, do they look realistic? Look what happens if you use our solution...." But this last isn't a translation from people who know, it's just my idea. Maybe technical fixes are beside the point. Talking business language, understanding what people mean when they talk it, that's central. Help them solve their short-run problems. Their short-run problem is not processor price. From: jfox@netcom.com (Jeff Fox) Subject: Re: Two Chucks (Intel answer) <3lpqla$904@news.cerf.net> Date: Mon, 3 Apr 1995 22:35:19 GMT In article <3lpqla$904@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes: >In article <1995Apr1.091710.3900@debet> snf_dw@debet.nhh.no writes: >> ... they blew $1 million >>on a single 1 minute ad that fell flat, at a major football game. > >If you are referring to the "1984" advertisement that kicked off >the Macintosh sales campaign, I think this was one of the best >$1 million ever spent. It didn't sell many Macs at the time, that >is true, but it became an indelible part of the Apple public image >and has been referred to, adapted, and parodied endlessly in the >decade since. Are we supposed to forget that image with the new Apple/IBM alliance? :-) It kind of makes you wonder.. Jeff Fox