home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3978 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  4.3 KB
  1. Path: sparky!uunet!ukma!gatech!pitt!willett!ForthNet
  2. From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
  3. Newsgroups: comp.lang.forth
  4. Subject: PHILOSOPHY & CM
  5. Message-ID: <4272.UUL1.3#5129@willett.pgh.pa.us>
  6. Date: 24 Jan 93 13:45:24 GMT
  7. Organization: EIEI-U
  8. Lines: 85
  9.  
  10. Category 1,  Topic 12
  11. Message 13        Sat Jan 23, 1993
  12. L.ZETTEL [Len]               at 19:46 EST
  13.  
  14.  In the beginning was the hardware.  And the hardware of the disk 
  15.  drive was divided into sectors and tracks and cylinders.  And the 
  16.  sectors could hold 512 bytes or 1024 bytes or some multiple 
  17.  thereof.  And Moore looked on this and saw that it was good.
  18.  
  19.  And Moore looked at the output screen and saw that it could 
  20.  display 16 lines of 64 characters.
  21.  
  22.  And Moore said "Let there be BLOCKs of 1024 characters that their 
  23.  size may match the storage characteristics of the hardware and 
  24.  the display capacity of the output screen".  And it became so and 
  25.  it was good.  And Moore said "Let each block be given a number 
  26.  that will uniquely identify it wherever it be in the system, 
  27.  whether on the first disk or the second disk or in memory".  And 
  28.  it became so.
  29.  
  30.  Well, maybe this is taking the idea of "Forth as religion" a 
  31.  little too far...
  32.  
  33.  Anyhow, having established the above as the design, there turned 
  34.  out to be collateral advantages of the sort that indicate sound 
  35.  choices.  By assuming that the commonest pattern of data transfer 
  36.  after moving one block in or out of memory would be moving a 
  37.  contiguous range of blocks, it became possible to adjust the 
  38.  mapping of blocks to sectors that maximized the data transfer 
  39.  rate, interleaving blocks in a way that reduced waits due to 
  40.  "latency" - having to wait while the next block swung round into 
  41.  position under the read-write head.  Different hardware, 
  42.  different mapping, but the correspondence between block number 
  43.  and data would be preserved.
  44.  
  45.  You also got maximum protection against head crashes and assorted 
  46.  ills.  Since the mapping of block numbers to physical position 
  47.  was fixed, you always knew where a block was and could read it as 
  48.  long as it wasn't physically damaged itself. 
  49.  
  50.  Now let's look at the relationship between the disk and main 
  51.  memory.  Fetching and storing to memory is about a thousand times 
  52.  faster than reading and writing from disk (mass storage), so you 
  53.  want to cut data movement to and from mass storage to a minimum.  
  54.  It would also be nice if stuff didn't get shuffled around in 
  55.  memory any more than necessary.  So you set up a buffer pool, 
  56.  with each buffer able to hold a block.  All transfer to and from 
  57.  mass storage goes in block-size chunks, which for most hardware 
  58.  comes close to maximum performance.  
  59.  
  60.  Once a block is in memory it is held there as long as possible, 
  61.  which will be until the system needs the space to hold another 
  62.  block and can't find space elsewhere because the pool is full.  
  63.  In one last attempt to economize, the system checks whether the 
  64.  buffer contents have changed since they were read in.  If they 
  65.  have, the new contents are written back out; if they haven't, the 
  66.  buffer is simply reused. 
  67.  
  68.  With just this much system machinery it is easy to use mass 
  69.  storage in any of three ways:
  70.  
  71.  1) For source code (with LOAD).  This is the use most argued 
  72.  about and probably the least important.
  73.  
  74.  2) For data, most conveniently as virtual memory.  Just reserve a 
  75.  range of blocks for the purpose.
  76.  
  77.  3) For a customized file system for an application, as elaborate 
  78.  as necessary.  A block or blocks can hold a FAT (File Access 
  79.  Table), mapping file names and extents to blocks.  Other blocks 
  80.  can hold indexing information.  The FAT, at the user's 
  81.  discretion, can be held permanently (well, for the duration of 
  82.  the application) in memory, speeding up performance by cutting 
  83.  down on disk accesses.  It could be on another device, or backed 
  84.  up for safety.  Or, the data blocks could contain their own links 
  85.  and pointers to other blocks.  Anything you want!
  86.  
  87.  And with all of this, the knowledgeable Forth user is 100% in 
  88.  charge of every last detail.
  89.                             -LenZ-
  90. -----
  91. This message came from GEnie via willett.  You *cannot* reply to the author
  92. using e-mail.  Please post a follow-up article, or use any instructions
  93. the author may have included (USMail addresses, telephone #, etc.).
  94. Report problems to: dwp@willett.pgh.pa.us
  95.