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

well formed flag ?

Started by	Chris Hinsley <chris.hinsley@gmail.com>
First post	2012-10-27 15:59 +0100
Last post	2012-10-31 09:25 +0000
Articles	20 on this page of 58 — 15 participants

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

  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 1 of 3 [1] 2 3 Next page →

#16763 — well formed flag ?

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 15:59 +0100
Subject	well formed flag ?
Message-ID	<2012102715594849117-chrishinsley@gmailcom>

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 ?

Chris

[toc] | [next] | [standalone]

#16764

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 16:03 +0100
Message-ID	<201210271603106615-chrishinsley@gmailcom>
In reply to	#16763

On 2012-10-27 14:59:48 +0000, Chris Hinsley said:

> 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 ?
> 
> Chris

I might also add that my 0BRANCH word is:

	defword "0BRANCH", 0, WORD_ZBRANCH, WORD_INLINE_COMMA
	mov eax, ebx
	POPDSP ebx
	test eax, eax
	jz strict near i_jmp
	ret
	defword_end

Regards

Chris

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

#16765

From	Alex McDonald <blog@rivadpm.com>
Date	2012-10-27 08:33 -0700
Message-ID	<dd0589f1-d982-4279-a3d3-b4cb7b5aea8d@s14g2000vba.googlegroups.com>
In reply to	#16764

On Oct 27, 4:03 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
> On 2012-10-27 14:59:48 +0000, Chris Hinsley said:
>
>
>
>
>
>
>
>
>
> > 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 ?
>
> > Chris
>
> I might also add that my 0BRANCH word is:
>
>         defword "0BRANCH", 0, WORD_ZBRANCH, WORD_INLINE_COMMA
>         mov eax, ebx
>         POPDSP ebx
>         test eax, eax
>         jz strict near i_jmp
>         ret
>         defword_end
>
> Regards
>
> Chris

: < ( 2 -- 1 )
\ ' nseopt compiles; code=$4014DF len=16 type=1
\ defined in src\kernel\gkernel32.f at line 564
( $0 )    mov     edx eax                           \ 8BD0
( $2 )    or      ecx $-1                           \ 83C9FF
( $5 )    xor     eax eax                           \ 33C0
( $7 )    cmp     dword { $0 ebp } edx              \ 395500
( $A )    cmovl   eax ecx                           \ 0F4CC1
( $D )    add     ebp $4                            \ 83C504
( $10 )   ret                                       \ C3 ( end ) ok


EAX is top of stack, EBP is the stack pointer and { EBP } is next to
top.

I'd definitely stick to well formed flags since this;

variable var 0 var !
: foo 10 < negate var +! ;

is well-formed Forth.

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

#16767

From	Alex McDonald <blog@rivadpm.com>
Date	2012-10-27 09:06 -0700
Message-ID	<1315f2d4-5da9-42dc-af23-d7d7a9f9018b@l12g2000vbj.googlegroups.com>
In reply to	#16765

On Oct 27, 4:33 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Oct 27, 4:03 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 2012-10-27 14:59:48 +0000, Chris Hinsley said:
>
> > > 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 ?
>
> > > Chris
>
> > I might also add that my 0BRANCH word is:
>
> >         defword "0BRANCH", 0, WORD_ZBRANCH, WORD_INLINE_COMMA
> >         mov eax, ebx
> >         POPDSP ebx
> >         test eax, eax
> >         jz strict near i_jmp
> >         ret
> >         defword_end
>
> > Regards
>
> > Chris
>
> : < ( 2 -- 1 )
> \ ' nseopt compiles; code=$4014DF len=16 type=1
> \ defined in src\kernel\gkernel32.f at line 564
> ( $0 )    mov     edx eax                           \ 8BD0
> ( $2 )    or      ecx $-1                           \ 83C9FF
> ( $5 )    xor     eax eax                           \ 33C0
> ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
> ( $A )    cmovl   eax ecx                           \ 0F4CC1
> ( $D )    add     ebp $4                            \ 83C504
> ( $10 )   ret                                       \ C3 ( end ) ok
>
> EAX is top of stack, EBP is the stack pointer and { EBP } is next to
> top.
>
> I'd definitely stick to well formed flags since this;
>
> variable var 0 var !
> : foo 10 < negate var +! ;
>
> is well-formed Forth.

There's also

