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

#52175

On Monday, October 24, 2016 at 4:36:57 AM UTC-7, Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Presumably code that uses CHARS in some places and
> >not others, CHAR+ in some places and 1+ in others, in a willy-nilly
> >fashion is now perfectly legal under 200x ?
> 
> Not sure what you mean with willy-nilly.  Forth-94 and Forth-2012
> programs can also use 1+, CHAR+, and CHARS in the same program.  In
> the next standard a standard program can use 1+ where a Forth-2012
> program should have used CHAR+ and use nothing where a Forth-2012 program
> should have used CHARS or 1 CHARS /.
> 
> >CHARS and CHAR+ are still there (and need to be)
> 
> They need to be there for compatibility with standard Forth-2012
> programs; they also allow people to use them who feel the urge to use
> these words for whatever reasons.

ANS-Forth and Forth-200x are both products of the 1970s. ANS-Forth's /STRING is to programming what bell-bottom jeans are to fashion --- cool in its day, but not something that anybody cares about now.

In Straight Forth the programmer will almost never directly access chars. You only work with strings --- some strings may have only one char in them --- this is the same as with my string-stack.4th that is written in ANS-Forth.

The char in Straight Forth could be an 8-bit ascii char, or a 32-bit UTF-32 char --- the user doesn't care if they are 1 byte or 4 bytes, because he doesn't directly access the chars (I'm actually using ascii right now, although later on I will upgrade to UTF-32).

Cells in Straight Forth are 64-bit (8 bytes), with numbers being fixed-point with an assumed unity of 2^32. All arrays have to have an element size that is a multiple of the cell size (the cell size is called W rather than CELL). This includes strings. Chars are UTF-32. So, a string element is a cell with only the integer part containing data but nothing in the fractional part --- this is wasteful of memory, as only 32 bits are needed for UTF-32, but 64 bits are being used --- I don't care because modern computers have plenty of memory.

I will provide functions to compress strings into UTF-8 for compact storage, and to uncompress them back into the format described above for working with them. That could be useful for programs that work with a large amount of text --- a text-editor for example --- it might not be needed though, as we do have virtual memory nowadays.

Most all of the design decisions of ANS-Forth assume the PDP-11 which had only eight 16-bit registers and only 64KB memory total. Charles Moore wrote Forth for the PDP-11 because it was state of the art at the time, and Elizabeth Rather has been carrying his design decisions onward for decades --- she acts like she is Moses and these design decisions were written in stone by the finger of God --- this is despite the fact that these design decision became obsolete at about the same time that Charles Moore got kicked out of Forth Inc. (1982).

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

#52278

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Anton Ertl wrote:
> >> And at the last meeting we standardized "1 chars = 1".  So if the
> >> address unit is a byte, /STRING works on bytes.
> ...
> >That option already existed under Forth-94.
>
> Yes, it was an option, and all popular systems implemented this
> option, and many programs rely on it.  I.e., it is common practice,
> and that's why we standardized it.

No.  It may be a fact that on most systems "1 chars = 1" but that doesn't
give carte blanche to programmers to write 'standard programs' in a
manner that disregards datatype.  ANS was explicit that certain functions
should handle characters, while others cells, address units and so on.

I don't write professionally so none of this affects me.  I don't even bother
to document code for my own benefit.  I get away with it because chances
are nobody will read my code and should anyone find it necessary, they will
eventually work it out.  But that isn't what Forth Standards are about, is it.
A 'Standard Forth Program' is meant to be professional and readable as
well as portable.  ANS went to pains to get Forth programmers to write code
that is clear, consistent and informative.  I think it's a mistake to wind back
the clock.

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

#52284

HAA <someone@microsoft.com> wrote:
> Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >Anton Ertl wrote:
>> >> And at the last meeting we standardized "1 chars = 1".  So if the
>> >> address unit is a byte, /STRING works on bytes.
>> ...
>> >That option already existed under Forth-94.
>>
>> Yes, it was an option, and all popular systems implemented this
>> option, and many programs rely on it.  I.e., it is common practice,
>> and that's why we standardized it.
> 
> No.  It may be a fact that on most systems "1 chars = 1" but that doesn't
> give carte blanche to programmers to write 'standard programs' in a
> manner that disregards datatype.

It does now.  "CHARS" was almost always nonsensical anyway.

> ANS was explicit that certain functions should handle characters,
> while others cells, address units and so on.

Time moves on: an address unit is a byte, and a byte is large enough
to hold a primitive character.

> I don't write professionally so none of this affects me.  I don't
> even bother to document code for my own benefit.  I get away with it
> because chances are nobody will read my code and should anyone find
> it necessary, they will eventually work it out.  But that isn't what
> Forth Standards are about, is it.  A 'Standard Forth Program' is
> meant to be professional and readable as well as portable.  ANS went
> to pains to get Forth programmers to write code that is clear,
> consistent and informative.

Perhaps, but I don't believe that's relevant.  Forth has always been
about simplicity and economy.  Sprinkling no-op words like CHARS over
programs never went any way towards that goal.  I believe that words
which (in must cases) literally do nothing are antithetical to Forth.
Leave the syntactic sugar to languages whose users like that stuff.

Andrew.

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

#52288

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >Anton Ertl wrote:
>> >> And at the last meeting we standardized "1 chars = 1".  So if the
>> >> address unit is a byte, /STRING works on bytes.
>> ...
>> >That option already existed under Forth-94.
>>
>> Yes, it was an option, and all popular systems implemented this
>> option, and many programs rely on it.  I.e., it is common practice,
>> and that's why we standardized it.
>
>No.  It may be a fact that on most systems "1 chars = 1" but that doesn't
>give carte blanche to programmers to write 'standard programs' in a
>manner that disregards datatype.

Certainly these programs were not standard programs; they could be
labeled as "standard programs with an environmental dependency on 1
chars = 1".  With the next standard, these programs will be standard
programs.

>ANS was explicit that certain functions
>should handle characters, while others cells, address units and so on.

Yes.  And it turned out that differentiating between chars and address
units was a freedom for systems that no widely-used system exploited;
and on the program side, most programmers chose to ignore this
theoretical difference.  But even those that did not cannot be sure
that their program does not have that environmental dependency (in
Forth-94 and -2012), because they have no way to test their programs
on a system that does not satisfy the environmental dependency.

>A 'Standard Forth Program' is meant to be professional and readable as
>well as portable.  ANS went to pains to get Forth programmers to write code
>that is clear, consistent and informative.

I don't see any particular move in Forth-94 towards requiring
additional words for informative purposes only.

The introduction of CHARS and CHAR+ did not happen for informative
purposes, but for abstracting the character size in the same way that
CELLS and CELL+ abstracts cell size (which became necessary due to the
move from 16-bit systems towards larger cell sizes).  The reasons why
they thought that we would need to abstract the character size were:

1) Nybble-addressed machines, where 8-bit chars would take 2 aus.

