Forth 2012 standard

[GARTHWILSON]

no 6502 content, except that it does address portability:
http://www.forth200x.org/

[scotws]

The current standard is here: http://www.forth200x.org/documents/forth-2012.pdf The details of the process make fascinating reading, if you're into those sort of things. Also, if you look at the membership list, there is an amazing number of Europeans, and only one American. Doesn't have to mean anything, but still, curious.

[JimBoyd]

I was just looking at the html version of the Forth-2012 document [Edit: I just checked http://www.forth200x.org/ and it has a link to https://forth-standard.org/ as an html version of the Forth-2012 document. ]
If I read this right, Forth-2012 document implies the decision of whether division is floored or symetrical up to the implementor?

[nyef]

For ANS Forth, an implementation may use floored or symmetrical (truncated?) division, provided that it does so consistently. It is not permitted to vary on an operation-to-operation basis. See section 3.2.2.1 in that specification, along with 6.1.1561 FM/MOD, 6.1.2214 SM/REM (plus there's an environment query for division behaviour and some interesting equivalency requirements in things like 6.1.0230).

Long story short: Implementations are permitted to implement either of two integer division behaviours, and have been for some time.

[JimBoyd]

So if I were to use ANS Forth and I needed to consider the effect of the division behavior, I would need to use FM/MOD, or SM/REM if I want symetrical division, to insure portability across platforms.

[scotws]

If I'm reading this right, floored division is the default with Gforth, which as far as I am concerned the de facto reference implementation. See

Code: Select all

s" floored" environment? drop .

- a true flag means it's FM/MOD.

[nyef]

As a data-point, the x86 integer division operation is symmetric, rather than floored, so there is a post-operation correction needed for a non-zero remainder with opposite-signed inputs.

As such, I might expect an x86 implementation to prefer symmetric division as the easier-and-faster operation, even if it tends to conflict with how I-as-a-person consider division. I can easily see gforth making the opposite choice, just like it does with case-sensitivity: these choices reveal our value systems. As I see it, gforth aims to be a "full-featured" implementation, and prefers to enhance the user experience at the expense of computational complexity and ease of porting to other implementations, while my current efforts are in the direction of conformance-to-spec and simple implementation models.

That gforth makes certain implementation choices in ways that a user may not necessarily agree with suggests that it is not suitable as a reference implementation wherever a choice is permitted by the standard unless there are options to select alternate behaviour, or the desired referent behaviour is what gforth implements.

Also note that the ANS standard does not specify anything about case-sensitivity for environment query strings: An implementation is permitted to return different results for S" floored" ENVIRONMENT? and S" FLOORED" ENVIRONMENT? . Of the two, the latter is the one specified by the standard.

[JimBoyd]

The version of Gforth I have on my desktop uses symetrical divison. The version on my phone uses floored division.

[JimBoyd]

The Ansi standard ( Forth 2012 Standard ) has FM/MOD for floored division and SM/REM for symetrical division. Maybe they didn't go far enough. Here are some suggestions.
/MOD for floored division and /REM for symetrical division with remainders.
MOD for floored remainder, or modulus, and REM for symetrical remainder.
As for / ( slash ), two different words could be implemented for this also but I imagine there would be no agreement on which should be called / ( slash) and which should get the new name.
Just my 2 cents worth.

Cheers,
Jim

[JimBoyd]

I was considering adding the Ansi Forth word /STRING to my Forth.

Code: Select all

/STRING   ( C-ADDR1 U1 N -- C-ADDR2 U2 )

The standard mentions that it can be used to trim a string, by using a positive value for n, or extend one by using a negative value. What is it supposed to do if the amount to trim is more than the length of the string?

[GARTHWILSON]

JimBoyd wrote:

What is it supposed to do if the amount to trim is more than the length of the string?

Even Elizabeth Rather's "Forth Application Techniques" doesn't say.

[IamRob]

GARTHWILSON wrote:

JimBoyd wrote:

What is it supposed to do if the amount to trim is more than the length of the string?

Even Elizabeth Rather's "Forth Application Techniques" doesn't say.

If one is trimming more than is there, I would just have it return a null string.

[JimBoyd]

IamRob wrote:

GARTHWILSON wrote:

JimBoyd wrote:

What is it supposed to do if the amount to trim is more than the length of the string?

Even Elizabeth Rather's "Forth Application Techniques" doesn't say.

If one is trimming more than is there, I would just have it return a null string.

Just some thoughts on the matter.
If /STRING is implemented to return a null string if the amount to trim is greater than the string size then it would probably be a good idea to limit how far the address of the string is incremented. Consider, there is a string at address 30000 and it is ten bytes long.
10 /STRING will change the address to 30010 and the count to 0.
-10 /STRING will extend this null string back to the original address and count.
Setting the count to zero to prevent a negative count but not limiting the address increment could result in odd behavior under some circumstances. Given the same string at address 30000 with a count of ten.
15 /STRING will change the address to 30015 and the count to 0 ( to return a null string).
-15 /STRING will change the address to 30000, but the count is now 15.
Handling both is relatively easy if /STRING is high level.

Code: Select all

: /STRING  ( ADR1 U1 N -- ADR2 U2 )
   OVER MIN
   DUP NEGATE UNDER+ UNDER+ ;

If written as a primitive, the test more than doubles the size of the body of /STRING for the 6510 and NMOS 6502 . Also, Forth words usually don't have a lot of error checking.
If /STRING is written without the test and a trim size larger than the count is a problem, one could try this:

Code: Select all

   OVER MIN /STRING

There may also be situations where the ability to extend a string is not desired if the trim value is negative. The following could be done for those cases:

Code: Select all

   OVER UMIN /STRING

Stack diagrams of the non standard words:

Code: Select all

UNDER+  ( N1 N2 N3 -- N1+N3 N2 )
UMIN  ( U1 U2 -- U3 ) \ where U3 is the unsigned minimum of U1 and U2.

Any other ideas, opinions, suggestions?

[JimBoyd]

I added /STRING to my kernel. It does no error checking. The high level would be this:

Code: Select all

: /STRING  ( ADR1 U1 N -- ADR2 U2 )
   DUP NEGATE UNDER+ UNDER+ ;

Making it a primitive only adds three bytes more than making it high level, so I made it a primitive.