: >= ( 2 -- 1 )
( $0 )    sub     eax dword { $0 ebp }              \ 2B4500
( $3 )    cdq                                       \ 99
( $4 )    mov     eax edx                           \ 8BC2
( $6 )    add     ebp $4                            \ 83C504
( $9 )    ret                                       \ C3 ( end ) ok

and correspondingly < is   neg eax

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

#16769

From	Alex McDonald <blog@rivadpm.com>
Date	2012-10-27 09:26 -0700
Message-ID	<9335db0c-143e-48cb-b306-1e8dc4c9851a@i8g2000vbq.googlegroups.com>
In reply to	#16767

On Oct 27, 5:06 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Oct 27, 4:33 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Oct 27, 4:03 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>
> > > On 2012-10-27 14:59:48 +0000, Chris Hinsley said:
>
> > > > 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 ?
>
> > > > Chris
>
> > > I might also add that my 0BRANCH word is:
>
> > >         defword "0BRANCH", 0, WORD_ZBRANCH, WORD_INLINE_COMMA
> > >         mov eax, ebx
> > >         POPDSP ebx
> > >         test eax, eax
> > >         jz strict near i_jmp
> > >         ret
> > >         defword_end
>
> > > Regards
>
> > > Chris
>
> > : < ( 2 -- 1 )
> > \ ' nseopt compiles; code=$4014DF len=16 type=1
> > \ defined in src\kernel\gkernel32.f at line 564
> > ( $0 )    mov     edx eax                           \ 8BD0
> > ( $2 )    or      ecx $-1                           \ 83C9FF
> > ( $5 )    xor     eax eax                           \ 33C0
> > ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
> > ( $A )    cmovl   eax ecx                           \ 0F4CC1
> > ( $D )    add     ebp $4                            \ 83C504
> > ( $10 )   ret                                       \ C3 ( end ) ok
>
> > EAX is top of stack, EBP is the stack pointer and { EBP } is next to
> > top.
>
> > I'd definitely stick to well formed flags since this;
>
> > variable var 0 var !
> > : foo 10 < negate var +! ;
>
> > is well-formed Forth.
>
> There's also
>
> : >= ( 2 -- 1 )
> ( $0 )    sub     eax dword { $0 ebp }              \ 2B4500
> ( $3 )    cdq                                       \ 99
> ( $4 )    mov     eax edx                           \ 8BC2
> ( $6 )    add     ebp $4                            \ 83C504
> ( $9 )    ret                                       \ C3 ( end ) ok
>
> and correspondingly < is   neg eax

Sorry, wrong way round. I should cut & paste more accurately...

: < ( 2 -- 1 )
\ ' nseopt compiles; code=$4014DF len=9 type=1
\ defined in src\kernel\gkernel32.f at line 574
( $0 )    sub     dword { $0 ebp } eax              \ 294500
( $3 )    cdq                                       \ 99
( $4 )    mov     eax edx                           \ 8BC2
( $6 )    add     ebp $4                            \ 83C504
( $9 )    ret                                       \ C3 ( end ) ok

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

#16784

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 20:33 +0100
Message-ID	<2012102720334580907-chrishinsley@gmailcom>
In reply to	#16769

> : < ( 2 -- 1 )
> \ ' nseopt compiles; code=$4014DF len=9 type=1
> \ defined in src\kernel\gkernel32.f at line 574
> ( $0 )    sub     dword { $0 ebp } eax              \ 294500
> ( $3 )    cdq                                       \ 99
> ( $4 )    mov     eax edx                           \ 8BC2
> ( $6 )    add     ebp $4                            \ 83C504
> ( $9 )    ret                                       \ C3 ( end ) ok

Here your wringting back the result of the subtract to [ebp], which is 
not required, wasting memory bandwidth. Why not change it to a 'cmp 
[ebp], eax' ?

I like the trick with cdq ! Neat !

Chris

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

#16785

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 20:38 +0100
Message-ID	<201210272038407012-chrishinsley@gmailcom>
In reply to	#16784

On 2012-10-27 19:33:45 +0000, Chris Hinsley said:

>> 
>> : < ( 2 -- 1 )
>> \ ' nseopt compiles; code=$4014DF len=9 type=1
>> \ defined in src\kernel\gkernel32.f at line 574
>> ( $0 )    sub     dword { $0 ebp } eax              \ 294500
>> ( $3 )    cdq                                       \ 99
>> ( $4 )    mov     eax edx                           \ 8BC2
>> ( $6 )    add     ebp $4                            \ 83C504
>> ( $9 )    ret                                       \ C3 ( end ) ok
> 
> Here your wringting back the result of the subtract to [ebp], which is 
> not required, wasting memory bandwidth. Why not change it to a 'cmp 
> [ebp], eax' ?
> 
> I like the trick with cdq ! Neat !
> 
> Chris

Hang on, I may have got my src and dest back to front ! Sorry, it 
actually subtrating [ebp] from eax ! And then setting edx to 0/-1 by 
extending the top bit of eax !

Apologies !

Chris

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

#16787

From	Alex McDonald <blog@rivadpm.com>
Date	2012-10-27 12:52 -0700
Message-ID	<1f2aecc9-e7d4-4d05-922b-35210414fb4c@w2g2000vbc.googlegroups.com>
In reply to	#16784

On Oct 27, 8:33 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
> > : < ( 2 -- 1 )
> > \ ' nseopt compiles; code=$4014DF len=9 type=1
> > \ defined in src\kernel\gkernel32.f at line 574
> > ( $0 )    sub     dword { $0 ebp } eax              \ 294500
> > ( $3 )    cdq                                       \ 99
> > ( $4 )    mov     eax edx                           \ 8BC2
> > ( $6 )    add     ebp $4                            \ 83C504
> > ( $9 )    ret                                       \ C3 ( end ) ok
>
> Here your wringting back the result of the subtract to [ebp], which is
> not required, wasting memory bandwidth. Why not change it to a 'cmp
> [ebp], eax' ?

That doesn't set EAX, just the flags, so CDQ generates the wrong sign
in EDX. SUB is required.

>
> I like the trick with cdq ! Neat !
>
> Chris

Ignore it anyway. It fails the Hsyes core tests due to overflow & an
incorrect sign on maximum sized 32bit integers.

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

#16788

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 21:01 +0100
Message-ID	<2012102721014029342-chrishinsley@gmailcom>
In reply to	#16787

On 2012-10-27 19:52:02 +0000, Alex McDonald said:

> On Oct 27, 8:33 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>>> : < ( 2 -- 1 )
>>> \ ' nseopt compiles; code=$4014DF len=9 type=1
>>> \ defined in src\kernel\gkernel32.f at line 574
>>> ( $0 )    sub     dword { $0 ebp } eax              \ 294500
>>> ( $3 )    cdq                                       \ 99
>>> ( $4 )    mov     eax edx                           \ 8BC2
>>> ( $6 )    add     ebp $4                            \ 83C504
>>> ( $9 )    ret                                       \ C3 ( end ) ok
>> 
>> Here your wringting back the result of the subtract to [ebp], which is
>> not required, wasting memory bandwidth. Why not change it to a 'cmp
>> [ebp], eax' ?
> 
> That doesn't set EAX, just the flags, so CDQ generates the wrong sign
> in EDX. SUB is required.
> 
>> 
>> I like the trick with cdq ! Neat !
>> 
>> Chris
> 
> Ignore it anyway. It fails the Hsyes core tests due to overflow & an
> incorrect sign on maximum sized 32bit integers.

Phew ! I was getting jelous and starting to wonder why I picked ebx as 
top of stack rather than eax ! ;)

Chris

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

#16790

From	Coos Haak <chforth@hccnet.nl>
Date	2012-10-27 22:18 +0200
Message-ID	<127oohv9bm4w7.1nbi9933q180a$.dlg@40tude.net>
In reply to	#16788

Op Sat, 27 Oct 2012 21:01:40 +0100 schreef Chris Hinsley:

> On 2012-10-27 19:52:02 +0000, Alex McDonald said:
> 
>> On Oct 27, 8:33 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>>>> : < ( 2 -- 1 )
>>>> \ ' nseopt compiles; code=$4014DF len=9 type=1
>>>> \ defined in src\kernel\gkernel32.f at line 574
>>>> ( $0 )    sub     dword { $0 ebp } eax              \ 294500
>>>> ( $3 )    cdq                                       \ 99
>>>> ( $4 )    mov     eax edx                           \ 8BC2
>>>> ( $6 )    add     ebp $4                            \ 83C504
>>>> ( $9 )    ret                                       \ C3 ( end ) ok
>>> 
>>> Here your wringting back the result of the subtract to [ebp], which is
>>> not required, wasting memory bandwidth. Why not change it to a 'cmp
>>> [ebp], eax' ?
>> 
>> That doesn't set EAX, just the flags, so CDQ generates the wrong sign
>> in EDX. SUB is required.
>> 
>>> 
>>> I like the trick with cdq ! Neat !
>>> 
>>> Chris
>> 
>> Ignore it anyway. It fails the Hsyes core tests due to overflow & an
>> incorrect sign on maximum sized 32bit integers.
> 
> Phew ! I was getting jelous and starting to wonder why I picked ebx as 
> top of stack rather than eax ! ;)
> 
Because it was natural in (your old, my current) 16 bit x86 implementation?

