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

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

well formed flag ?

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

Contents

  well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 15:59 +0100
    Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 16:03 +0100
      Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 08:33 -0700
        Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 09:06 -0700
          Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 09:26 -0700
            Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:33 +0100
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:38 +0100
              Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 12:52 -0700
                Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 21:01 +0100
                  Re: well formed flag ? Coos Haak <chforth@hccnet.nl> - 2012-10-27 22:18 +0200
                  Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 04:19 -0400
          Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 17:44 +0100
            Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-27 14:52 -0400
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:06 +0100
          Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 19:25 +0100
            Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 19:33 +0100
            Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 15:08 -0700
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-28 00:53 +0100
    Re: well formed flag ? Mark Wills <forthfreak@gmail.com> - 2012-10-27 09:31 -0700
      Re: well formed flag ? "A. K." <akk@nospam.org> - 2012-10-27 19:21 +0200
        Re: well formed flag ? Mark Wills <forthfreak@gmail.com> - 2012-10-27 10:33 -0700
          Re: well formed flag ? Coos Haak <chforth@hccnet.nl> - 2012-10-27 22:21 +0200
          Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-28 12:33 +1100
            Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-27 15:46 -1000
    Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-27 08:54 -1000
      Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:11 +0100
    Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-28 11:05 +1100
      Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-28 11:53 +0000
        Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 14:17 +0100
          Re: well formed flag ? mhx@iae.nl (Marcel Hendrix) - 2012-10-28 16:59 +0200
            Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 18:37 +0100
          Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-29 23:46 +1100
            Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 08:33 -0500
              Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-29 08:25 -0700
                Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 12:27 -0500
                  Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 08:18 -0700
                    Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 10:33 -0500
                      Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 08:48 -0700
                        Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 11:45 -0500
                    Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-30 20:10 +0100
                      Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-30 15:10 -0700
                        Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 18:28 -0700
                          Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-11-02 05:28 -0700
                            Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 08:13 -0700
                      Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-30 12:50 -1000
                      Re: well formed flag ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 14:57 +0000
                        Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-31 17:58 +0100
                          Re: well formed flag ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 17:39 +0000
                        Re: well formed flag ? David Thompson <dave.thompson2@verizon.net> - 2012-11-16 23:21 -0500
                    Aliasing (was: well formed flag ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 14:03 +0000
                    Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 12:06 -0400
                      Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 09:31 -0700
                        Aliases (was: well formed flag ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 17:02 +0000
                        Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 20:06 -0400
        Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-29 23:47 +1100
          Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-30 18:02 +0000
            Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-31 11:44 +1100
              Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-31 09:25 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16774

On Oct 27, 6:21 pm, "A. K." <a...@nospam.org> wrote:
> On 27.10.2012 18:31, Mark Wills wrote:
>
>
>
> > Yes, you want well formed flags otherwise code such as the following
> > might not do what you want:
>
> > BEGIN
> >    MyFile EOF? NOT WHILE
> >      PAD MyFile #Get PAD COUNT TYPE
> > REPEAT
> > MyFile #Close
>
> > I had this issue on Thursday! EOF was not returning a boolean value
> > for EOF. It was returning 8. Ouch.
>
> In that case not EOF? is to blame, but NOT. I should produce a boolean.

Not in Forth 83 it isn't. It's a ones compliment. My system is a Forth
83 system.

http://forthworks.com/standards/F83/fst83-12.htm#not

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

#16791

Op Sat, 27 Oct 2012 10:33:30 -0700 (PDT) schreef Mark Wills:

> On Oct 27, 6:21 pm, "A. K." <a...@nospam.org> wrote:
>> On 27.10.2012 18:31, Mark Wills wrote:
>>
>>
>>
>>> Yes, you want well formed flags otherwise code such as the following
>>> might not do what you want:
>>
>>> BEGIN
>>>    MyFile EOF? NOT WHILE
>>>      PAD MyFile #Get PAD COUNT TYPE
>>> REPEAT
>>> MyFile #Close
>>
>>> I had this issue on Thursday! EOF was not returning a boolean value
>>> for EOF. It was returning 8. Ouch.
>>
>> In that case not EOF? is to blame, but NOT. I should produce a boolean.
> 
> Not in Forth 83 it isn't. It's a ones compliment. My system is a Forth
> 83 system.
> 
> http://forthworks.com/standards/F83/fst83-12.htm#not

Since F83 there is no NOT
Try 0= or INVERT

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#16796

Mark Wills wrote:
> On Oct 27, 6:21 pm, "A. K." <a...@nospam.org> wrote:
> > On 27.10.2012 18:31, Mark Wills wrote:
> >
> >
> >
> > > Yes, you want well formed flags otherwise code such as the following
> > > might not do what you want:
> >
> > > BEGIN
> > > MyFile EOF? NOT WHILE
> > > PAD MyFile #Get PAD COUNT TYPE
> > > REPEAT
> > > MyFile #Close
> >
> > > I had this issue on Thursday! EOF was not returning a boolean value
> > > for EOF. It was returning 8. Ouch.
> >
> > In that case not EOF? is to blame, but NOT. I should produce a boolean.
>
> Not in Forth 83 it isn't. It's a ones compliment. My system is a Forth
> 83 system.
>
> http://forthworks.com/standards/F83/fst83-12.htm#not

Yes, and it was considered one the worst decisions of Forth-83 - even
before the ink had dried.

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

#16797

On 10/27/12 3:33 PM, Ed wrote:
> Mark Wills wrote:
>> On Oct 27, 6:21 pm, "A. K." <a...@nospam.org> wrote:
>>> On 27.10.2012 18:31, Mark Wills wrote:
>>>
>>>
>>>
>>>> Yes, you want well formed flags otherwise code such as the following
>>>> might not do what you want:
>>>
>>>> BEGIN
>>>> MyFile EOF? NOT WHILE
>>>> PAD MyFile #Get PAD COUNT TYPE
>>>> REPEAT
>>>> MyFile #Close
>>>
>>>> I had this issue on Thursday! EOF was not returning a boolean value
>>>> for EOF. It was returning 8. Ouch.
>>>
>>> In that case not EOF? is to blame, but NOT. I should produce a boolean.
>>
>> Not in Forth 83 it isn't. It's a ones compliment. My system is a Forth
>> 83 system.
>>
>> http://forthworks.com/standards/F83/fst83-12.htm#not
>
> Yes, and it was considered one the worst decisions of Forth-83 - even
> before the ink had dried.

And I agree with that wholeheartedly. By the time we started work on ANS 
Forth, though, it had become common practice. The solution was to 
replace NOT with either NEGATE (arithmetic inversion) or INVERT (invert 
bits). All compromises have flaws, but at least you know what you're 
getting.

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]

#16779

On 10/27/12 4:59 AM, Chris Hinsley wrote:
> Folks, I'm doing some tweaking to my hobby Forth compiler and just been
> doing some inlineing work.
>
> I'm not very happy about the size of the x86 code for comparision words
> (I know I could reduce the code size if I had a full optimizing code
> generator, but I don't yet…) this is my code for "<"
>
>      defword ">", 0, WORD_GT, WORD_INLINE_COMMA
>      POPDSP eax
>      cmp eax, ebx
>      setg bl
>      movzx ebx, bl
>      neg ebx
>      ret
>      defword_end
>
> I followed the 'well formed flag' comments in Ms Rathers book for this,
> but the IF and TRUE, FALSE words only talk about 0 for false or not zero
> for true. Is it definately the case that Forth needs -1 to come from the
> comparason words ?
>
> Are you allowed to write code that _needs_ the -1 from the ">" ? ie if
> it produce just a 1, would that be incorrect ?

Yes, the standard (everything since Forth83) provides that the 
comparison words return well-formed flags, so they can be used with 
things like AND, as masks, etc., even though IF, WHILE, and UNTIL don't 
require well-formed flags.

In SwiftForth:
see >
354F   EBX 0 [EBP] CMP                  395D00
3552   0 # EBX MOV                      BB00000000
3557   355A JLE                         7E01
3559   EBX DEC                          4B
355A   4 # EBP ADD                      83C504
355D   RET                              C3 ok

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]

#16781

> In SwiftForth:
> see >
> 354F   EBX 0 [EBP] CMP                  395D00
> 3552   0 # EBX MOV                      BB00000000
> 3557   355A JLE                         7E01
> 3559   EBX DEC                          4B
> 355A   4 # EBP ADD                      83C504
> 355D   RET                              C3 ok
> 
> Cheers,
> Elizabeth

Ouch, not keen on the JLE there ! I no branch predicators have got better but !

How about useing 'xor ebx,ebx' rather than the mov too !

Chris 

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

#16795

Chris Hinsley wrote:
> ...
> Are you allowed to write code that _needs_ the -1 from the ">" ? ie if
> it produce just a 1, would that be incorrect ?

A well-formed flag benefits the programmer since flags are often used
to logically mask previous values on the stack.  The well-formed flag
was introduced in Forth-83.

That Forth requires flags and results be left as discrete values on a
stack is one of the reasons Forth won't beat C in the speed stakes.
Highly optimized forths such as VFX go to length to eliminate these
by in-lining sequences of forth words as pure machine code.  Thus
the result of a comparison is reflected at the CPU level, not at the
Forth level.  It's only the start/end values that appear on the stack.
The downside is that a good forth optimizer isn't cheap.  IIRC Stephen
once quoted a figure of 50,000 lines of code.  And still it may not be
as fast as a good C compiler.

On the plus side, Forth has incremental compile and test and an
assembler for writing code words.  For many, this compensates
for the less than stellar speed performance.

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

#16803

On Sun, 28 Oct 2012 11:05:55 +1100, "Ed" <invalid@nospam.com> wrote:

>The downside is that a good forth optimizer isn't cheap.  IIRC Stephen
>once quoted a figure of 50,000 lines of code.

Aout 5,000 lines for many CPUs. 6,000 lines for the x86 version.
Then add the code for the assembler and disassembler.

>And still it may not be as fast as a good C compiler.

The important comparison is the number of hours spent on the
code generators for C and Forth.

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]

