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

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

Umm...help?

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

Contents

  Umm...help? David J <skamolex@gmail.com> - 2014-04-29 18:46 -0700
    Re: Umm...help? Julian Fondren <ayrnieu@gmail.com> - 2014-04-29 19:32 -0700
      Re: Umm...help? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-30 10:21 +0000
        Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-01 15:39 -0700
          Re: Umm...help? Coos Haak <chforth@hccnet.nl> - 2014-05-02 10:13 +0200
          Re: Umm...help? Mark Wills <markwills1970@gmail.com> - 2014-05-02 02:06 -0700
            Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-08 16:04 -0700
            Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-08 16:10 -0700
              Re: Umm...help? rickman <gnuarm@gmail.com> - 2014-05-09 14:18 -0400
                Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-19 14:20 -0700
    Re: Umm...help? "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 16:51 -1000
      Re: Umm...help? David J <skamolex@gmail.com> - 2014-04-29 20:03 -0700
        Re: Umm...help? "Elizabeth D. Rather" <erather@forth.com> - 2014-04-29 17:41 -1000
          Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-01 15:29 -0700
    Re: Umm...help? David J <skamolex@gmail.com> - 2014-04-29 19:51 -0700
    Re: Umm...help? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-04-30 08:49 +0000
      Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-01 15:32 -0700
        Re: Umm...help? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-02 09:03 +0000
        Re: Umm...help? Torfinn Ingolfsen <tingo@home.no> - 2014-05-02 13:33 +0200
          Re: Umm...help? rickman <gnuarm@gmail.com> - 2014-05-04 15:11 -0400
            Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-08 16:15 -0700
          Re: Umm...help? David J <skamolex@gmail.com> - 2014-05-08 16:11 -0700
    Re: Umm...help? David Hume <David.Hume@example.com> - 2014-05-04 20:35 +0100
      Re: Umm...help? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-04 12:47 -1000
        Re: Umm...help? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-05 01:59 +0200
          Re: Umm...help? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-04 15:05 -1000
            Re: Umm...help? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-05 13:06 +0200
              Re: Umm...help? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-05 08:07 -1000
                SEE (was: Umm...help?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-06 16:30 +0000
                  Re: SEE "Elizabeth D. Rather" <erather@forth.com> - 2014-05-06 09:24 -1000
                    Re: SEE Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-06 21:53 +0200
                      no more ASS cracks? (was Re: SEE) all2001@spambog.com (Wolfgang Allinger) - 2014-05-06 19:48 -0400
                    Re: SEE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 17:11 +0000
              Re: Umm...help? Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-05-10 15:47 +0100
                Re: Umm...help? Assad Ebrahim <assad.ebrahim@alum.swarthmore.edu> - 2014-05-10 16:06 +0100

Page 2 of 2 — ← Prev page 1 [2]

#30207

> This looks like as good a place as any to jump in...

Rick,  don't want to annoy Torfinn so I edited your excellent response.  Thank you for all the great links.  Very much appreciated!

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

#30206

On Friday, May 2, 2014 5:33:25 AM UTC-6, Torfinn Ingolfsen wrote:
> On 05/02/2014 00:32, David J wrote:
> 
> >
> 
> > The FORTH I'm using is so spartan that it doesn't recognize LOCATE.  But if it did, this would surely be the word I'm searching for.
> 
> >
> 
> Another hint: if you are a nice person, you trim your quotes. 

I'll trim them anyway.  ;)

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

#30089

David J <skamolex@gmail.com> writes:

> I'm the most recent person in the world to learn FORTH.  (Yay!) One
> question I have not found an answer to is this: How do I review the
> current definitions of words I've created?  I realize there are
> endless FORTH implementations.  I'm using something that purports to
> be FIG_FORTHish.
>
> (I'm just presuming there IS some way to review definitions.  The
> alternative seems almost intractable.)

In gforth you can use SEE. However doing that in swiftforth output a
disassembly of the word, which was fascinating, but not quite what you
want.

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

#30099

On 5/4/14 9:35 AM, David Hume wrote:
> David J <skamolex@gmail.com> writes:
>
>> I'm the most recent person in the world to learn FORTH.  (Yay!) One
>> question I have not found an answer to is this: How do I review the
>> current definitions of words I've created?  I realize there are
>> endless FORTH implementations.  I'm using something that purports to
>> be FIG_FORTHish.
>>
>> (I'm just presuming there IS some way to review definitions.  The
>> alternative seems almost intractable.)
>
> In gforth you can use SEE. However doing that in swiftforth output a
> disassembly of the word, which was fascinating, but not quite what you
> want.

SEE shows what is compiled; in interpreted Forths, that's pointers to 
the words that comprise a definition. For Forths that generate machine 
code, that's only displayable as a disassembly. Use LOCATE to see the 
source. A system that doesn't have either is, IMO, below the "usability" 
standard.

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]