> Chris

-- 
Coos

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

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

#16799

From	"Rod Pemberton" <do_not_have@notemailnotz.cnm>
Date	2012-10-28 04:19 -0400
Message-ID	<k6ipk1$23h$1@speranza.aioe.org>
In reply to	#16788

"Chris Hinsley" <chris.hinsley@gmail.com> wrote in message
news:2012102721014029342-chrishinsley@gmailcom...

> Phew ! I was getting jelous and starting to wonder why I picked ebx as
> top of stack rather than eax ! ;)
>

It seems that only XLAT uses EBX.  So, it's more flexible in terms of
instruction choice, or more likely to not be clobbered.  ECX or CL is used
by loop, branching, and rotate or shift instructions.  EDX is used by
multiply and division instructions.  EAX is used by multiply, division,
string instructions, etc.  If you're moving immediates into registers, quite
a few x86 instructions have shorter forms for the EAX register.


Rod Pemberton

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

#16771

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 17:44 +0100
Message-ID	<2012102717444755036-chrishinsley@gmailcom>
In reply to	#16767

On 2012-10-27 16:06:07 +0000, Alex McDonald said:

> On Oct 27, 4:33 pm, Alex McDonald <b...@rivadpm.com> wrote:
>> On Oct 27, 4:03 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 2012-10-27 14:59:48 +0000, Chris Hinsley said:
>> 
>>>> 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 ?
>> 
>>>> Chris
>> 
>>> I might also add that my 0BRANCH word is:
>> 
>>>         defword "0BRANCH", 0, WORD_ZBRANCH, WORD_INLINE_COMMA
>>>         mov eax, ebx
>>>         POPDSP ebx
>>>         test eax, eax
>>>         jz strict near i_jmp
>>>         ret
>>>         defword_end
>> 
>>> Regards
>> 
>>> Chris
>> 
>> : < ( 2 -- 1 )
>> \ ' nseopt compiles; code=$4014DF len=16 type=1
>> \ defined in src\kernel\gkernel32.f at line 564
>> ( $0 )    mov     edx eax                           \ 8BD0
>> ( $2 )    or      ecx $-1                           \ 83C9FF
>> ( $5 )    xor     eax eax                           \ 33C0
>> ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
>> ( $A )    cmovl   eax ecx                           \ 0F4CC1
>> ( $D )    add     ebp $4                            \ 83C504
>> ( $10 )   ret                                       \ C3 ( end ) ok
>> 
>> EAX is top of stack, EBP is the stack pointer and { EBP } is next to
>> top.
>> 
>> I'd definitely stick to well formed flags since this;
>> 
>> variable var 0 var !
>> : foo 10 < negate var +! ;
>> 
>> is well-formed Forth.
> 
> There's also
> 
> : >= ( 2 -- 1 )
> ( $0 )    sub     eax dword { $0 ebp }              \ 2B4500
> ( $3 )    cdq                                       \ 99
> ( $4 )    mov     eax edx                           \ 8BC2
> ( $6 )    add     ebp $4                            \ 83C504
> ( $9 )    ret                                       \ C3 ( end ) ok
> 
> and correspondingly < is   neg eax

One thing I just noticed is that NASM isn't encodeing small constant 
adds as a single byte, it's useing the full 4 byte encodeing ! I don't 
recall there being an option to tell NASM to optimise constants, I 
thought there was only -O flags to say optimize branches ?

Need to double check the NASM manual...

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

#16778

From	"Rod Pemberton" <do_not_have@notemailnotz.cnm>
Date	2012-10-27 14:52 -0400
Message-ID	<k6haag$tcc$1@speranza.aioe.org>
In reply to	#16771

"Chris Hinsley" <chris.hinsley@gmail.com> wrote in message
news:2012102717444755036-chrishinsley@gmailcom...

