Dictionary size limit per device instance
Does anyone happen to know what the dictionary size upper limit (for openbios) is hardcoded to per device instance? _____________ Äsif Haswaréy QLogic Corporation
Dear Äsif * Asif Haswarey <asif.haswarey@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.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/
Stefan Reinauer wrote:
Dear Äsif
* Asif Haswarey <asif.haswarey@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@netscape.net
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
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@openbios.org [mailto:openbios-bounces@openbios.org] 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@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@netscape.net -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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@openbios.org [mailto:openbios-bounces+asif.haswarey=qlogic.com@openbios.org] 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@openbios.org [mailto:openbios-bounces@openbios.org] 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@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@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
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@netscape.net
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
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&pat... 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@openbios.org [mailto:openbios-bounces@openbios.org] 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@netscape.net -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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&pat...
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@netscape.net
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@openbios.org [mailto:openbios-bounces@openbios.org] 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@netscape.net -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
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.
* Tarl Neustaedter <Tarl.Neustaedter@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.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
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@openbios.org [mailto:openbios-bounces@openbios.org] 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
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.
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
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@openbios.org [mailto:openbios-bounces@openbios.org] 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
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@netscape.net
participants (5)
-
Asif Haswarey -
David L. Paktor -
Segher Boessenkool -
Stefan Reinauer -
Tarl Neustaedter