marmar@mtk.UUCP (Mark Martino) (11/14/89)
I expect this has been talked about before, but I missed it. I was reading an article about ANS Forth last night in the FIG journal. I really liked the changes that were discussed in the article, but one change confused me. I agree with it, but it baffled me. This article proposed that PICK and ROLL become members of the extended word set instead of being required words. I agree with the article that they are fairly cumbersome, but I could not think of a way to get along without them. How WOULD you get along without them? I'm not being sarcastic or facetious here, I really am curious. I'd love to get along without them.
wmb@SUN.COM (Mitch Bradley) (11/16/89)
> How WOULD you get along without [PICK and ROLL]
I get along without ROLL just fine. I can't remember the last time
I used it. The only thing I would miss is "2 PICK".
Like the article in Forth Dimensions says, you can always implement
PICK and ROLL in high level if you have to.
You need not worry, because most vendors are going to implement the
full core extension wordset anyway, for marketing reasons.
The "required/extension" separation is really a political technique
used to facilitate compromise between standards team members.
For some words, there is a "must have it" camp and a "no way, I don't
want to burden my system with that useless word" camp.
Such words often end up in the extension part of a wordset.
The need for PICK is somewhat reduced by the existence of local variables.
At the last meeting, a proposal for local variables was adopted. Here is
how it works:
LOCAL name ( initial-value -- )
Used inside a colon definition to define a local variable.
When the colon definition is executed, the stack is popped into
the local variable. When name is later used within that
definition, the value is left on the stack.
TO name ( value -- )
Changes the value of a local variable.
Here's an example. This word looks for the first occurrence of the
value "test" between start-addr and start-addr + size . It illustrates
the use of LOCAL/TO and multiple WHILEs . I have used capitalization
to point out new usage.
: search ( test start-addr size -- test next-addr size found-addr found? )
swap LOCAL addr ( test size )
addr + LOCAL end-addr ( test )
LOCAL test
BEGIN
addr end-addr <
WHILE
addr @ test -
WHILE
addr 1 cells + TO addr
AGAIN THEN THEN \ resolve both "while"s
\ REPEAT THEN would have worked too
addr end-addr < if
test addr 1 cells + end-addr addr - addr -1
else
test end-addr 0 0 0
then
;toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/16/89)
In article <931@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: >This article proposed that PICK and ROLL become members of the extended >word set instead of being required words. I agree with the article that >they are fairly cumbersome, but I could not think of a way to get along >without them. > >How WOULD you get along without them? Well I guess that this makes me really old, but I used Forth before there was PICK and ROLL, and I got along just fine! Two reasons to avoid them: 1) If you "need" them, then you are dealing with two many values at once on the stack, and will have an extremely difficult time debugging and especially maintaining that code. 2) Optimizing Forth compilers (such as my native code compilers) make use of machine registers to hold top of stack values. When PICK and ROLL have a non literal argument (i.e. X @ PICK rather than 4 PICK) then the compiler is forced to flush registers to the stack -- a decidedly non-optimal situation. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
olorin@walt.cc.utexas.edu (Dave Weinstein) (11/16/89)
In article <931@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: [Discussion of PICK and ROLL deleted] >How WOULD you get along without them? I'm not being sarcastic or >facetious here, I really am curious. I'd love to get along without >them. I'm trying to remember the last time I used PICK and ROLL (and failing). I have this bias against them (they seem inelegant to me), and I've always found that changing the code (including other words and sometimes the format of the parameter stack stream) to make PICK and ROLL unnecessary makes the code cleaner in other ways as well. (I try not to overgeneralize, but in _my_ experience this has been the case...I literally cannot remember the last time I used PICK and ROLL). --Dave --- Dave Weinstein "No one has ever wanted a new computer language. olorin@walt.cc.utexas.edu They want an improved Fortran!" -- Chuck Moore GEnie: OLORIN Disclaimer: These are my opinions. Find your own.
peter@ficc.uu.net (Peter da Silva) (11/16/89)
In article <931@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: > How WOULD you get along without them? I'm not being sarcastic or > facetious here, I really am curious. I'd love to get along without > them. Just don't use them. We used to get along just fine without PICK and ROLL, I don't see what harm they're doing, though, except for possible performance problems on some architectures. Personally I think PICK is pretty cheap (sp@ 2* + @), and should be retained. ROLL does a lot of copying, though, and is a lot less commonly used. In many cases just redesigning to avoid use of ROLL will give you a performance boost. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "*Real* wizards don't whine about how they paid their dues" -- Quentin Johnson quent@atanasoff.cs.iastate.edu
peter@ficc.uu.net (Peter da Silva) (11/16/89)
In article <8911152104.AA10027@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: > LOCAL name ( initial-value -- ) So far, so good. > TO name ( value -- ) Bleaaaaagh!!!!!! NONONONONONO! Please please please. There is *no* technical reason to require this "TO" abomination. I experimented with this construct years ago, and decided that the extremely minor increase in clarity in a few cases was outweighed by (a) the lack of consistency... is that a constant or a variable... in the common case, and (b) the extra complexity in the case where you need an address. > Here's an example. Here's a changed version of your example using normal, conventional @ and !: : search ( test start-addr size -- test next-addr size found-addr found? ) swap LOCAL addr ( test size ) addr + LOCAL end-addr ( test ) LOCAL test BEGIN addr @ end-addr @ < WHILE addr @ @ test @ - ( shouldn't this be <>??? ) WHILE addr @ 1 cells + addr ! AGAIN THEN THEN \ resolve both "while"s \ REPEAT THEN would have worked too addr @ end-addr @ < if test @ addr @ 1 cells + end-addr @ addr @ - addr @ -1 else test @ end-addr @ 0 0 0 then ; Actually, I'd do it like this: : search ( test start-addr size -- test next-addr size found-addr found? ) LOCAL size LOCAL start-addr LOCAL test size @ 0 do test @ i start-addr + @ @ = if i start-addr +! i size -! leave then loop size @ if test @ start-addr @ size + 0 0 0 else test @ addr @ 1 cells + size @ 1+ addr @ -1 then ; And let the optimiser worry about the details. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "*Real* wizards don't whine about how they paid their dues" -- Quentin Johnson quent@atanasoff.cs.iastate.edu
wmb@SUN.COM (11/17/89)
> There is *no* technical reason to require this "TO" abomination.
Actually, that turns out not to be the case. If you use @ and !,
the data must be stored in addressable memory. With TO, the local
variables can be stored in registers or on a special hardware stack
or in a different segment.
A lot of people I have talked to really like "TO" variables
(or QUANs or VALUEs or whatever you want to call them). Even in the
ANSI standard group, where even the seemingly most trivial point can
trigger bloody arguments, there seemed to be no opposition to the "TO"
semantics.
Mitchkoopman@a.gp.cs.cmu.edu (Philip Koopman) (11/17/89)
Support for PICK and ROLL vary wildly on stack hardware. On some machines, they can get pretty nasty, if the machine only supports access to the top of the stack. It turns out that microcode works really well for PICK and ROLL, because you can twiddle with the stack pointers without worrying about an interrupt trashing the stack within a single opcode. (Of course, you can disable interrupts in other systems explicitly). The real problem is that most machines have limited on-chip stack size, with spilling or paging into program memory. If you PICK or ROLL something that has been spilled into program memory, you can have a real problem! This means that PICK and ROLL either have to be used only with programs that are guaranteed not to spill to program memory, or, PICK and ROLL flush all buffers to program memory before starting operation. Other compromises or schemes are certainly possible, but this illustrates the key elements of the problem. I used to use PICK and ROLL a lot, because you get deep stacks working with 32-bit and 64-bit quantities on a 16-bit Forth. Now that I use 32-bit systems, I use them much less frequently. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
peter@ficc.uu.net (Peter da Silva) (11/18/89)
> > There is *no* technical reason to require this "TO" abomination. > Actually, that turns out not to be the case. If you use @ and !, > the data must be stored in addressable memory. With TO, the local > variables can be stored in registers or on a special hardware stack > or in a different segment. OK. It's still incredibly ugly. And the number of implementations that could usefully take advantage of registers in this context is not likely to be large. Certainly not in the embedded controller feild. Hardware stacks are even scarcer. > A lot of people I have talked to really like "TO" variables > (or QUANs or VALUEs or whatever you want to call them). I called them EQUs, back when I thought they were a neat idea. They really don't add much to the language, though, and much of what they add is confusion. > ANSI standard group, where even the seemingly most trivial point can > trigger bloody arguments, there seemed to be no opposition to the "TO" > semantics. Sigh. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "vi is bad because it didn't work after I put jelly in my keyboard." -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)