> One thing I just noticed is that NASM isn't encodeing small constant
> adds as a single byte, it's useing the full 4 byte encodeing !

Old style NASM produced the most generic instruction encoding, i.e., large
offsets.  With NASM, you need BYTE keyword for imm8 and maybe mem8
encodings.  That's before H.P.A. started messing with NASM's syntax and made
it more MASM like.  So, for new versions of NASM w/64-bit support, I'd check
the manual for any syntax changes.

NASM requires you to specify data sizes when it's indeterminable from the
instruction.  This is the opposite of assemblers like MASM where you use
keywords to specify pointer types.  GAS (GCC) places sizes on the
instruction name.  Unfortunately, that produces naming conflicts with Intel
instructions names for a few instructions.

> I don't
> recall there being an option to tell NASM to optimise constants, I
> thought there was only -O flags to say optimize branches ?
>

Maybe, ask on comp.lang.asm.x86 or alt.lang.asm.


Rod Pemberton

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

#16780

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 20:06 +0100
Message-ID	<2012102720063140720-chrishinsley@gmailcom>
In reply to	#16778

On 2012-10-27 18:52:49 +0000, Rod Pemberton said:

> "Chris Hinsley" <chris.hinsley@gmail.com> wrote in message
> news:2012102717444755036-chrishinsley@gmailcom...
> 
>> One thing I just noticed is that NASM isn't encodeing small constant
>> adds as a single byte, it's useing the full 4 byte encodeing !
> 
> Old style NASM produced the most generic instruction encoding, i.e., large
> offsets.  With NASM, you need BYTE keyword for imm8 and maybe mem8
> encodings.  That's before H.P.A. started messing with NASM's syntax and made
> it more MASM like.  So, for new versions of NASM w/64-bit support, I'd check
> the manual for any syntax changes.
> 
> NASM requires you to specify data sizes when it's indeterminable from the
> instruction.  This is the opposite of assemblers like MASM where you use
> keywords to specify pointer types.  GAS (GCC) places sizes on the
> instruction name.  Unfortunately, that produces naming conflicts with Intel
> instructions names for a few instructions.
> 
>> I don't
>> recall there being an option to tell NASM to optimise constants, I
>> thought there was only -O flags to say optimize branches ?
>> 
> 
> Maybe, ask on comp.lang.asm.x86 or alt.lang.asm.
> 
> 
> Rod Pemberton

Thanks Rod, I found the relavent section in the NASM manual. You do 
need to specify 'byte' on constant loads of a 32bit reg from an imm8 ! 
So I changed my macro to do this:

	; adjust data stack
	%macro ADDDSP 1
		%if ((%1 >= -128) && (%1 < 128))
			add ebp, byte %1
		%else
			add ebp, %1
		%endif
	%endm

This has shorten quite a few words ! :)

Chris

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

#16776

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 19:25 +0100
Message-ID	<2012102719252825860-chrishinsley@gmailcom>
In reply to	#16767

>> : < ( 2 -- 1 )
>> \ ' nseopt compiles; code=$4014DF len=16 type=1
>> \ defined in src\kernel\gkernel32.f at line 564
>> ( $0 )    mov     edx eax                           \ 8BD0
>> ( $2 )    or      ecx $-1                           \ 83C9FF
>> ( $5 )    xor     eax eax                           \ 33C0
>> ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
>> ( $A )    cmovl   eax ecx                           \ 0F4CC1
>> ( $D )    add     ebp $4                            \ 83C504
>> ( $10 )   ret                                       \ C3 ( end ) ok
>> 
>> EAX is top of stack, EBP is the stack pointer and { EBP } is next to
>> top.

	defword "<", 0, WORD_LT, WORD_INLINE_COMMA
	cmp [ebp], ebx
	setl bl
	sub ebp, byte 4
	movzx ebx, bl
	neg ebx
	ret
	defword_end

This is shorter at 14 bytes rather than 16 ! ;)

Chris

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

#16777

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-27 19:33 +0100
Message-ID	<2012102719334450649-chrishinsley@gmailcom>
In reply to	#16776

> 	defword "<", 0, WORD_LT, WORD_INLINE_COMMA
> 	cmp [ebp], ebx
> 	setl bl
> 	sub ebp, byte 4
> 	movzx ebx, bl
> 	neg ebx
> 	ret
> 	defword_end
> 
> This is shorter at 14 bytes rather than 16 ! ;)
> 
> Chris

