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

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

1 /STRING vs SNIP

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

Contents

  1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-18 19:31 -0700
    Re: 1 /STRING vs SNIP Ron Aaron <rambamist@gmail.com> - 2016-10-19 07:24 +0300
    Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-19 07:52 +0000
      Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-19 16:58 -0700
        Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-21 16:01 +1000
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-21 00:51 -0700
            Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-21 00:57 -0700
          Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 05:20 -0700
            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-22 00:25 +1000
              Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 09:13 -0700
                Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-21 16:24 +0000
                  Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-21 20:06 +0200
                    Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 14:19 -0700
                    Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-22 13:46 +1000
                    Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-22 11:34 +0000
                      Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-22 13:49 +0000
                        Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-24 11:15 +1000
                          Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-24 03:01 +0200
                            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-24 13:29 +1000
                          Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-24 11:15 +0000
                            Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-24 19:44 -0700
                            Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-29 11:17 +1000
                              Re: 1 /STRING vs SNIP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-29 04:09 -0500
                              Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-29 16:44 +0000
                                Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-29 17:11 -0700
                                Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-31 19:11 +1100
                                  Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 08:47 +0000
        Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 03:49 -0700
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-22 20:02 -0700
          Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-22 20:13 -0700
            Re: 1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-22 21:09 -0700
              Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-23 18:36 -0700
            Re: 1 /STRING vs SNIP alex <alex@rivadpm.com> - 2016-10-27 14:07 +0100
              Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-27 19:12 -0700
                Re: 1 /STRING vs SNIP alex <alex@rivadpm.com> - 2016-10-28 19:39 +0100
                  Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-28 20:26 -0700
      Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-26 19:52 -0700
        Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-27 09:42 +0000
          Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-27 06:46 -0700
          Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-28 07:31 +0000
            Re: 1 /STRING vs SNIP jim <anon@example.com> - 2016-10-28 11:33 +0100
            Re: 1 /STRING vs SNIP jasmijn Bonting <tessa.bonting@gmail.com> - 2016-10-28 04:09 -0700
              Re: 1 /STRING vs SNIP stephen@mpeforth.com (Stephen Pelc) - 2016-10-28 12:41 +0000
              Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-28 16:50 +0000
                Re: 1 /STRING vs SNIP Chris Curl <ccurl609@gmail.com> - 2016-10-28 10:59 -0700
                  Re: 1 /STRING vs SNIP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-29 10:17 +0000
    Re: 1 /STRING vs SNIP "HAA" <someone@microsoft.com> - 2016-10-19 20:19 +1000
      Re: 1 /STRING vs SNIP foxaudioresearch@gmail.com - 2016-10-19 05:12 -0700
    1 /STRING vs SNIP trans <transfire@gmail.com> - 2016-10-21 04:07 -0700
      Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-21 15:50 +0200
      Re: 1 /STRING vs SNIP hughaguilar96@gmail.com - 2016-10-25 16:38 -0700
        Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-26 10:50 -0400
          Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-26 10:53 -0400
          Re: 1 /STRING vs SNIP albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-26 17:33 +0200
            Re: 1 /STRING vs SNIP "David N. Williams" <williams@umich.edu> - 2016-10-27 10:16 -0400
              Re: 1 /STRING vs SNIP Doug Hoffman <glidedog@gmail.com> - 2016-10-27 17:01 -0400
            Re: 1 /STRING vs SNIP Coos Haak <htrofhc@gmail.com> - 2016-10-27 17:00 +0200
    Re: 1 /STRING vs SNIP Hans Bezemer <the.beez.speaks@gmail.com> - 2016-10-22 12:25 +0200

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

#52264

Stephen

These days it's hard to find a processor. Just a processor.
If you want to implement a high speed application 
(say a radar imaging job)  you end up having to look
at video processors - it seems nobody is making "just a 
processor" anymore. We now seem to aquired the 
concept of "hardware bloat" 
It's not exactly conducive to stack machines. 

> In article <5812fe2f.243659084@news.eternal-september.org>, 
stephen@mpeforth.com says...

> 
> At some stage in the past (I forget for which x86 CPU),
> memory/immediate instructions became very slow. At that point,
> we removed their use by the VFX code generator. Ho, hum, time
> to read up on current CPUs.
> 
> Stephen

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

#52266

Op vrijdag 28 oktober 2016 09:31:47 UTC+2 schreef Stephen Pelc:
> On Thu, 27 Oct 2016 09:42:20 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
> 
> >It can be reduced to two instructions on IA-32, as SwiftForth demonstrates:
> >
> >see foo2 
> >8083C4F   1 # 0 [EBP] ADD               83450001
> >8083C53   1 # EBX SUB                   83EB01
> >8083C56   RET                           C3 ok
> >
> >Apparently SwiftForth has an optimization rule for n /STRING; whether
> >this is faster than the VFX code depends on the actual processor.
> 
> At some stage in the past (I forget for which x86 CPU),
> memory/immediate instructions became very slow. At that point,
> we removed their use by the VFX code generator. Ho, hum, time
> to read up on current CPUs.
> 
> Stephen
> 

It is still slow, since the total instruction for large immidates is longer then 7 bytes and has to pre decoded before the next instruction.
The instruction by itself is a 4 micro cycle instruction and can not 
combined with a other non 1 micro opcode instruction.

Tessa

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

#52269

On Fri, 28 Oct 2016 04:09:53 -0700 (PDT), jasmijn Bonting
<tessa.bonting@gmail.com> wrote:

>It is still slow, since the total instruction for large immidates is
>longer then 7 bytes and has to pre decoded before the next instruction.
>The instruction by itself is a 4 micro cycle instruction and can not 
>combined with a other non 1 micro opcode instruction.

Thanks for the reminder and telling me that the problem still exists.

Stephen

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

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

#52272

jasmijn Bonting <tessa.bonting@gmail.com> writes:
>Op vrijdag 28 oktober 2016 09:31:47 UTC+2 schreef Stephen Pelc:
>> On Thu, 27 Oct 2016 09:42:20 GMT, anton@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>> 
>> >It can be reduced to two instructions on IA-32, as SwiftForth demonstrates:
>> >
>> >see foo2 
>> >8083C4F   1 # 0 [EBP] ADD               83450001
>> >8083C53   1 # EBX SUB                   83EB01
>> >8083C56   RET                           C3 ok
>> >
>> >Apparently SwiftForth has an optimization rule for n /STRING; whether
>> >this is faster than the VFX code depends on the actual processor.
>> 
>> At some stage in the past (I forget for which x86 CPU),
>> memory/immediate instructions became very slow. At that point,
>> we removed their use by the VFX code generator. Ho, hum, time
>> to read up on current CPUs.
>> 
>> Stephen
>> 
>
>It is still slow, since the total instruction for large immidates is longer then 7 bytes and has to pre decoded before the next instruction.
>The instruction by itself is a 4 micro cycle instruction and can not 
>combined with a other non 1 micro opcode instruction.

I have now done a benchmark: ten copies of the "1 /STRING" code, but
with different memory locations for the second stack items to avoid
the dependence-through-memory slowdown that would probably swamp all
other effects.  Here are two copies:

VFX-like             SF-like
movq (%rdi), %rax    addq $1, 0(%rdi)
addq $1, %rax        subq $1, %rsi   
movq %rax, (%rdi)    addq $1, 8(%rdi)
subq $1, %rsi        subq $1, %rsi   
movq 8(%rdi), %rax
addq $1, %rax
movq %rax, 8(%rdi)
subq $1, %rsi

100M iterations of these ten copies take the following number of cycles:

VFX-like    SF-like
1537853028  1167890963 Phenom II X2 560
1105969806  1021509951 Core i7 4690K (Haswell)

So the SwiftForth-like code is faster than the VFX-like code on both
the Phenom II and the Haswell.

- 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 2016: http://www.euroforth.org/ef16/

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

#52273