2) Unicode, which around 1990 looked to be a 2-byte fixed-width
character set (UCS-2).

However, looking at it 22 years later, no Forth-94 implementation for
nybble-addressed machines is known to me, and it's unlikely that we
will ever see one for the next standard; and it turned out that UCS-2
is not good enough for Unicode, that we can work with Unicode nicely
using 8-bit units, and as a result, the move towards wider chars that
was the reason for introducing CHARS and CHAR+ has not happened in
Forth systems.

Anyway, if you feel the need to use these unnecessary abstractions in
your programs, they are still there, and nobody has proposed removing
them, so you are free to use these words to write what you consider
professional, readable, clear, consistent and informative code.

- 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]

#52298

On Saturday, October 29, 2016 at 9:49:41 AM UTC-7, Anton Ertl wrote:
> The introduction of CHARS and CHAR+ did not happen for informative
> purposes, but for abstracting the character size in the same way that
> CELLS and CELL+ abstracts cell size (which became necessary due to the
> move from 16-bit systems towards larger cell sizes).  The reasons why
> they thought that we would need to abstract the character size were:
> 
> 1) Nybble-addressed machines, where 8-bit chars would take 2 aus.
> 
> 2) Unicode, which around 1990 looked to be a 2-byte fixed-width
> character set (UCS-2).
> 
> However, looking at it 22 years later, no Forth-94 implementation for
> nybble-addressed machines is known to me, and it's unlikely that we
> will ever see one for the next standard; and it turned out that UCS-2
> is not good enough for Unicode, that we can work with Unicode nicely
> using 8-bit units, and as a result, the move towards wider chars that
> was the reason for introducing CHARS and CHAR+ has not happened in
> Forth systems.

This is a typical example of how the ANS-Forth and Forth-200x committees get bogged down in nonsense.

In Straight Forth the programmer doesn't generally have access to chars. The programmer only works with strings. Why would anybody want to have access to a char? What does this do for you that a string with length of 1 does not do? If you are working only with strings, you have a lot of functions that do useful things --- there are no functions that do anything with chars.

A Straight Forth system would normally use UTF-32. It would be possible to have a Straight Forth system that uses one of the 8-bit ascii extension though, and it would have to declare this fact. Programs should compile and run just fine under all of these systems --- the only problem would be if one of your literal strings in the source-code contains a char that is not represented in the underlying character scheme (for example: pi is not in ascii).
 
> Anyway, if you feel the need to use these unnecessary abstractions in
> your programs, they are still there, and nobody has proposed removing
> them, so you are free to use these words to write what you consider
> professional, readable, clear, consistent and informative code.

