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

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

Detecting low-level words.

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

Contents

  Detecting low-level words. "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-27 00:23 -0400
    Re: Detecting low-level words. "Elizabeth D. Rather" <erather@forth.com> - 2014-04-26 22:56 -1000
    Re: Detecting low-level words. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-27 12:35 +0000
    Detecting low-level words. Mark Wills <markwills1970@gmail.com> - 2014-04-27 09:29 -0700
      Detecting low-level words. Mark Wills <markwills1970@gmail.com> - 2014-04-27 09:30 -0700
      Re: Detecting low-level words. "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 01:22 -0400
        Re: Detecting low-level words. "Elizabeth D. Rather" <erather@forth.com> - 2014-04-27 22:10 -1000
          Re: Detecting low-level words. "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 05:58 -0400
            Re: Detecting low-level words. foxaudioresearch@gmail.com - 2014-04-28 19:51 -0700
              Re: Detecting low-level words. "Elizabeth D. Rather" <erather@forth.com> - 2014-04-28 18:22 -1000
                Re: Detecting low-level words. Gary Bergstrom <forthprgrmr@gmail.com> - 2014-04-29 20:59 -0700
                  Re: Detecting low-level words. AKK <akk@nospam.org> - 2014-04-30 10:50 +0200
                  Re: Detecting low-level words. Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-04-30 13:23 +0200
                    Re: Detecting low-level words. mhx@iae.nl - 2014-04-30 11:06 -0700
                      Re: Detecting low-level words. Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-04-30 23:15 +0200
            Re: Detecting low-level words. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-30 10:28 +0000
    Re: Detecting low-level words. Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-27 22:36 -0700

#29898 — Detecting low-level words.

Do most Forths have a mechanism to detect low-level words ("primitives")?

E.g., say I need to determine if BYE is a low-level word or
a compiled definition.

If yes, is there any common word to do so?

If not, is there a method that works for most Forths? interpreted Forths?


Rod Pemberton

[toc] | [next] | [standalone]

#29908

On 4/26/14 6:23 PM, Rod Pemberton wrote:
>
> Do most Forths have a mechanism to detect low-level words ("primitives")?
>
> E.g., say I need to determine if BYE is a low-level word or
> a compiled definition.
>
> If yes, is there any common word to do so?
>
> If not, is there a method that works for most Forths? interpreted Forths?

The easiest way is to look at source. Most Forths have LOCATE <name> 
which will show you the source for a word. It's a "quality of 
implementation" issue.

It's technically possible in interpreted Forths to identify CODE words, 
but seeing source is ever so much more useful.

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]

#29914

"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>
>Do most Forths have a mechanism to detect low-level words ("primitives")?

Yes, except for (some?) native-code Forth systems.

>E.g., say I need to determine if BYE is a low-level word or
>a compiled definition.
>
>If yes, is there any common word to do so?

No.

>If not, is there a method that works for most Forths? interpreted Forths?

For interpreted Forths, SEE may show the difference.

- 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 2013: http://www.euroforth.org/ef13/

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

#29920

Assuming a threaded system, tick the word and if it points to DOCOL it's a high-level word,  otherwise it's something else. 

No standard way to determine it,  and the address of DOCOL could change with each release of a particular forth system. 

If your system had a word that returned the address of social it would be helpful. Say 'DOCOL...

: 'DOCOL ( -- ADDR ) ... ... ... ; 

Then it would simply be:

: IsColonDef ( cfa -- flag ) @ 'DOCOL = ;

Test: 

' IsColonDef IsColonDef .

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

#29921

Grrr... 'social' should be DOCOL. Sorry. A case of my smart phone not being so smart! 

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

#29926

On Sun, 27 Apr 2014 12:29:02 -0400, Mark Wills <markwills1970@gmail.com>  
wrote:

> Assuming a threaded system, tick the word and if it points to DOCOL it's
> a high-level word,  otherwise it's something else.
>
> No standard way to determine it,  and the address of DOCOL could change
> with each release of a particular forth system.
>
> If your system had a word that returned the address of [DOCOL] it would
> be helpful. Say 'DOCOL...
>
> : 'DOCOL ( -- ADDR ) ... ... ... ;
>
> Then it would simply be:
>
> : IsColonDef ( cfa -- flag ) @ 'DOCOL = ;
>
> Test:
>
> ' IsColonDef IsColonDef .
>

It's ENTER instead of DOCOL on my system.  It's setup like DOVAR or DODOES
which returns the address of those routines so it can be compiled.  I may
also have DOCON etc internally, unexposed.

The idea is some word, like SEE, which emits high-level definitions in
terms of the complete sequence of low-level words, not just the uppermost,
high-level definition, like TRACE without execution.  That can then be
analysed for optimization.  I would guess that this idea has been around
for some time and perhaps even been developed by someone.


Rod Pemberton

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

#29928

On 4/27/14 7:22 PM, Rod Pemberton wrote:
> On Sun, 27 Apr 2014 12:29:02 -0400, Mark Wills <markwills1970@gmail.com>
> wrote:
>
>> Assuming a threaded system, tick the word and if it points to DOCOL it's
>> a high-level word,  otherwise it's something else.
>>
>> No standard way to determine it,  and the address of DOCOL could change
>> with each release of a particular forth system.
>>
>> If your system had a word that returned the address of [DOCOL] it would
>> be helpful. Say 'DOCOL...
>>
>> : 'DOCOL ( -- ADDR ) ... ... ... ;
>>
>> Then it would simply be:
>>
>> : IsColonDef ( cfa -- flag ) @ 'DOCOL = ;
>>
>> Test:
>>
>> ' IsColonDef IsColonDef .
>>
>
> It's ENTER instead of DOCOL on my system.  It's setup like DOVAR or DODOES
> which returns the address of those routines so it can be compiled.  I may
> also have DOCON etc internally, unexposed.
>
> The idea is some word, like SEE, which emits high-level definitions in
> terms of the complete sequence of low-level words, not just the uppermost,
> high-level definition, like TRACE without execution.  That can then be
> analysed for optimization.  I would guess that this idea has been around
> for some time and perhaps even been developed by someone.

The thing is, there are so many ways of factoring and naming these 
things, and so many names even for the same things. Since the early 
70's, for example, FORTH, Inc. called some of these "behaviors" 
(CREATE), (:), etc., and never found a need for DODOES because of the 
way we compiled DOES>.

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]

#29932

On Mon, 28 Apr 2014 04:10:19 -0400, Elizabeth D. Rather  
<erather@forth.com> wrote:
> On 4/27/14 7:22 PM, Rod Pemberton wrote:

>> The idea is some word, like SEE, which emits high-level definitions in
>> terms of the complete sequence of low-level words, not just the  
>> uppermost,
>> high-level definition, like TRACE without execution.  That can then be
>> analysed for optimization.  I would guess that this idea has been around
>> for some time and perhaps even been developed by someone.
>
> The thing is, there are so many ways of factoring and naming these
> things, and so many names even for the same things. Since the early
> 70's, for example, FORTH, Inc. called some of these "behaviors"
> (CREATE), (:), etc., and never found a need for DODOES because of the
> way we compiled DOES>.
>

True.

However, that doesn't mean the ability to emit complete low-level
sequences wouldn't be useful.  Every word in the dictionary
could be emitted as a complete low-level sequence rather easily.
E.g., with all sequences available, one could potentially detect
unoptimized words, or code thrashing, etc.  It could also allow
partial sequences of low-level words to be optimized by a non-Forth
optimizer, e.g., stack sequences.  Or, it could allow for rewriting
definitions to preference one Forth word over another.  It could
also be used for static frequency analysis of the low-level words,
i.e., which low-level words are being used the most.  These would
be the words that need more optimization.  Those should already
be known to the designer, but maybe something unexpected comes
out from the analysis, say perhaps that the implementation of
the branching is excessively complicated, and likely slow.