That should of course be add ebp, byte 4 !!!

Chris

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

#16792

From	Alex McDonald <blog@rivadpm.com>
Date	2012-10-27 15:08 -0700
Message-ID	<ecfb2d6f-3b61-4361-8cfa-fd3361c8fb81@b19g2000vbt.googlegroups.com>
In reply to	#16776

On Oct 27, 7:25 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
> >> : < ( 2 -- 1 )
> >> \ ' nseopt compiles; code=$4014DF len=16 type=1
> >> \ defined in src\kernel\gkernel32.f at line 564
> >> ( $0 )    mov     edx eax                           \ 8BD0
> >> ( $2 )    or      ecx $-1                           \ 83C9FF
> >> ( $5 )    xor     eax eax                           \ 33C0
> >> ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
> >> ( $A )    cmovl   eax ecx                           \ 0F4CC1
> >> ( $D )    add     ebp $4                            \ 83C504
> >> ( $10 )   ret                                       \ C3 ( end ) ok
>
> >> EAX is top of stack, EBP is the stack pointer and { EBP } is next to
> >> top.
>
>         defword "<", 0, WORD_LT, WORD_INLINE_COMMA
>         cmp [ebp], ebx
>         setl bl
>         sub ebp, byte 4
>         movzx ebx, bl
>         neg ebx
>         ret
>         defword_end
>
> This is shorter at 14 bytes rather than 16 ! ;)
>
> Chris

Yes, but it may run slower.

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

#16794

From	Chris Hinsley <chris.hinsley@gmail.com>
Date	2012-10-28 00:53 +0100
Message-ID	<2012102800531128996-chrishinsley@gmailcom>
In reply to	#16792

On 2012-10-27 22:08:25 +0000, Alex McDonald said:

> On Oct 27, 7:25 pm, Chris Hinsley <chris.hins...@gmail.com> wrote:
>>>> : < ( 2 -- 1 )
>>>> \ ' nseopt compiles; code=$4014DF len=16 type=1
>>>> \ defined in src\kernel\gkernel32.f at line 564
>>>> ( $0 )    mov     edx eax                           \ 8BD0
>>>> ( $2 )    or      ecx $-1                           \ 83C9FF
>>>> ( $5 )    xor     eax eax                           \ 33C0
>>>> ( $7 )    cmp     dword { $0 ebp } edx              \ 395500
>>>> ( $A )    cmovl   eax ecx                           \ 0F4CC1
>>>> ( $D )    add     ebp $4                            \ 83C504
>>>> ( $10 )   ret                                       \ C3 ( end ) ok
>> 
>>>> EAX is top of stack, EBP is the stack pointer and { EBP } is next to
>>>> top.
>> 
>>         defword "<", 0, WORD_LT, WORD_INLINE_COMMA
>>         cmp [ebp], ebx
>>         setl bl
>>         sub ebp, byte 4
>>         movzx ebx, bl
>>         neg ebx
>>         ret
>>         defword_end
>> 
>> This is shorter at 14 bytes rather than 16 ! ;)
>> 
>> Chris
> 
> Yes, but it may run slower.

Not sure about that, its 1 instruction less, and should probably 
shedule ok on a modern micro op x86 design. Only hard benchmarks would 
tell. I'll probably leave it as that for now, better than what I had.

Regards

Chris

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

#16770

From	Mark Wills <forthfreak@gmail.com>
Date	2012-10-27 09:31 -0700
Message-ID	<6d5b502c-84a6-4502-8e65-a88b1d59efb8@3g2000yqn.googlegroups.com>
In reply to	#16763

On Oct 27, 3:59 pm, Chris Hinsley <chris.hins...@gmail.com> 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 ?
>
> Chris

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.

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

#16773

From	"A. K." <akk@nospam.org>
Date	2012-10-27 19:21 +0200
Message-ID	<508c181c$0$6637$9b4e6d93@newsspool2.arcor-online.net>
In reply to	#16770

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.

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

Page 1 of 3 [1] 2 3 Next page →

csiph-web

well formed flag ?

Contents

#16763 — well formed flag ?

#16764

#16765

#16767

#16769

#16784

#16785

#16787

#16788

#16790

#16799

#16771

#16778

#16780

#16776

#16777

#16792

#16794

#16770

#16773