<!-- Forthmacs Formatter generated HTML V.2 output -->
<html>
<head>
<title>Forthmacs Implementation</title>
</head>
<body>
<h1>Forthmacs Implementation</h1>
<hr>
<p>
This chapter describes how RISC OS Forthmacs implements the Forth virtual 
machine on the ARM processors.  It assumes that you have a fairly good knowledge 
of conventional Forth implementations; it does not attempt to be a tutorial on 
how Forth works.  
<p>
<p>
<h2>Dialect</h2>
<p>
RISC OS Forthmacs has been an implementation of the Forth-83 standard, with a 
few exceptions.  It is now far on it's way to be an ANS compliant 
implementation.  It is still rather compatible with the other implementations 
for Sun-68k, Sparc, Atari, Macintosh and OS-9 computers.  
<p>
<p>
<h2>Stack Width and Addressing</h2>
<p>
In RISC OS Forthmacs, all stack items as well as memory cells are 32-bit wide, 
remember this when writing portable programs.  Use the portable ANS operators 
like <code><A href="_smal_BK#1A2">cell+</A></code> <code><A href="_smal_BM#1A4">cells</A></code> 
or the RISC OS Forthmacs specific words like <code><A href="_smal_BI#110">/cell</A></code> <code><A href="_smal_BO#1A6">cells+</A>.</code> 
<p>
The address could conceivably grow to 2 to the 32nd power (4 gigabytes), but 
this is restricted by the current CPU/MMU versions to 16/256 MBytes.  16-bit or 
2-byte memory accesses are not supported any longer and must be emulated if 
necessary.  
<p>
Note: word accesses are simulated by two byte accesses, take care about 
interrupts occurring here! 
<p>
The current ARM MMUs don't support non-aligned memory accesses.  <strong>Note:</strong> 
They don't abort or run any exception vector but just do something <strong>undefined</strong> 
and CPU core dependent.  Take care of this, it took me hours to find a bug! 
<p>
All accesses must be one of: 
<p>
1) byte-wide access to any address in the address area 
<p>
2) cell-wide ( 32-bit ) access to any aligned address 
<p>
The word wide access possible at least on StrongARM and ARM8 cpus is <strong>not</strong> 
supported by the RiscPC platforms.  Special source extensions are available for 
single-board platforms.  
<p>
<p>
Both stacks are pre-decrementing/post-incrementing.  The parameter stack holds 
its top-of-stack in the top-register <code><A href="_smal_BF#1D">top</A></code> 
- r10, this allows much faster code definitions because of the CPUs 
load-and-store architecture.  
<p>
<p>
<h2>Register Usage</h2>
<p>
<p>
<p><pre>  r9      user area pointer       up</pre><p>
<p><pre>  r10     top-of-stack register   top</pre><p>
<p><pre>  r11     returnstack pointer     rp</pre><p>
<p><pre>  r12     instruction pointer     ip</pre><p>
<p><pre>  r13     stack pointer           sp</pre><p>
<p><pre>  r14     link register           lk</pre><p>
<p><pre>  r15     pc + status + flags     pc</pre><p>
<p><pre>  r15     sr                      sr  hold the flags part of r15</pre><p>
<p>
Note: The internal structure of the pc and flags registers differs between cpus.  
It seems to be better, to generally imagine pc and status register as two 
registers.  The hardware-errors and the <code><A href="_smal_AU#44">.registers</A></code> 
instruction know about this.  
<p>
r0, r1, r2, r3, r4, r5, and r6 are available for use within code definitions.  
Don't try to use them for permanent storage, because they are used by many code 
words with no attempt to preserve the previous contents.  
<p>
Registers r7-r14 can be used within code definitions with great care, but you 
have to save and restore their values at the beginning/end of the definition.  
<p>
<p>
<h2>Inner &lt;address&gt; Interpreter</h2>
<p>
The inner interpreter <code><A href="_smal_AH#37">next</A></code> is direct 
threaded, post incrementing.  The compilation address of all definitions contain 
machine code to be executed, not a pointer.  Each <code><A href="_smal_BV#1AD">code</A></code> 
definition ends with the <code><A href="_smal_AH#37">next</A></code> code, 
assembled in-line.  The <code><A href="_smal_AH#37">next</A></code> code is: 
<p><pre>       pc      ip )+   ldr</pre><p>
This means: Load the program-counter <code><A href="_smal_BK#52">pc</A></code> ( 
don't affect the CPU status ) from the 4-byte cell pointed to by the instruction 
pointer ip, postincrement the instruction-pointer.  So the <code><A href="_smal_AH#37">next</A></code> 
is only one CPU instruction and very fast.  It is much faster than 
<p><pre>       address  dolink branch</pre><p>
<p><pre>       ...</pre><p>
<p><pre>       pc link mov</pre><p>
constructions because of only one pipeline reload per <code><A href="_smal_AH#37">next</A>.</code> 
But on the other hand, there is definitely a larger overhead for calling 
secondaries.  
<p>
RISC OS Forthmacs versions <code><A href="_smal_BI#140">&gt;=</A></code> 
3.1/2.70 can switch to another <code><A href="_smal_AH#37">next</A></code> 
scheme.  The first 8 <code><A href="_smal_BM#1A4">cells</A></code> in the user 
area are free debugging purposes.  <strong>slow-next </strong> ( you find this 
in lib.arm.debugm ) patches all <code><A href="_smal_AH#37">next</A></code> as 
well as conditional <code><A href="_smal_AH#37">next</A></code> calls to 
<p><pre>  pc up mov</pre><p>
Normall there is a normal <code><A href="_smal_AH#37">next</A></code> 
instruction at <code><A href="_smal_BD#34B">up@</A></code> but may install any 
service routine there to do additional checking at run time.  The new debugger 
uses this to branch into the debugger handler.  After 'debugging' you switch 
back to the normal <code><A href="_smal_AH#37">next</A></code> with <strong>fast-next</strong> 
<p>
If you want to use this scheme, there is one thing to remember.  As <strong>slow-next</strong> 
patches all instructions 
<p><pre>  pc ip )+ condition ldr</pre><p>
your handler might be patches as well.  In these cases you should use 
<p><pre>  pc 1  ip ia!  ldm</pre><p>
instead.  This does the same - at least from RISC OS Forthmacs point of view - 
but isn't patched.  See lib.arm.debugm again for an example in the debugger.  
<p>
For discussions about subroutine threaded ( macro extended ) versus threaded 
code implementations see the Forth literature.  Generally, macros do bring some 
advantage in execution speed but give less information about the code itself, so 
debuggers are less useful.  The penalty for direct threaded code is hard to 
predict, it depends very much on the type of application.  Something like 50% 
sounds reasonable, so optimising the bottlenecks could bring big advantages.  
The <em>runtimer </em> utilities might help you doing this.  
<p>
The assembler macro <code><A href="_smal_AW#196">c;</A></code> assembles the <code><A href="_smal_AH#37">next</A></code> 
instruction and ends assembling by <code><A href="_smal_BO#206">end-code</A>.</code> 
A fast conditional next can be done by 
<p><pre>       ...</pre><p>
<p><pre>       r2 0 cmp</pre><p>
<p><pre>       eq next</pre><p>
<p><pre>       ...</pre><p>
<p>
<p>
<h2>Other Definitions</h2>
<p>
Any word that is not a code definition contains a branch+link instruction at the 
code-field, this makes a relative branch to an inline-address and saves the 
pc+sr to the lk register.  
<p><pre>       runtime-addr    dolink branch</pre><p>
The inline address points to a code fragment (headerless in most cases) that 
implements the run-time action of the word.  The parameter field starts just 
after this branch+link instruction and can be found by clearing the flags in the 
link register like this: 
<p><pre>       r0 lk    th fc000003 #   bic</pre><p>
<p><pre>       r0  get-link</pre><p>
<p>
The run-time codes may have to push the top-register to the stack, save the 
return pointer to the return-stack and set the instruction or stack pointer to 
the parameter field address.  All standard runtime codes (those of variables, 
constants, colon definitions, user variables ...) have been optimized for best 
cache-hit rates.  
<p>
Note: <code><A href="_smal_AH#367">word-type</A></code> ( cfa -- addr ) finds 
the address of the words runtime code in this implementation.  
<p>
<p>
<h2>Colon definitions</h2>
<p>
The runtime code: 
<p><pre>  mlabel docolon  assembler</pre><p>
<p><pre>       ip      rp      push</pre><p>
<p><pre>       ip      get-link c;</pre><p>
The body of a Colon Definition starts 4 bytes after the compilation address.  
The body contains a list of compilation addresses of other words.  Each such 
compilation address is a 32-bit number which is an absolute address.  
<p>
<p>
<h2>Variable</h2>
<p>
The Parameter Field of a <code><A href="_smal_BM#354">variable</A></code> 
contains a 32-bit number which is the value of the variable.  The runtime code: 
<p><pre>  mlabel dovariable  assembler</pre><p>
<p><pre>       top     sp      push</pre><p>
<p><pre>       top     get-link c;</pre><p>
<p>
<p>
<h2>Constants</h2>
<p>
The Parameter Field of a <code><A href="_smal_AK#1BA">constant</A></code> 
contains the 32-bit value of the constant.  The runtime code: 
<p><pre>  mlabel doconstant  assembler</pre><p>
<p><pre>       top     sp      push</pre><p>
<p><pre>       r0      get-link</pre><p>
<p><pre>       top     r0 )    ldr c;</pre><p>
<p>
<p>
<h2>User Variables</h2>
<p>
The value of a <code><A href="_smal_BJ#351">user</A></code> variable is stored 
in the <code><A href="_smal_BJ#351">user</A></code> area as a 32-bit number.  
The Parameter Field of a user variable contains a 32-bit offset into the user 
area of the current task.  r8 contains the base address of the current user 
area.  r8 is symbolically defined as <code><A href="_smal_BC#34A">up</A></code> 
in the assembler.  The runtime code: 
<p><pre>  mlabel douser  assembler</pre><p>
<p><pre>       top     sp      push</pre><p>
<p><pre>       r0      get-link</pre><p>
<p><pre>       r0      r0 )    ldr</pre><p>
<p><pre>       top     r0      up add c;</pre><p>
<p>
<p>
<h2>Deferred words</h2>
<p>
The compilation address of the word to be executed by a <code><A href="_smal_BT#1DB">defer</A></code> 
word is stored as a 32-bit absolute address in the <code><A href="_smal_BJ#351">user</A></code> 
area.  The Parameter Field of a deferred word contains a 32-bit number which is 
an offset into the user area of the current task.  The runtime code: 
<p><pre>  mlabel dodefer  assembler</pre><p>
<p><pre>       r0      get-link</pre><p>
<p><pre>       r0      r0 )    ldr</pre><p>
<p><pre>       pc      r0      up  ib ldr end-code</pre><p>
The last line holds a somewhat optimized <code><A href="_smal_AH#37">next</A></code> 
instruction, it means: Load the pc from the address in the user area with the 
offset r0.  
<p>
<p>
<h2>;code</h2>
<p>
The compilation address of a word created by a <code><A href="_smal_AS#1C2">create</A></code> 
...  <code><A href="_smal_AX#137">;code</A></code> data type construction 
contains the standard branch+link instruction that branches to the runtime code.  
<p>
The runtime code is defined by the programmer in the <code><A href="_smal_AX#137">;code</A></code> 
part of the definition.  
<p>
In versions up to 3.1/2.62 <code><A href="_smal_AX#137">;code</A></code> 
assembled two instructions for your convenience 
<p><pre>       top     sp      push</pre><p>
<p><pre>       top     get-link</pre><p>
this is not the case any more.  I changed this to be more portable with the 
FirmWorks implementation and i feel that all Forth programmers using <code><A href="_smal_AX#137">;code</A></code> 
should be able to handle this.  
<p>
<p>
<h2>does&gt;</h2>
<p>
<p>
<p><pre>  mlabel dodoes  assembler</pre><p>
<p><pre>       ip      rp      push</pre><p>
<p><pre>       ip      get-link c;</pre><p>
The runtime code is defined by the programmer in the <code><A href="_smal_AV#1F5">does&gt;</A></code> 
part of the definition.  Before branching to the dodoes code, the does&gt; 
instruction assembles 
<p><pre>       top     sp      push</pre><p>
<p><pre>       top     lk      th fc000003 # bic</pre><p>
to get the parameter field address.  
<p>
<p>
<h2>local variables</h2>
<p>
RISC OS Forthmacs has built in ANS Forth conforming local variables spending 
their lifetime on the return-stack in stack-frames.  The stack-frames are linked 
via a <code><A href="_smal_BJ#351">user</A></code> variable <strong>local-frame</strong> 
which is also used to locate a local variables value.  The frame structure is 
like: 
<p><pre>  | cfa:frame&gt;   | old-frame     | old-rs        | loc   | loc   | .........</pre><p>
with cfa:pop-frame on top of the return-stack.  pop-frame removes the current 
frame and switches to the last frame.  
<p><pre>  headerless code pop-frame \ this routine is pushed on return stack by push-locals</pre><p>
<p><pre>       here /cell+ token,</pre><p>
<p><pre>  	r0 rp 2	rp ia	ldm</pre><p>
<p><pre>  	r0	'user local-frame str</pre><p>
<p><pre>  	ip	rp	pop c;</pre><p>
<p><pre>  </pre><p>
The local variables are accessed using (loc) followed by an stack frame index.  
<p><pre>  code (loc)	\ ( -- n )  runtime-code of any local</pre><p>
<p><pre>  	r0	'user local-frame ldr</pre><p>
<p><pre>  	r1	ip )+	ldr</pre><p>
<p><pre>  	top	sp	push</pre><p>
<p><pre>  	top	r0 r1 2 #asl db ldr c;</pre><p>
<p>
Note: The decompiler can <code><A href="_smal_AF#2A5">not</A></code> know the 
local variables names, so it assumes names like ( v0 v1 ...).  
<p>
<p>
<h2>Tokens</h2>
<p>
Within the body of a colon definition, calls to other Forth words are compiled 
as the 32-bit absolute compilation address of those words.  These tokens have a 
corresponding bit in the relocation table.  
<p>
<p>
<h2>Branching</h2>
<p>
Branch targets are offsets relative to the location that contains the branch 
offset.  They are stored as 32-bit twos-complement numbers representing the 
number of bytes between the offset location and the branch target.  For example, 
a branch to the following location could be compiled with: 
<p>
<p><pre>       postpone branch   4 ,</pre><p>
<p>
<strong>Note:</strong> This is implemented different in version 3.1/2.00.  The 
relative offset is replaced by an immediate absolute relocated address.  
<p>
<p>
<h2>Doubles</h2>
<p>
RISC OS Forthmacs versions newer than 1.83 have full double number support, all 
conversion tools <code><A href="_smal_AN#1BD">convert</A>,</code> <code><A href="_smal_AK#2AA">number?</A>,</code> 
<code><A href="_smal_BH#1CF">d.</A></code> use doubles, the 'scaling' words <code><A href="_smal_BS#EA">*/</A></code> 
<code><A href="_smal_BT#EB">*/mod</A></code> <code><A href="_smal_AR#341">um/mod</A></code> 
use double intermediate results.  
<p>
Also the text-interpreter and compiler accept literals as doubles when there is 
a period at the end of it.  
<p><pre>       : test 1234. d. ;</pre><p>
1234.  is a double number and <code><A href="_smal_BH#1CF">d.</A></code> 
displays it.  
<p>
This could only be achieved with changing stack effects in a number of words.  
So these new RISC OS Forthmacs versions are no longer compatible when these 
words are used.  The lib.compatible tool does <code><A href="_smal_AF#2A5">not</A></code> 
cover these changes.  
<p>
The advantage of the new stack behaviour is it's ANS compliancy and the improved 
arithmetic capabilities.  
<p>
<p>
<h2>Floats</h2>
<p>
RISC OS Forthmacs versions newer than 3.1/2.13 have the ANS Floating and 
Floating Extended wordsets included.  There isn't any further documentation 
available so far, please use the ANS docs for this purpose.  
<p>
<p>
<h2>StrongARM compatibility</h2>
<p>
Versions from 3.1/2.30 run on StronARM based machines but optimized code is 
available from 3.1/2.40 onwards.  
<p>
<p>
<h2>Cache</h2>
<p>
The newer ARM based cpus ( ARM8, StrongARM ) have a different cache structure 
than the elder versions.  Separate instruction- and data caches are used and 
code synchronizing has to be done after change of the code space.  
<p>
<code><A href="_smal_BJ#231">flush-cache</A></code> and <code><A href="_smal_AS#312">sync-cache</A></code> 
are both implemented in current RISC OS Forthmacs versions &gt;3.1/2.40 in such 
a way, that the compiler is not significantly slowed down, in fact a StrongARM 
compilation is much faster than on the older ARM710.  
<p>
<p>
<h2>Header format - # of bytes in parentheses</h2>
<p>
Source Field (4), Link Field (4), Name Field (n), Padding (0 to 3), Flags (1), 
Code Field (4), Parameter Field (n).  
<p>
As all addresses need to be, the Link Field, Name Field, and Code Field are all 
aligned.  
<p>
Links point to links ( <code><A href="_smal_AF#2A5">not</A></code> to Name 
Fields, as in FIG Forth! ) 
<p>
The name field is a normal Forth packed string.  (Many Forth implementations set 
the high bit in the first and last characters of the name field; 
RISC OS Forthmacs does not).  
<p>
Name Field: length-byte, 0-31 character name.  
<p>
<p>
<p>
<h2>Vocabularies</h2>
<p>
Vocabularies have <code><A href="_smal_BA#A8">#threads</A></code> - way hashing.  
This means that each vocabulary has 16 separate linked lists of words.  The 
threads are stored in the <code><A href="_smal_BJ#351">user</A></code> area.  
The Parameter Field of a <code><A href="_smal_BQ#358">vocabulary</A></code> 
contains the 32-bit offset of the threads in the <code><A href="_smal_BJ#351">user</A></code> 
area, followed by the vocabulary-link, a 32-bit pointer to the previous <code><A href="_smal_BQ#358">vocabulary</A>.</code> 
The runtime high-level code is: 
<p><pre>       does&gt; body&gt; context token!</pre><p>
<p>
Before searching a vocabulary, a hashing function is applied to the name to be 
located.  The hashing function selects one of the 16 linked lists to search.  
<p>
The hashing function is very simple.  The lower 4 bits of the first character in 
the name (the first name character, not the length byte) are interpreted as a 
number from 0 to 15, selecting a linked list.  
<p>
Vocabularies are not chained to one another.  Search order is implemented using 
the <code><A href="_smal_BI#170">also</A></code> / <code><A href="_smal_AS#2B2">only</A></code> 
scheme.  Each vocabulary thread is terminated with a special link field in the 
final word.  The special link address is the address of the origin of the Forth 
system (which may change from session to session due to the relocation that the 
operating system applies when loading and executing the Forth system.  
<p>
The parameter field for a vocabulary looks like: 
<p>
User number (/cell), Voc-link (/cell) 
<p>
The user number selects the place in the user area where the head of list 
pointers for the 16 vocabulary threads are stored.  Each vocabulary requires 16 <code><A href="_smal_BM#1A4">cells</A></code> 
bytes of user area storage for these 16 threads.  The values stored in the user 
area are the Link field Addresses for the top word in each thread.  
<p>
<p>
<h2>Relocation</h2>
<p>
In the RISC OS environment all programs of the absolute type are loaded at $8000 
and executed from there.  So on first sight the relocation table doesn't make 
much sense in this version if you don't care about being portable to other 
RISC OS Forthmacs implementations.  
<p>
But the relocation table can be used for target/meta-compiling or for relocating 
code during run-time.  This is necessary for producing turnkey applications with 
an 'Application Stripper', use of the application stripper requires strict 
adherence to the rules of relocatability.  
<p>
If the program is not relocatable, then a file saved with <code><A href="_smal_BE#2EC">save-forth</A></code> 
will work only if it is later executed at the same address where it was 
executing when it was saved.  If saved with <code><A href="_smal_BE#2EC">save-forth</A>,</code> 
a program that is not relocatable will not work at all, regardless of the 
address where it is later executed.  Consequently, use of the application 
stripper requires strict adherence to the rules of relocatability.  
<p>
In most cases, the relocation bitmap is maintained automatically, without 
requiring any special effort on the part of the programmer.  However, there are 
some cases where the programmer must take explicit actions to ensure that the 
program is relocatable.  
<p>
The executable file contains a relocation list used to identify the locations in 
the program's binary image which contain absolute addresses.  When the program 
is loaded, each of these locations is modified by adding the starting address of 
the program to the number contained in that location.  Only 32-bit numbers may 
be so modified.  
<p>
While RISC OS Forthmacs is running, it maintains its own relocation table, 
identifying those locations in the Forth dictionary which must be relocated 
during <code><A href="_smal_AA#1B0">cold-code</A>.</code> Each bit in the map 
represents the address of one aligned location.  This relocation table is 
completely different from the standard RISC OS relocation tables, it is only 
used from within RISC OS Forthmacs.  
<p>
In order for this to work properly, the programmer must be careful to use <code><A href="_smal_BU#32C">token,</A></code> 
A, <code><A href="_smal_AH#277">link,</A></code> <code><A href="_smal_BT#32B">token!</A>,</code> 
A! or <code><A href="_smal_AG#276">link!</A></code> to store an address or token 
in the dictionary, all six set the relocation flags.  
<p>
Addresses may be stored into <code><A href="_smal_BM#354">variable</A>s</code> 
with ! ( without requiring the use of <code><A href="_smal_BT#32B">token!</A></code> 
) if the <code><A href="_smal_BM#354">variable</A></code> is re-initialized 
every time that the application is started.  <code><A href="_smal_BT#32B">token!</A></code> 
is only necessary if the <code><A href="_smal_BM#354">variable</A>s</code> value 
must be set before <code><A href="_smal_BE#2EC">save-forth</A></code> is 
executed, and then is used when the saved application is later invoked, without 
being re-initialized by the application's initialization code.  
<p>
If , or ! is used instead, the address will not be properly relocated if <code><A href="_smal_BE#2EC">save-forth</A></code> 
has been used to write the dictionary image to an executable file.  
<p>
Note: The lib/checkrel.fth program can help you catch relocation problems in 
your applications.  It should be loaded before you load your application, and 
will warn you if your application does things that may not be relocatable.  
After you have fixed the relocation problems, you can load your application 
without lib/checkrel.fth .  
<p>

See: <code><A href="_smal_AK#FA">.buffers</A></code> <code><A href="_smal_AW#106">.pointers</A></code> 
<code><A href="_smal_BT#32B">token!</A></code> <code><A href="_smal_BU#32C">token,</A></code> 
A! A, <code><A href="_smal_AG#276">link!</A></code> <code><A href="_smal_AH#277">link,</A></code> <code><A href="_smal_BQ#2F8">set-relocation-bit</A></code> 
<code><A href="_smal_AE#2D4">relocation-map</A></code> 
<p>
<p>
<h2>Program header</h2>
<p>
The header of the executable binary image looks like this: 
<p>
<p><pre>
 h_magic   (  0)    \ Magic Number
 h_tlen    (  4)    \ length of text (code)
 h_dlen    (  8)    \ length of initialised data
 h_blen    (  c)    \ length of BSS unitialised data
 h_slen    (  10)   \ length of symbol table
 h_entry   (  14)   \ Entry address
 h_trlen   (  18)   \ Text Relocation Table length
 h_drlen   (  1c)   \ Data Relocation Table length
</pre><p>
<p>
the magic number is the branch+link instruction just behind this header.  Note: 
this header might be changed with future releases according to Acorns executable 
binary code standard.  
<p>
<p>
<h2>Heap memory</h2>
<p>
RISC OS Forthmacs is loaded to $8000 and will have as much memory available as 
was defined by <em>WimpSlot</em> .  
<p>
The <code><A href="_smal_BF#28D">main-task</A>s</code> user area immediately 
follows the first instructions and some permanent data at $8040.  
<p>
$600 byte will be allocated in the module-heap RMA, it will hold the <code><A href="_smal_BT#20B">env-area</A>,</code> 
the command-line area plus all handlers used by shelled programs.  
<p>
The implementation of the dynamic memory manager has changed in Version 
3.1-2.00.  From now on the dictionary and the heap share the same memory area, 
the dictionary grows from lower addresses and the heap can be as large as the 
area between the stacks and <code><A href="_smal_AL#24B">here</A>.</code> 
<p>
Note: Of course you may install another memory manager or add more heaps.  
<p>
<p>
<h2>Dictionary memory</h2>
<p>
At the top of the dictionary are both stacks defined by <code><A href="_smal_AT#2E3">rp0</A></code> 
- <code><A href="_smal_AV#2E5">rs-size</A></code> and <code><A href="_smal_AG#306">sp0</A></code> 
- <code><A href="_smal_BQ#2C8">ps-size</A></code> and the <code><A href="_smal_BJ#321">tib</A>,</code> 
below this are MBytes of free memory (well, hopefully).  <code><A href="_smal_AL#24B">here</A></code> 
marks the end of the allocated dictionary, classically <code><A href="_smal_BD#2BB">pad</A></code> 
is <code><A href="_smal_AL#24B">here</A></code> plus something.  
<p>
RISC OS Forthmacs knows about two dictionary areas, the <code><A href="_smal_AH#2D7">resident</A></code> 
(which is the dictionary you know in all implementations) and the <code><A href="_smal_AA#330">transient</A>.</code> 
The transient dictionary is in the heap memory, definitions defined here won't 
use dictionary space in the target application.  So it might be useful to do: 
<p><pre>  transient</pre><p>
<p><pre>    fload assembler</pre><p>
<p><pre>    fload debugger</pre><p>
<p><pre>  resident</pre><p>
<p><pre>    fload myapplication</pre><p>
Now the debugger and assembler will be in transient address space.  To remove 
all links, pointers etc.  into the transient address space use <code><A href="_smal_AJ#1E9">dispose</A>,</code> 
it will do this for you.  <code><A href="_smal_AR#101">.dispose</A></code> will 
also give some informations what is removed while executing <code><A href="_smal_AJ#1E9">dispose</A>.</code> 
<p>
</body>
</html>