Rod Pemberton

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

#29946

On Monday, April 28, 2014 5:58:08 AM UTC-4, Rod Pemberton wrote:
> On Mon, 28 Apr 2014 04:10:19 -0400, Elizabeth D. Rather  
> 
> <erather@forth.com> wrote:
> 
> > On 4/27/14 7:22 PM, Rod Pemberton wrote:
> 
> 
> 
> >> The idea is some word, like SEE, which emits high-level definitions in
> 
> >> terms of the complete sequence of low-level words, not just the  
> 
> >> uppermost,
> 
> >> high-level definition, like TRACE without execution.  That can then be
> 
> >> analysed for optimization.  I would guess that this idea has been around
> 
> >> for some time and perhaps even been developed by someone.
> 
> >
> 
> > The thing is, there are so many ways of factoring and naming these
> 
> > things, and so many names even for the same things. Since the early
> 
> > 70's, for example, FORTH, Inc. called some of these "behaviors"
> 
> > (CREATE), (:), etc., and never found a need for DODOES because of the
> 
> > way we compiled DOES>.
> 
> >
> 
> 
> 
> True.
> 
> 
> 
> However, that doesn't mean the ability to emit complete low-level
> 
> sequences wouldn't be useful.  Every word in the dictionary
> 
> could be emitted as a complete low-level sequence rather easily.
> 
> E.g., with all sequences available, one could potentially detect
> 
> unoptimized words, or code thrashing, etc.  It could also allow
> 
> partial sequences of low-level words to be optimized by a non-Forth
> 
> optimizer, e.g., stack sequences.  Or, it could allow for rewriting
> 
> definitions to preference one Forth word over another.  It could
> 
> also be used for static frequency analysis of the low-level words,
> 
> i.e., which low-level words are being used the most.  These would
> 
> be the words that need more optimization.  Those should already
> 
> be known to the designer, but maybe something unexpected comes
> 
> out from the analysis, say perhaps that the implementation of
> 
> the branching is excessively complicated, and likely slow.
> 
> 
> 
> 
> 
> Rod Pemberton

Back in the stone age FPC and my personal version of HS/Forth had a version of WORDS that displayed different types of words in different colors.  CODE words were therefore clearly visible. I don't know if that could be done in a system independent manner...  I leave that to the smart people here.

BF

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

#29949

On 4/28/14 4:51 PM, foxaudioresearch@gmail.com wrote:
> On Monday, April 28, 2014 5:58:08 AM UTC-4, Rod Pemberton wrote:
>> On Mon, 28 Apr 2014 04:10:19 -0400, Elizabeth D. Rather
>>
>> <erather@forth.com> wrote:
>>
>>> On 4/27/14 7:22 PM, Rod Pemberton wrote:
>>
>>
>>
>>>> The idea is some word, like SEE, which emits high-level definitions in
>>
>>>> terms of the complete sequence of low-level words, not just the
>>
>>>> uppermost,
>>
>>>> high-level definition, like TRACE without execution.  That can then be
>>
>>>> analysed for optimization.  I would guess that this idea has been around
>>
>>>> for some time and perhaps even been developed by someone.
>>
>>>
>>
>>> The thing is, there are so many ways of factoring and naming these
>>
>>> things, and so many names even for the same things. Since the early
>>
>>> 70's, for example, FORTH, Inc. called some of these "behaviors"
>>
>>> (CREATE), (:), etc., and never found a need for DODOES because of the
>>
>>> way we compiled DOES>.
>>
>>>
>>
>>
>>
>> True.
>>
>>
>>
>> However, that doesn't mean the ability to emit complete low-level
>>
>> sequences wouldn't be useful.  Every word in the dictionary
>>
>> could be emitted as a complete low-level sequence rather easily.
>>
>> E.g., with all sequences available, one could potentially detect
>>
>> unoptimized words, or code thrashing, etc.  It could also allow
>>
>> partial sequences of low-level words to be optimized by a non-Forth
>>
>> optimizer, e.g., stack sequences.  Or, it could allow for rewriting
>>
>> definitions to preference one Forth word over another.  It could
>>
>> also be used for static frequency analysis of the low-level words,
>>
>> i.e., which low-level words are being used the most.  These would
>>
>> be the words that need more optimization.  Those should already
>>
>> be known to the designer, but maybe something unexpected comes
>>
>> out from the analysis, say perhaps that the implementation of
>>
>> the branching is excessively complicated, and likely slow.

