home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3798 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.5 KB  |  60 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!pazsan
  3. From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
  4. Subject: Re: X3J14 Holding Pattern Here
  5. References:  <4187.UUL1.3#5129@willett.pgh.pa.us>
  6. Originator: pazsan@hphalle5h.informatik.tu-muenchen.de
  7. Sender: news@Informatik.TU-Muenchen.DE (USENET Newssystem)
  8. Organization: Technische Universitaet Muenchen, Germany
  9. Date: Fri, 8 Jan 1993 08:51:35 GMT
  10. Message-ID: <1993Jan8.085135.29418@Informatik.TU-Muenchen.DE>
  11. Lines: 47
  12.  
  13.  
  14. In article <4187.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
  15. |> Category 10,  Topic 12
  16. |> Message 195       Sun Dec 13, 1992
  17. |> ELLIOTT.C                    at 20:44 EST
  18. |>  
  19. |>  -----via CRS Premium Bulletin Board -
  20. |>  USR Dual Standard 16.8K  (416) 629-7000
  21. |> 
  22. |>  Date: 12-07-92 (01:40)
  23. |>    To: ALL
  24. |>  From: MARCEL HENDRIX
  25. |>  Subj: VALUE
  26. |> 
  27. |>  Re Changes in dpANS-3 (Bernd Paysan):
  28. |> 
  29. |>  bp> 8. VALUE changed to take an initial argument from the stack
  30. |>  bp>    (like CONSTANT)
  31. |> 
  32. |>  I hope we'll get some background on this. Of course, it is now
  33. |>  reversed to the way it is in F-PC and like everybody else has
  34. |>  had it for a decade, but the previous dpANS proposal was better
  35. |>  with respect to ROMmability (IMHO).  I suppose now we'll have to
  36. |>  put in code ( a chain? ) to initialize all VALUE's when the
  37. |>  system boots from ROM.
  38.  
  39. Hm, I don't see were the problem is. Every object in Unix, TOS or MS-DOS has
  40. (at least) three parts: The TEXT (initialized, but unchanged at runtime) which
  41. could stay in ROM, the DATA (initialized, but possibly modified at runtime),
  42. which is copied to RAM at boot time and the BLOCK STORAGE, (uninitialized or
  43. initialized to zero and modified while running) which is only allocated and
  44. erased at boot time. Target compiling for ROM means then: Use two buffers
  45. (one for DATA, one for TEXT), and generate addresses for DATA space when
  46. CREATE, VARIABLE or CONSTANT (and switch to RAM or DATA allocation
  47. scheme until the next CODE or COLON definition).
  48.  
  49. |>  Does this mean that VARIABLE's and CREATE structures may be
  50. |>  initialized too (I know the committee doesn't want to think
  51. |>  about ROMmability yet, but...)
  52.  
  53. I prefer VARIABLES and CREATE structures to be initialized at target compile
  54. time. Sometimes my CREATE structures are more likely to be constants than
  55. variables (i.e. an uppercase converting table), then I use LABEL to get
  56. the address.
  57. -- 
  58. Bernd Paysan
  59. "Late answers are wrong answers!"
  60.