ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/02/91)
Category 10, Topic 25
Message 15 Mon Dec 31, 1990
JAX at 20:35 PST
Dennis ---
Could you possibly print this out and drop it in the X3J14 hopper?
Thank you very nicely. =jax=
------------------------------------------------------------------
X3J14 Proposal January 1, 1991 Page 1
of 1
Title: ROM-based Systems Quibble with >BODY
Words: >BODY CREATE DOES> ENVIRONMENT?
Abstract:
>BODY as defined in BASIS14 may benefit from redefinition
with an eye to portability between mixed RAM/ROM and RAM-only
systems.
Proposal:
8.1.0550 -- >BODY
In conjunction with 5.3.2 "Addressable Memory" this construct
and the underlying concepts of PFA appear to be ambiguous for ROMmed
creatures of CREATE which contain address tokens in their PFA.
Propose: "a-addr is the parameter field associated with the
execution token w of a word defined via CREATE. The contents
of this address may be constant data, such as an address token
to memory where the data which makes the CREATEd word useful
is stored (as is often the case in a ROMmed system), or such
data itself (as is typically the case in a RAM-only system).
If there is any question as to which is the case, a Standard
program should compare the token returned by >BODY with the
token returned by EXECUTEing the CREATEd word itself."
The counter argument could be brought that the above technique
would not work for CREATE ... DOES>. In such case another CREATE
construct could be examined by a Standard program to determine what
sort of PFAs CREATE creates. In any event, it is hard to imagine a
truly portable Standard program that would want access to the internals
of a CREATE ... DOES> word via >BODY. It would be safer in such cases
simply to create some data structure that was more easily manipulable
and then write a colon definition that performed the desired action
upon it.
Alternatively, perhaps a query string could be defined for the
ENVIRONMENT? construct (8.1.1345) which could inform the Standard
program as to whether CREATE words contain data or address pointers in
their PFA's.
Submitted by:
Jack J. Woehr Voice: (303) 422-8088
Vesta Technology Inc. FAX: (303) 422-9800
7100 W. 44th Ave, Suite #101 BBS: (303) 278-0364
Wheat Ridge, CO 80033 jax@well.UUCP JAX on
GEnie
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 10, Topic 25 Message 18 Sat Mar 02, 1991 B.RODRIGUEZ2 [Brad] at 22:23 EST > 1) I think the loss of the ability to compile bytes is a great > loss. Well, in the system I was speaking of, you didn't lose that ability. Structures had no alignment restrictions other than _starting_ at a word boundary. Which means that yes, if you were careless, you could create a structure which would lead to an addressing violation. What was lost was the ability to, for example, compile a BRANCH with a one- byte offset ("in-line" parameter). This was because the thread needed to maintain word-alignment. You didn't lose any capabilities with this restriction, just some micro-optimizations of memory usage. - Brad ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/06/91)
Category 10, Topic 25
Message 21 Sun May 05, 1991
B.RODRIGUEZ2 [Brad] at 10:09 EDT
Okay, I have a copy of BASIS15 now.
According to BASIS13, your example
> CREATE ... HERE CONSTANT XYZZY
would not necessarily work, because nothing equated the address returned by
CREATEd words to the address returned by HERE.
The first key addition in BASIS15 was section 5.4.1, which states (among other
things) that "HERE always identifies the beginning of the next region to be
allocated."
The second key addition was the rationale note in >BODY that you quoted
(although I don't know if the rationale note carries the same weight as the
text of the standard itself).
At any rate, you've answered my question -- the problem was fixed in BASIS15.
BTW, I found the section in BASIS13 perfectly understandable, Mitch. It's just
that there was a difference betweeen what it said, and what everyone assumed.
Thanks (to you or whoever) for elucidating this in BASIS15.
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!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/25/91)
Category 10, Topic 25 Message 29 Mon Jun 24, 1991 D.RUFFER [Dennis] at 00:23 EDT Again, I think you all are missing the point. Since I won't be passing this stuff back to Elizabeth for a week, I will try to explain it again. C, can most certainly cause HERE to return an unaligned address and no, it does not need to be "fixed" and results will be unpredictable if used by an operator that is expecting an aligned address. BASIS does not require HERE to return an aligned address, but since the programmer is in control of the situation (and actually caused the misalignment), it is his responsiblity to use ALIGN before he assumes HERE can be used with an operator that requires alignment. In other words, if you do a C, and then want to do a HERE @, then you had better do an ALIGN first. Why is this such a mystery? Re: rob@innovus.uucp (Rob Sciuk) >=> appropriate boundaries. Further, `ALLOT' and `,' should align >=> on CELL boundaries, and `C,' should ensure that the next >=> invocation of `HERE', `ALLOT', `,' etc. will utilize a CELL >=> boundary appropriate to the processor [mine]. This is _NOT_ what Elizabeth said. ALLOT and C, do not do anything about alignment, nor do they assure that the next invocation of HERE will return an aligned address. It is up to the programmer to make these assurances, since he is the one that used the C, or an odd number of bytes in ALLOT. In fact, Elizabeth specifically did say that HERE can return an unaligned address if the programmer does these things. At FORTH, Inc. we work on aligned systems all the time and it is really not a problem. Sure, a nieve programmer can get himself in trouble, by using HERE improperly, but in practice, this doesn't happen much. All the defining words that are garanteed to return aligned addresses, do the alignment before they make use of HERE. Yes, this does mean that ALIGN gets executed frequently as you compile your system, but IMHO, it should be written for speed and frequent use anyways. {B-{)> DaR ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (07/01/91)
Category 10, Topic 25 Message 37 Sun Jun 30, 1991 B.RODRIGUEZ2 [Brad] at 12:12 EDT >> Hmmm... reading Robert Berkey's comments, I'm beginning to believe >> that _all_ existing Forth code will be rendered nonconforming by >> the BASIS. > In a sense, this is correct. ... > ANS Forth will not magically make existing code portable. True. But I wasn't saying that ANS Forth would make existing code _portable_ (most of it isn't); I was pointing out that it would make existing code _non- standard_ (even if it happens to be portable). - 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