Modern s/w has kernel doin all ALLOCATE ,
NewForth allows DICTIONARY ONLY !
You can only put stuff in D' !! No need to figure it .
typically low level coding uses a form of ALLOCATE , but the next
time you need it , you use parts of your code to make this
transparent , so you can concentrate on im****t stuff .
As you code , you answer questions from kernel
and it then knows how to warn you about asking too much
RAM . This is NOT a 16KB Forth on a Z-80 nor ANSI Forth !!!!
----------------------
Now tell me why i cant link ABSOLUTELY everything !
a serial number for every Dict entry !!
LFA is only 8 bits in Primatives , 16 bits in midlevel and higher
and yet it is UNLIMITED , it can link gigabytes of dict !
There is one dict , but look close and you can see
Vocabs embeded ! No speed penalty ...
How de do dat ?
Stephen Pelc wrote:
> ThrowIors.txt
> Stephen Pelc, 21 August 2006
>
> Rationale
> =========
>
> Problem
> -------
> Error codes returned by some words, e.g. ALLOCATE are not specified,
> and an application has no entitlement to use them as THROW codes.
> The leads to very clumsy code of the form:
>
> ALLOCATE IF <lit> THROW ENDIF
>
> or
>
> : ?THROW \ ior throwcode --
> SWAP IF THROW ELSE DROP THEN ;
>
> ALLOCATE <lit> ?THROW
>
> However, we also see many instances of code such as
>
> ALLOCATE THROW
>
> which leads to silent aborts when a system issues -1 THROW (as
> it is currently entitled to) or incorrect error messages.
>
> Current practice
> ----------------
> As far as possible within historical and commercial constarints,
> MPE has attempted to make iors THROWable. The only downside has
> been some necessary conversion of operating system error codes
> to ANS or application error codes.
>
> Some years ago, some people objected to making iors the same as
> THROW codes because of the documentation overhead. This RfD is
> made to sample opinion again, particularly among Forth system
> implementers.
>
> Solution
> --------
> All words which return an ior should have one value assigned in the
> THROW code table (Table 9.2 in 9.3.5). This table reserves values
> -1..-255 for system-defined exceptions. Systems that ignore this
> proposal are unaffected if they already avoid these values, and
> systems that implement this proposal gain use of these new fixed
> iors.
>
> The only downside is that we have to define some new THROW codes.
>
> Proposal
> ========
> Extend the THROW code table (Table 9.2 in 9.3.5) so that there is
> a separate THROW code for each word that returns an ior.
>
> Labelling
> =========
> ENVIRONMENT? impact - table 3.5 in Basis1
> name stack conditions
>
> THROW/ior impact - table 9.2 in Basis1
> value text
>
>
>
> --
> Stephen Pelc, stephenXXX@[EMAIL PROTECTED]
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com
- free VFX Forth downloads
|
