loader and ficl/Forth help

[Oliver Fromme]

Jeremy Chadwick wrote:
 > I have a lot more reading to do on the subject of Forth.  Stacks are
 > hardly a new concept to me, but the conditions where Forth puts
 > something onto the stack are.  I've never worked with a language like
 > this before (at least RPN doesn't frustrate me!).  I've already found
 > some reading material which should help.

It also took me some time to get familiar with it.  It's
also somewhat non-trivial to find out what the FreeBSD-
specific things do.

For example, "environment?" picks a string from the stack
and searches for that name in an internal dictionary of
environment attributes.  It leaves the result of the
attribute on the stack and true if found, otherwise false.

So, for the arch-* attributes there are three possible
results:

false        (not found)
false true   (found, value is false)
true true    (found, value is true)

The attribute "arch-pc98" is special:  If it is set, it
is always true, and all the other arch-* are not set:

s" arch-pc98" environment?     -->  true true
s" arch-i386" environment?     -->  false
s" arch-ia64" environment?     -->  false
s" arch-powerpc" environment?  -->  false

In all other cases (i.e. non-pc98), arch-pc98 is not
set, and all the others are set to either true or false.
For example, in the case of i386:

s" arch-pc98" environment?     -->  false
s" arch-i386" environment?     -->  true true
s" arch-ia64" environment?     -->  false true
s" arch-powerpc" environment?  -->  false true

I don't know why it is that way.  That inconsistency makes
if-branches somewhat more complicated.

Another thing to keep in mind is that getenv leaves two
values on the stack if the name was found (a Forth string
consists of two values: the actual string and its length).
If not found, only one value is left on the stack (-1).
2dup and 2drop are suitable for strings.

 > Sadly, the "sh_el not found" error still continues with this code -- but
 > it does fix the crashing I was seeing.  I believe the problem is that
 > constants cannot be put inside of a function (functions being runtime
 > things, not compile-time things).  Since the original code used
 > compile-time conditions ([if], etc.), it meant that only one declaration
 > for sh_el, sv_el, etc. was made.

Maybe you should declare these as variables (outside of
functions) instead of constants, and only assign to them
within the functions.  That should work.

 > And so on, ditto with adding "variable sh_el", "variable sv_el" and
 > others to the very top of frames.4th.  This actually fixed the "not
 > found" error, and now I'm stuck with "Error: compile only!" being
 > induced by the "dup -1 = if" line.

"if" is for compile mode, and "[if]" is for immediate mode.
If you're not in a function definition, then you're not in
compile mode.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is the only current language making COBOL look good."
        -- Bertrand Meyer