Nobody on the ANS-Forth committee knows what "abstraction" means. CHARS was just nonsense. The Forth-200x committee doesn't know either, because they are requiring 8-bit chars on the theory that this is what most users need, and to hell with those who need 16-bit or 32-bit chars.

Straight Forth abstracts away the character format (UTF-32 UTF-8 extended-ascii, etc.) by only making strings available to the user --- the string is an abstraction of the concept: "array of chars" --- this is how abstraction works!

It is possible in Straight Forth for a programmer to load a string into PTR and CNT and directly access the chars, in which case the programmer obviously needs to know what format the chars are, and needs to know how big the chars are. Programmers are strongly discouraged from writing such low-level code unless absolutely necessary --- for ordinary application programs, the programmer just works with strings and doesn't worry about what the underlying character format is or how big the chars are --- leave low-level code to the code-library writers (code libraries have dependencies).

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

#52327

Anton Ertl wrote:
> ...
> The introduction of CHARS and CHAR+ did not happen for informative
> purposes,

How do you know?  It can't be ruled out.

> but for abstracting the character size in the same way that
> CELLS and CELL+ abstracts cell size (which became necessary due to the
> move from 16-bit systems towards larger cell sizes).  The reasons why
> they thought that we would need to abstract the character size were:
>
> 1) Nybble-addressed machines, where 8-bit chars would take 2 aus.
>
> 2) Unicode, which around 1990 looked to be a 2-byte fixed-width
> character set (UCS-2).

I'm sure these were issues.  The practical consequence of Forth-94
introducing mnemonics for the two most used datatypes in Forth was
portability and readability.  Forth had been dogged by complaints of
'write-only' code and ANS helped address that.

> Anyway, if you feel the need to use these unnecessary abstractions in
> your programs, they are still there, and nobody has proposed removing
> them, so you are free to use these words to write what you consider
> professional, readable, clear, consistent and informative code.

The fact is CHAR+ CHARS are necessary and must remain in CORE so
systems can read/write portable code.  200x needs to explain to users
what it hopes to gain by allowing coding such as this:

: nextword \ ad -- ad'
  dup c@ + 1+ ;

Forth-94 would require it be written:

: nextword \ ad -- ad'
  dup c@ 1+ CHARS + ;

It's not just the addition of CHARS that's different, the logic has changed
for the better.

(no offence to the original author intended)

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

#52329

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> ...
>> The introduction of CHARS and CHAR+ did not happen for informative
>> purposes,
>
>How do you know?  It can't be ruled out.

It says so in the Forth-94 document.  From E.2.3:

|However, there are cases where a character is larger than an address
|unit. Examples include (1) systems with small address units (e.g.,
|bit- and nibble-addressed systems), and (2) systems with large
|character sets (e.g., 16-bit characters on a byte-addressed
|machine). CHAR+ and CHARS operators, analogous to CELL+ and CELLS are
|available to allow maximum portability.

>> Anyway, if you feel the need to use these unnecessary abstractions in
>> your programs, they are still there, and nobody has proposed removing
>> them, so you are free to use these words to write what you consider
>> professional, readable, clear, consistent and informative code.
>
>The fact is CHAR+ CHARS are necessary and must remain in CORE so
>systems can read/write portable code.

Systems don't write code.  And programs using CHAR+ CHARS are not any
more portable in practice than code using 1+ and nothing.

>200x needs to explain to users
>what it hopes to gain by allowing coding such as this:
>
>: nextword \ ad -- ad'
>  dup c@ + 1+ ;

More standard programs; another benefit is that this reflects the
mainstream of Forth usage in the standard, so that system implementors
are not misled into thinking that it's a good idea to choose UTF-16 as
char encoding on byte-addressed machines.

- 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]

#52086

Don't quite get anti-mid vs anti-inner. Also their names seem odd.

P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?

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

#52121

On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
> Don't quite get anti-mid vs anti-inner. Also their names seem odd.

They are simple and obvious. Here is the excerpt:
--------------------------------------------------------------------
MID$                        ( start-index length -- )           \ string: a -- b
The B string is a substring in the middle of the A string.

ANTI-MID$                   ( start-index length -- )           \ string: a -- b
Returns the string with the middle part extracted (what MID$ would have 
returned is not returned, but instead the edge parts concatenated together are 
returned).

INNER$                      ( start-index limit-index -- )      \ string: a -- b
This is like MID$ except that it uses a LIMIT-INDEX rather than a LENGTH (this 
is somewhat like Mark Wills' MID$ and, to the best of my recollection, like 
the QBASIC MID$). Note that the LIMIT-INDEX is 1 beyond the middle-part that 
is kept (LIMIT-INDEX minus START-INDEX equals length).

