From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PHILOSOPHY & CM
Date: 24 Jan 93 13:45:24 GMT
Organization: EIEI-U

Category 1,  Topic 12
Message 13        Sat Jan 23, 1993
L.ZETTEL [Len]               at 19:46 EST
 
 In the beginning was the hardware.  And the hardware of the disk 
 drive was divided into sectors and tracks and cylinders.  And the 
 sectors could hold 512 bytes or 1024 bytes or some multiple 
 thereof.  And Moore looked on this and saw that it was good.

 And Moore looked at the output screen and saw that it could 
 display 16 lines of 64 characters.

 And Moore said "Let there be BLOCKs of 1024 characters that their 
 size may match the storage characteristics of the hardware and 
 the display capacity of the output screen".  And it became so and 
 it was good.  And Moore said "Let each block be given a number 
 that will uniquely identify it wherever it be in the system, 
 whether on the first disk or the second disk or in memory".  And 
 it became so.

 Well, maybe this is taking the idea of "Forth as religion" a 
 little too far...

 Anyhow, having established the above as the design, there turned 
 out to be collateral advantages of the sort that indicate sound 
 choices.  By assuming that the commonest pattern of data transfer 
 after moving one block in or out of memory would be moving a 
 contiguous range of blocks, it became possible to adjust the 
 mapping of blocks to sectors that maximized the data transfer 
 rate, interleaving blocks in a way that reduced waits due to 
 "latency" - having to wait while the next block swung round into 
 position under the read-write head.  Different hardware, 
 different mapping, but the correspondence between block number 
 and data would be preserved.

 You also got maximum protection against head crashes and assorted 
 ills.  Since the mapping of block numbers to physical position 
 was fixed, you always knew where a block was and could read it as 
 long as it wasn't physically damaged itself. 

 Now let's look at the relationship between the disk and main 
 memory.  Fetching and storing to memory is about a thousand times 
 faster than reading and writing from disk (mass storage), so you 
 want to cut data movement to and from mass storage to a minimum.  
 It would also be nice if stuff didn't get shuffled around in 
 memory any more than necessary.  So you set up a buffer pool, 
 with each buffer able to hold a block.  All transfer to and from 
 mass storage goes in block-size chunks, which for most hardware 
 comes close to maximum performance.  

 Once a block is in memory it is held there as long as possible, 
 which will be until the system needs the space to hold another 
 block and can't find space elsewhere because the pool is full.  
 In one last attempt to economize, the system checks whether the 
 buffer contents have changed since they were read in.  If they 
 have, the new contents are written back out; if they haven't, the 
 buffer is simply reused. 

 With just this much system machinery it is easy to use mass 
 storage in any of three ways:

 1) For source code (with LOAD).  This is the use most argued 
 about and probably the least important.

 2) For data, most conveniently as virtual memory.  Just reserve a 
 range of blocks for the purpose.

 3) For a customized file system for an application, as elaborate 
 as necessary.  A block or blocks can hold a FAT (File Access 
 Table), mapping file names and extents to blocks.  Other blocks 
 can hold indexing information.  The FAT, at the user's 
 discretion, can be held permanently (well, for the duration of 
 the application) in memory, speeding up performance by cutting 
 down on disk accesses.  It could be on another device, or backed 
 up for safety.  Or, the data blocks could contain their own links 
 and pointers to other blocks.  Anything you want!

 And with all of this, the knowledgeable Forth user is 100% in 
 charge of every last detail.
                            -LenZ-
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us