#16804

Stephen Pelc wrote:
> The important comparison is the number of hours spent on the
> code generators for C and Forth.

IMHO VFX is limited on x86 by the numbers of registers.  As are C 
compilers.  When I wrote my Wurstkessel cryptography core, Marcel did 
compare the C compiler result with iForth on x64, where more registers 
are available, and the speed was about the same.

On x86, Andy Glew (one of the designers of the Pentium Pro) suggested 
adding an instruction for "well formed flags" in the Forth sense - which 
could be used for bit-wise operations.  It got turned down by senior 
management, because C compilers couldn't make any benefit from it; 
though assembly code would.

Later, in the SSE instruction set, the idea was revived, and indeed 
implemented: SSE compares store their result flags as either all bits 
set or all bits cleared in the destination register.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#16808

Bernd Paysan <bernd.paysan@gmx.de> writes Re: well formed flag ?

> Stephen Pelc wrote:
>> The important comparison is the number of hours spent on the
>> code generators for C and Forth.

> IMHO VFX is limited on x86 by the numbers of registers.  As are C 
> compilers.  When I wrote my Wurstkessel cryptography core, Marcel did 
> compare the C compiler result with iForth on x64, where more registers 
> are available, and the speed was about the same.

I redid these just now on an i7 2.66 GHz machine:

64bits - 0.985 seconds; Speed: 518,743,667 bytes/sec. 
32bits - 2.981 seconds; Speed: 171,696,847 bytes/sec. ( rngs_wurst in CODE )
32bits - 4.741 seconds; Speed: 107,971,320 bytes/sec. ( high-level )

> On x86, Andy Glew (one of the designers of the Pentium Pro) suggested 
> adding an instruction for "well formed flags" in the Forth sense - which 
> could be used for bit-wise operations.  It got turned down by senior 
> management, because C compilers couldn't make any benefit from it; 
> though assembly code would.

Rngs_wurst is in CODE because the carry bit is needed.

	: rngs_wurst ( ud1 index -- ud2 )  
	    64s ( 8 * ) 'rngs + 64@ 
	    2>R
	    DUP 0< >R D2* R> DUP D- 2R>
	    ROT XOR >R XOR R> ; PRIVATE

> Later, in the SSE instruction set, the idea was revived, and indeed 
> implemented: SSE compares store their result flags as either all bits 
> set or all bits cleared in the destination register.

-marcel

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

#16811

Marcel Hendrix wrote:
>> IMHO VFX is limited on x86 by the numbers of registers.  As are C
>> compilers.  When I wrote my Wurstkessel cryptography core, Marcel did
>> compare the C compiler result with iForth on x64, where more
>> registers are available, and the speed was about the same.
> 
> I redid these just now on an i7 2.66 GHz machine:
> 
> 64bits - 0.985 seconds; Speed: 518,743,667 bytes/sec.
> 32bits - 2.981 seconds; Speed: 171,696,847 bytes/sec. ( rngs_wurst in
> CODE ) 32bits - 4.741 seconds; Speed: 107,971,320 bytes/sec. (
> high-level )

