Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!purdue!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma From: toma@tekgvs.LABS.TEK.COM (Tom Almy) Newsgroups: comp.lang.forth Subject: Re: Implementation dependence Keywords: swizzling implementation Message-ID: <5750@tekgvs.LABS.TEK.COM> Date: 14 Aug 89 16:40:02 GMT References: <4617@sdcc6.ucsd.EDU> Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 96 In article <4617@sdcc6.ucsd.EDU> ir230@sdcc6.ucsd.EDU (john wavrik) writes: >The point is that if the order for 2@ and 2! are "implementation dependent", >the programmer can write selectors (albeit slower than those if the order was >known). But the order for 2@ and 2! are not implementation dependent, they are specified in the Standard! LMI implemented them "wrong" to better match the hardware, and then corrected their mistake. >Some people go for a lifetime without needing to know the order in which pairs >of numbers are stored in memory, or how double precision numbers are stored. These people never had to write applications that transfer binary data to other applications that run in different machines or use different compilers, which was my original complaint. >But others write "*large*" applications in which this information is used. >There is a lesson to be learned here: many Forth programmers use their >knowledge of how Forth is implemented in their work. They get "burned" when >someone later decides that the memory representation of a data object should >be different. As I say, this decision (on implementing 2@ and 2!) wase contrary to the standard. The fix (once I found the implementation error) took less than a minute to implement. >TRUE should be -1 instead of 1, EXPECT should no longer leave a >0 at the end of input, ' should refer to the CFA instead of the PFA, etc. I can virtually guarentee that any non-trivial program written in FIG Forth would have required major changes for 79-Standard, and still more major changes for 83-Standard. I never rely on TRUE returning a certain value because of readability of the resulting code, but: 1. Expect used to return a zero delimited string (as you mentioned) but now sets a variable to the size of the string. Since the variable did not exist before, there is no way to be portable. 2. The change to ' breaks all code, especially when you consider that the 83 standard removes the state smart action and adds a new word [']. 3. Every standard defines DO LOOP differently such that it is only portable if the arguments are non-negative and not equal. This is not a pleasing limitation. 4. You can't make use of vocabularies because the fig definitions <> 79 Standard <> Laxen&Perry F83 <> 83 Standard, the latter of which is so vague that any of the preceeding, as well as STOIC which has a vocabulary stack, meet the standard. 5. In converting from FIG, VARIABLE and CREATE changed, and DOES> is used differently. 6. Don't even think of using CODE words! 7. There is no such thing as portable code (nor a language that guarentees it!) > They get cremated when an important aspect of implementation becomes >"implementation dependent". Yet my *large* application has been used on Z-80, 8086 CP/M, MS-DOS, VAX, and 68000 systems using Forths meeting FIG, 79, and 83 Standards. All I ask is that the "standard" is well defined, and that if the Forth I buy claims to meet a standard, it actually does. >In the past we enjoyed total knowledge of how Forth works -- and achieved >powerful (and portable) results by exploiting this knowledge. Every time a >feature of implementation is removed from the Standard it must (to retain >power) be replaced by words to replace the missing knowledge. Of course no one >can really anticipate the implementation features that others will find >useful. The real question is whether anyone really wants a collection of >auxilliary words to replace some simple information about the implementation. >Charles Moore supplied a model of a (virtual) computer that can be implemented >on ANY real machine. The Forth language is (semantically) an extensible >assembly language for this virtual machine. Some would like this virtual >machine, as the Cheshire Cat, to fade away -- leaving only its Reverse Polish >smile. I can't tell what you really want. Having the virtual machine is saying "implementation independent". This is what I want. But you still need functions to access the hardware and OS -- and these will always be "implementation dependent". In my case, 2@ and 2! should always work the same since this is part of the virtual machine model. On the other hand, D@ and D! fetch and store in a "machine dependent" fashion. These words are only needed when it is necessary to communicate with hardware or other programs, 2@ and 2! can be used at all other times, which will insure portability (well, it should...). At it is possible that 2@ and 2! will be *slower* than D@ and D!, but that's just fine. Note that correctly implemented Forths for the 68000 must go through contortions to do @ and ! when not at a word boundary, but this is necessary for portability! Tom Almy toma@tekgvs.labs.tek.com