But this kind of analysis is much more easily done with tools that 
interact with source. Earlier in the thread I mentioned LOCATE, which 
has been around since the 80's. Other common tools include SEE, which 
will show you the compiled code for a word. Slightly less common is 
WHERE (often abbreviated WH) which gives you a cross-reference, 
displaying the line of source in which the requested word is used.

This is really another case where learning to use Forth is best done 
starting from a successful widely-used standard system. That's the way 
to learn not only the inside technical details but also the common tools 
and development strategies that are appropriate to Forth. If you then 
want to write your own Forth you'll be
better equipped to do so


> Back in the stone age FPC and my personal version of HS/Forth had a version of WORDS that displayed different types of words in different colors.  CODE words were therefore clearly visible. I don't know if that could be done in a system independent manner...  I leave that to the smart people here.

That's a lot easier to do with ITC Forths than compile-to-code 
implementations. But, even with ITC, it's hard to imagine that not being 
intensely implementation-dependent. Actually, most really useful 
development tools are implementation-dependent.

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]

#29992

I'd agree with Elizabeth that modern compile to code Forth systems can be a challenge to look at the compiled code and visualize the source.

I've done virtually all the different threading models around in the 35 years that I've been writing Forth.  Lately I'm using a compile to code or subroutine threaded model.  Like Stephen - I don't write assembler code in my embedded products anymore.  The compiler is good enough.
And since I use a tethered model I don't have a "kernel" or "low level words".  I just have words.  Sometimes I use/include lots of the standard words.  And sometimes I don't.  Whatever the project needs.
Since I'm doing embedded systems without access to an outer interpreter in the target, I'm free to pick and choose what the system needs.

So I'd say my systems don't have any method to recognize "low level words".
And I'd go further - usually they don't even have words like DUP or DROP.  These are handled by the tether system while developing and always compiled in-line when compiling.  No need to waste flash on something that won't be called.

Gary

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

#29999

Am 30.04.2014 05:59, schrieb Gary Bergstrom:
> I'd agree with Elizabeth that modern compile to code Forth systems can be a challenge to look at the compiled code and visualize the source.
>
> I've done virtually all the different threading models around in the 35 years that I've been writing Forth.  Lately I'm using a compile to code or subroutine threaded model.  Like Stephen - I don't write assembler code in my embedded products anymore.  The compiler is good enough.
> And since I use a tethered model I don't have a "kernel" or "low level words".  I just have words.  Sometimes I use/include lots of the standard words.  And sometimes I don't.  Whatever the project needs.
> Since I'm doing embedded systems without access to an outer interpreter in the target, I'm free to pick and choose what the system needs.
>
> So I'd say my systems don't have any method to recognize "low level words".
> And I'd go further - usually they don't even have words like DUP or DROP.  These are handled by the tether system while developing and always compiled in-line when compiling.  No need to waste flash on something that won't be called.
>
> Gary
>

With subroutine threading and inlining you lose also debugging 
capabilities on the target. We found this extremely helpful sometimes. 
(and lets you sleep better)  :-)

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

#30006