In theory, Wurstkessel should take about twice the time on a 32 bit 
processor than on a 64 bit processor.  However, when we compile high-
level code for both, it's a factor 5.  The way the code is arranged 
gives a benefit on x64 with 8 accumulator registers - a version tuned 
for 32 bits would use one accumulator after the other (or maybe two 
accumulators, 4 registers), but will have a lot less intrinsic 
parallelism.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#16823

Bernd Paysan wrote:
> Stephen Pelc wrote:
> > The important comparison is the number of hours spent on the
> > code generators for C and Forth.
>
> IMHO VFX is limited on x86 by the numbers of registers.  As are C
> compilers.  When I wrote my Wurstkessel cryptography core, Marcel did
> compare the C compiler result with iForth on x64, where more registers
> are available, and the speed was about the same.

How many C compilers were tested?

> On x86, Andy Glew (one of the designers of the Pentium Pro) suggested
> adding an instruction for "well formed flags" in the Forth sense - which
> could be used for bit-wise operations.  It got turned down by senior
> management, because C compilers couldn't make any benefit from it;
> though assembly code would.
>
> Later, in the SSE instruction set, the idea was revived, and indeed
> implemented: SSE compares store their result flags as either all bits
> set or all bits cleared in the destination register.

I expect C (and similar languages) to generate better code, more easily,
because they operate at a higher level of abstraction than does Forth.
Unlike other languages, Forth is (as you point out) highly reliant on registers
and optimizers.  It needs these to eliminate the inefficiency of pushing items
around a virtual stack - something which conventional cpu's were never
designed to do.

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

#16825

Ed <invalid@nospam.com> wrote:
> I expect C (and similar languages) to generate better code, more
> easily, because they operate at a higher level of abstraction than
> does Forth.

On what is this opinion based?

> Unlike other languages, Forth is (as you point out) highly reliant
> on registers and optimizers.

And C isn't?

> It needs these to eliminate the inefficiency of pushing items around
> a virtual stack - something which conventional cpu's were never
> designed to do.

They weren't designed to evaluate expression trees either.  What you
perhaps don't realize is that expression trees and RPN are equivalent:
there is a 1:1 mapping between the two.  In both cases you have to
convert the abstract form into instructions that push data between
memory and registers.

Andrew.

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

#16827

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> What you perhaps don't realize is that expression trees and RPN are
> equivalent: there is a 1:1 mapping between the two.  

I think not quite right--RPN is more like linear logic, unless you have
locals or something like PICK.  This is apparent from Koopman's book
where he talks about ways to compile C into Forth.  There's also a cool
paper by Henry Baker:

http://home.pipeline.com/~hbaker1/ForthStack.html 

> In both cases you have to convert the abstract form into instructions
> that push data between memory and registers.

If the Forth code is written in the classic style (using global
variables to hold temporary values when stack shuffling gets too
complex) then it may be harder to compile good code.

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

#16828

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> What you perhaps don't realize is that expression trees and RPN are
>> equivalent: there is a 1:1 mapping between the two.  
> 
> I think not quite right--RPN is more like linear logic, unless you have
> locals or something like PICK. 

Of course you have locals.  We've had locals in Forth for 20 years.

> This is apparent from Koopman's book where he talks about ways to
> compile C into Forth. 

OK, I shouldn't have written that without a list of caveats.  :-)