ANTI-INNER$                 ( start-index limit-index -- )      \ string: a -- b
Returns the string with the middle part extracted (what INNER$ would have 
returned is not returned, but instead the edge parts concatenated together are 
returned). Note that the LIMIT-INDEX is 1 beyond the middle-part that is 
extracted (LIMIT-INDEX minus START-INDEX equals length).
--------------------------------------------------------------------

MID$ takes a start-index and a length
INNER$ takes a start-index and a limit-index
These two extract a sub-string from the middle of a string.
This is how INNER$ is defined:

: inner$ ( start-index limit-index -- )                         \ string: a -- b
    over -  mid$ ;

ANTI-MID$ and ANTI-INNER$ are like MID$ and INNER$ except that instead of returning the sub-string in the middle, they discard the middle part and return the rest of the string (the two edge sub-strings concatenated together).

What don't you get?

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

#52122

On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
> P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?

I'm not reinventing the wheel. The memory-management system in string-stack.4th is my own invention. Nobody else has ever done anything like this.

The history here is that Mark Wills suggested to me that I write a string-stack package that used the heap. My original plan was pretty simple --- every time that a string is duplicated (with DUP$ OVER$ etc.) I would ALLOCATE a new string and copy the old string to the new string --- this way, any changes made to one string won't affect the other string.

This original plan is actually quite slow however, so it wasn't acceptable to me. My invention was the "unique" and "derivative" strings. A derivative string is just a reference to the unique string, so ALLOCATE is not necessary, and copying the string is not necessary. Only if the derivative string is going to change does it get converted into a unique string. Also, if a unique is going to change, then all of its derivatives get converted into uniques so they don't get affected. A lot of what you do with strings doesn't change them, so in many cases it is not necessary to convert derivatives into uniques. For example, printing out a string doesn't change it. 

I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.

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

#52123

On Saturday, October 22, 2016 at 11:13:37 PM UTC-4, hughag...@gmail.com wrote:
> On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
> > P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?
> 
> I'm not reinventing the wheel. The memory-management system in string-stack.4th is my own invention. Nobody else has ever done anything like this.
> 
> The history here is that Mark Wills suggested to me that I write a string-stack package that used the heap. My original plan was pretty simple --- every time that a string is duplicated (with DUP$ OVER$ etc.) I would ALLOCATE a new string and copy the old string to the new string --- this way, any changes made to one string won't affect the other string.
> 
> This original plan is actually quite slow however, so it wasn't acceptable to me. My invention was the "unique" and "derivative" strings. A derivative string is just a reference to the unique string, so ALLOCATE is not necessary, and copying the string is not necessary. Only if the derivative string is going to change does it get converted into a unique string. Also, if a unique is going to change, then all of its derivatives get converted into uniques so they don't get affected. A lot of what you do with strings doesn't change them, so in many cases it is not necessary to convert derivatives into uniques. For example, printing out a string doesn't change it. 
> 
> I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.

In that case disregard everything I said.

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

#52142

On Saturday, October 22, 2016 at 9:09:18 PM UTC-7, trans wrote:
> On Saturday, October 22, 2016 at 11:13:37 PM UTC-4, hughag...@gmail.com wrote:
> > I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.
> 
> In that case disregard everything I said.

I have said that I want Straight Forth to be a grassroots effort, and that I am willing to listen to input from Forth programmers.

I said above: "I don't need to look at their stuff." What I meant here, is that I want to avoid a situation like we have in Forth-200x. On the Forth-200x mailing-list, there are a lot of people who seem to know very little about Forth, but just think that it is pretty awesome that they get to participate in the design of the Forth-200x standard. The result is a lot of tedious discussions about nonsense. I want input on Straight Forth --- but only if the person is an actual programmer --- only if the person has something worthwhile to say, and isn't just playing big-expert make-believe.

Another bad thing about Forth-200x, is that ultimately Leon Wagner just decides what will be Forth-200x, and he is mostly focused on keeping SwiftForth legacy code going. For example, locals have been defined with { ... } since the late 1980s (the John Hopkins format), but Leon Wagner killed this in Forth-200x because SwiftForth uses { ... } for multi-line comments. I don't want to be like Leon Wagner and pretend to be interested in people's input, but to not actually care in the slightest. If a person has input that contradicts my ideas, I'm willing to change Straight Forth if this is shown to be better. It is a waste of everybody's time to solicit input and then ignore it, the way that Leon Wagner does.

I think that the whole purpose of the Forth-200x mailing list is just to collect names of "contributors." Even if a person withdraws from the mailing list and withdraws his support of Forth-200x, the Forth-200x committee will still list that person's name as a contributor. They just want people's names, so they can list them as contributors (which is assumed to mean supporters), but they don't actually want the people's input.

