Dictionary size limit per device instance

[Asif Haswarey]

Does anyone happen to know what the dictionary size upper limit
(for openbios) is hardcoded to per device instance?

_____________

Äsif Haswaréy

QLogic Corporation

[Stefan Reinauer]

Dear Äsif

* Asif Haswarey  [070822 01:06]:
> Does anyone happen to know what the dictionary size upper limit
> (for openbios) is hardcoded to per device instance?

If I remember correctly there is no limit per device instance, but
during bootstrap the dictionary size is limited to 256k:
kernel/bootstrap.c:#define DICTIONARY_SIZE (256*1024) /* 256k for the dictionary */
and I think that value applies for the ports, too.

It's just an arbitrary numbers, we chose it a couple of years ago
when 256k was the usual size of system flash roms, so the resulting
openbios would always fit in a such a small chip with LinuxBIOS and
a compressed OpenBIOS payload.

Stefan

[David L. Paktor]

Stefan Reinauer wrote:
> Dear Äsif
> Asif Haswarey  [070822 01:06]:
> > Does anyone happen to know what the dictionary size upper limit
> > (for openbios) is hardcoded to per device instance?
>
> If I remember correctly there is no limit per device instance, but
> during bootstrap the dictionary size is limited to 256k:
> kernel/bootstrap.c:#define DICTIONARY_SIZE (256*1024) /* 256k for the dictionary */
> and I think that value applies for the ports, too.
>
> It's just an arbitrary numbers, we chose it a couple of years ago
> when 256k was the usual size of system flash roms, so the resulting
> openbios would always fit in a such a small chip with LinuxBIOS and
> a compressed OpenBIOS payload.
>
> Stefan

Well, Flash ROMs certainly have expanded since then!  I understand that
sizes of 8 or 16 Meg are commonplace now, and that 4 Meg sizes are now
considered obsolete (or at least, obsolescent) and that 8 Meg-gers are 
heading
rapidly in that direction!

You might want to browse around the Sun sources.  What happened there,
basically, was that, after the image in ROM was decompressed into memory
and when FCode probing took place, the only real limits on dictionary size
were the amount of physical memory and the difference between the start
of the dictionary and the top of the address space!

There was a variable called LIMIT which marked the end of memory that
was currently allocated for, and mapped to, the dictionary's address-space.
The word ALLOT had a clause that tested for the requested allotment going
past LIMIT, and, if needed, would "just" allocate and map a large chunk of
more memory that would last for a while....

With that arrangement, the amount of dictionary space available to plug-in
device drivers was virtually unlimited!

[Segher Boessenkool]

> > It's just an arbitrary numbers, we chose it a couple of years ago
> > when 256k was the usual size of system flash roms, so the resulting
> > openbios would always fit in a such a small chip with LinuxBIOS and
> > a compressed OpenBIOS payload.
> Well, Flash ROMs certainly have expanded since then!  I understand that
> sizes of 8 or 16 Meg are commonplace now, and that 4 Meg sizes are now
> considered obsolete (or at least, obsolescent) and that 8 Meg-gers are
> heading
> rapidly in that direction!

Not on commodity x86 PCs yet :-(

Segher

[Asif Haswarey]

> With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!

Weel, I ran into this problem while testing (QLogic iSCSI) FCode I had developed for the SPARC.
I experimented with a dummy fcode consisting of only constant declarations.
The FCode failed to get interpreted when the total tokenized size reached just a little
above 50KB (that's kilo-bytes). Unfortunately I system OBP would not let me use the "here"
word to find out the exact size of the dictionary space my dummy FCode used up. So I figured
the dictionary space available for my FCode is basically a portion of the overall dictionary
space available to the system. In short, every device FCode has a limit of dictionary
space available to it.

Is my understand correct? If so, then this is what my question is about concerning OpenBIOS.

-Asif

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David L. Paktor
Sent: Wednesday, August 22, 2007 1:18 AM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Dictionary size limit per device instance

Stefan Reinauer wrote:
> Dear Äsif
> Asif Haswarey  [070822 01:06]:
> > Does anyone happen to know what the dictionary size upper limit (for 
> > openbios) is hardcoded to per device instance?
>
> If I remember correctly there is no limit per device instance, but 
> during bootstrap the dictionary size is limited to 256k:
> kernel/bootstrap.c:#define DICTIONARY_SIZE (256*1024) /* 256k for the 
> dictionary */ and I think that value applies for the ports, too.
>
> It's just an arbitrary numbers, we chose it a couple of years ago when 
> 256k was the usual size of system flash roms, so the resulting 
> openbios would always fit in a such a small chip with LinuxBIOS and a 
> compressed OpenBIOS payload.
>
> Stefan

Well, Flash ROMs certainly have expanded since then!  I understand that sizes of 8 or 16 Meg are commonplace now, and that 4 Meg sizes are now considered obsolete (or at least, obsolescent) and that 8 Meg-gers are heading rapidly in that direction!

You might want to browse around the Sun sources.  What happened there, basically, was that, after the image in ROM was decompressed into memory and when FCode probing took place, the only real limits on dictionary size were the amount of physical memory and the difference between the start of the dictionary and the top of the address space!

There was a variable called LIMIT which marked the end of memory that was currently allocated for, and mapped to, the dictionary's address-space.
The word ALLOT had a clause that tested for the requested allotment going past LIMIT, and, if needed, would "just" allocate and map a large chunk of more memory that would last for a while....

With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!

[Asif Haswarey]

Pardon my spelling errors. Was in a hurry and forgot to do
a spell check!

-Asif

-----Original Message-----
From: openbios-bounces+asif.haswarey=[e-mail] [mailto:openbios-bounces+asif.haswarey=[e-mail]] On Behalf Of Asif Haswarey
Sent: Wednesday, August 22, 2007 5:00 PM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Dictionary size limit per device instance
> With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!

Weel, I ran into this problem while testing (QLogic iSCSI) FCode I had developed for the SPARC.
I experimented with a dummy fcode consisting of only constant declarations.
The FCode failed to get interpreted when the total tokenized size reached just a little above 50KB (that's kilo-bytes). Unfortunately I system OBP would not let me use the "here"
word to find out the exact size of the dictionary space my dummy FCode used up. So I figured the dictionary space available for my FCode is basically a portion of the overall dictionary space available to the system. In short, every device FCode has a limit of dictionary space available to it.

Is my understand correct? If so, then this is what my question is about concerning OpenBIOS.

-Asif

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David L. Paktor
Sent: Wednesday, August 22, 2007 1:18 AM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Dictionary size limit per device instance

Stefan Reinauer wrote:
> Dear Äsif
> Asif Haswarey  [070822 01:06]:
> > Does anyone happen to know what the dictionary size upper limit (for
> > openbios) is hardcoded to per device instance?
>
> If I remember correctly there is no limit per device instance, but 
> during bootstrap the dictionary size is limited to 256k:
> kernel/bootstrap.c:#define DICTIONARY_SIZE (256*1024) /* 256k for the 
> dictionary */ and I think that value applies for the ports, too.
>
> It's just an arbitrary numbers, we chose it a couple of years ago when 
> 256k was the usual size of system flash roms, so the resulting 
> openbios would always fit in a such a small chip with LinuxBIOS and a 
> compressed OpenBIOS payload.
>
> Stefan

Well, Flash ROMs certainly have expanded since then!  I understand that sizes of 8 or 16 Meg are commonplace now, and that 4 Meg sizes are now considered obsolete (or at least, obsolescent) and that 8 Meg-gers are heading rapidly in that direction!

You might want to browse around the Sun sources.  What happened there, basically, was that, after the image in ROM was decompressed into memory and when FCode probing took place, the only real limits on dictionary size were the amount of physical memory and the difference between the start of the dictionary and the top of the address space!

There was a variable called LIMIT which marked the end of memory that was currently allocated for, and mapped to, the dictionary's address-space.
The word ALLOT had a clause that tested for the requested allotment going past LIMIT, and, if needed, would "just" allocate and map a large chunk of more memory that would last for a while....

With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!

[David L. Paktor]

Asif Haswarey wrote:
> > With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!
>
> Weel, I ran into this problem while testing (QLogic iSCSI) FCode I had developed for the SPARC.
> I experimented with a dummy fcode consisting of only constant declarations.
> The FCode failed to get interpreted when the total tokenized size reached just a little
> above 50KB (that's kilo-bytes). Unfortunately I system OBP would not let me use the "here"
> word to find out the exact size of the dictionary space my dummy FCode used up. So I figured
> the dictionary space available for my FCode is basically a portion of the overall dictionary
> space available to the system. In short, every device FCode has a limit of dictionary
> space available to it.
>
> Is my understand correct? If so, then this is what my question is about concerning OpenBIOS.

Well, it's not an inherent characteristic of Open Firmware, nor of OBP.  
It might depend on the
platform where you were running your test.  If it was one of the 
E{3..6}{0,5}00 servers, that
would be consistent.  Incidentally, what happened when you hit the limit?

As for seeing "here" from FCode:

defer my_here
 '  noop to my_here
" here" $find if  to my_here  then

( you might need a  "drop"  after  the "if"; I forgot whether  $find  
returns just the XT or
the "immediate" indicator, too...)

Then you can rock'n'roll with  my_here  to show you where you are...

[Segher Boessenkool]

> As for seeing "here" from FCode:
>
> defer my_here
>  '  noop to my_here
> " here" $find if  to my_here  then
>
> ( you might need a  "drop"  after  the "if"; I forgot whether  $find
> returns just the XT or
> the "immediate" indicator, too...)
>
> Then you can rock'n'roll with  my_here  to show you where you are...

: my-here  " here" eval ;

Slower at run time (searching the dictionary every time), but this
is debug code right :-)

Segher

[Asif Haswarey]

Ok, I found out what the problem is!
It's the FCode-Number limit, ie. 0x0fff.
For details please look at:
OpenFirmware IEEE-1275 (1994) spec. section 2.3.43.

If I got this right, I am allowed to define/declare only 0x0fff number of
constants and/or functions, variables, defers etc. for which the
tokenizer assigns a FCode-Number in the final tokenized FCode image.
Please look at the constant symbol FCODE_LIMIT in nextfcode.h
in fcode-utils-1.0.2 suite at:
http://www.openbios.org/viewvc/fcode-utils.tar.gz?view=tar&root=OpenBIOS...

Now given that today we have complex feature rich PCI based
plugin cards, I can see FCode images of size 50K+ in order to
support the various features. I don't expect to see a revision of the
original OpenFirmware IEEE-1275 (1994) spec., but should we reconsider this
FCode-Number limitation?

Moreover, I am actually running into this limitation for one of our PCI-E
plugin cards!
_____________
Äsif Haswaréy
QLogic Corporation
FCode Driver Development

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David L. Paktor
Sent: Wednesday, August 22, 2007 7:30 PM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Dictionary size limit per device instance

Asif Haswarey wrote:
> > With that arrangement, the amount of dictionary space available to plug-in device drivers was virtually unlimited!
>
> Weel, I ran into this problem while testing (QLogic iSCSI) FCode I had developed for the SPARC.
> I experimented with a dummy fcode consisting of only constant declarations.
> The FCode failed to get interpreted when the total tokenized size 
> reached just a little above 50KB (that's kilo-bytes). Unfortunately I system OBP would not let me use the "here"
> word to find out the exact size of the dictionary space my dummy FCode 
> used up. So I figured the dictionary space available for my FCode is 
> basically a portion of the overall dictionary space available to the 
> system. In short, every device FCode has a limit of dictionary space available to it.
>
> Is my understand correct? If so, then this is what my question is about concerning OpenBIOS.

Well, it's not an inherent characteristic of Open Firmware, nor of OBP.  
It might depend on the
platform where you were running your test.  If it was one of the E{3..6}{0,5}00 servers, that would be consistent.  Incidentally, what happened when you hit the limit?

As for seeing "here" from FCode:

defer my_here
 '  noop to my_here
" here" $find if  to my_here  then

( you might need a  "drop"  after  the "if"; I forgot whether  $find returns just the XT or the "immediate" indicator, too...)

Then you can rock'n'roll with  my_here  to show you where you are...

FCode Limit (Was:Dictionary size limit per device instance)

[David L. Paktor]

Asif Haswarey wrote:
> Ok, I found out what the problem is!
> It's the FCode-Number limit, ie. 0x0fff.
> For details please look at:
> OpenFirmware IEEE-1275 (1994) spec. section 2.3.43.

Oh, for goodness sake.  Sometimes, when we're looking for a mystery we 
overlook
the most obvious thing!
> If I got this right, I am allowed to define/declare only 0x0fff number of
> constants and/or functions, variables, defers etc. for which the
> tokenizer assigns a FCode-Number in the final tokenized FCode image.
> Please look at the constant symbol FCODE_LIMIT in nextfcode.h
> in fcode-utils-1.0.2 suite at:
> http://www.openbios.org/viewvc/fcode-utils.tar.gz?view=tar&root=OpenBIOS...

It's not merely a detail of implementation; it's fundamental to the 
structure of FCode.

And, as you noted, a part of the Standard.

That being said, I'm still very puzzled:  What are you using for a 
tokenizer?  I am quite
certain that the tokenizer obtainable from the OpenBIOS project issues 
an unambiguous
error-message when that limit is exceeded.
> Now given that today we have complex feature rich PCI based
> plugin cards, I can see FCode images of size 50K+ in order to
> support the various features. I don't expect to see a revision of the
> original OpenFirmware IEEE-1275 (1994) spec., but should we reconsider this
> FCode-Number limitation?

That isn't going to happen without an updated Standard.  That would be a 
Good Thing,
and I am certainly -- in principle -- in favor of it.  But it won't help 
with your short-term
(i.e., present) needs.
> Moreover, I am actually running into this limitation for one of our PCI-E
> plugin cards!

Indeed!  Devices are reaching new levels of complexity never envisioned 
when the '94
Standard was being developed.  Fortunately, you are not the only -- or 
first -- to run
up against this limitation.  Even more fortunately, some of the earlier 
encounterers were
among the Alpha-testers who inspired the features documented in the 
section of the
OpenBIOS Tokenizer User's Guide to New Features (or whatever it's 
called...  ;-}  )
headed "Manipulating the FCode-Token-Number Assignment Counter" .  Look 
under:

http://www.openbios.org/data/fcodesuite/Documents/toke.html#mozTocId573280

These features allow you to re-use the assigned FCode numbers.  It's a 
tricky operation,
but done carefully, it will allow you to pack a lot of functionality 
into your code.  If you're
still in contact with our mutual colleagues in Austin, ask them -- they 
should be able to
give you more detailed advice.

I hope this helps...

FCode Limit (Was:Dictionary size limit per deviceinstance)

[Asif Haswarey]

> That being said, I'm still very puzzled:  What are you using for a
> tokenizer? I am quite certain that the tokenizer obtainable from the
> OpenBIOS project issues an unambiguous error-message when that limit
> is exceeded.

I did not give the details, but this error message is what led me to
conclude with further experimentation that the FCode-Number limit was
the culprit! Here is the error message:

| Fatal Error:  File junk1.fth, Line 2048.  (Output Position = 29766).
| (PCI-Block Position = 29714).  Too many definitions.  Assigned FCode
| exceeds limit specified by IEEE-1275.
| Tokenization terminating.
| Suppressing binary output.

Interesting to note that Sun's tokenizer does not catch this problem
and simply builds the image. I have not tried to find out the upper limit
at which the tokenizer complains.
> http://www.openbios.org/data/fcodesuite/Documents/toke.html#mozTocId573280
> These features allow you to re-use the assigned FCode numbers.
> It's a tricky operation, but done carefully, it will allow you
> to pack a lot of functionality into your code.  If you're still
> in contact with our mutual colleagues in Austin, ask them -- they
> should be able to give you more detailed advice.

I is a helpful pointer! I am going to investigate this further! Thanks!
> That isn't going to happen without an updated Standard.
> That would be a Good Thing, and I am certainly -- in
> principle -- in favor of it.  But it won't help with
> your short-term (i.e., present) needs.

Very unfortunate if the IEEE-1275 Std. never gets updated, and if that's
the case, it a grim indication of a serious lack of interest by the big
guys! However, I don't see what could stop the developers/maintainers of
OpenBIOS from updating the std. (with consultation from Mitch Bradley and
other _interested_ folks.)

_____________
Äsif Haswaréy
QLogic Corporation

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David L. Paktor
Sent: Tuesday, August 28, 2007 11:23 PM
To: The OpenBIOS Mailinglist
Subject: [OpenBIOS] FCode Limit (Was:Dictionary size limit per deviceinstance)

Asif Haswarey wrote:
> Ok, I found out what the problem is!
> It's the FCode-Number limit, ie. 0x0fff.
> For details please look at:
> OpenFirmware IEEE-1275 (1994) spec. section 2.3.43.

Oh, for goodness sake.  Sometimes, when we're looking for a mystery we overlook the most obvious thing!
> If I got this right, I am allowed to define/declare only 0x0fff number 
> of constants and/or functions, variables, defers etc. for which the 
> tokenizer assigns a FCode-Number in the final tokenized FCode image.
> Please look at the constant symbol FCODE_LIMIT in nextfcode.h in 
> fcode-utils-1.0.2 suite at:
> http://www.openbios.org/viewvc/fcode-utils.tar.gz?view=tar&root=OpenBI
> OS&pathrev=113

It's not merely a detail of implementation; it's fundamental to the structure of FCode.

And, as you noted, a part of the Standard.

That being said, I'm still very puzzled:  What are you using for a tokenizer?  I am quite certain that the tokenizer obtainable from the OpenBIOS project issues an unambiguous error-message when that limit is exceeded.
> Now given that today we have complex feature rich PCI based plugin 
> cards, I can see FCode images of size 50K+ in order to support the 
> various features. I don't expect to see a revision of the original 
> OpenFirmware IEEE-1275 (1994) spec., but should we reconsider this 
> FCode-Number limitation?

That isn't going to happen without an updated Standard.  That would be a Good Thing, and I am certainly -- in principle -- in favor of it.  But it won't help with your short-term (i.e., present) needs.
> Moreover, I am actually running into this limitation for one of our 
> PCI-E plugin cards!

Indeed!  Devices are reaching new levels of complexity never envisioned when the '94 Standard was being developed.  Fortunately, you are not the only -- or first -- to run up against this limitation.  Even more fortunately, some of the earlier encounterers were among the Alpha-testers who inspired the features documented in the section of the OpenBIOS Tokenizer User's Guide to New Features (or whatever it's called...  ;-}  ) headed "Manipulating the FCode-Token-Number Assignment Counter" .  Look
under:

http://www.openbios.org/data/fcodesuite/Documents/toke.html#mozTocId573280

These features allow you to re-use the assigned FCode numbers.  It's a tricky operation, but done carefully, it will allow you to pack a lot of functionality into your code.  If you're still in contact with our mutual colleagues in Austin, ask them -- they should be able to give you more detailed advice.

I hope this helps...

FCode Limit (Was:Dictionary size limit per deviceinstance)

[Tarl Neustaedter]

Asif Haswarey wrote:
[...]
> Very unfortunate if the IEEE-1275 Std. never gets updated,

Unfortunately, the status of IEEE-1275 is "obsolete" (the official
term is "withdrawn"). It's an annoyance because it means getting
new copies of the publication is harder.

Lessee. According to IEEE:

Status: Withdrawn Standard. Withdrawn Date: May 01, 2000.
    No longer endorsed by the IEEE.

IEEE requires the standards be re-affirmed and re-published
every several years (I think it's five years), and the last
time, there simply was no longer enough industry interest to
warrant republishing the standard (or so I'm informed). So
the last one published was IEEE Std 1275-1994, and it no longer
has the status of an active standard.

It would be good if openbios participants revived the standard,
but it takes a lot of effort.

FCode Limit (Was:Dictionary size limit per deviceinstance)

[Stefan Reinauer]

* Tarl Neustaedter  [070829 20:09]:
> IEEE requires the standards be re-affirmed and re-published
> every several years (I think it's five years), and the last
> time, there simply was no longer enough industry interest to
> warrant republishing the standard (or so I'm informed). So
> the last one published was IEEE Std 1275-1994, and it no longer
> has the status of an active standard.
>
> It would be good if openbios participants revived the standard,
> but it takes a lot of effort.

Can you give some pointers? There are many good inputs for a revised
standard out there that need to be bundled for more momentum.

I know the IBM guys are doing their standards via POWER DOT ORG by now.

FCode Limit (Was:Dictionary size limit per deviceinstance)

[Asif Haswarey]

Tarl Neustaedter wrote:
...
> It would be good if openbios participants revived the standard, but it

takes a lot of effort.

How would you categorize this "lot of effort"?

1) Technical
2) Political

Perhaps the current potential market for OpenFirmware is embedded
systems.
The desktop market seems to be following the EFI trend.
May be I am mistaken about EFI's influence. At least I hope I am!

-Asif

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Tarl Neustaedter
Sent: Wednesday, August 29, 2007 11:10 AM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] FCode Limit (Was:Dictionary size limit per
deviceinstance)

Asif Haswarey wrote:
[...]
> Very unfortunate if the IEEE-1275 Std. never gets updated,

Unfortunately, the status of IEEE-1275 is "obsolete" (the official term
is "withdrawn"). It's an annoyance because it means getting new copies
of the publication is harder.

Lessee. According to IEEE:

Status: Withdrawn Standard. Withdrawn Date: May 01, 2000.
    No longer endorsed by the IEEE.

IEEE requires the standards be re-affirmed and re-published every
several years (I think it's five years), and the last time, there simply
was no longer enough industry interest to warrant republishing the
standard (or so I'm informed). So the last one published was IEEE Std
1275-1994, and it no longer has the status of an active standard.

It would be good if openbios participants revived the standard, but it
takes a lot of effort.

FCode Limit (Was:Dictionary size limit per deviceinstance)

[Tarl Neustaedter]

Asif Haswarey wrote:
> Tarl Neustaedter wrote:
> ...
> > It would be good if openbios participants revived the standard, but it
>
> takes a lot of effort.
>
> How would you categorize this "lot of effort"?
> Technical
> Political

Hi Asif -

We had an off-line conversation trading warstories about
committee meetings and a lot of experience from when Mitch
standardized 1275 in the first place.

IEEE has a number of requirements on what the committee
has to contain, in terms of diversity of backgrounds
(industry, academia, ect.), which we don't have here.
Getting enough people from the right backgrounds would be
painful, and probably we'd end up having to teach some of
them the basics so they could contribute.

At a guess, the amount of effort (assuming no underlying
disagreements) would be about six months of committee
time (call it half-time for the committee members and
full time for a chair or editor). Then you'd have to come
up with the up-front money the standards organization is
apt to want - it depends what umbrella organization is
picked.

Note that committee work is expensive; you can't do it
all over phone calls, you have to have periodic face-to-face
meetings to make progress, where you can stick a bunch of
people in a room and not let them out for twelve hours :-).
Seriously, getting the members in a room where they *have*
to pay attention is critical to making progress. This means
a lot of travel, expensive in both money and time.

One problem is probably exemplified by Sun's position;
for all of our interest in OFW, I doubt we could get
a firmware engineer assigned to such a committee. Our
engineers are utterly saturated at this time, and our
CEO has announced we should expect layoffs sometime soon.
Other companies are probably facing similar strictures
at this time. Without some major product's success
hanging on the committee's completion, I doubt you'd
find enough industry representation at this time.

I do wish you luck in trying to formalize a re-invigoration
of the spec.

[Segher Boessenkool]

> It's the FCode-Number limit, ie. 0x0fff.
> For details please look at:
> OpenFirmware IEEE-1275 (1994) spec. section 2.3.43.
>
> If I got this right, I am allowed to define/declare only 0x0fff number 
> of
> constants and/or functions, variables, defers etc. for which the
> tokenizer assigns a FCode-Number in the final tokenized FCode image.

Some Open Firmware implementations have a special FCode x'f4 which
allows FCode#s up to x'ffff; x'f4 followed by "high" byte, "low" byte.

Segher

[Asif Haswarey]

Segher,

I am looking into the possibility of contacting certain important people
to convince them about revising the IEEE-1275 std. If none of them are
interested, then I'll look into the possiblity of the openbios.info
group
getting enough control of IEEE-1275 to revive it and start applying
revisions (which would be subject to reviews).

-Asif

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Segher Boessenkool
Sent: Thursday, August 30, 2007 5:39 PM
To: The OpenBIOS Mailinglist
Subject: Re: [OpenBIOS] Dictionary size limit per device instance
> It's the FCode-Number limit, ie. 0x0fff.
> For details please look at:
> OpenFirmware IEEE-1275 (1994) spec. section 2.3.43.
>
> If I got this right, I am allowed to define/declare only 0x0fff number
> of constants and/or functions, variables, defers etc. for which the 
> tokenizer assigns a FCode-Number in the final tokenized FCode image.

Some Open Firmware implementations have a special FCode x'f4 which
allows FCode#s up to x'ffff; x'f4 followed by "high" byte, "low" byte.

Segher

[David L. Paktor]

Asif Haswarey wrote:
> Does anyone happen to know what the dictionary size upper limit
> (for openbios) is hardcoded to per device instance?
>
> Äsif Haswaréy
>
> QLogic Corporation

Hey, Asif!

Technically speaking, an "instance" of a device does not take up any 
dictionary space.  The "package" does.
All "instances" of a device use the same "package" code, and each one 
has its own allocation of memory
to use with the "instance" variables, values, defers that are part of 
the "package" definition.

Many systems, however will, use the identical FCode source to create 
duplicate "package" nodes for
devices that are replicated on a card or board.  Such an approach might, 
at first glance, appear to be
appallingly inefficient, but it might be justified by the need for 
different address (and suchlike) properties
for the replicated devices...  But I digress.

Anyway, I'm guessing that that might be what you might mean by 
"instance" in your question.

On most systems, there is no particular limit on dictionary usage per 
device node other than the general
limit on the overall dictionary, which, of course, may vary by 
manufacturer and possibly by platform and
version..

One exception comes to mind:  Sun's mid-range Enterprise servers, models 
E3000 through E6500
were configured with a number of "slots" (more on the higher-numbered 
models) into which could
be placed, interchangeably, CPU boards or one of several flavors of I/O 
boards.  Furthermore,
the systems were intended to support Dynamic Reconfiguration.  When a 
board was placed in a
slot, part of its installation procedure was that Open Boot PROM would 
probe it, interpreting its
FCode to build new device nodes.  The mechnism chosen to simplify 
managing the dictionary
was to reserve a generous -- but fixed -- amount of dictionary space for 
each slot; when a slot
was not in use, the linked-list would simply skip over the reserved 
space.  After a new board
was installed and probed, the links would be adjusted to include the new 
entries.  If an overflow
occurred, well, all the system could do was to scream a warning and fail 
the installation.

So, having said all that I am left only with a guess about OpenBIOS:  
I'd guess it follows the
"most systems" pattern.  Stefan, any more details?