If we're going to nitpick, and I guess we are, expression trees and
RPN are equivalent in the absence of stack order manipulation and
loops: in that case the algorithm to convert between the two is pretty
trivial.  In the presence of stack manipulation things get a bit more
complicated but it's a fairly simple matter of copying and creating
temporaries.  (We did all of this in gcj, which converts stack code to
expression trees in a GCC front end.)  There's certainly nothing
inherent to generating code for a register machine from stack code
that would make generation less efficient.  Data flow analysis on the
stack is no different from data flow analysis between a bunch of local
variables.  As Stephen has pointed out on many occasions, the only
additional thing you need to do in a Forth optimizer is a stack
shuffle at block boundaries.

> There's also a cool paper by Henry Baker:
> 
> http://home.pipeline.com/~hbaker1/ForthStack.html 
> 
>> In both cases you have to convert the abstract form into instructions
>> that push data between memory and registers.
> 
> If the Forth code is written in the classic style (using global
> variables to hold temporary values when stack shuffling gets too
> complex)

'tain't my classic style!  I always had to bear multi-tasking in mind,
anyway.

> then it may be harder to compile good code.

The same applies to C, surely.

Andrew.

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

#16839

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> expression trees and RPN are equivalent: ...
> Of course you have locals.  We've had locals in Forth for 20 years.

OK, in this case there's equivalence, it's just no longer pure RPN, but
no problem.

>> If the Forth code is written in the classic style (using global
>> variables to hold temporary values when stack shuffling gets too
>> complex)
>
> 'tain't my classic style!  I always had to bear multi-tasking in mind,
> anyway.

Oh good point, by "global" I just meant "not local".  In particular if
you store to a variable, any subroutine you call might access or modify
it, so you need whole-program analysis to tell if that has happeened.

> The same applies to C, surely.

There are a bunch of rules in C about when the compiler can assume
variables aren't aliased.  I don't think Forth has anything like that.

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

#16840

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> expression trees and RPN are equivalent: ...
>> Of course you have locals.  We've had locals in Forth for 20 years.
> 
> OK, in this case there's equivalence, it's just no longer pure RPN, but
> no problem.

In what sense is it not "pure" RPN?  IMO,

  A B +

is still RPN, even if A and B are local variables.  RPN is just how
you write expressions.  It's no different from  A + B  or  (+ A B) .

>>> If the Forth code is written in the classic style (using global
>>> variables to hold temporary values when stack shuffling gets too
>>> complex)
>>
>> 'tain't my classic style!  I always had to bear multi-tasking in mind,
>> anyway.
> 
> Oh good point, by "global" I just meant "not local".  In particular if
> you store to a variable, any subroutine you call might access or modify
> it, so you need whole-program analysis to tell if that has happeened.

Sure, as in any language.  That's my point: there isn't really much of
a difference in practice.

Andrew.

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

#16841

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> In what sense is it not "pure" RPN?  IMO,
>   A B +
> is still RPN, even if A and B are local variables.

The impurity happens when you have to store to locals (or to the
interior of the stack) in the middle of the evaluation.  I don't think
pure RPN has a way to do that.

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

#16842

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> In what sense is it not "pure" RPN?  IMO,
>>   A B +
>> is still RPN, even if A and B are local variables.
> 
> The impurity happens when you have to store to locals (or to the
> interior of the stack) in the middle of the evaluation.  I don't think
> pure RPN has a way to do that.

No, I'm sure it doesn't.  But pure RPN doesn't have a way to store
into a global either: all RPN can do is expressions.

Andrew.

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

#16844

Paul Rubin wrote:
> There are a bunch of rules in C about when the compiler can assume
> variables aren't aliased.  I don't think Forth has anything like that.

Standard Forth has IMHO 6 separate memory areas:

* dictionary + heap
* code memory
* data stack
* return stack
* floating point stack
* locals

You can only address the dictionary and heap with @ and !.

In any case, it would be *much* better for an optimizer if you 
deliberately and explicitely can specify unaliased variables if it can 
help the compiler.

Languages without arbitrary pointers like traditional Fortran have much 
stricter rules for unaliased memories.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web