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


Groups > comp.lang.forth > #43950

Re: Ann: ANS/FORTH 2012 test suite update

Subject Re: Ann: ANS/FORTH 2012 test suite update
References <n3acur$8s6$1@dont-email.me> <880ce15f-f5fb-45b0-94f3-a5db59293dec@googlegroups.com> <2c8fa539-4739-4d74-b1db-4f9eaf5eb5fb@googlegroups.com> <0f6442eb-f1c9-4327-9363-6cc161d8772b@googlegroups.com> <826af8af-6529-434e-a825-eb9831ef1570@googlegroups.com>
Newsgroups comp.lang.forth
From "Elizabeth D. Rather" <erather@forth.com>
Organization FORTH, Inc.
Date 2015-11-29 13:14 -1000
Message-ID <lqWdnbaEDdV2G8bLnZ2dnUU7-e2dnZ2d@supernews.com> (permalink)

Show all headers | View raw


On 11/29/15 8:47 AM, peter.m.falth@gmail.com wrote:
> On Sunday, 29 November 2015 17:41:19 UTC+1, peter....@gmail.com  wrote:
>> On Sunday, 29 November 2015 12:47:27 UTC+1, st...@srpalmer.me.uk  wrote:
>>> Hi Peter,
>>>
>>>> I found a problem.
>>>> You have changed COMPARE to STR= but you give a definition to S=
>>>> in the utilities file. STR= is used in 3 of the files so compilation stops
>>>
>>> Gerry is on this.  Thanks for reporting it.
>>>
>>>> Then I found several problems in my Forth when running the Block tests.
>>>> This is due to the way I implement Blocks. I simply do a memory mapping
>>>> of the blockfile and have it all in memory. For this reason I can set
>>>> : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
>>>> is handled by the operating system (Linux or Windows) and eventually
>>>> transferred to disk.
>>>>
>>>> For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
>>>> as the contents has already been written.
>>>> I need to think if I want to introduce a buffer to transfer each block thru
>>>> to pass your tests. I like the simplicity of the mapped file and it has
>>>> worked well for me for 20 years.
>>>
>>> Thanks for the feedback.  I checked the ANS standard regarding blocks and buffers and found the following relevant statements:
>>>
>>> Section 7.2 gives a definition of "block buffer: A block-sized region of data space where a block is made temporarily available for use. The current block buffer is the block buffer most recently accessed by BLOCK, BUFFER, LOAD, LIST, or THRU."
>>>
>>> Section 7.6.1.2400 gives the semantics of the word UPDATE, including the statement "Mark the current block buffer as modified. ... UPDATE does not immediately cause I/O."
>>>
>>> Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS, saying "Do not transfer the contents of any UPDATEd block buffer to mass
>>> storage."
>>>
>>> I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and the latest version I can find on-line and they are all the same.
>>>
>>> The Rationale section goes on to say and Blocks "Early Forth systems ran without a host OS; these are known as native systems. Such systems provide mass storage in blocks of 1024 bytes. The Block Word set includes the most common words for accessing program source and data on disk."  The Block word set operational model (as I interpret from the definitions above) is also trying to maintain consistency with native systems without advanced memory management hardware.  In particular, the forth system maintained a cache of buffers and the forth program had to indicate when a buffer had been changed (UPDATE) and when the changes where complete and so needed to be written back (FLUSH).
>>>
>>> It also provided the option of throwing away the changes using EMPTY-BUFFERS.  (I'm not sure how a Forth Program that used more than one buffer could know what was being thrown away, but there you go.)  The semantics indicated in the language standard specifically state that even UPDATEd blocks do not get written back if EMPTY-BUFFERS is called.
>>>
>>> Moving forwards to modern times with 32+ bit processors and hardware memory managers, I can quite understand the attraction of a memory mapped block file.  All changes are automatically captured and there is no need for UPDATE or FLUSH or others.  I suspect that it will make the life on real Forth Program using blocks to be much easier.  However, I don't think it is consistent with the language standard.
>>>
>>> To test compliance with the standard, (at around line 555) I write a block (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then discard the changes using EMPTY-BUFFERS.  The expectation is that the block contains the first value, not the second.  I guess that this is (at least one of) the place where an error is being reported.  If I've misunderstood the standard, then obviously the test should be changed, but I think that this test is a fair reflection of, in particular, section 7.6.2.1330.
>>>
>>> You do ask a good question as to whether to change your current approach.  This will depend on your use cases.  I could easily be wrong, but I also get the impression that the Block word set is "falling out of fashion".  The ANS standard stated in section 3.2.5 that "A system need not provide any standard words for accessing mass storage. If a system provides any standard word for accessing mass storage, it shall also implement the Block word set."  RC3 has only the first statement and does not include the second statement, eliminating the need to provide at least the block word set.  I also struggle to see how the provided API could be used in a multitasking system, since the Forth Program can never now whether the address it has in the cache is still valid.  This problem disappears with a memory mapped block file.
>>>
>>> So a long answer, but basically:
>>>   1. I think that the tests are consistent with the language standard;
>>>   2. I can see the advantages of the memory mapped block file and you may choose usability over compliance.
>>>
>>> Thanks again,
>>> Steve
>>
>> Hi Steve,
>>
>> I share your analysis and think that my implementation failed when I updated
>> the block when modified but not marked updated.
>>
>> I have now implemented 1 buffer and pass all of the tests except one.
>> This is a bug on my side in save-input that was there all the time
>> (or seen now with 1 buffer)
>>
>> I found one problem that I think is an error in your test.
>> In TL7 (line 474) you test if there is only one buffer. if that is the case
>> you drop the parameters and push zeros and then exists. There is one drop
>> to much.
>>
>> I can see that you and Gerry have put in a lot of work on these tests.
>> They have really helped me create a better forth. A big thanks for your efforts
>>
>> BR
>> Peter
>
> Hi again Steve,
>
> I fixed my problem but did still not pass the test!
> Instead I found a problem in your test.
> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> but the old buffer is not updated so it will be overwritten and not committed
> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.

In a correctly-written BLOCK system SAVE-BUFFERS should not ever be 
necessary
except when you're about to power-down the system, because BLOCK should
automatically write an UPDATEd buffer when the buffer is about to be reused.
UPDATE *is* necessary if you have changed any block contents, though.

Cheers,
Elizabeth

> I now pass all the tests in the test suite except one.
>
> INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T
>
> But this I do not really consider a problem. Maybe this test should be deleted
>
> I also get 2 errors on the FP tests, but also these I think is OK.
> I allow an FP number to have leading or trailing blank chars where your
> tests does not.
>
> Again thanks to both Steve and Gerry for a very good work put into this test suite
>
> BR
> Peter
>


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 20:06 +0000
  Re: Ann: ANS/FORTH 2012 test suite update Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-27 22:19 -0800
  Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-28 10:07 -0800
    Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 10:13 +0000
    Re: Ann: ANS/FORTH 2012 test suite update "steve@srpalmer.me.uk" <steverpalmer27@gmail.com> - 2015-11-29 03:47 -0800
      Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-29 12:41 +0000
      Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-29 12:41 +0000
      Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 08:41 -0800
        Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 10:47 -0800
          Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 20:29 +0000
            Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 14:44 -0800
              Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 01:24 +0100
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:35 +0000
                Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:04 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 22:59 +0100
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 12:29 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-02 10:08 +0000
                Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 15:57 +0000
              Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:49 +0000
                Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:16 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
              Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 10:25 +0000
          Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:14 -1000
          Re: Ann: ANS/FORTH 2012 test suite update steverpalmer27@gmail.com - 2015-11-30 03:51 -0800
            Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-30 09:00 -0800
              Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 07:54 -1000
                Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-30 18:25 +0000
                Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 11:06 -1000
      Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:08 -1000

csiph-web