On 30/04/2014 05:59, Gary Bergstrom wrote:
> I'd agree with Elizabeth that modern compile to code Forth systems can be a challenge to look at the compiled code and visualize the source.
>
> I've done virtually all the different threading models around in the 35 years that I've been writing Forth.  Lately I'm using a compile to code or subroutine threaded model.  Like Stephen - I don't write assembler code in my embedded products anymore.  The compiler is good enough.
> And since I use a tethered model I don't have a "kernel" or "low level words".  I just have words.  Sometimes I use/include lots of the standard words.  And sometimes I don't.  Whatever the project needs.
> Since I'm doing embedded systems without access to an outer interpreter in the target, I'm free to pick and choose what the system needs.
>
> So I'd say my systems don't have any method to recognize "low level words".
> And I'd go further - usually they don't even have words like DUP or DROP.  These are handled by the tether system while developing and always compiled in-line when compiling.  No need to waste flash on something that won't be called.
>
> Gary
>

Can subscribe to this in general. One point though:

"modern compile to code Forth systems"   these were around 30 years ago 
and quite common (preferred) on certain non Intel PC platforms. Stop 
calling this modern everyone!

Grew up on those and have never used another threading model. Have no 
idea of low vs high words concepts as used by the OP. Like Gary I just 
have words. Moreover, when writing Forth words, it's assembler opcodes I 
envision. And yes, optimized (DUP and DROP are merely hints).

Checking what the compiler does with the source is as common as tying my 
laces. Pays off you know. For the OP: seeing what actually is compiled 
might lead to another word choice for sure.

No disrespect to Stephen and Marcel, but I keep checking, although less 
frequently now. It's part of my responsibility of the testing process. 
I'm to blame, not the vendor. At times it might even help to improve the 
compiler. A predictable optimizing compiler (with all its possible 
quirks) is worth a kingdom.

So far all Forths used had/have ways to jump to the source and words to 
check the compiled code. Luckily, because I would get a bit nervous without.

For the OP: information in the head (header, namespace or whatever you 
want to call the dictionary entree of a word) to help the optimizing 
compiler is a used practice indeed.

-r

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

#30012

Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes Re: Detecting low-level words.
> On 30/04/2014 05:59, Gary Bergstrom wrote:
>> I'd agree with Elizabeth that modern compile to code Forth systems can 
>> be a challenge to look at the compiled code and visualize the source.
[..]
>> So I'd say my systems don't have any method to recognize "low level words".
>> And I'd go further - usually they don't even have words like DUP or DROP.  
[..]
>> Gary

[..]
> No disrespect to Stephen and Marcel, but I keep checking, although less 
> frequently now. It's part of my responsibility of the testing process. 
> I'm to blame, not the vendor. At times it might even help to improve the 
> compiler. A predictable optimizing compiler (with all its possible 
> quirks) is worth a kingdom.

> So far all Forths used had/have ways to jump to the source and words to 
> check the compiled code. Luckily, because I would get a bit nervous without.

Maybe you like this, then:

FORTH> -256 __listing__ ! -256 __verbose__ ! -256 __debug__ !  ok
FORTH> : N 2000 ;
Info: made `N' an immediate macro ok
FORTH> : init_cumul
<3>[FORTH>]  N 0 ?do
Executing `;-null' of a tokenized word/quotation/anon, at PC: $0122064A, near N
[3]<3>[FORTH>]  i 3 / i +
[3]<3>[FORTH>]  over i cells + !
[3]<3>[FORTH>]  loop ;
Info: made `init_cumul' an immediate macro ok
FORTH> : test init_cumul N . ;
Executing `;-null' of a tokenized word/quotation/anon, at PC: $0122074A, near init_cumul
Executing `;-null' of a tokenized word/quotation/anon, at PC: $012207B8, near init_cumul
Executing `;-null' of a tokenized word/quotation/anon, at PC: $012207B7, near init_cumul ok
FORTH> see test
Flags: ANSI
$01220740  : test
$0122074A  mov           rcx, $000007D0 d#
$01220751  xor           rbx, rbx
$01220754  call          (?DO) offset NEAR
$0122075E  nop
$0122075F  nop
$01220760  mov           rdi, [rbp 0 +] qword
$01220764  mov           rcx, rbx
$01220767  mov           rbx, rdi
$0122076A  mov           r8, rbx
$0122076D  sar           r8, #63 b#
$01220771  xor           rbx, r8
$01220774  sub           rbx, r8
$01220777  xchg          rdx, rbx
$0122077A  mov           rax, $55555555:55555556 q#
$01220784  mul           rdx
$01220787  xchg          rdx, rbx
$0122078A  xor           rbx, r8
$0122078D  sub           rbx, r8
$01220790  mov           rdi, [rbp 0 +] qword
$01220794  mov           rax, [rbp 0 +] qword
$01220798  lea           rdx, [rbx rdi*1] qword
$0122079C  mov           [rcx rax*8] qword, rdx
$012207A0  mov           rbx, rcx
$012207A3  add           [rbp 0 +] qword, 1 b#
$012207A8  add           [rbp 8 +] qword, 1 b#
$012207AD  jno           $01220760 offset NEAR
$012207B3  add           rbp, #24 b#
$012207B7  push          rbx
$012207B8  push          $000007D0 d#
$012207BD  jmp           .+10 ( $0113A97A ) offset NEAR
FORTH> see init_cumul
Flags: TOKENIZE, ANSI
: init_cumul  [trashed] 0 ?DO I 3 / I + OVER I CELLS + ! LOOP ;  ok
FORTH> see N
Flags: TOKENIZE, ANSI
: N  2000 ;  ok

-marcel

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

#30017

On 30/04/2014 20:06, mhx@iae.nl wrote:
> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes Re: Detecting low-level words.
>> On 30/04/2014 05:59, Gary Bergstrom wrote:
>>> I'd agree with Elizabeth that modern compile to code Forth systems can
>>> be a challenge to look at the compiled code and visualize the source.
> [..]
>>> So I'd say my systems don't have any method to recognize "low level words".
>>> And I'd go further - usually they don't even have words like DUP or DROP.
> [..]
>>> Gary
>
> [..]
>> No disrespect to Stephen and Marcel, but I keep checking, although less
>> frequently now. It's part of my responsibility of the testing process.
>> I'm to blame, not the vendor. At times it might even help to improve the
>> compiler. A predictable optimizing compiler (with all its possible
>> quirks) is worth a kingdom.
>
>> So far all Forths used had/have ways to jump to the source and words to
>> check the compiled code. Luckily, because I would get a bit nervous without.
>
> Maybe you like this, then:
>
> FORTH> -256 __listing__ ! -256 __verbose__ ! -256 __debug__ !  ok
> FORTH> : N 2000 ;
> Info: made `N' an immediate macro ok
> FORTH> : init_cumul
> <3>[FORTH>]  N 0 ?do
> Executing `;-null' of a tokenized word/quotation/anon, at PC: $0122064A, near N
> [3]<3>[FORTH>]  i 3 / i +
> [3]<3>[FORTH>]  over i cells + !
> [3]<3>[FORTH>]  loop ;
> Info: made `init_cumul' an immediate macro ok
> FORTH> : test init_cumul N . ;
> Executing `;-null' of a tokenized word/quotation/anon, at PC: $0122074A, near init_cumul
> Executing `;-null' of a tokenized word/quotation/anon, at PC: $012207B8, near init_cumul
> Executing `;-null' of a tokenized word/quotation/anon, at PC: $012207B7, near init_cumul ok
> FORTH> see test
> Flags: ANSI
> $01220740  : test
> $0122074A  mov           rcx, $000007D0 d#
> $01220751  xor           rbx, rbx
> $01220754  call          (?DO) offset NEAR
> $0122075E  nop
> $0122075F  nop
> $01220760  mov           rdi, [rbp 0 +] qword
> $01220764  mov           rcx, rbx
> $01220767  mov           rbx, rdi
> $0122076A  mov           r8, rbx
> $0122076D  sar           r8, #63 b#
> $01220771  xor           rbx, r8
> $01220774  sub           rbx, r8
> $01220777  xchg          rdx, rbx
> $0122077A  mov           rax, $55555555:55555556 q#
> $01220784  mul           rdx
> $01220787  xchg          rdx, rbx
> $0122078A  xor           rbx, r8
> $0122078D  sub           rbx, r8
> $01220790  mov           rdi, [rbp 0 +] qword
> $01220794  mov           rax, [rbp 0 +] qword
> $01220798  lea           rdx, [rbx rdi*1] qword
> $0122079C  mov           [rcx rax*8] qword, rdx
> $012207A0  mov           rbx, rcx
> $012207A3  add           [rbp 0 +] qword, 1 b#
> $012207A8  add           [rbp 8 +] qword, 1 b#
> $012207AD  jno           $01220760 offset NEAR
> $012207B3  add           rbp, #24 b#
> $012207B7  push          rbx
> $012207B8  push          $000007D0 d#
> $012207BD  jmp           .+10 ( $0113A97A ) offset NEAR
> FORTH> see init_cumul
> Flags: TOKENIZE, ANSI
> : init_cumul  [trashed] 0 ?DO I 3 / I + OVER I CELLS + ! LOOP ;  ok
> FORTH> see N
> Flags: TOKENIZE, ANSI
> : N  2000 ;  ok
>

