From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 24 21:43:43 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EFF716A403; Sun, 24 Feb 2008 21:43:43 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 91DD413C458; Sun, 24 Feb 2008 21:43:42 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1OLheEW040879; Sun, 24 Feb 2008 22:43:41 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1OLhe9l040878; Sun, 24 Feb 2008 22:43:40 +0100 (CET) (envelope-from olli) Date: Sun, 24 Feb 2008 22:43:40 +0100 (CET) Message-Id: <200802242143.m1OLhe9l040878@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG In-Reply-To: <20080224200305.GA49564@eos.sc1.parodius.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sun, 24 Feb 2008 22:43:41 +0100 (CET) Cc: Subject: Re: loader and ficl/Forth help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 21:43:43 -0000 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