Date: Sun Dec 5 02:15:57 2010
New Revision: 979
forth: Fix ([IF]) to handle nested [IFDEF] as well
Depending on the condition, either the [IFDEF] FOO or the [ELSE]
would get compiled as an [IF], eating words until [ELSE] or [THEN]
respectively. While doing so, [IFDEF] does not get compiled to [IF],
so we need to handle nested [IFDEF] to account for its [ELSE] or [THEN].
This fixes [IFDEF] not disabling the full section of code.
Thanks to Segher for pointing me in the right direction.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
Signed-off-by: Segher Boessenkool <segher(a)kernel.crashing.org>
--- trunk/openbios-devel/forth/lib/preprocessor.fs Sun Nov 28 21:03:46 2010 (r978)
+++ trunk/openbios-devel/forth/lib/preprocessor.fs Sun Dec 5 02:15:57 2010 (r979)
@@ -19,6 +19,7 @@
2dup " [IF]" strcmp 0= if 1 throw then
+ 2dup " [IFDEF]" strcmp 0= if 1 throw then
2dup " [ELSE]" strcmp 0= if 2 throw then
2dup " [THEN]" strcmp 0= if 3 throw then
" \\" strcmp 0= if linefeed parse 2drop then
A construct like:
has been seen to return, e.g., 4 3 according to the debug word.
Is this nesting forbidden in Forth? Easily fixable? A better way to do
this? I do want a final catch-all since returning no value would have
unexpected results, and we currently do not have a define CONFIG_PPC32
so that a concatenation of independent [IFDEF]...[THEN]s wouldn't work.
It's taken me a lot longer to get to grips with moving SPARC32 to OFMEM
than expected, mostly due to problems with the increased BSS size of the
resulting image causing several large headaches.
Having spent some time looking at where the memory is currently being
used, it strikes me that there are 2 main places where we can claim some
i) Reduce (remove) the runtime memory allocated to the Forth machine
One interesting aspect of the current design is that we have 2 memory
allocation ranges - the Forth machine memory which is used for alloc-mem
and free-mem, and also the OFMEM ranges. For example, in SPARC32 this is
set to 256K which given the large I/O space requirements for the frame
buffer, is about a quarter of the total memory.
I'd like to suggest that we unify the memory management by removing the
Forth implementations of alloc-mem/free-mem and replace them with
wrappers to the internal ofmem_malloc() and ofmem_free() functions. This
would then enable us to have one continuous pool of allocatable memory
which could be used for everything.
One slight issue with this is that there are a few references to
alloc-mem/free-mem within the internal Forth code. These are mainly for
allocating static buffers, and so I believe these could be removed and
replaced by functions that simply allocate memory within the dictionary
ii) Avoid re-allocation of memory for the Forth dictionary
At runtime we currently have two copies of the dictionary held within
memory - the first is the actual static dictionary data, while the
second is the relocated dictionary image within the BSS. In the case of
SPARC32 this is responsible for just over 100K of the BSS image size.
Rather than having to allocate a second copy of the dictionary, would it
make sense to embed the fixed size dictionary directly within the
OpenBIOS image? As an example SPARC32 specifies 256K for the total
I think it should be possible to rewrite the relocation routine to
relocate the dictionary 'in place' and then remove the relocation data
so that the dictionary can extend normally up to its final limit. The
downside of this is that the ROM images will be bigger on disk, but I
don't feel that this should be too much of an issue.
I realise that these two ideas are probably fairly controversial, but
they should both help considerably reduce the size of the OpenBIOS
runtime memory footprint. Thoughts/comments/criticisms?
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs