On Sun, Feb 24, 2008 at 06:38:38PM +0100, Oliver Fromme wrote:
> There's a debugging aid called "testmain" so you can run
> Forth code interactively in multi-user mode for testing
> purposes. For details please read the thread starting
> here:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/015387.html
Thanks! This helps a lot. I'm able to reproduce the sh_el not found
condition with testmain.
> Personally I use qemu for testing loader things. I wrote
> a trivial script that updates a small disk image and then
> boot its in qemu, which only takes two or three seconds,
> so testing cycles are pretty short.
Hmm, interesting software. I'm used to VMware myself, but this seems a
bit less bloated. I'd have to run it on Windows, since I don't use
FreeBSD as a workstation (no SDL, no VNC/X, etc.). The FreeBSD box in
my home runs Samba, so I should be able to set up a method of creating
ISO images of FreeBSD, which I can then test via qemu on Windows via
CIFS/SMB share...
> I suggest you switch to ASCII characters automatically if
> the loader is running on comconsole (i.e. serial), and use
> CP437 it it is running on vidconsole (i.e. VGA). Then
> there will be no need to manually switch a variable.
Great idea; I think I'll go with that.
> I think the stack layout is not correct, particularly the
> drops aren't quite right in some branches of the "if"
> statements, I think. It's best to make a stack diagram
> on paper and go through all possible branches with it.
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.
> s" loader_logo_lines" getenv
> dup -1 = if
> drop
> s" arch-pc98" environment? if
> drop
> pc98_lines
> else
> cp437_lines
> then
> else
> s" ascii" compare-insensitive 0= if
> ascii_lines
> else
> cp437_lines
> then
> then
Again, thanks -- I don't quite understand the changes yet, but will
after I read aforementioned documents.
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.
Since the *_lines functions are doing the assignments, I had to change
them all to runtime, e.g.:
149 sh_el !
150 sv_el !
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. The same happens when running this
natively (outside of testmain). I'll have to get the qemu stuff set up
so I can test this more easily.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