#30100

Elizabeth D. Rather wrote:
> SEE shows what is compiled; in interpreted Forths, that's pointers to
> the words that comprise a definition. For Forths that generate machine
> code, that's only displayable as a disassembly. Use LOCATE to see the
> source. A system that doesn't have either is, IMO, below the "usability"
> standard.

How good compiled systems do SEE depends on the effort the implementer made.  
bigForth's SEE usually can reconstruct the source code; the peephole 
optimizer is relatively easy to revert.  SwiftForth should be able to do the 
same (the native code compiler of SwiftForth is not that complicated), VFX 
and iForth with their analytical compilers create code that is not that easy 
to decompile.

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

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

#30103

On 5/4/14 1:59 PM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>> SEE shows what is compiled; in interpreted Forths, that's pointers to
>> the words that comprise a definition. For Forths that generate machine
>> code, that's only displayable as a disassembly. Use LOCATE to see the
>> source. A system that doesn't have either is, IMO, below the "usability"
>> standard.
>
> How good compiled systems do SEE depends on the effort the implementer made.
> bigForth's SEE usually can reconstruct the source code; the peephole
> optimizer is relatively easy to revert.  SwiftForth should be able to do the
> same (the native code compiler of SwiftForth is not that complicated), VFX
> and iForth with their analytical compilers create code that is not that easy
> to decompile.

It's harder than you might think. There are different sequences of 
high-level words that can compile the same few machine instructions, and 
how would you know whence they came? In any case, since the source is 
usually available, why not show it, with LOCATE? Then you get to see 
comments, stack diagram, etc.

And having SEE show what's actually compiled is valuable because there's 
no other good way to see it (assuming you don't like disassembling 
dumps, which few of us do).

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]

#30109

Elizabeth D. Rather wrote:
> It's harder than you might think. There are different sequences of
> high-level words that can compile the same few machine instructions, and
> how would you know whence they came?

Search and display the most likely result.  SEE in bigForth is not always 
100% accurate, either.  Example: If you have DUP +, you can optimize that to 
2*.  A SEE that reports 2* would be fine for me.  Or when you do constant 
folding, just display the results (e.g. 1 2 + would result in 3).

How easy that is depends on how many optimizations you do.

> In any case, since the source is
> usually available, why not show it, with LOCATE? Then you get to see
> comments, stack diagram, etc.

Sure, but that's a different purpose.

> And having SEE show what's actually compiled is valuable because there's
> no other good way to see it (assuming you don't like disassembling
> dumps, which few of us do).

I've other words to see the actual code.  SEE tries to reconstruct the 
source code.

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

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

#30112

On 5/5/14 1:06 AM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>> It's harder than you might think. There are different sequences of
>> high-level words that can compile the same few machine instructions, and
>> how would you know whence they came?
>
> Search and display the most likely result.  SEE in bigForth is not always
> 100% accurate, either.  Example: If you have DUP +, you can optimize that to
> 2*.  A SEE that reports 2* would be fine for me.  Or when you do constant
> folding, just display the results (e.g. 1 2 + would result in 3).
>
> How easy that is depends on how many optimizations you do.

We do a lot more than that.

>> In any case, since the source is
>> usually available, why not show it, with LOCATE? Then you get to see
>> comments, stack diagram, etc.
>
> Sure, but that's a different purpose.

If you want to see source, why not see it? Actual source is surely more 
useful than an attempted reconstruction, which is almost certainly flawed.