Sure, the
-256 __listing__ ! -256 __verbose__ ! -256 __debug__ !
might come in handy!
BTW in your Forth I prefer IDIS over SEE because of the 'guaranteed' 
assembler output. Using LOCATE for Forth source.

Thanks, -r

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

#30004

In article <op.xe0ty6sv6zenlw@localhost>,
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>On Mon, 28 Apr 2014 04:10:19 -0400, Elizabeth D. Rather
><erather@forth.com> wrote:
>> On 4/27/14 7:22 PM, Rod Pemberton wrote:
>
>>> The idea is some word, like SEE, which emits high-level definitions in
>>> terms of the complete sequence of low-level words, not just the
>>> uppermost,
>>> high-level definition, like TRACE without execution.  That can then be
>>> analysed for optimization.  I would guess that this idea has been around
>>> for some time and perhaps even been developed by someone.
>>
>> The thing is, there are so many ways of factoring and naming these
>> things, and so many names even for the same things. Since the early
>> 70's, for example, FORTH, Inc. called some of these "behaviors"
>> (CREATE), (:), etc., and never found a need for DODOES because of the
>> way we compiled DOES>.
>>
>
>True.
>
>However, that doesn't mean the ability to emit complete low-level
>sequences wouldn't be useful.  Every word in the dictionary
>could be emitted as a complete low-level sequence rather easily.
>E.g., with all sequences available, one could potentially detect
>unoptimized words, or code thrashing, etc.  It could also allow
>partial sequences of low-level words to be optimized by a non-Forth
>optimizer, e.g., stack sequences.  Or, it could allow for rewriting
>definitions to preference one Forth word over another.  It could
>also be used for static frequency analysis of the low-level words,
>i.e., which low-level words are being used the most.  These would
>be the words that need more optimization.  Those should already
>be known to the designer, but maybe something unexpected comes
>out from the analysis, say perhaps that the implementation of
>the branching is excessively complicated, and likely slow.

This doesn't apply to a FIG-Forth look-alike.
I interpret that as an indirect threaded Forth without optimizer,
the situation would be more like SEE in lina/wina.

In lina/wina can always easily relate the result of SEE to what
you typed or compiled.
You can almost always cut and paste the result of SEE in an
editor, (apart from branches that result from control structures.)

>
>
>Rod Pemberton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#29927

In my Forth a byte is written whenever a word is compiled, defining the type of the word.

[toc] | [prev] | [standalone]

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

csiph-web