http://www.openfirmware.info/pipermail/openbios/2015-June/008722.html
diff --git a/openbios-devel/forth/bootstrap/interpreter.fs b/openbios-devel/forth/bootstrap/interpreter.fs index 5187058..74a109f 100644 --- a/openbios-devel/forth/bootstrap/interpreter.fs +++ b/openbios-devel/forth/bootstrap/interpreter.fs @@ -163,7 +163,7 @@ defer outer-interpreter : evaluate ( str len -- ?? ) 2dup + -rot over + over do - i c@ 0a = if + i c@ dup 0a = swap 0d = or if i over -
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
This is a solution I came up with to fix incompatibility with other operating systems and still be able to boot Mac OS 9. The adler32 word is only used on Mac OS 9, so what if it sets a flag variable to indicate Mac OS 9 is being used. Then OpenBIOS uses that flag to determine which line of code should be used. Here is the pseudo-code:
In adler32.... set using_mac_os_9 = true
In the evaluate word:
if (using_mac_os_9 == true) { i c@ dup 0a = swap 0d = or if }
else { i c@ 0a = if }
Does this sound good?
On 2016-Feb-1 23:08 , Programmingkid wrote:
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
0d is carriage return. "carret" means carriage return, not "^", which would be "caret".
On Feb 2, 2016, at 6:08 AM, Tarl Neustaedter wrote:
On 2016-Feb-1 23:08 , Programmingkid wrote:
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
0d is carriage return. "carret" means carriage return, not "^", which would be "caret".
Thank you very much for the clarification. I request that the name be changed to carriage_return.
Mark, would you accept that patch?
On 02/02/16 15:19, Programmingkid wrote:
On Feb 2, 2016, at 6:08 AM, Tarl Neustaedter wrote:
On 2016-Feb-1 23:08 , Programmingkid wrote:
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
0d is carriage return. "carret" means carriage return, not "^", which would be "caret".
Thank you very much for the clarification. I request that the name be changed to carriage_return.
Mark, would you accept that patch?
To be honest I'm not particularly keen on having this hack on a hack - I'd much rather we figure out a way to handle r-stack commands in a normal context rather than relying on something which happens to work out of sheer luck :(
ATB,
Mark.
On Feb 2, 2016, at 3:02 PM, Mark Cave-Ayland wrote:
On 02/02/16 15:19, Programmingkid wrote:
On Feb 2, 2016, at 6:08 AM, Tarl Neustaedter wrote:
On 2016-Feb-1 23:08 , Programmingkid wrote:
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
0d is carriage return. "carret" means carriage return, not "^", which would be "caret".
Thank you very much for the clarification. I request that the name be changed to carriage_return.
Mark, would you accept that patch?
To be honest I'm not particularly keen on having this hack on a hack - I'd much rather we figure out a way to handle r-stack commands in a normal context rather than relying on something which happens to work out of sheer luck :(
I remember you saying that Mac OS 9 reorders the return stack. If that is true, then in theory this problem could be fixed by placing a bunch of no-ops in the stack before Mac OS 9 reorders it.
Stack Before: Stack with no-ops: func1 func1 func2 func2 func3 func3 no-op1 no-op2 no-op3 no-op4 no-op5 Then when Mac OS 9 does its reordering, it would look like this:
Reordered stack: func1 func2 func3 no-op2 no-op4 no-op3 no-op1 Mac OS 9 code
No harm would be done. In theory this shouldn't hurt other operating systems since the no-ops would do nothing. What do you think?
On Feb 2, 2016, at 3:02 PM, Mark Cave-Ayland wrote:
On 02/02/16 15:19, Programmingkid wrote:
On Feb 2, 2016, at 6:08 AM, Tarl Neustaedter wrote:
On 2016-Feb-1 23:08 , Programmingkid wrote:
This is most of the patch that is needed to make OpenBIOS successfully boot Mac OS 9. From the bootstrap.fs file, the 0a means linefeed. The file also says the 0d means carret '^'? If this patch is to look for linefeeds and carriage returns, why use the carret character here?
0d is carriage return. "carret" means carriage return, not "^", which would be "caret".
Thank you very much for the clarification. I request that the name be changed to carriage_return.
Mark, would you accept that patch?
To be honest I'm not particularly keen on having this hack on a hack - I'd much rather we figure out a way to handle r-stack commands in a normal context rather than relying on something which happens to work out of sheer luck :(
I was wondering why you think there is a problem with r-stack commands. I haven't found anything that indicates they are a problem. Mac OS 9 does use R> and >R a lot, but they don't seem to cause any problems. The problem seems to be with the missing CR-LF patch. I tested this patch with Fedora and Debian. They both boot. There is an exception message that is printed, but that doesn't appear to stop any of the OS's from booting. It could be something else that is causing problems.
This is the Debian error message:
method:interpret: exception -13 caught ^mem isn’t unique. ^mmu isn’t unique.
Here is the Fedora error message:
milliseconds:interpret: exception -13 caught ^mem isn’t unique. ^mmu isn’t unique.
Exception -13 is an undefined word.
^mem and ^mmu are both defined in the yaboot file in Fedora. I assume the "isn't unique" message is because something already defined both words. I don't know if they are being defined twice or more, but they aren't already defined in OpenBIOS.
Now I think I know what is wrong with Fedora. It is with the milliseconds word. The function is surrounded by NULL characters on either side. Maybe they are interfering with the interpret word.
OpenBIOS does appear to have the milliseconds word defined in methods.c.
On 04/02/16 18:41, Programmingkid wrote:
I was wondering why you think there is a problem with r-stack commands. I haven't found anything that indicates they are a problem. Mac OS 9 does use R> and >R a lot, but they don't seem to cause any problems. The problem seems to be with the missing CR-LF patch. I tested this patch with Fedora and Debian. They both boot. There is an exception message that is printed, but that doesn't appear to stop any of the OS's from booting. It could be something else that is causing problems.
This is the Debian error message:
method:interpret: exception -13 caught ^mem isn’t unique. ^mmu isn’t unique.
Here is the Fedora error message:
milliseconds:interpret: exception -13 caught ^mem isn’t unique. ^mmu isn’t unique.
Exception -13 is an undefined word.
^mem and ^mmu are both defined in the yaboot file in Fedora. I assume the "isn't unique" message is because something already defined both words. I don't know if they are being defined twice or more, but they aren't already defined in OpenBIOS.
Now I think I know what is wrong with Fedora. It is with the milliseconds word. The function is surrounded by NULL characters on either side. Maybe they are interfering with the interpret word.
OpenBIOS does appear to have the milliseconds word defined in methods.c.
From memory the r-stack commands were being executed but the only reason
this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
ATB,
Mark.
Here is another reason why I think the CR-LF patch should be applied:
This is the output of Fedora without the CR-LF patch: *note: used the -nographic option to see the text
0 > boot cd:,\:tbxi : $CM $call-method ;w then ;0= ;de-int nip nip ; INTERPRETE: --- " /chosen" find-package if dup " memory" rot GPP$ if D2NIP swapvalue mmu# value mem# NIP else 0 then else 0 0 then else 0 0 then INTERPRETE: --- : ^mem mem# $CM ; : ^mmu mmu# $CM ; INTERPRETE: --- " _screen-ihandle" $find if execute else 0 then call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
Config file read, 244 bytes INTERPRETE: --- 0 to background-color
INTERPRETE: --- f to foreground-color
Welcome to the 32-bit Fedora 17 installer! Hit <TAB> for boot options.
Without the patch it still prints a lot of unrelated errors. The "INTERPRETE" text is from ciface.fs with the debugging code uncommented.
The output with the patch is mostly unchanged. The ^mem and ^mmu messages look harmless. The only addition is the -13 exception. According to a comment in the interpret word, this exception might not be an error.
0 > boot cd:,\:tbxi : $CM $call-method ;w then ;0= ;de-int nip nip ; INTERPRETE: --- " /chosen" find-package if dup " memory" rot GPP$ if D2NIP swapvalue mmu# value mem# NIP else 0 then else 0 0 then else 0 0 then milliseconds:interpret: exception -13 caught
interpret " /chosen" find-package if dup " memory" rot GPP$ if D2NIP swap " value mmu# value mem# failed with error ffffffedelse 0 0 then
INTERPRETE: --- : ^mem mem# $CM ; : ^mmu mmu# $CM ; ^mem isn't unique. ^mmu isn't unique. INTERPRETE: --- " _screen-ihandle" $find if execute else 0 then call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
call-method color!: exception -21
call-method color! failed with error ffffffdf
Config file read, 244 bytes INTERPRETE: --- 0 to background-color
INTERPRETE: --- f to foreground-color
Welcome to the 32-bit Fedora 17 installer! Hit <TAB> for boot options.
Welcome to yaboot version 1.3.17 (Red Hat 1.3.17-2.fc16) Enter "help" to get some basic usage information boot:
With and without the patch Fedora makes it to the same place.
On Thu, 4 Feb 2016, Programmingkid wrote:
Here is another reason why I think the CR-LF patch should be applied:
[...]
With and without the patch Fedora makes it to the same place.
This does not change that it's a hack we should avoid, especially if it only works by chance.
On Thu, 4 Feb 2016, Mark Cave-Ayland wrote:
From memory the r-stack commands were being executed but the only reason this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
Do you have any more info about what are these r-stack commands and what's the issue with them currently so we can find a way that this could be cleanly resolved? Maybe if you can describe what needs to be done someone would be able to pick it up and create a patch.
Regards, BALATON Zoltan
On 05/02/16 12:33, BALATON Zoltan wrote:
On Thu, 4 Feb 2016, Programmingkid wrote:
Here is another reason why I think the CR-LF patch should be applied:
[...]
With and without the patch Fedora makes it to the same place.
This does not change that it's a hack we should avoid, especially if it only works by chance.
On Thu, 4 Feb 2016, Mark Cave-Ayland wrote:
From memory the r-stack commands were being executed but the only reason this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
Do you have any more info about what are these r-stack commands and what's the issue with them currently so we can find a way that this could be cleanly resolved? Maybe if you can describe what needs to be done someone would be able to pick it up and create a patch.
Well the r-stack is the Forth equivalent of a frame pointer, i.e. the return address once the end of the word is reached. In Forth world, the r-stack can be used for temporary storage as long as it is returned to its initial state before the currently executing word has completed.
The Apple 9.2 bootloader ignores the Forth specification in this respect and includes direct r-stack commands and hence the return address is corrupted once they have executed (for fun, try typing r-stack commands directly into the OpenBIOS command line).
So the solution is to find some way to preserve the r-stack in this context to ensure that execution continues back at the right location.
HTH,
Mark.
On Fri, 5 Feb 2016, Mark Cave-Ayland wrote:
The Apple 9.2 bootloader ignores the Forth specification in this respect and includes direct r-stack commands and hence the return address is corrupted once they have executed (for fun, try typing r-stack commands directly into the OpenBIOS command line).
So the solution is to find some way to preserve the r-stack in this context to ensure that execution continues back at the right location.
How does this work on Apple's OF implementation? How is that different from OpenBIOS?
Regards, BALATON Zoltan
On 05/02/16 13:08, BALATON Zoltan wrote:
On Fri, 5 Feb 2016, Mark Cave-Ayland wrote:
The Apple 9.2 bootloader ignores the Forth specification in this respect and includes direct r-stack commands and hence the return address is corrupted once they have executed (for fun, try typing r-stack commands directly into the OpenBIOS command line).
So the solution is to find some way to preserve the r-stack in this context to ensure that execution continues back at the right location.
How does this work on Apple's OF implementation? How is that different from OpenBIOS?
No idea, since we don't have the source code ;) However we can assume that the only reason this works is due to a specific implementation detail of Apple's OF in this respect.
You can get fairly close by forcing the interpret word to execute in compile mode, however that fails as soon as you come across a : to define a word which is also present in the Apple bootloader. I guess the solution would have to involved switching to a separate r-stack context for words executed within the interpret string or similar.
Segher, did you have any further ideas on this?
ATB,
Mark.
On Feb 5, 2016, at 8:17 AM, Mark Cave-Ayland wrote:
On 05/02/16 13:08, BALATON Zoltan wrote:
On Fri, 5 Feb 2016, Mark Cave-Ayland wrote:
The Apple 9.2 bootloader ignores the Forth specification in this respect and includes direct r-stack commands and hence the return address is corrupted once they have executed (for fun, try typing r-stack commands directly into the OpenBIOS command line).
So the solution is to find some way to preserve the r-stack in this context to ensure that execution continues back at the right location.
How does this work on Apple's OF implementation? How is that different from OpenBIOS?
No idea, since we don't have the source code ;) However we can assume that the only reason this works is due to a specific implementation detail of Apple's OF in this respect.
You can get fairly close by forcing the interpret word to execute in compile mode, however that fails as soon as you come across a : to define a word which is also present in the Apple bootloader. I guess the solution would have to involved switching to a separate r-stack context for words executed within the interpret string or similar.
Segher, did you have any further ideas on this?
I'm not entirely convinced that anything is broken. Mac OS 9 booting successfully in OpenBIOS doesn't translate to me as something being broken, but actually working.
Maybe when the client interface is running, there should be two return stacks.
On Feb 5, 2016, at 7:33 AM, BALATON Zoltan wrote:
On Thu, 4 Feb 2016, Programmingkid wrote:
Here is another reason why I think the CR-LF patch should be applied:
[...]
With and without the patch Fedora makes it to the same place.
This does not change that it's a hack we should avoid, especially if it only works by chance.
Are you talking about the CR-LF patch? The logic of the patch looks sound. It just keeps linefeeds and carriage returns out of strings that are being executed. What chance are we taking?
On Thu, 4 Feb 2016, Mark Cave-Ayland wrote:
From memory the r-stack commands were being executed but the only reason this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
Do you have any more info about what are these r-stack commands and what's the issue with them currently so we can find a way that this could be cleanly resolved? Maybe if you can describe what needs to be done someone would be able to pick it up and create a patch.
I think the CR-LF patch and this r-stack issue are two completely unrelated issues. Or are they related?
On 05/02/16 16:39, Programmingkid wrote:
On Feb 5, 2016, at 7:33 AM, BALATON Zoltan wrote:
On Thu, 4 Feb 2016, Programmingkid wrote:
Here is another reason why I think the CR-LF patch should be applied:
[...]
With and without the patch Fedora makes it to the same place.
This does not change that it's a hack we should avoid, especially if it only works by chance.
Are you talking about the CR-LF patch? The logic of the patch looks sound. It just keeps linefeeds and carriage returns out of strings that are being executed. What chance are we taking?
On Thu, 4 Feb 2016, Mark Cave-Ayland wrote:
From memory the r-stack commands were being executed but the only reason this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
Do you have any more info about what are these r-stack commands and what's the issue with them currently so we can find a way that this could be cleanly resolved? Maybe if you can describe what needs to be done someone would be able to pick it up and create a patch.
I think the CR-LF patch and this r-stack issue are two completely unrelated issues. Or are they related?
Yes, they are. It just so happens that with the CR-LF patch the interpret word breaks down the incoming Forth string in such a way that r-stack words are "caught" by the trampoline in a way that allows execution to continue.
ATB,
Mark.
On Feb 5, 2016, at 12:55 PM, Mark Cave-Ayland wrote:
On 05/02/16 16:39, Programmingkid wrote:
On Feb 5, 2016, at 7:33 AM, BALATON Zoltan wrote:
On Thu, 4 Feb 2016, Programmingkid wrote:
Here is another reason why I think the CR-LF patch should be applied:
[...]
With and without the patch Fedora makes it to the same place.
This does not change that it's a hack we should avoid, especially if it only works by chance.
Are you talking about the CR-LF patch? The logic of the patch looks sound. It just keeps linefeeds and carriage returns out of strings that are being executed. What chance are we taking?
On Thu, 4 Feb 2016, Mark Cave-Ayland wrote:
From memory the r-stack commands were being executed but the only reason this worked was because of the OpenBIOS trampoline between calling each word which just about allowed execution to continue.
Do you have any more info about what are these r-stack commands and what's the issue with them currently so we can find a way that this could be cleanly resolved? Maybe if you can describe what needs to be done someone would be able to pick it up and create a patch.
I think the CR-LF patch and this r-stack issue are two completely unrelated issues. Or are they related?
Yes, they are. It just so happens that with the CR-LF patch the interpret word breaks down the incoming Forth string in such a way that r-stack words are "caught" by the trampoline in a way that allows execution to continue.
Being caught by the trampoline is not allowed? I and probably everyone else is a little fuzzy about this trampoline issue. Is there anything you could show us to help us understand what you want?
-
BALATON Zoltan -
Mark Cave-Ayland -
Programmingkid -
Tarl Neustaedter