[OpenBIOS] Found out why replacing '\r' with '\n' works

[Segher Boessenkool]

On Tue, Apr 19, 2016 at 08:32:59AM +0100, Mark Cave-Ayland wrote:
> >> The executing one line at a time idea turned out to be a pretty good idea. That is enough to make Mac OS 9.2 boot. It is also entertaining to watch each executed line be printed to the terminal. Here is the patch:
> > 
> > [ LONG LINES ]
> > 
> > If you look at forth/bootstrap/interpreter.fs, you see EVAL already
> > handles multiple lines, but only with unix line endings:
> > 
> > : evaluate ( str len -- ?? )
> >   2dup + -rot
> >   over + over do
> >     i c@ 0a = if
> >       i over -
> >       (evaluate)
> >       i 1+
> >     then
> >   loop
> >   swap over - (evaluate)
> >   ;
> > 
> > So, change that instead?  Or rewrite it, it's yucky.  Bonus points if
> > you also handle 0d 0a and 0a 0d line endings.
> 
> ... which is what the original patch was trying to do last year:
> http://www.openfirmware.info/pipermail/openbios/2015-August/008781.html.

This patch looks good.

> This works for OS X but causes yaboot to throw errors on the console.

And that is weird.  Any idea what causes it?

One way to avoid this problem is to only handle 0d this way if booting
some mac thing, if we have detected that by then anyway :-/

> I still feel we're lacking a good explanation as to why processing this
> on a line-by-line basis makes a difference, and how the r-stack problem
> is being mitigated in this case.

The Forth standard requires EVALUATE to treat its whole input as one
string, carriage returns and newlines included.  OF defers this to the
Forth standard.  So it would be best *not* to do this in EVALUATE, to
comply with this.

The closest I've found to how to parse a script is the Forth requirements
for how to handle INCLUDE-FILE, and that is line-by-line.

The R problems aren't mitigated at all IMO, just worked around.

I'll have a look at whether ofw's EVAL handles multiple lines.


Segher