On Friday, October 28, 2016 at 1:09:47 PM UTC-4, Anton Ertl wrote:
> jasmijn Bonting <tessa.bonting@gmail.com> writes:
> >Op vrijdag 28 oktober 2016 09:31:47 UTC+2 schreef Stephen Pelc:
> >> On Thu, 27 Oct 2016 09:42:20 GMT, anton@mips.complang.tuwien.ac.at
> >> (Anton Ertl) wrote:
> >> 
> >> >It can be reduced to two instructions on IA-32, as SwiftForth demonstrates:
> >> >
> >> >see foo2 
> >> >8083C4F   1 # 0 [EBP] ADD               83450001
> >> >8083C53   1 # EBX SUB                   83EB01
> >> >8083C56   RET                           C3 ok
> >> >
> >> >Apparently SwiftForth has an optimization rule for n /STRING; whether
> >> >this is faster than the VFX code depends on the actual processor.
> >> 
> >> At some stage in the past (I forget for which x86 CPU),
> >> memory/immediate instructions became very slow. At that point,
> >> we removed their use by the VFX code generator. Ho, hum, time
> >> to read up on current CPUs.
> >> 
> >> Stephen
> >> 
> >
> >It is still slow, since the total instruction for large immidates is longer then 7 bytes and has to pre decoded before the next instruction.
> >The instruction by itself is a 4 micro cycle instruction and can not 
> >combined with a other non 1 micro opcode instruction.
> 
> I have now done a benchmark: ten copies of the "1 /STRING" code, but
> with different memory locations for the second stack items to avoid
> the dependence-through-memory slowdown that would probably swamp all
> other effects.  Here are two copies:
> 
> VFX-like             SF-like
> movq (%rdi), %rax    addq $1, 0(%rdi)
> addq $1, %rax        subq $1, %rsi   
> movq %rax, (%rdi)    addq $1, 8(%rdi)
> subq $1, %rsi        subq $1, %rsi   
> movq 8(%rdi), %rax
> addq $1, %rax
> movq %rax, 8(%rdi)
> subq $1, %rsi
> 
> 100M iterations of these ten copies take the following number of cycles:
> 
> VFX-like    SF-like
> 1537853028  1167890963 Phenom II X2 560
> 1105969806  1021509951 Core i7 4690K (Haswell)
> 
> So the SwiftForth-like code is faster than the VFX-like code on both
> the Phenom II and the Haswell.
> 
> - 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 2016: http://www.euroforth.org/ef16/
Sure, the numbers are smaller for the SF-like version, but those numbers 
are so big that they don't tell me a clear story. Can you put the results 
into something a human can wrap his head around, as in "the difference 
results in the VFX version taking <X> seconds|minutes|hours longer to 
execute on a data size of <Y>"?

If it is only a second or two for 100 MILLION iterations, then ... sure it 
is faster, but the difference PER CYCLE is so small that the difference will 
never be noticed in practice.

At the end of the day though, knowing which is faster IS valuable, because 
it never hurts to do things as efficiently as possible.

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

#52286

Chris Curl <ccurl609@gmail.com> writes:
>On Friday, October 28, 2016 at 1:09:47 PM UTC-4, Anton Ertl wrote:
>> I have now done a benchmark: ten copies of the "1 /STRING" code, but
>> with different memory locations for the second stack items to avoid
>> the dependence-through-memory slowdown that would probably swamp all
>> other effects.  Here are two copies:
>> 
>> VFX-like             SF-like
>> movq (%rdi), %rax    addq $1, 0(%rdi)
>> addq $1, %rax        subq $1, %rsi   
>> movq %rax, (%rdi)    addq $1, 8(%rdi)
>> subq $1, %rsi        subq $1, %rsi   
>> movq 8(%rdi), %rax
>> addq $1, %rax
>> movq %rax, 8(%rdi)
>> subq $1, %rsi
>> 
>> 100M iterations of these ten copies take the following number of cycles:

Now including Skylake:

VFX-like    SF-like
1537853028  1167890963 Phenom II X2 560
1105969806  1021509951 Core i7 4690K (Haswell)
1102112502  1010674749 Core i7 6700K (Skylake)

>> So the SwiftForth-like code is faster than the VFX-like code on both
>> the Phenom II and the Haswell.
...
>Sure, the numbers are smaller for the SF-like version, but those numbers 
>are so big that they don't tell me a clear story. Can you put the results 
>into something a human can wrap his head around, as in "the difference 
>results in the VFX version taking <X> seconds|minutes|hours longer to 
>execute on a data size of <Y>"?

It depends on how /STRING is used in the application.  An application
that calls 1 /STRING 1e12 times in a way that is similar (wrt
dependences and resource consumption) to the microbenchmark will run
22s faster on a Core i7-6700K in turbo mode (4.2GHz) and 112s faster
on the Phenom II X2 560 (3.3GHz) with the SF-like variant than with
the VFX-like variant.  I doubt that is really very informative, though.

Another way to look at it is, that if you ignore this kind of
difference everywhere else, your programs will run slower by a factor
of 1.08 (Haswell) ... 1.32 (Phenom II) than if you always go for the
faster code.

>If it is only a second or two for 100 MILLION iterations, then ... sure it 
>is faster, but the difference PER CYCLE is so small that the difference will 
>never be noticed in practice.

It's more like 0.01s on Phenom II and less on the Intel chips.
However, if you have a 1 /STRING in an inner loop (as can easily
happen), you can easily get more than 100M executions in a program,
and you can get a noticable (Phenom II) or at least measurable
difference even in an application.

>At the end of the day though, knowing which is faster IS valuable, because 
>it never hurts to do things as efficiently as possible.

Sometimes it has it's cost, but knowing which is faster by how much
let's you make an informed decision on whether the speedup is worth
the cost.

- 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 2016: http://www.euroforth.org/ef16/

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

#52038

foxaudioresearch@gmail.com wrote:
> I noticed a lot of code uses the phrase 1 /STRING so I made a word I call SNIP.
>
> : snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;
>
> It's not rocket science but in my ITC system SNIP was 3 times faster than
> 1 /STRING.  Seems like a Forthy thing to do if 1 /STRING is used a lot.
>
> BF
>
> (I was going to call it MOHEL, but thought better of it.)
>  :-)

Is your /STRING written in machine code?

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

#52042

No. I was comparing Forth to Forth.

It is impressive to see what VFX turns /STRING into!  Wow.  That's tight code..

I will optimize /string.

BF

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

#52087

Forth APIs seem very confusing, as to which ones work with which Forths. And varying conventions. 

Anyway this looked interesting: 
http://www-personal.umich.edu/~williams/archive/forth/strings/fstrings/fstrings.txt

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

#52090

In article <9c78f98e-09a2-491e-94dc-e986d24e7c1b@googlegroups.com>,
trans  <transfire@gmail.com> wrote:
>Forth APIs seem very confusing, as to which ones work with which Forths. And varying conventions.
>
>Anyway this looked interesting:
>http://www-personal.umich.edu/~williams/archive/forth/strings/fstrings/fstrings.txt

Sensible and solid piece of work.
However.

After decennia of working with my 5 word ministring package I never
encountered a situation where I would rather use Williams package.

I'm now full busy with Basic Lisp and pascal compilers. For this I'm
inclined to go special purpose, and get dynamic strings tightly
coupled to my ALLOCATE (including "Hugh's" SIZE).

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]

#52204

On Friday, October 21, 2016 at 4:07:20 AM UTC-7, trans wrote:
> Forth APIs seem very confusing, as to which ones work with which Forths. And varying conventions. 
> 
> Anyway this looked interesting: 
> http://www-personal.umich.edu/~williams/archive/forth/strings/fstrings/fstrings.txt

I skimmed over that article FSTRINGS.TXT --- he isn't doing any memory-management, so it is not directly interesting to me --- I might be willing to switch over to his naming convention though; mine is based on QBASIC which he didn't like.

He has some functions that I don't have. Rotating strings, for example --- I could implement that if there were a demand --- I don't know what it is for.

He has some functions for treating strings as sets --- I could implement that too --- I'm also unclear on what that is for, but it seems more likely.

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

#52216

On 10/25/16 7:38 PM, hughaguilar96@gmail.com wrote:
 > On Friday, October 21, 2016 at 4:07:20 AM UTC-7, trans wrote:
 >> [...]
 >>
 >> Anyway this looked interesting:
 >> http://www-personal.umich.edu/~williams/archive/forth/strings/
 >> fstrings/fstrings.txt
 >>
 >
 > I skimmed over that article FSTRINGS.TXT --- he isn't doing any
 > memory-management, so it is not directly interesting to me --- I might
 > be willing to switch over to his naming convention though; mine is
 > based on QBASIC which he didn't like.

Just in case there's any confusion, the article is not by me, but rather
by Marcus Gabriel, as explained here:

http://www.umich.edu/~williams/archive/forth/strings/fstrings/readme.txt

My own dynamic-strings package,