I do want people's input --- but only if they have given some thought to the subject --- if a person just wants to have fun being a big expert, but has nothing to contribute except idiot blather, then the person should stay with Forth-200x because I have no patience for this.

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

#52238

On 23/10/16 04:13, hughaguilar96@gmail.com wrote:
> On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
>> P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?
>
> I'm not reinventing the wheel. The memory-management system in string-stack.4th is my own invention. Nobody else has ever done anything like this.
>
> The history here is that Mark Wills suggested to me that I write a string-stack package that used the heap. My original plan was pretty simple --- every time that a string is duplicated (with DUP$ OVER$ etc.) I would ALLOCATE a new string and copy the old string to the new string --- this way, any changes made to one string won't affect the other string.
>
> This original plan is actually quite slow however, so it wasn't acceptable to me. My invention was the "unique" and "derivative" strings. A derivative string is just a reference to the unique string, so ALLOCATE is not necessary, and copying the string is not necessary. Only if the derivative string is going to change does it get converted into a unique string. Also, if a unique is going to change, then all of its derivatives get converted into uniques so they don't get affected. A lot of what you do with strings doesn't change them, so in many cases it is not necessary to convert derivatives into uniques. For example, printing out a string doesn't change it.
>
> I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.
>

The technique is very well known. It even has a name; COW. Copy On Write.

-- 
Alex

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

#52258

On Thursday, October 27, 2016 at 6:07:49 AM UTC-7, alex wrote:
> On 23/10/16 04:13, hughaguilar96@gmail.com wrote:
> > On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
> >> P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?
> >
> > I'm not reinventing the wheel. The memory-management system in string-stack.4th is my own invention. Nobody else has ever done anything like this.
> >
> > The history here is that Mark Wills suggested to me that I write a string-stack package that used the heap. My original plan was pretty simple --- every time that a string is duplicated (with DUP$ OVER$ etc.) I would ALLOCATE a new string and copy the old string to the new string --- this way, any changes made to one string won't affect the other string.
> >
> > This original plan is actually quite slow however, so it wasn't acceptable to me. My invention was the "unique" and "derivative" strings. A derivative string is just a reference to the unique string, so ALLOCATE is not necessary, and copying the string is not necessary. Only if the derivative string is going to change does it get converted into a unique string. Also, if a unique is going to change, then all of its derivatives get converted into uniques so they don't get affected. A lot of what you do with strings doesn't change them, so in many cases it is not necessary to convert derivatives into uniques. For example, printing out a string doesn't change it.
> >
> > I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.
> >
> 
> The technique is very well known. It even has a name; COW. Copy On Write.

I had never heard of Copy On Write --- I looked it up right now though and it does seem to be pretty much the same as what I'm doing.

If this is so "well known," why hasn't it ever been done in Forth before?

The reason why this technique, and other good ideas, have never been done in Forth before is that ANS-Forth is the "Standard." There aren't going to be any good ideas in Forth-200x either, because Forth-200x is mandated to be 100% compatible with ANS-Forth, and because all of the committee members are appointed by Elizabeth Rather.

The whole idea with Straight Forth is to escape from the dumb-as-dirt mentality that permeates Elizabeth Rather's toy language. I'm really never going to become an ANS-Forth or Forth-200x programmer --- that is just shameful --- that is like voluntarily signing up for the Special-Ed class.

There are a lot of good ideas in computer science. Quotations are one of them. This COW for strings is another one. There are others. I'm not saying that I can think up everything myself --- I'm saying that in Straight Forth good ideas will be made a part of the Standard.

Here is an excerpt from my Straight Forth document:
-----------------------------------------------------------------------------
There are seven types of data:
These are the 3 primary types of data:
1.) number          a signed 64-bit fixed-point with unity assumed to be 2^32 --- this includes pointers, etc.          
data-stack
2.) string          this is a one-cell struct containing a pointer and a count                                          
string-stack or data-stack
3.) xt              an "execution-token" --- this is a one-cell struct --- these are given to EXECUTE                   
data-stack
These are 4 more types of data, all of which are optional extensions:
4.) double-number   a 128-bit fixed-point with unity assumed to be 2^64                                                 
double-stack
5.) ratio           two 64-bit integers (unity assumed to be 1), which are a numerator and denominator                  
double-stack
6.) BFI             "big f'ing integer" --- a 128-bit integer with unity assumed to be 1                                                        
double-stack
7.) float           an IEEE-754 64-bit float                                                                            
float-stack
-----------------------------------------------------------------------------

The only use for BFI numbers that I can think of, is Nathaniel Grossman's continued-fraction program. The Float data-type is mostly only used for low-level numeric functions (SIN COS etc.), but all of the obvious ones are built-in anyway. Both of these can be ignored by almost all users. 

The Double and Ratio data-types are only useful for cases in which a Number lacks adequate precision and/or range. Both of these can be ignored by most users. 

Most programs will only use the Number, String and XT data-types --- the two "killer apps" are cross-compiling to micro-controllers (primarily Forth, but other languages as well), and CAM (generating gcode for CNC machines) --- these three basic data types should be adequate.

The two built-in data-structures are the Array and the Chain --- these (mostly the Chain) should be adequate for 99% of all Straight Forth programs.

I really really really hate ANS-Forth; I'm never going to become an ANS-Forth programmer --- the Straight Forth that I'm proposing is pretty simple --- support for the Number and String data-types, and the Array and Chain data-structures, seems obvious and non-controversial to me.

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

#52274

On 28/10/16 03:12, hughaguilar96@gmail.com wrote:
> On Thursday, October 27, 2016 at 6:07:49 AM UTC-7, alex wrote:
>> On 23/10/16 04:13, hughaguilar96@gmail.com wrote:
>>> On Friday, October 21, 2016 at 3:49:55 AM UTC-7, trans wrote:
>>>> P.S. I know what it is to feel like the outsider, having strong opinions that differ from the mainstream group. It can bw very frustrating! But chin up, I for one like these little lib. Why reinvent the wheel?
>>>
>>> I'm not reinventing the wheel. The memory-management system in string-stack.4th is my own invention. Nobody else has ever done anything like this.
>>>
>>> The history here is that Mark Wills suggested to me that I write a string-stack package that used the heap. My original plan was pretty simple --- every time that a string is duplicated (with DUP$ OVER$ etc.) I would ALLOCATE a new string and copy the old string to the new string --- this way, any changes made to one string won't affect the other string.
>>>
>>> This original plan is actually quite slow however, so it wasn't acceptable to me. My invention was the "unique" and "derivative" strings. A derivative string is just a reference to the unique string, so ALLOCATE is not necessary, and copying the string is not necessary. Only if the derivative string is going to change does it get converted into a unique string. Also, if a unique is going to change, then all of its derivatives get converted into uniques so they don't get affected. A lot of what you do with strings doesn't change them, so in many cases it is not necessary to convert derivatives into uniques. For example, printing out a string doesn't change it.
>>>
>>> I've never looked at any other string packages so I don't really know what they are doing, but I feel confident that my string-stack.4th is far superior to them --- I think up ideas, and they work --- nobody else is doing any thinking at all; I don't need to look at their stuff.
>>>
>>
>> The technique is very well known. It even has a name; COW. Copy On Write.
>
> I had never heard of Copy On Write --- I looked it up right now though and it does seem to be pretty much the same as what I'm doing.
>
> If this is so "well known," why hasn't it ever been done in Forth before?
>
> The reason why this technique, and other good ideas, have never been done in Forth before is that ANS-Forth is the "Standard." There aren't going to be any good ideas in Forth-200x either, because Forth-200x is mandated to be 100% compatible with ANS-Forth, and because all of the committee members are appointed by Elizabeth Rather.
>
> The whole idea with Straight Forth is to escape from the dumb-as-dirt mentality that permeates Elizabeth Rather's toy language. I'm really never going to become an ANS-Forth or Forth-200x programmer --- that is just shameful --- that is like voluntarily signing up for the Special-Ed class.
>

You are confusing implementation with definition. It's a common problem 
in standards work; it's not the job of the standard to tell you how to 
do things. Straight Forth appears to do quite a bit of telling you how 
to do things.

 > There are a lot of good ideas in computer science. Quotations are one 
of them. This COW for strings is another one. There are others. I'm not 
saying that I can think up everything myself --- I'm saying that in 
Straight Forth good ideas will be made a part of the Standard.
 >

You don't read widely enough. On several occasion you have claimed to 
have discovered or invented something, generally a technique or idea 
that has been know for many years.

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

#52279

On Friday, October 28, 2016 at 11:39:11 AM UTC-7, alex wrote:
> On 28/10/16 03:12, hughaguilar96@gmail.com wrote:
> > The reason why this technique, and other good ideas, have never been done in Forth before is that ANS-Forth is the "Standard." There aren't going to be any good ideas in Forth-200x either, because Forth-200x is mandated to be 100% compatible with ANS-Forth, and because all of the committee members are appointed by Elizabeth Rather.
> >
> > The whole idea with Straight Forth is to escape from the dumb-as-dirt mentality that permeates Elizabeth Rather's toy language. I'm really never going to become an ANS-Forth or Forth-200x programmer --- that is just shameful --- that is like voluntarily signing up for the Special-Ed class.
> >
> 
> You are confusing implementation with definition. It's a common problem 
> in standards work; it's not the job of the standard to tell you how to 
> do things. Straight Forth appears to do quite a bit of telling you how 
> to do things.

I know that a standard is supposed to standardize behavior rather than implementation. In my document, I don't say anything about the unique/derivative strings --- I just say that the string-stack is supposed to behave as if every string on the stack were unique. Similarly with chains I use a made-up name "chain" rather than specify how it is implemented (it is an AVL tree with an UP pointer) --- I take pains to document the behavior rather than the implementation --- chains could be implemented with doubly-linked lists too (this would make LEFT and RITE etc. faster, but SEARCH and INSERT etc. slower).

As for telling people what data-structures to use, I don't see a problem with that. Factor has "sequences," Lisp has lists --- Straight Forth has chains --- I learned Factor and I was impressed by how much readability was improved when everybody used sequences. In Straight Forth novice programmers use chains and don't implement their own data-structures, but intermediate programmers are also encouraged to use chains and not implement their own data-structures (although, being intermediate, they know how to write HOFs so they can implement their own data-structures). There are no advanced programmers in Straight Forth --- not even me; I use chains too --- I don't think it is useful to have advanced programmers because they would write programs that nobody else could understand (the other side of the coin is that most advanced programmers don't think high-level languages are useful, but they just program in assembly-language).

Readability is also improved by standardizing. In ANS-Forth there are multiple string-stack implementations (I have only looked at Mark Wills'), but all of them are different because there is no standard. I described MID$ and INNER$ above. Are these the best names for these functions? I don't care! They are reasonable names, so I'm going with that. The important point is that every Straight Forth implementation uses the same names --- even if they were goofy names such as Lisp's CAR and CDR it is still better to standardize something, rather than have everybody do everything different from one program to the next. Maybe red, amber and green are not the best colors for stop-lights and some people argue that green, purple and orange would be better, but we have to standardize on something or chaos will result. Also, we should strive to be reasonably compatible with everybody else in the world --- we don't want to be like the English who purposely make their standards opposite from the rest of the world in a misguided effort to prove that they are smarter than everybody else (for example: the rifling in an Enfield barrel turns in the opposite direction of everybody else's rifles, although a bullet is going to fly just as straight whether it is rotating clock-wise or counter-clock-wise).

In addition to improving readability, having certain data-structures built-in and standardized allows them to be implemented efficiently. All the words associated with chains are written in assembly-language. Similarly, the string-stack is written in assembly-language (btw: I have gotten rid of the REG and ACC user-registers; the two registers I had used for that are now dedicated to being the ptr and count for the top value of the string-stack). 

>  > There are a lot of good ideas in computer science. Quotations are one 
> of them. This COW for strings is another one. There are others. I'm not 
> saying that I can think up everything myself --- I'm saying that in 
> Straight Forth good ideas will be made a part of the Standard.
>  >
> 
> You don't read widely enough. On several occasion you have claimed to 
> have discovered or invented something, generally a technique or idea 
> that has been know for many years.

I don't think there are "several occasions." You may be referring to when John Passaniti was telling everybody that my symtab.4th was a Splay Tree, but it isn't. 

It is true though that I don't have any education. I remember when I was 19 or 20 that I invented DeMorgan's Theorum --- I was very proud of myself --- only much later did I find out that this has been well known since the late Middle Ages and it is described in every novice-level book on probability. I'm still interested in probability, but I've read some books now so I have my terminology consistent with everybody else --- my LowDraw.4th program was my first-ever ANS-Forth program --- I thought I could become an ANS-Forth programmer when I wrote that, but it was only later when I wrote my second ANS-Forth program (symtab.4th) that Elizabeth Rather and Bernd Paysan told me that I could never be an ANS-Forth programmer (they consider John Passaniti to be a true ANS-Forth programmer, despite the fact that he has never written any ANS-Forth code and knows almost nothing about computer-science).

I may be ignorant of some computer-science, but I'm not an ignoramus. I don't make utterly stupid statements such as:
----------------------------------------------------------------------------
Truly, I don't see the point of all this paranoia about reentrancy, particularly in 
systems without a multitasker. VARIABLE was *designed* for things that would be used in 
multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's 
in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. 
I think this is all about mythical dragons.
----------------------------------------------------------------------------

So, I may be ignorant of some things (I had never heard of this COW idea before I thought it up myself) --- but I'm willing to learn --- there is a big difference between being ignorant and being an ignoramus.

I still have hope that Forth can become successful --- Elizabeth Rather must be kicked out of the Forth community --- after that, respect in the programming world becomes possible.

Straight Forth is designed for writing programs. You have to have data-structures in order to write programs. If you don't have data-structures, then you are limited to writing toy programs such as appeared in the "Starting Forth" book. Note that all the Forth code Elizabeth Rather has posted on comp.lang.forth was copied directly out of "Starting Forth." She says:

----------------------------------------------------------------------------
People are much too phobic about [global] variables. The cry, "They aren't re-entrant" 
simply means you have to look at the whole application and how it is organized.
----------------------------------------------------------------------------