>> And having SEE show what's actually compiled is valuable because there's
>> no other good way to see it (assuming you don't like disassembling
>> dumps, which few of us do).
>
> I've other words to see the actual code.  SEE tries to reconstruct the
> source code.

The Forth200x definition of SEE is pretty opaque, IMO: "Display a 
human-readable representation of the named word’s definition. The source
of the representation (object-code decompilation, source block, etc.) 
and the particular form of the display is implementation defined."

It would be much more useful if it clarified whether it shows what has 
been compiled (which to me is most useful) vs. an attempted reconstruction.

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]

#30129 — SEE (was: Umm...help?)

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 5/5/14 1:06 AM, Bernd Paysan wrote:
>> Elizabeth D. Rather wrote:
>>> It's harder than you might think. There are different sequences of
>>> high-level words that can compile the same few machine instructions, and
>>> how would you know whence they came?
>>
>> Search and display the most likely result.  SEE in bigForth is not always
>> 100% accurate, either.  Example: If you have DUP +, you can optimize that to
>> 2*.  A SEE that reports 2* would be fine for me.  Or when you do constant
>> folding, just display the results (e.g. 1 2 + would result in 3).
>>
>> How easy that is depends on how many optimizations you do.
>
>We do a lot more than that.

Is there a paper on it?  The last I heard about SwiftForth compilation
technique is that it combines sequences of primitives into optimized
primitives.  That is relatively straightforward to decompile, even if
you get synonymous code sometimes.

>If you want to see source, why not see it? Actual source is surely more 
>useful than an attempted reconstruction, which is almost certainly flawed.

Decompiled code (to the Forth level) is useful for seeing whether,
e.g., macros worked as intended.

And with enough effort, it is certainly not flawed.  The question is
whether the benefit justifies the effort.  For SwiftForth customers,
apparently not.  For gforth-fast other things are also higher on the
to-do list.

>The Forth200x definition of SEE is pretty opaque, IMO: "Display a 
>human-readable representation of the named word’s definition. The source
>of the representation (object-code decompilation, source block, etc.) 
>and the particular form of the display is implementation defined."
>
>It would be much more useful if it clarified whether it shows what has 
>been compiled (which to me is most useful) vs. an attempted reconstruction.

Your proposal on that will be welcome.  BTW, IIRC this wording came
unchanged from Forth-94.

In Gforth we have a number of code inspection words:

SEE tries to reconstruct something close to source.

SIMPLE-SEE tries to reconstruct the primitives and their arguments.

SEE-CODE is like SIMPLE-SEE, but shows the native code for the
  primitives that has been copied into dynamic superinstructions.

Sure, one might rename SEE into SEE-FORTH and SEE-CODE into SEE, but
does it really matter?  Portable programs don't depend on it, and what
the programmers want depends on the occasion.

Here's an example of input and output (for a somewhat extreme example):

: foo ." hello" ;  ok

see foo          
: foo  
  .\" hello" ; ok

simple-see foo   
$F7255F10 branch
$F7255F14 <-148545760> 
$F7255F18 <1819043176> 
$F7255F1C <538976367> 
$F7255F20 lit
$F7255F24 <-148545768> 
$F7255F28 lit
$F7255F2C <5> 
$F7255F30 lit-perform
$F7255F34 <type> 
$F7255F38 ;s ok

