Mark W Wenning/Austin/IBM is out of the office.
by Mark W Wenning
I will be out of the office starting 03/21/2005 and will not return until
03/25/2005.
I will be in a class all week and will not be checking mail. Please
contact Colleen Stouffer for SCSI issues, Muhamed Sadic for network issues,
and my manager, Cathy Nunez for any other issues.
14 years, 10 months
- 1
- 0
abort and resume, assembler
by sachin thakur
Hi,
Thanks for your inputs..
I have one more querry...
1. I am trying to implement abort and resume (section 7.6.3). After reading the spec my understanding is that when a abort key sequence is pressed the currently running program should halt and control should transfer to the command interpreter.
But the openfirmware process model is single-threaded and there is only one, non-preempted program running at a time. So when a program is running how can i detect the abort key sequence?
2. I am trying to implement forth word for the Assembler mentioned In Open Firmware spec., section 7.3.9.3.
According to this section user should be able to create machine-level code definition from the command interpreter.
My doubt is how forth inner-interpreter will identify the machine dependent assembly mnemonics?
Whether Assembler would be invoked to parse the machine level code entered from the command interpreter?
In this case, Assembler should be the part of the boot firmware?
Regards
Sachin
-----Original Message-----
From: Stefan Reinauer [mailto:stepan@openbios.org]
Sent: Thursday, March 17, 2005 8:05 PM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] cpeek, wpeek etc
* sachin thakur <koolsachin_26(a)yahoo.co.in> [050317 08:36]:
> Hi all
>
> I am trying to implement the words mentioned in section 5.3.7.1 of
> open firmware specification viz. cpeek, wpeek etc.
>
> For this I have already implemented exception handling, which is in C
> and assembly.
Sounds interesting. Did you have a look at the exception handling code I checked in a while ago?
> Now to implement these words I need to create some flags (variables)
> which can be accessed from both forth and C.
>
> Is there any way by which I can access the same variable from both c
> and forth.
Yes, look at the handling of "last". Variables in forth are just normal words that push the address of the memory associated with them to the stack. You can use this with the normal forth-c-bindings
If you publish a patch of your work people here can likely help you.
14 years, 10 months
- 1
- 0
tokenizer bug
by Mark Wenning
Greetings,
Our "OpenBIOS guy" thinks he found a bug in the tokenizer.
Can you comment?
What's the procedure for submitting fixes?
Looks like my previous post attempt was screwed up by Lotus notes,
trying again...
-----
Mark Wenning wenning(a)us.ibm.com 1-512-838-6263
Global FirmWare: Networking and I/O, FC lackey
-----
Experience is what you get when you were expecting something else. -
Anon
-----
----- Forwarded by Mark W Wenning/Austin/IBM on 03/07/2005 10:02 AM -----
David L Paktor/Almaden/IBM
03/04/2005 05:33 PM
To
wenning(a)us.ibm.com
cc
Subject
Re: Found a serious bug in OpenBios Tokenizer
Hi, Mark.
As we spoke, I'm giving you some additional detail to describe the bug I
found.
Here's a recap of what I wrote before:
It has to do with fload ; When your source fload s a file, that file
is supposed to be a continuation of your source-stream.
New definitions, as they are processed in the Tokenizer, are supposed to
get successive FCode tokens assigned to them, starting at 0x0800.
But when the OpenBios Tokenizer fload s a new file, it resets the FCode
token-number, and starts assigning tokens from 0x0800 again. So if you
have:
definition A
definition B
definition C
definition D
\ and then
fload File1 \ which has:
definition E
definition F
definition G
definition H
and then you have something that intends to invoke A B C or D you
will instead get E F G or H , respectively....
Here's the additional material:
The source of the problem can be traced to the routines: init_stream
and init_output in the file stream.c . They are both called at the
beginning of tokenization, one to prepare the source from which input
will be scanned, and the other to prepare the area to which output will
be delivered (broadly speaking). When the fload directive is
encountered, the input source is suspended and a new one is activated;
when the new one is exhausted, the previous one is re-activated at the
point from which it was suspended. So far so good. The init_stream
routine is called to effectuate that activation. Unfortunately, the
line that initializes the FCode token-numbers being assigning to new
definitions -- the variable called nextfcode -- occurs inside the
init_stream routine.
I believe that moving that line to the init_output routine is
sufficient to fix this bug.
14 years, 10 months
- 2
- 2
cpeek, wpeek etc
by sachin thakur
Hi all
I am trying to implement the words mentioned in section 5.3.7.1 of open firmware specification viz. cpeek, wpeek etc.
For this I have already implemented exception handling, which is in C and assembly.
Now to implement these words I need to create some flags (variables) which can be accessed from both forth and C.
Is there any way by which I can access the same variable from both c and forth.
Kindly tell me the solution.
Regards
Sachin
14 years, 10 months
- 2
- 1
Re: [OpenBIOS] Fw: Found a serious bug in OpenBios Tokenizer
by Stefan Reinauer
Hi,
* Mark W Wenning <wenning(a)us.ibm.com> [050307 17:10]:
> Our "OpenBIOS guy" thinks he found a bug in the tokenizer.
> Can you comment?
> What's the procedure for submitting fixes?
sorry for the late answer. The best way is to enter it as an issue
in the OpenBIOS issue tracker at
https://www.openbios.org/roundup/openbios/
Or just report it on this mailing list.
> It has to do with fload ; When your source fload s a file, that file is
> supposed to be a continuation of your source-stream.
>
> New definitions, as they are processed in the Tokenizer, are supposed to
> get successive FCode tokens assigned to them, starting at 0x0800.
>
> But when the OpenBios Tokenizer fload s a new file, it resets the FCode
> token-number, and starts assigning tokens from 0x0800 again. So if you
> have:
Oops. This is nasty. Thanks for spotting it. I remember resetting the
fcode number to 0x800 to allow multiple files to be tokenized in a row.
Obviously this one sneaked in.
> I believe that moving that line to the init_output routine is sufficient
> to fix this bug.
It is. Commited. See
stepan(a)openbios.org--devel/openbios--main--1.0--patch-17 and
stepan(a)openbios.org--devel/openbios--xml--1.0--patch-9
Stefan
14 years, 10 months
- 1
- 0
Fw: Found a serious bug in OpenBios Tokenizer
by Mark W Wenning
Greetings,
Our "OpenBIOS guy" thinks he found a bug in the tokenizer.
Can you comment?
What's the procedure for submitting fixes?
-----
Mark Wenning wenning(a)us.ibm.com 1-512-838-6263
Global FirmWare: Networking and I/O, FC lackey
-----
Experience is what you get when you were expecting something else. -
Anon
-----
----- Forwarded by Mark W Wenning/Austin/IBM on 03/07/2005 10:02 AM -----
David L
Paktor/Almaden/IB
M To
wenning(a)us.ibm.com
03/04/2005 05:33 cc
PM
Subject
Re: Found a serious bug in OpenBios
Tokenizer(Document link: Mark W
Wenning)
Hi, Mark.
As we spoke, I'm giving you some additional detail to describe the bug I
found.
Here's a recap of what I wrote before:
It has to do with fload ; When your source fload s a file, that file is
supposed to be a continuation of your source-stream.
New definitions, as they are processed in the Tokenizer, are supposed to
get successive FCode tokens assigned to them, starting at 0x0800.
But when the OpenBios Tokenizer fload s a new file, it resets the FCode
token-number, and starts assigning tokens from 0x0800 again. So if you
have:
definition A
definition B
definition C
definition D
\ and then
fload File1 \ which has:
definition E
definition F
definition G
definition H
and then you have something that intends to invoke A B C or D you will
instead get E F G or H , respectively....
Here's the additional material:
The source of the problem can be traced to the routines: init_stream and
init_output in the file stream.c . They are both called at the
beginning of tokenization, one to prepare the source from which input will
be scanned, and the other to prepare the area to which output will be
delivered (broadly speaking). When the fload directive is encountered,
the input source is suspended and a new one is activated; when the new one
is exhausted, the previous one is re-activated at the point from which it
was suspended. So far so good. The init_stream routine is called to
effectuate that activation. Unfortunately, the line that initializes the
FCode token-numbers being assigning to new definitions -- the variable
called nextfcode -- occurs inside the init_stream routine.
I believe that moving that line to the init_output routine is sufficient
to fix this bug.
The two files attached are the new version of stream.c and a diffs
file, going from the old version to the new.
Please incorporate this fix into the published code at the earliest
possible juncture.
David L. Paktor System Firmware Developer
System and Technology Group Global Firmware Division
dlpaktor(a)us.ibm.com David L Paktor/Almaden/IBM@IBMUS
18880 Homestead Rd. Building 9945
Cupertino CA 95014 Room 1026
408-342-6110 T/L 560-6110(See attached file: stream.c)
(See attached file: stream.diffs)
14 years, 10 months
- 1
- 0