ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/13/91)
Category 10, Topic 22
Message 34 Fri May 10, 1991
JAX at 22:32 PDT
ANSI ASC X3/X3J14 Forth Technical Proposal Page 1 of 1
===============================================================
Title: Commercial Implementation of A.2 Leads to Preliminary Conclusions
Related Proposals: none
Keyword(s): Mixed RAM/ROM systems
Forth Word(s): RAM ROM HERE ALLOT C, , ALIGN ALIGNED CREATE UNUSED
Abstract:
Vesta Technology is already using RAM and ROM modality keywords in a
very successful 83-STANDARD-style product.
Proposal:
1) We suggest adding UNUSED to the list of words affected by the RAM
ROM keywords. We further suggest that any text effecting the above be
supplemented with the cautionary "while ROM UNUSED may in a particular
implementation be useful in determining the quantity of dictionary space
remaining in a system, the Standard Program may not depend on such."
2) We suggest changing the status of RAM ROM from "informative" to
"normative" by whatever means to be determined by more procedurally-aware
members of the TC.
Rationale:
Vesta's Forth-83i96 was in development shortly after the RAM ROM
keywords were added to Appendix A.2. As Forth-83i96 generates truly ROMmable
code, we adopted the committee's suggestion. A variable called: " RAM/ROM " is
set TRUE by RAM and set FALSE by ROM. Affected keywords (A.2) read this
variable before performing their respective duties. The added Vesta utilities
RAM? and ROM? return boolean flags indicating current system state, but are
not necessary to the implementation. "Colon" : VARIABLE and other important
definers which implicitly reference one address space or the other all push
the modality, perform their operation in the appropriate address space and
subsequently pop the modality so that the action of CREATE in such context
conforms to the expectation of the user. ( "Colon" : of course in ANS Forth
will not implicitly call CREATE as our 83-STANDARD Forth-83i96 does.)
Our conclusion is that the RAM ROM modality works excellently.
The list of keywords for the RAM/ ROM modality should be extended to
include UNUSED 8.2.2395: it's often as important to know how much ROM data
space is left as to know how much RAM data space is left.
The material set forth in A.2 should be given normative weight,
rendering portable otherwise incompatible ROMmable applications and increasing
the readability of the Standard ROMmable Program.
RAM ROM turns out to be very good Forth. We complement Martin Tracy on
his suggestion which has proved its merit in the ease with which our customers
have assimilated the concept.
=====================================================================
Submitted by: Jack Woehr, Vesta Technology Inc. Date: 05/10/90
Address: 7100 W. 44th Ave., Suite #101
Wheat Ridge, CO 80033
Phone: (303) 422-8088 FAX: (303) 422-9800 BBS: (303) 278-0364
-----
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 _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/15/91)
Category 10, Topic 22
Message 35 Mon May 13, 1991
B.RODRIGUEZ2 [Brad] at 23:25 EDT
Re. Jack's proposals for ROMability: I agree, and disagree.
We've found this capability very useful in embedded systems. However, we
usually need more than just two address spaces (RAM and ROM). For this reason
our metacompiler includes the defining word
DICTIONARY, which resembles VOCABULARY in some respects:
start-adr end-adr DICTIONARY name
defines a named dictionary with its own dictionary pointer, and then later
invocation of 'name' makes that dictionary current. Rather than set a flag,
we define a "dictionary-pointer-pointer" 'DP which holds the address of the
current DP. Thus,
: DP 'DP @ ;
and HERE, ALLOT, and such will follow. Of course, 'DP can be a user variable,
but all of the dictionary pointers should be in common RAM (shared among
tasks). This scheme can conform to the RAM and ROM usage, e.g.,
HEX 0 8000 DICTIONARY ROM
8000 FFFF DICTIONARY RAM \ or any other address limits
but is much more powerful. It is very nice for supporting paged memory
systems. We're even working on parallel compilation of separate programs
(where two CPUs need to know each other's symbol tables) using this technique.
There are refinements for extended addressing and physically separate memory
spaces.
Jack's right...this concept is VERY useful, and good Forth. But I hope this
example shows that it's too soon to move RAM and ROM into the "normative"
status.
- Brad
Brad Rodriguez | brad%candice@maccs.uucp (God willing)
B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
"Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic)
-----
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 _or_ uunet!willett!dwp