see-code foo     
$F7255F10 branch
$F7255F14 <-148545760> 
$F7255F18 <1819043176> 
$F7255F1C <538976367> 
( $F7213306 )  mov     dword ptr 806256C , ebx  \ $89 $1D $6C $25 $6 $8 
( $F721330C )  mov     ebx , dword ptr [ebx]  \ $8B $1B 
( $F721330E )  add     ebx , # 4  \ $83 $C3 $4 
( $F7213311 )  mov     eax , dword ptr FC [ebx]  \ $8B $43 $FC 
( $F7213314 )  jmp     eax  \ $FF $E0 
$F7255F20 lit
$F7255F24 <-148545768> 
( $F7213316 )  mov     dword ptr 806256C , ebx  \ $89 $1D $6C $25 $6 $8 
( $F721331C )  mov     eax , dword ptr [ebx]  \ $8B $3 
( $F721331E )  add     ebx , # 4  \ $83 $C3 $4 
( $F7213321 )  add     esi , # -4  \ $83 $C6 $FC 
( $F7213324 )  add     ebx , # 4  \ $83 $C3 $4 
( $F7213327 )  mov     dword ptr [esi] , eax  \ $89 $6 
$F7255F28 lit
$F7255F2C <5> 
( $F7213329 )  mov     dword ptr 806256C , ebx  \ $89 $1D $6C $25 $6 $8 
( $F721332F )  mov     eax , dword ptr [ebx]  \ $8B $3 
( $F7213331 )  add     ebx , # 4  \ $83 $C3 $4 
( $F7213334 )  add     esi , # -4  \ $83 $C6 $FC 
( $F7213337 )  add     ebx , # 4  \ $83 $C3 $4 
( $F721333A )  mov     dword ptr [esi] , eax  \ $89 $6 
$F7255F30 lit-perform
$F7255F34 <type> 
( $F721333C )  mov     dword ptr 806256C , ebx  \ $89 $1D $6C $25 $6 $8 
( $F7213342 )  mov     eax , dword ptr [ebx]  \ $8B $3 
( $F7213344 )  add     ebx , # 4  \ $83 $C3 $4 
( $F7213347 )  mov     edx , dword ptr [eax]  \ $8B $10 
( $F7213349 )  mov     eax , dword ptr [edx]  \ $8B $2 
( $F721334B )  xchg     eax, eax  \ $90 
( $F721334C )  jmp     eax  \ $FF $E0 
( $F721334E )  d16: \ $66 
( $F721334F )  xchg     eax, ax  \ $90 
$F7255F38 ;s ok

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#30131 — Re: SEE

On 5/6/14 6:30 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> On 5/5/14 1:06 AM, Bernd Paysan wrote:
>>> Elizabeth D. Rather wrote:
>>>> It's harder than you might think. There are different sequences of
>>>> high-level words that can compile the same few machine instructions, and
>>>> how would you know whence they came?
>>>
>>> Search and display the most likely result.  SEE in bigForth is not always
>>> 100% accurate, either.  Example: If you have DUP +, you can optimize that to
>>> 2*.  A SEE that reports 2* would be fine for me.  Or when you do constant
>>> folding, just display the results (e.g. 1 2 + would result in 3).
>>>
>>> How easy that is depends on how many optimizations you do.
>>
>> We do a lot more than that.
>
> Is there a paper on it?  The last I heard about SwiftForth compilation
> technique is that it combines sequences of primitives into optimized
> primitives.  That is relatively straightforward to decompile, even if
> you get synonymous code sometimes.

It compiles optimized machine code for many sequences, calls for others. 
It's described in the manual.

>> If you want to see source, why not see it? Actual source is surely more
>> useful than an attempted reconstruction, which is almost certainly flawed.
>
> Decompiled code (to the Forth level) is useful for seeing whether,
> e.g., macros worked as intended.
>
> And with enough effort, it is certainly not flawed.  The question is
> whether the benefit justifies the effort.  For SwiftForth customers,
> apparently not.  For gforth-fast other things are also higher on the
> to-do list.
>
>> The Forth200x definition of SEE is pretty opaque, IMO: "Display a
>> human-readable representation of the named word’s definition. The source
>> of the representation (object-code decompilation, source block, etc.)
>> and the particular form of the display is implementation defined."
>>
>> It would be much more useful if it clarified whether it shows what has
>> been compiled (which to me is most useful) vs. an attempted reconstruction.
>
> Your proposal on that will be welcome.  BTW, IIRC this wording came
> unchanged from Forth-94.

Contrary to Hugh's rants, I have not been involved in Forth200x, 
although I have followed it with interest. I'm afraid I don't really 
have the incentive make a proposal.

> In Gforth we have a number of code inspection words:
>
> SEE tries to reconstruct something close to source.
>
> SIMPLE-SEE tries to reconstruct the primitives and their arguments.
>
> SEE-CODE is like SIMPLE-SEE, but shows the native code for the
>    primitives that has been copied into dynamic superinstructions.
>
> Sure, one might rename SEE into SEE-FORTH and SEE-CODE into SEE, but
> does it really matter?  Portable programs don't depend on it, and what
> the programmers want depends on the occasion.
>
> Here's an example of input and output (for a somewhat extreme example):
>
> : foo ." hello" ;  ok

