ir230@sdcc6.ucsd.EDU (john wavrik) (08/12/89)
Tom Almy <toma@tekgvs.LABS.TEK.COM> writes: > Not necessarily so, and the reason LMI added D@ and D!, was that they > changed 2@ and 2! from an earlier version so as to match the Intel preferred > order (oposite from the Forth standard). This broke my code. I have a > *large* application which used 2VARIABLEs, and 2@ and @!, to hold x,y > coordinate points. I rely on "@" getting the Y value and "WSIZE + @" > getting the X value. So the order is important! > Good point. My problem would have been solved had there been something like > 2A@ and 2B@ for the "A" and "B" elements of the pair! > Of course you are right from an architectural point of view. The preferred > order must be inferred from the "little-endian" architecture. But when > interfacing with other languages, 32 bit numbers had better be stored with > least significance in the lower addresses. This is also important if you > intend to access the data in the 80386 -- I have been "burned" by several > Forth programs that 32 bit data via 2!, and then my 80386 native program has > to swizzle the data to read it. Ugh! -------------------------------------------------------------------------- IMPLEMENTATION DEPENDENCE When someone posts a message it is not only a reply to a specific prior message, but also to all the other sources (comments, articles, conversations, etc.) which have impinged on the sender. This message may, therefore, not really be a response to Tom Almy's. There have numerous such "sources" in the Forth community whose input can be summarized by "If X and Y are two processors and something can be done a bit faster in one way on X and in another way on Y, we should make the thing 'implementation dependent' and not specify how it is done in the Standards". If someone stores a pair of coordinates by <x> <y> POINT 2!, one can always define selector functions x-coord and y-coord by : x-coord 2@ drop ; : y-coord 2@ swap drop ; (Thus POINT x-coord will retrieve the x-coordinate no matter what order the pair is stored in memory). For double precision numbers there is, unfortunately, no simple way to write selectors for the high and low word without knowing the order in which the component words occur on the stack or in memory. 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). In the case of double precision numbers, however, if the order is declared to be "implementation dependent", there MUST be selector functions provided. 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. 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, 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. They get cremated when an important aspect of implementation becomes "implementation dependent". 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. There is more to power in a computer language than the execution speed of its code. There may be merit in suggesting that a bit of "swizzling" on the part of the implementation is a worthy tradeoff for preserving a simple and uniform structure. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
toma@tekgvs.LABS.TEK.COM (Tom Almy) (08/14/89)
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
peter@ficc.uu.net (Peter da Silva) (08/15/89)
In article <5750@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > 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! No they don't, any more than correctly implemented forths for the PDP-11 do. If you depend on @ and ! working at arbitrary boundaries, then your program is machine-dependant. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
toma@tekgvs.LABS.TEK.COM (Tom Almy) (08/16/89)
In article <5693@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <5750@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >> 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! > >No they don't, any more than correctly implemented forths for the PDP-11 >do. If you depend on @ and ! working at arbitrary boundaries, then your >program is machine-dependant. If you view Forth as implementing a virtual machine, then the implementation must allow @ and ! at odd addresses. The 83 Standard states that the argument to @ and ! is "addr", where the definition of "addr" is a 16 bit unsigned integer (range 0..65535). So, again, a correctly implemented Forth for the 68000 (or PDP-11) must handle @ and ! at odd addresses to meet the standard. No one said it had to be fast, just portable. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
peter@ficc.uu.net (Peter da Silva) (08/16/89)
In article <5769@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > If you view Forth as implementing a virtual machine, then the implementation > must allow @ and ! at odd addresses. The 83 Standard states that the argument > to @ and ! is "addr", where the definition of "addr" is a 16 bit unsigned > integer (range 0..65535). Then might I respectfully note that the 83 standard sucks? To begin with, on a cell-oriented machine that same address space would have the range 0..32767. Secondly, forcing an implementation to permit byte-adressing rather than provide alignment words (such as !=CELLS!) is seriously brain damaged. I remain an unrepentant forth-77 fan, for this and other reasons. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
wmb@SUN.COM (Mitch Bradley) (08/16/89)
I would claim that the "Forth Virtual Machine", as implied by FIG Forth or Forth 79 or Forth 83 or whatever standard you choose, has the following properties. * 16-bit stack width * Byte addressing with no alignment restrictions * twos-complement arithmetic * ASCII character set * threaded code I believe that this is a stupid virtual machine, because it imposes too many unnecessary restrictions. Many of these restrictions follow from too few operators, in that one operator is used for 2 purposes. The main culprit is the lack of separate operators for address arithmetic, forcing the use of integer arithmetic operators for address arithmetic, and subsequently imposing a model (linear, byte addressed, no alignment) of the address organization. Many vendors have chosen to relax one or more of these restrictions, implementing something that is not a "correct" Forth Virtual Machine. It's a pity that the Forth Virtual Machine was so badly designed in this respect. The BCPL language, upon which C was modeled, had similar problems in that it imposed an implicit addressing model through lack of ability to distinguish between integer arithmetic and address arithmetic. A main reason that C was invented was because BCPL didn't fit very cleanly on a PDP-11, so Dennis Ritchie decided to fix the language. The ANSI standards team is attempting to remedy this addressing problem by providing operators for address manipulation. I hope it's not too late. Mitch
jax@well.UUCP (Jack J. Woehr) (08/17/89)
>>>>>> everything deleted ...
Tom and Pete, if you think the '83 Standard was confused,
you should see what they are hatching now ... PLEASE get involved
in the ANSI X3J14 Proceedings before they turn Forth into Algol-99 :-) !
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{} {}
{} jax@well ." Sysop, Realtime Control and Forth Board" FIG {}
{} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {}
{} JAX on GEnie ." Tell them JAX sent you!" Coordinator {}
{} {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}RAYBRO%UTRC@utrcgw.utc.COM ("William R Brohinsky", ay) (08/17/89)
Peter-- are you implying that your putative cell-oriented machine would have a 16-bit word, and yet still use byte addressing? I thought a cell- oriented machine (with 16-bit 83-std cellsize) would have an address space of 65536 addressable cells, i.e., 128Kbytes! my question, on the same 0-65535 address range, is this: is this range intended to be absolute (from absolute address $000000...) or can it be relative (i.e., from some marker in address space for variable addressing region start point. I believe that I have some forths that do both (although I am trying to expunge all from my organic memory other than the 3 I am forced to use on a regular basis: Forth, Inc's ChipForth 68HC11; FPC on the pc; Jforth on the Amiga (my personal machine and favorite by FAR!) -raybro It doesn't matter what I disclaim. Noone would believe me, anyway.
peter@ficc.uu.net (Peter da Silva) (08/17/89)
In article <8908161813.AA12808@jade.berkeley.edu>, wmb@SUN.COM (Mitch Bradley) writes: > I would claim that the "Forth Virtual Machine", as implied by FIG Forth > or Forth 79 or Forth 83 or whatever standard you choose, has the following > properties. Forth 79 or Forth 83, yes, but... > * 16-bit stack width > * Byte addressing with no alignment restrictions Fig-forth ran just fine on the PDP-11 and HP1000 with alignment restrictions in place. You just had to use =CELLS on occasion. > * twos-complement arithmetic Maybe. > * ASCII character set > * threaded code -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff