Questions about OpenFirmware

[deech]

Hi all,
I have a couple of questions about OpenFirmware but there hasn't been any activity on the mailing list (http://www.openfirmware.info/pipermail/openfirmware/) in quite some time so I thought I'd ask here.

I'm having trouble seeing how the whole thing is bootstrapped.
For instance
1. there's a builder.dic binary file that's used by the forth implementation and I don't see how that is built,
2. I can't see the code that actually parses the Forth code and converts it to assembly.

Thanks!
-deech

[Alex Wegel]

Hi

How about:

http://tracker.coreboot.org/trac/openfirmware/browser/forth/lib/builder.
fth

Code generation for various cpus is also in that source tree:

http://tracker.coreboot.org/trac/openfirmware/browser/cpu

Did you have a look at http://www.openfirmware.info/ itself (not just
the mailing list)?

HTH,
Alex

[Elizabeth D. Rather]

The details depend on the version of Open Firmware. Apple's system
differed significantly from Sun's, and IBM's was different still.

In most of them there is a core that was written in assembler (although
I think Sun's was meta-compiled with Forth). And none of them actually
compile machine language in the sense that a C compiler or a "compile to
code" Forth does. It's a "subroutine threaded" system, in which the
runtime code consists of sequences of calls. The reason for this is that
it's essential to be able to decompile ("see") the content of
definitions for debugging purposes, since the source is rarely available.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:SYSdnQ8ozpNuQQLN...@supernews.com...
...

> The details depend on the version of Open Firmware. Apple's system
> differed significantly from Sun's, and IBM's was different still.
>

Sigh... It's a standard! Why are the implementations different?

"IEEE Standard for Boot (Initialization Configuration) Firmware:
Core Requirements and Practices"
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.3940


Rod Pemberton

[Elizabeth D. Rather]

Implementations can differ if the external interface complies with the
standard, which all of these do. Consider all the many approaches to
implementing ANS Forth! The OP was asking about internal implementation
issues, which are not standardized in OF any more than they are in Forth
or most systems.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:Ar2dnff2p-fDrz3N...@supernews.com...

> On 11/11/12 1:09 PM, Rod Pemberton wrote:
> > "Elizabeth D. Rather" <era...@forth.com> wrote in message
> > news:SYSdnQ8ozpNuQQLN...@supernews.com...
...

> >> The details depend on the version of Open Firmware. Apple's system
> >> differed significantly from Sun's, and IBM's was different still.
> >>
> >
> > Sigh... It's a standard! Why are the implementations different?
> >
> > "IEEE Standard for Boot (Initialization Configuration) Firmware:
> > Core Requirements and Practices"
> > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.3940
>
> Implementations can differ if the external interface complies with the
> standard, which all of these do.

So, you're contradicting yourself elsewhere. You're now saying that if
someone implements COUNT where addr1 and addr2 are the same instead of
different, it's entirely valid because "the external interface complies with
the standard". That's what I said previously about such a COUNT ... I.e.,
there is no check in COUNT and no error checking mechanism in Forth to
verify that COUNT's addr1and addr2 are actually different addresses.

Anyway, by me asking why the supposedly standard compliant implementations
are radically different, I was hoping to once again reinforce the notion of
the importance of conformance testing. A standard by itself can be
interpreted to mean just about anything, as everyone here has seen me do
- validly I might add - quite a few times now... ;-)


Rod Pemberton

[Elizabeth D. Rather]

On 11/11/12 10:49 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather" <era...@forth.com> wrote in message
> news:Ar2dnff2p-fDrz3N...@supernews.com...
>> On 11/11/12 1:09 PM, Rod Pemberton wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> wrote in message
>>> news:SYSdnQ8ozpNuQQLN...@supernews.com...
> ...
>
>>>> The details depend on the version of Open Firmware. Apple's system
>>>> differed significantly from Sun's, and IBM's was different still.
>>>>
>>>
>>> Sigh... It's a standard! Why are the implementations different?
>>>
>>> "IEEE Standard for Boot (Initialization Configuration) Firmware:
>>> Core Requirements and Practices"
>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.3940
>>
>> Implementations can differ if the external interface complies with the
>> standard, which all of these do.
>
> So, you're contradicting yourself elsewhere. You're now saying that if
> someone implements COUNT where addr1 and addr2 are the same instead of
> different, it's entirely valid because "the external interface complies with
> the standard". That's what I said previously about such a COUNT ... I.e.,
> there is no check in COUNT and no error checking mechanism in Forth to
> verify that COUNT's addr1and addr2 are actually different addresses.

COUNT's glossary entry describes its interface, in terms of arguments
supplied and results returned. It does not specify how these things are
done internally. Validation is the responsibility of test suites, and
there are several around.

> Anyway, by me asking why the supposedly standard compliant implementations
> are radically different, I was hoping to once again reinforce the notion of
> the importance of conformance testing. A standard by itself can be
> interpreted to mean just about anything, as everyone here has seen me do
> - validly I might add - quite a few times now... ;-)

No one disputes the usefulness of conformance testing. That's why
everyone loves the Hayes test suite and similar developments.

[Paul E. Bennett]

Rod Pemberton wrote:

[%X]

> So, you're contradicting yourself elsewhere. You're now saying that if
> someone implements COUNT where addr1 and addr2 are the same instead of
> different, it's entirely valid because "the external interface complies
> with
> the standard". That's what I said previously about such a COUNT ...
> I.e., there is no check in COUNT and no error checking mechanism in Forth
> to verify that COUNT's addr1and addr2 are actually different addresses.

I see no contradiction.

Consider the internal storage model of two versions of COUNT.

The first one takes the initial address extracts the first value as a count
of how many bytes are in the string and returns the address of where the
rest of the string is located.

The second version takes the address, reads the value from the location just
before the string and returns the address it was first passed as the start
of the string.

The effects of both versions are consistent with the interface specification
in the stack comments. However, they have two different storage models. Code
that uses COUNT would not care about which version was implemented as on the
same system, the activity would be self consistent.

> Anyway, by me asking why the supposedly standard compliant implementations
> are radically different, I was hoping to once again reinforce the notion
> of
> the importance of conformance testing. A standard by itself can be
> interpreted to mean just about anything, as everyone here has seen me do
> - validly I might add - quite a few times now... ;-)

The ANS standard described behaviour of the words as seen at their
interfaces (the stacks) except where it has been declared in the standard
that there are implementation variations that might make such behaviour
different.

--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************