http://www.umich.edu/~williams/archive/forth/strings/dstrings.html

with string stack and garbage collection, was apparently too elaborate
to have been taken up by Forthists, although I am fairly proud of it.

My more conventional ANS Forth string library

http://www.umich.edu/~williams/archive/forth/strings/mstrings.html

works with the data stack and buffers allocated by the user.  It is lean,
to me at least.

-- David W.

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

#52217

On 10/26/16 10:50 AM, David N. Williams wrote:
>
> Just in case there's any confusion, the article is not by me, but rather
> by Marcus Gabriel, as explained here:

Oops!  It's by George Hawkins!

-- David W.

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

#52218

In article <nuqfri$k4m$1@dont-email.me>,
David N. Williams <williams@umich.edu> wrote:
>On 10/25/16 7:38 PM, hughaguilar96@gmail.com wrote:
> > On Friday, October 21, 2016 at 4:07:20 AM UTC-7, trans wrote:
> >> [...]
> >>
> >> Anyway this looked interesting:
> >> http://www-personal.umich.edu/~williams/archive/forth/strings/
> >> fstrings/fstrings.txt
> >>
> >
> > I skimmed over that article FSTRINGS.TXT --- he isn't doing any
> > memory-management, so it is not directly interesting to me --- I might
> > be willing to switch over to his naming convention though; mine is
> > based on QBASIC which he didn't like.
>
>Just in case there's any confusion, the article is not by me, but rather
>by Marcus Gabriel, as explained here:
>
>http://www.umich.edu/~williams/archive/forth/strings/fstrings/readme.txt
>
>My own dynamic-strings package,
>
>http://www.umich.edu/~williams/archive/forth/strings/dstrings.html
>
>with string stack and garbage collection, was apparently too elaborate
>to have been taken up by Forthists, although I am fairly proud of it.
>
>My more conventional ANS Forth string library
>
>http://www.umich.edu/~williams/archive/forth/strings/mstrings.html
>
>works with the data stack and buffers allocated by the user.  It is lean,
>to me at least.

I see with respect the neatness and the amount of work that is gone
into this. However, if you're honest, can you testify that all
those words have been used at least once in your life, or someone else
who use the package?

If I look at the way I handle strings, I always use a fixed buffer,
and merely 5 words that I can remember easily.
Lately I've added .format that uses %xxx with xxx in a user extendable
wordlist.

The only thing I miss is the word $\ (string-slash-from-behind)
analogous to $/ (string slash) :
This would do
"/home/scan/mimi/test090910.tif" &/ $\ TYPE TYPE

/home/scan/mimi test090910.tif

Now I'm thinking about how turn a pascal program (file size long string)
into a Forth program (idem). My conclusion is that it needs special
string handling, closely coupled to an ALLOCATE implementation.
This results in a very limited set of words, and very little copying
and also very little generality.
I'm always am surprised with the ease one introduces string concatenation
$+ that can easily lead to quadratic run time in e.g. the above case
and immediately confronts one with problems like memory recovery/
garbage collection.

>
>-- David W.
>

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]

#52242

On 10/26/16 11:33 AM, Albert van der Horst wrote:
 > In article <nuqfri$k4m$1@dont-email.me>,
 > David N. Williams <williams@umich.edu> wrote:
 >> [...]
 >>
 >> My own dynamic-strings package,
 >>
 >> http://www.umich.edu/~williams/archive/forth/strings/dstrings.html
 >>
 >> with string stack and garbage collection, was apparently too elaborate
 >> to have been taken up by Forthists, although I am fairly proud of it.
 >>
 >> My more conventional ANS Forth string library
 >>
 >> http://www.umich.edu/~williams/archive/forth/strings/mstrings.html
 >>
 >> works with the data stack and buffers allocated by the user.  It is 
lean,
 >> to me at least.
 >
 > I see with respect the neatness and the amount of work that is gone
 > into this. However, if you're honest, can you testify that all
 > those words have been used at least once in your life, or someone else
 > who use the package?

I can't say that I've used them all, beyond testing; but I have used a
fair number of them.  I can't speak for other users.  I actually know of
only one (if memory serves), and that was experimental.

 > If I look at the way I handle strings, I always use a fixed buffer,
 > and merely 5 words that I can remember easily.