Looking at the "whole application" only works for toy programs that are small enough to glanced over quickly (less than 40 lines of code) --- also, glancing over the "whole application" only works if you have all of the source-code, which means that you can't have any code-libraries.

ANS-Forth is a toy language --- it isn't any good for writing programs --- this is why everybody abandoned Forth in 1994.

With Straight Forth though, the Forth language can be resurrected.

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

#52225

On Wednesday, October 19, 2016 at 3:59:33 AM UTC-4, Anton Ertl wrote:
> foxaudioresearch@gmail.com writes:
> >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 ;
> 
> 63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
> having to remember yet another word.
> 
> >It's not rocket science but in my ITC system SNIP was 3 times faster than 
> >1 /STRING.
> 
> In VFX:
> 
> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> : snip 1- swap 1+ swap ;  ok
> : foo1 snip ;  ok
> : foo2 1 /string ;  ok
> see foo1 
> FOO1 
> ( 080C0AB0    4B )                    DEC       EBX
> ( 080C0AB1    8B5500 )                MOV       EDX, [EBP]
> ( 080C0AB4    42 )                    INC       EDX
> ( 080C0AB5    895500 )                MOV       [EBP], EDX
> ( 080C0AB8    C3 )                    NEXT,
> ( 9 bytes, 5 instructions )
>  ok
> see foo2 
> FOO2 
> ( 080C0AE0    83C3FF )                ADD       EBX, -01
> ( 080C0AE3    8B5500 )                MOV       EDX, [EBP]
> ( 080C0AE6    83C201 )                ADD       EDX, 01
> ( 080C0AE9    895500 )                MOV       [EBP], EDX
> ( 080C0AEC    C3 )                    NEXT,
> ( 13 bytes, 5 instructions )
> 
> Probably same speed as long as the code working set fits in the cache.
> 
> - 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/

Just for fun it's only three instructions on the TMS9900 with TOS in a register.
Memory to memory architecture was cool for coding but sloooooooow.

CODE: /STRING  ( c-addr1 u1 n -- c-addr2 u2 )
              TOS  *SP SUB,
              TOS  2 (SP) ADD,
              *SP+ TOS MOV,    \ refill TOS
              NEXT,
              END-CODE

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

#52233

foxaudioresearch@gmail.com writes:
>On Wednesday, October 19, 2016 at 3:59:33 AM UTC-4, Anton Ertl wrote:
>> foxaudioresearch@gmail.com writes:
>> >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 ;
>> 
>> 63 occurences "1 /string" in 62393 lines of code.  Too little IMO for
>> having to remember yet another word.
>> 
>> >It's not rocket science but in my ITC system SNIP was 3 times faster than 
>> >1 /STRING.
>> 
>> In VFX:
>> 
>> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
>> : snip 1- swap 1+ swap ;  ok
>> : foo1 snip ;  ok
>> : foo2 1 /string ;  ok
>> see foo1 
>> FOO1 
>> ( 080C0AB0    4B )                    DEC       EBX
>> ( 080C0AB1    8B5500 )                MOV       EDX, [EBP]
>> ( 080C0AB4    42 )                    INC       EDX
>> ( 080C0AB5    895500 )                MOV       [EBP], EDX
>> ( 080C0AB8    C3 )                    NEXT,
>> ( 9 bytes, 5 instructions )
>>  ok
>> see foo2 
>> FOO2 
>> ( 080C0AE0    83C3FF )                ADD       EBX, -01
>> ( 080C0AE3    8B5500 )                MOV       EDX, [EBP]
>> ( 080C0AE6    83C201 )                ADD       EDX, 01
>> ( 080C0AE9    895500 )                MOV       [EBP], EDX
>> ( 080C0AEC    C3 )                    NEXT,
>> ( 13 bytes, 5 instructions )
>> 
>> Probably same speed as long as the code working set fits in the cache.
...
>Just for fun it's only three instructions on the TMS9900 with TOS in a register.

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.  The
SNIP code is bigger and probably slower on SwiftForth, however:

see snip                                                                       
8083BFF   EBX DEC                       4B
8083C00   0 [EBP] EAX MOV               8B4500
8083C03   EBX 0 [EBP] MOV               895D00
8083C06   EAX EBX MOV                   8BD8
8083C08   EBX INC                       43
8083C09   0 [EBP] EAX MOV               8B4500
8083C0C   EBX 0 [EBP] MOV               895D00
8083C0F   EAX EBX MOV                   8BD8
8083C11   RET                           C3 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 2016: http://www.euroforth.org/ef16/

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

#52239

Is the rule just for 1 /string ?

My example is for an arbitrary parameter value.

BF

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

#52262

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

-- 
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]

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

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

csiph-web