home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3980 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  3.1 KB
  1. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!gatech!pitt!willett!ForthNet
  2. From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
  3. Newsgroups: comp.lang.forth
  4. Subject: Data types
  5. Message-ID: <4273.UUL1.3#5129@willett.pgh.pa.us>
  6. Date: 24 Jan 93 13:45:26 GMT
  7. Organization: EIEI-U
  8. Lines: 74
  9.  
  10. Category 10,  Topic 29
  11. Message 18        Sat Jan 23, 1993
  12. ELLIOTT.C                    at 14:35 EST
  13.  
  14.  -----via CRS Premium Bulletin Board -
  15.  USR 16.8K Dual Standard  (416) 629-7000
  16.  
  17.  Date: 01-18-93 (01:27)
  18.    To: ALL
  19.  From: MARCEL HENDRIX
  20.  Subj: VALUES
  21.  
  22.  Re Re ``Changes in dpANS-3'' (Bernd Paysan):
  23.  
  24.   ...
  25.  |> bp> 8. VALUE changed to take an initial argument from the stack
  26.  |> bp>    (like CONSTANT)
  27.   ...
  28.  |>                           the previous dpANS proposal was better
  29.  |>  with respect to ROMmability (IMHO).  I suppose now we'll have to
  30.  |>  put in code ( a chain? ) to initialize all VALUE's when the
  31.  |>  system boots from ROM.
  32.  
  33.  bp> Hm, I don't see were the problem is.
  34.  
  35.  Well, take "3 VALUE foo". When target compiling, the "3" is
  36.  stored in ROM. When the system ``boots'' from ROM, code will be
  37.  needed to copy the value 3 in the RAM location occupied by foo at
  38.  run-time. There will be no user code that does this explicitly,
  39.  as the standard suggests that VALUE is somewhat like CONSTANT in
  40.  this respect (this is what I fear, I hope to be wrong).
  41.  
  42.  bp> Every object in Unix, TOS or MS-DOS has (at least) three parts:
  43.  bp> The TEXT (initialized, but unchanged at runtime) which could
  44.  bp> stay in ROM, the DATA (initialized, but possibly modified at
  45.  bp> runtime), which is copied to RAM at boot time and the BLOCK
  46.  bp> STORAGE, (uninitialized or initialized to zero and modified
  47.  bp> while running) which is only allocated and erased at boot time.
  48.  
  49.  Somehow, I do not think it is a solution to simply burn all RAM
  50.  into ROM ( CREATE bar 128000 ALLOT ), although it has the kind of
  51.  elegant simplicity Forth is famous for. I hope I'm
  52.  misinterpreting your comment :-)
  53.  
  54.  bp> I prefer VARIABLES and CREATE structures to be initialized at
  55.  bp> target compile time.
  56.  
  57.  I do not know how a commercial target compiler will handle
  58.  "VARIABLE foo  3 foo !", but personally I would not expect (nor
  59.  demand) it to (have) work(ed) when the system is booted and runs.
  60.  
  61.  In fact, it will not be very difficult to handle initialization
  62.  of VALUE's -- doing the same with CREATE structures poses real
  63.  problems. ( CREATE ape  33 , 0 ,  8 ape 2 CELLS + ! ).
  64.  
  65.  bp> "Late answers are wrong answers!"
  66.  
  67.  Marcel Hendrix,       | "an engineer is somebody who spends three
  68.  Dutch Forth Workshop. |  hours figuring out how to do a two hour
  69.                        |  job in one hour."
  70.  
  71.  
  72.  NET/Mail : FS FORTH Systeme BBS West Germany ++49 7667 556
  73.  ---
  74.   * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  75.   * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub
  76.  
  77.  
  78.  
  79. -----
  80. This message came from GEnie via willett.  You *cannot* reply to the author
  81. using e-mail.  Please post a follow-up article, or use any instructions
  82. the author may have included (USMail addresses, telephone #, etc.).
  83. Report problems to: dwp@willett.pgh.pa.us
  84.