Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #9157 > unrolled thread

CASE comparison values

Back to article view | Back to comp.lang.forth

Contents

  CASE comparison values Percy <percival.andrews@gmail.com> - 2012-01-23 05:32 -0800
    Re: CASE comparison values Brad <hwfwguy@gmail.com> - 2012-01-23 07:57 -0800
      Re: CASE comparison values Aleksej Saushev <asau@inbox.ru> - 2012-01-23 22:23 +0400
    Re: CASE comparison values JennyB <jennybrien@googlemail.com> - 2012-01-23 09:11 -0800
      Re: CASE comparison values stephenXXX@mpeforth.com (Stephen Pelc) - 2012-01-23 18:38 +0000
        Re: CASE comparison values alberto pasquale <alberto@hal-pc.org> - 2012-01-23 11:42 -0800
          Re: CASE comparison values Percy <percival.andrews@gmail.com> - 2012-01-23 14:58 -0800
            Re: CASE comparison values "Elizabeth D. Rather" <erather@forth.com> - 2012-01-23 13:41 -1000
            Re: CASE comparison values Brad <hwfwguy@gmail.com> - 2012-01-23 19:20 -0800
          Re: CASE comparison values "Peter Knaggs" <pjk@bcs.org.uk> - 2012-01-24 10:03 +0000

#9157 — CASE comparison values

Hello,

ASCII Forth seems to state that the comparison values in a CASE
statement (the values just before the OF statements) must be
"constants or literal values, and not expressions" (Programmers
Handbook 3rd ed p111).

Can I just check why this is?  I just implemented CASE for a softcore
processor and found that provided the stack at reaching the OF
statement was ( x1 x2), with x1 the test value and x2 the comparison
value, then it didn't matter whether x2 was a literal or the result of
a preceeding expression.

Am I missing something?

[toc] | [next] | [standalone]

#9162

On Jan 23, 6:32 am, Percy <percival.andr...@gmail.com> wrote:
> ASCII Forth seems to state that the comparison values in a CASE
> statement (the values just before the OF statements) must be
> "constants or literal values, and not expressions" (Programmers
> Handbook 3rd ed p111).
>
The (draft) ANS standard says this about OF:

Compilation:  ( C: --  of-sys )
Put of-sys onto the control flow stack.  Append the run-time semantics
given below to the current definition.  The semantics are incomplete
until resolved by a consumer of of-sys such as ENDOF.

Run-time: ( x1 x2 -- | x1 )
If the two values on the stack are not equal, discard the top value
and continue execution at the location specified by the consumer of
of-sys, e.g., following the next ENDOF.  Otherwise, discard both
values and continue execution in line.

So, OF doesn't know or care where x2 came from. It's just a number on
the stack.

The standard (dpans94.pdf) gives a simple example implementation (page
135):

0 CONSTANT CASE IMMEDIATE  ( init count of OFs )

