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 <asif.haswarey(a)qlogic.com> [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

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: info(a)coresystems.de  • http://www.coresystems.de/

[David L. Paktor]

Stefan Reinauer wrote:
  Dear Äsif

 * Asif Haswarey <asif.haswarey(a)qlogic.com> [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             dlpaktor(a)netscape.net

[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: openbios-bounces(a)openbios.org [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 <asif.haswarey(a)qlogic.com> [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             dlpaktor(a)netscape.net


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

[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=qlogic.com(a)openbios.org
[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: openbios-bounces(a)openbios.org [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 <asif.haswarey(a)qlogic.com> [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             dlpaktor(a)netscape.net


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

[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...

-- 

David L. Paktor             dlpaktor(a)netscape.net

[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=OpenBIO…

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: openbios-bounces(a)openbios.org [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...

-- 

David L. Paktor             dlpaktor(a)netscape.net


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

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=OpenBIO…
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...

-- 

David L. Paktor             dlpaktor(a)netscape.net

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: openbios-bounces(a)openbios.org [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...

-- 

David L. Paktor             dlpaktor(a)netscape.net


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

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 <Tarl.Neustaedter(a)Sun.COM> [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. 

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: info(a)coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

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: openbios-bounces(a)openbios.org
[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.

-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

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"?
 
 1) Technical
 2) 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: openbios-bounces(a)openbios.org
[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


-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you

[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?

-- 

David L. Paktor             dlpaktor(a)netscape.net