NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/3988

Text File | 1993-01-25 | 3.5 KB | 82 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!pazsan
From: [e-mail] (Bernd Paysan)
Subject: Re: Data types
References:  <4273.UUL1.3#[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET Newssystem)
Organization: Technische Universitaet Muenchen, Germany
Date: Mon, 25 Jan 1993 10:30:43 GMT
Message-ID: <[e-mail]>
Lines: 69


In article <4273.UUL1.3#[e-mail]>, [e-mail] (ForthNet articles from GEnie) writes:
[...]
|>  Re Re ``Changes in dpANS-3'' (Bernd Paysan):
|>
|>   ...
|>  |> bp> 8. VALUE changed to take an initial argument from the stack
|>  |> bp>    (like CONSTANT)
|>   ...
|>  |>                           the previous dpANS proposal was better
|>  |>  with respect to ROMmability (IMHO).  I suppose now we'll have to
|>  |>  put in code ( a chain? ) to initialize all VALUE's when the
|>  |>  system boots from ROM.
|>
|>  bp> Hm, I don't see were the problem is.
|>
|>  Well, take "3 VALUE foo". When target compiling, the "3" is
|>  stored in ROM. When the system ``boots'' from ROM, code will be
|>  needed to copy the value 3 in the RAM location occupied by foo at
|>  run-time. There will be no user code that does this explicitly,
|>  as the standard suggests that VALUE is somewhat like CONSTANT in
|>  this respect (this is what I fear, I hope to be wrong).

Your fear is right. VALUEs are patchable constants.

|>  bp> Every object in Unix, TOS or MS-DOS has (at least) three parts:
|>  bp> The TEXT (initialized, but unchanged at runtime) which could
|>  bp> stay in ROM, the DATA (initialized, but possibly modified at
|>  bp> runtime), which is copied to RAM at boot time and the BLOCK
|>  bp> STORAGE, (uninitialized or initialized to zero and modified
|>  bp> while running) which is only allocated and erased at boot time.
|>
|>  Somehow, I do not think it is a solution to simply burn all RAM
|>  into ROM ( CREATE bar 128000 ALLOT ), although it has the kind of
|>  elegant simplicity Forth is famous for. I hope I'm
|>  misinterpreting your comment :-)

Simple ALLOTed stuff is uninitialized, so it will be BLOCK STORAGE. You
don't have to copy uninitialized values into ROM, you only have to set up
pointers and data space.

|>  bp> I prefer VARIABLES and CREATE structures to be initialized at
|>  bp> target compile time.
|>
|>  I do not know how a commercial target compiler will handle
|>  "VARIABLE foo  3 foo !", but personally I would not expect (nor
|>  demand) it to (have) work(ed) when the system is booted and runs.

Works well with bigFORTH. But the only romable version of bigFORTH,
Ewald Rieger's port to his 68K VME board, copies everything (code and
data) to RAM at boot time. He can, because he has 512 K RAM :-).

|>  In fact, it will not be very difficult to handle initialization
|>  of VALUE's -- doing the same with CREATE structures poses real
|>  problems. ( CREATE ape  33 , 0 ,  8 ape 2 CELLS + ! ).

As the target compiler builds an host-executable ape, that gives it's
target address, this will work. The TC has to figure out, wether the
DATA is initialized (as in your example), or not.

It seems you have to switch between DATA SEGMENT and BSS, like in any
assembler. Words like INITIALIZED or UNINITIALIZED like RAM and ROM come
in mind, but they are a bit too long to be useful. Perhaps IRAM for
initialized RAM.

[.sig]
--
Bernd Paysan
"Late answers are wrong answers!"