: OF  ( #of -- orig #of+1 / x -- )
   1+    ( count OFs )
   >R    ( move off the stack in case the control-flow )
         ( stack is the data stack. )
   POSTPONE OVER  POSTPONE = ( copy and test case value)
   POSTPONE IF    ( add orig to control flow stack )
   POSTPONE DROP  ( discards case value if = )
   R>             ( we can bring count back now )
; IMMEDIATE

: ENDOF ( orig1 #of -- orig2 #of )
   >R   ( move off the stack in case the control-flow )
        ( stack is the data stack. )
   POSTPONE ELSE
   R>   ( we can bring count back now )
; IMMEDIATE

: ENDCASE  ( orig1..orign #of -- )
   POSTPONE DROP  ( discard case value )
   0 ?DO
     POSTPONE THEN
   LOOP
; IMMEDIATE

[toc] | [prev] | [next] | [standalone]

#9168

Brad <hwfwguy@gmail.com> writes:

> The standard (dpans94.pdf) gives a simple example implementation (page
> 135):
>
> 0 CONSTANT CASE IMMEDIATE  ( init count of OFs )
>
> : OF  ( #of -- orig #of+1 / x -- )
>    1+    ( count OFs )
>    >R    ( move off the stack in case the control-flow )
>          ( stack is the data stack. )
>    POSTPONE OVER  POSTPONE = ( copy and test case value)
>    POSTPONE IF    ( add orig to control flow stack )
>    POSTPONE DROP  ( discards case value if = )
>    R>             ( we can bring count back now )
> ; IMMEDIATE

"over = if drop" is useful factor itself.

Personally, I find using "... case: ... case;" in many cases more readable
than standard "case ... of ... endof endcase.

: case:  postpone over postpone = postpone if postpone drop ; immediate
: case;  postpone exit postpone then ; immediate
: otherwise:  postpone drop ; immediate

These even allow nesting. Even though you have to watch for it yourself,
rules are simple enough.


-- 
HE CE3OH...

[toc] | [prev] | [next] | [standalone]

#9163

Literals and constants are known at compile time, the results of expressions are not. If you avoid the latter then a CASE statement can be implemented behind the scenes as a jump table, otherwise it has to be equivalent to a nested IF ... ELSE, where each alternative has to be tested in turn until a match is found. 

In practice, x2 would almost always be known at compile time. I can't think of offhand of a useful CASE where it is not.

[toc] | [prev] | [next] | [standalone]

#9170

On Mon, 23 Jan 2012 09:11:39 -0800 (PST), JennyB
<jennybrien@googlemail.com> wrote:

>In practice, x2 would almost always be known at compile time. I can't think=
> of offhand of a useful CASE where it is not.

When checking for DOS/Unix/Mac line endings.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#9173

On Jan 23, 12:38 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Mon, 23 Jan 2012 09:11:39 -0800 (PST), JennyB
>
> <jennybr...@googlemail.com> wrote:
> >In practice, x2 would almost always be known at compile time. I can't think=
> > of offhand of a useful CASE where it is not.
>
> When checking for DOS/Unix/Mac line endings.
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads


I have used these extensions for range checking, I think they were
initially published in FD

\ Range Case Utility
\ on the case construct of the form n case  n1 of xxx endof n2 of yyy
endof endcase
\ of expects a pair of numbers, the range utylities will leave a
number equal to the input
\ if the range condition is meet



 : ..<= ( n1 n2 -- n n )  OVER MIN ;		\ less than or equal
 : ..< ( n1 n2 -- n n ) 1- OVER MIN ;		\ less than
 : ..>= ( n1 n2 -- n n ) OVER MAX ;		\ grater than or equal
 : ..> ( n1 n2 -- n n ) 1+ OVER MAX ;		\ greater than
 : ..[] ( n1 n2 -- n n ) >R OVER MAX R> MIN ;	\ withing


alberto

[toc] | [prev] | [next] | [standalone]

#9181

It seems that the comparison values don't need to be fixed at compile
time.  I'll proceed that way.   If other compilers want to implement a
jump table as an alternaltive optimization then they can check for
themselves if they are dealing with literals and constants...

Many thanks.

[toc] | [prev] | [next] | [standalone]

#9183

On 1/23/12 12:58 PM, Percy wrote:
> It seems that the comparison values don't need to be fixed at compile
> time.  I'll proceed that way.   If other compilers want to implement a
> jump table as an alternaltive optimization then they can check for
> themselves if they are dealing with literals and constants...
>
> Many thanks.

No, they certainly do not have to be fixed at *compile* time, but they 
do have to be two values on the stack when OF is executed, such that OF 
can do a simple = test. The point the standard's language is trying to 
make (perhaps not all that well!) is that, unlike IF, which is testing 
'truth', OF is testing *two integers* for equality. So, for example, 
although you could say...

	<x1> <x2> > IF ...

you cannot say...

	<x1> <x2> > OF ...

...although you could say something like...

	<a> <b> > TRUE OF ...

...since the result of > and TRUE are integers that can be tested for 
equality. This particular example would be a poor use of CASE, though, 
since there are only two possibilities.

Also, note (many people forget) that *both* values will be discarded by 
OF if it succeeds, and *x2* will be discarded if it fails (leaving x1 to 
be tested by a subsequent OF or discarded by ENDCASE).

X2 is, indeed, often a literal or a constant, but doesn't have to be.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#9189

On Jan 23, 3:58 pm, Percy <percival.andr...@gmail.com> wrote:
> It seems that the comparison values don't need to be fixed at compile
> time.  I'll proceed that way.   If other compilers want to implement a
> jump table as an alternaltive optimization then they can check for
> themselves if they are dealing with literals and constants...
>
I think LIT OF would be an easy optimization. You still have a series
of 0BRANs instead of a table.

Forth programmers use a jump table when they mean a jump table. There
isn't really anything that easily embeds n-way machine code jumps. You
could roll your own, though.

F83 had EXEC: that did that. Native code generation would need EXEC:
to parse the input stream until a terminator (; would work) to lay
down a jump table. Think of it as a fuzzy tail.

-Brad

[toc] | [prev] | [next] | [standalone]

#9195

alberto pasquale wrote:

>
> I have used these extensions for range checking, I think they were
> initially published in FD
>
>  : ..<= ( n1 n2 -- n n )  OVER MIN ;		\ less than or equal
>  : ..< ( n1 n2 -- n n ) 1- OVER MIN ;		\ less than
>  : ..>= ( n1 n2 -- n n ) OVER MAX ;		\ grater than or equal
>  : ..> ( n1 n2 -- n n ) 1+ OVER MAX ;		\ greater than
>  : ..[] ( n1 n2 -- n n ) >R OVER MAX R> MIN ;	\ withing

You could of course simply use ?OF ( x flag -- x ).

-- 
Peter Knaggs

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web