SwiftForth produces:

: foo ." hello" ;  ok
   ok
see foo
3B01F   4E5F ( (S") ) CALL              E83B9EFCFF
3B024   "hello"
3B02B   43AF ( TYPE ) JMP               E97F93FCFF ok

That's (obviously) an example of a call, and as you see we do give you 
the name of the word called (much more helpful than an address) as well 
as the decoded string. For compile-to-code, we usually give the example 
of DIGIT:

: DIGIT ( n -- n )
    DUP 9 > IF 7 + THEN [CHAR] 0 + ;

see digit
884F   9 # EBX CMP                      83FB09
8852   885B JLE                         0F8E03000000
8858   7 # EBX ADD                      83C307
885B   30 # EBX ADD                     83C330
885E   RET

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]

#30132 — Re: SEE

Elizabeth D. Rather wrote:
> That's (obviously) an example of a call, and as you see we do give you
> the name of the word called (much more helpful than an address) as well
> as the decoded string. For compile-to-code, we usually give the example
> of DIGIT:
> 
> : DIGIT ( n -- n )
>     DUP 9 > IF 7 + THEN [CHAR] 0 + ;
> 
> see digit
> 884F   9 # EBX CMP                      83FB09
> 8852   885B JLE                         0F8E03000000
> 8858   7 # EBX ADD                      83C307
> 885B   30 # EBX ADD                     83C330
> 885E   RET

SwiftForth nowadays does a bit more than bigForth (where the optimizer 
hasn't been changed for 25 years now).  However, that stuff still should 
decompile perfect, even when the push/pop of EAX were optimized away in 
bigForth (the xchg ESP, ESI is, because using that performed better on the 
486 and Pentium, the CPUs that were relevant for bigForth's optimization 
choice):

: digit dup 9 > IF 7 + THEN '0 + ;  ok
see digit 
: DIGIT 
  DUP 9 
  > IF 7 + THEN 
  48 + ; 
 ok
disw digit  Adresse : 268645632 
10033500: xchg    ESP,ESI           87F4
10033502: push    EAX               50
10033503: cmp     EAX,$9            3D09000000
10033508: pop     EAX               58
10033509: jle     $10033514         0F8E05000000
1003350F: add     EAX,$7            0507000000
10033514: add     EAX,$30           0530000000
10033519: xchg    ESP,ESI           87F4
1003351B: ret                       C3

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

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

#30135 — no more ASS cracks? (was Re: SEE)

 On 06 May 14 at group /comp/lang/forth in article lkbej7$n3b$1@online.de
 <bernd.paysan@gmx.de>  (Bernd Paysan)  wrote:

>Elizabeth D. Rather wrote:

>> : DIGIT ( n -- n )
>>     DUP 9 > IF 7 + THEN [CHAR] 0 + ;
>
>: digit dup 9 > IF 7 + THEN '0 + ;  ok

>disw digit  Adresse : 268645632
>10033500: xchg    ESP,ESI           87F4
>10033502: push    EAX               50
>10033503: cmp     EAX,$9            3D09000000
>10033508: pop     EAX               58
>10033509: jle     $10033514         0F8E05000000
>1003350F: add     EAX,$7            0507000000
>10033514: add     EAX,$30           0530000000
>10033519: xchg    ESP,ESI           87F4
>1003351B: ret                       C3

SHUDDER!

Kann denn heute keiner mehr Assembler?
Are there no assembler cracks anymore?
assumed the hex number is in AL (0..9; A..F)

             ; 0-9:    CY      AF      A-F:    CY      AF
 add al,90h  ; 90..99  0       0       9A..9F  0       0
 daa         ; 90..99  0       0       FA..FF  1       1
 adc al,40h  ; D0..D9  0       0       3B..40  0       0
 daa         ; 30..39  `0..9`          41..46  `A..F`


Just 9 byte and its a more than 40a old trick from the 8008
works with Z80, 8051 an zillions of other uC



and another brain twister:

        cmp     al,0ah
        sbb     al,69h
        das

This one is 1 byte and 1 instruction shorter, but you need a x86.




Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

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

#30266 — Re: SEE

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 5/6/14 6:30 AM, Anton Ertl wrote:
>> Is there a paper on it?  The last I heard about SwiftForth compilation
>> technique is that it combines sequences of primitives into optimized
>> primitives.  That is relatively straightforward to decompile, even if
>> you get synonymous code sometimes.
>
>It compiles optimized machine code for many sequences, calls for others. 

Does not contradict my impression up to now.

> For compile-to-code, we usually give the example 
>of DIGIT:
>
>: DIGIT ( n -- n )
>    DUP 9 > IF 7 + THEN [CHAR] 0 + ;
>
>see digit
>884F   9 # EBX CMP                      83FB09
>8852   885B JLE                         0F8E03000000
>8858   7 # EBX ADD                      83C307
>885B   30 # EBX ADD                     83C330
>885E   RET

Nice, but the problem with this primitive-sequence-combining approach
is that even with a lot of sequences, there is a significant part of
the code that you don't catch.  Of course, for your example, you can
make sure that you cover it.  In this spirit, as an experiment I added
the following line to Gforth's file peeprules.vmg:

super31 = dup lit > ?branch

With that I get:

: DIGIT ( n -- n )  compiled        
    DUP 9 > IF 7 + THEN [CHAR] 0 + ;  ok
see-code digit \ output fixed manually for clarity
$7F693590BDC8 dup
$7F693590BDD0 lit 
$7F693590BDD8 <9> 
$7F693590BDE0 > 
$7F693590BDE8 ?branch 
$7F693590BDF0 <140089846971920> 
   0x00007f693716f3f9:  cmp    %r14,0x8(%rbp)
   0x00007f693716f3fd:  mov    0x20(%rbp),%rax
   0x00007f693716f401:  jl     0x7f693716f40f
   0x00007f693716f403:  mov    (%rax),%rdx
   0x00007f693716f406:  lea    0x8(%rax),%rbp
   0x00007f693716f40a:  mov    %rdx,%rax
   0x00007f693716f40d:  jmpq   *%rax
   0x00007f693716f40f:  add    $0x30,%rbp
$7F693590BDF8 lit
$7F693590BE00 <7> 
$7F693590BE08 +
   0x00007f693716f413:  add    0x0(%rbp),%r14
   0x00007f693716f417:  add    $0x18,%rbp
$7F693590BE10 lit
$7F693590BE18 <48> 
$7F693590BE20 + 
   0x00007f693716f41b:  add    0x0(%rbp),%r14
   0x00007f693716f41f:  add    $0x18,%rbp
$7F693590BE28 ;s ok

Not as compact as the SwiftForth code, but a lot better than without
super31; unfortunately, super31 won't help much in other code.  For
those who want to understand it: Gforth still has threaded code in
parallel to the native code, and %rbp is the threaded-code instruction
pointer.

The decompiler is actually not as good as shown above and shows many
of the primitives as <0>.  I fixed the output here for clarity.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#30256

On Mon, 05 May 2014 13:06:59 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:
>Elizabeth D. Rather wrote:
>> And having SEE show what's actually compiled is valuable because there's
>> no other good way to see it (assuming you don't like disassembling
>> dumps, which few of us do).
>
>I've other words to see the actual code.  SEE tries to reconstruct the 
>source code.

What words do you use to see the actual code?  (assuming GForth)

Assad

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

#30260

On Sat, 10 May 2014 15:47:51 +0100, Assad Ebrahim
<assad.ebrahim@alum.swarthmore.edu> wrote:

>On Mon, 05 May 2014 13:06:59 +0200, Bernd Paysan <bernd.paysan@gmx.de>
>wrote:
>>Elizabeth D. Rather wrote:
>>> And having SEE show what's actually compiled is valuable because there's
>>> no other good way to see it (assuming you don't like disassembling
>>> dumps, which few of us do).
>>
>>I've other words to see the actual code.  SEE tries to reconstruct the 
>>source code.
>
>What words do you use to see the actual code?  (assuming GForth)
>
>Assad


This can be ignored.   Anton has just provided a comprehensive list in
the thread "GForth - Way to Turn off the Optimising Compiler".

Assad

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web