I understand the appeal of doing much with few words.  However, I'm
firmly in the library camp.  To me, a library is a collection of words
organized for a purpose for which there is a more or less natural
logical structure.  I find it more of a conceptual load to omit words
that logically "ought" to be there than to include them.  Coming from
there, I admit that I probably get seduced into over-elaboration.  But
actually I'm not so sure it's unjustified.  I guess it's not for me to
say.  It goes without saying that a library needs to be well documented
and tested.

Even worse, I'm in the multiple namespace and multiple stack camps.  :-)

 > Lately I've added .format that uses %xxx with xxx in a user extendable
 > wordlist.
 >
 > The only thing I miss is the word $\ (string-slash-from-behind)
 > analogous to $/ (string slash) :
 > This would do
 > "/home/scan/mimi/test090910.tif" &/ $\ TYPE TYPE
 >
 > /home/scan/mimi test090910.tif

Nice word!

 > Now I'm thinking about how turn a pascal program (file size long string)
 > into a Forth program (idem). My conclusion is that it needs special
 > string handling, closely coupled to an ALLOCATE implementation.
 > This results in a very limited set of words, and very little copying
 > and also very little generality.
 > I'm always am surprised with the ease one introduces string concatenation
 > $+ that can easily lead to quadratic run time in e.g. the above case
 > and immediately confronts one with problems like memory recovery/
 > garbage collection.

It was not *the* design purpose, but this an example of the kind of
thing the dstrings library was designed for.  Before the project got
scooped by the open sourcing of Vermaseren's FORM and the demise of the
ppc, I was well along in a project that was using it to write a text
translater for Veltman's Schoonschip M680x0 assembly language source to
ppc assembly language.

There was also a Forth to pfe C project (which I don't guarantee to work
with the latest dstrings.):

   http://www.umich.edu/~williams/archive/forth/hatforth/

A simpler example, which may even still work, is a text translator I
wrote to translate C library binding descriptions to pfe C bindings:

http://www.umich.edu/~williams/archive/forth/gmpfr/#pfebindings

This was used with the forth-gmpfr bignum package.

-- David

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

#52253

On 10/27/16 10:16 AM, David N. Williams wrote:

> It was not *the* design purpose, but this an example of the kind of
> thing the dstrings library was designed for.  Before the project got
> scooped by the open sourcing of Vermaseren's FORM and the demise of the
> ppc, I was well along in a project that was using it to write a text
> translater for Veltman's Schoonschip M680x0 assembly language source to
> ppc assembly language.

That's interesting. Long ago when Macs were 680x0 I invested
considerable time and effort learning (Forth) assembler for the same. I
had a few non-trivial routines written that way including a fast
Boyer-Moore text search. But all that effort was negated when Macs moved
to the PPC. It was then that I vowed to stick with high level standard
Forth and I haven't looked back. No regrets. Optimizing compilers like
VFX do an excellent job.

-Doug

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

#52244

Op Wed, 26 Oct 2016 17:33:08 +0200 (CEST) schreef Albert van der Horst:

<snip>
> The only thing I miss is the word $\ (string-slash-from-behind)
> analogous to $/ (string slash) :
> This would do
> "/home/scan/mimi/test090910.tif" &/ $\ TYPE TYPE
> 
> /home/scan/mimi test090910.tif
> 
> 
> Groetjes Albert

I've two words for that, only for path+filenames, looks only for both
slashes and dots.

  ident          type f:/bin/f.exe
  ident basename type f.exe
  ident dirname  type f:/bin

(DOS accepts forward slashes, I like them better)

groet Coos

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

#52111

foxaudioresearch@gmail.com wrote:

> I noticed a lot of code uses the phrase 1 /STRING so I made a word I call
> SNIP.
> 
> : snip      ( addr len -- addr' len' ) 1- swap 1+ swap ;
> 
> It's not rocket science but in my ITC system SNIP was 3 times faster than
> 1 /STRING.  Seems like a Forthy thing to do if 1 /STRING is used a lot.
4tH has got a similar word called CHOP. I use it more regularly than /STRING
(can't even remember when I used that one for the last time. Must have been
while I was porting something). IMHO it is a useful abstraction.

Hans Bezemer

[toc] | [prev] | [standalone]

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

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

csiph-web