On 14 Oct, Stefan Reinauer wrote:
On Tue, 13 Oct 1998, Daniel Engstrom wrote:
Some boards have 4MBit (256k byte) flash these days... And IO though one could use compression. The gunzip object code in linux is 14k bytes and the kernel compresses about 2.5:1 which means that if we total 16k uncompressed code we have 112k left in the PROM. If we get 2.5x as well it will give 280k. If we only get 2x it will still be 224k binary code.
I fear that you can't rely on this. Even many PII Systems are not equipped with 2MBit (256kbyte) Flash chips.
Yeah I meant 2Mbit too.
I also heard, that bios manufacturers are about to lower their bios sizes again to fit into smaller chips,
Note that the 220-280k figure above is based on a 128k flash and gzip compression. Or do you mean that they are trying to squeeze it in to a 64k flash?
Another idea that comes to my mind is the question for a general bios concept. If Intel switches to ia64 at about y2k, we would only support old and obsolete hardware if we specialize on intel ia32 architecture.
Yeah, thats the point of IEEE-1275. It's a general, cross-platform approach and any code base produces will make sense on any platform.
We can say that every PC better than an 386 has at least 128bytes today. 4 or 8k versions are used in EISA boards. But as you might know, the Award BIOS uses parts of the flash rom to save it's PnP information.
Well that's one solution, maybe we'll have to do something like that for NVRAM-starved systems. One other way would be to use the boot prom socket "everybody" have sitting empty on their NICs to add more flash or a NVRAM module.
Hmm.. Do you have an idea where to get those "Instruction Set Architecture Supplement"s??
They're linked from the main page, but I'll include the URLs here:
Sparc: http://playground.sun.com/1275/bindings/sparc/d14a/12751d1a.ps PPC: http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.ps ARM: http://playground.sun.com/1275/bindings/arm/arm0_3d.pdf
7: Parse NVRAM 8: Scan for FORTH code 9: Execute any FORTH code
Does anyone have an idea how much code is needed for this one?? :-) A java bytecode interpreter comes to my mind :-)
Me thinks FORTH is smaller than java...
GNU forth 0.3.0 static and dynamic linking.
-rwxrwxr-x 1 root root 240928 Oct 14 12:08 gforth -rwxrwxr-x 1 danne danne 38628 Oct 14 12:20 gforth
Note that this is supposed to be a general-purpose forth and I think a Open Firmaware compilant Forth dosent have to be 250kb.
/Daniel
Here is a mail that appeared on linux-kernel about forth (in the kernel this time):
From humbubba@raptor.cqi.com Wed Oct 14 11:40:44 1998
Date: Fri, 18 Sep 1998 17:57:46 -0400 (EDT) From: RHS Linux User humbubba@raptor.cqi.com To: linux-kernel@vger.rutgers.edu Subject: Helge, Forth is not an interpreter.
In reference to the wish for an "interpreter" in the kernel for device drivers...
Forth is machine language for a virtual 2-stack machine. This is a machine with no registers, not stacks implemented in registers. This machine language has ops at a very low level to implement a compiler and an interpreter. Open Firmware is the example. The author of Open Firmware, Mitch Bradley, was a bigwig on the ANSI Forth Standard commitee.
How the Forth virtual machine is implemented varies from silicon to Java. A Forth running on a silicon 2 stack machine OUTperforms anything else. gForth uses the labels-as-values capability of GNU C ( which egcs seems to have also) to "thread" Forth primitives together in what is called Indirect Threading in the Forth world. This gives a level of performance unattainable in ANSI C. The first Forth-in-C was written by the above Mitch Bradley, who invented "switch-threading" for it. His CForth was a single C switch statement. One of the authors of GForth has an x86 Forth called BigForth. It outperforms GNU C for some floating-point operations.
The reason for Open Firmware is this... a driver manufacturer writes ONE driver in ANSI Forth. It is distributed as ANSI Forth sourcecode. How it performs is entirely up to the OS. If that OS was on a silicon Forth engine CPU that driver would compile to the screamingest stuff you've ever seen.
I don't know the specifics of Open Firmware, since Open here has the usual meaning, but Forth compiles fully, to the limit of how the Forth VM is implemented. There would be a performance hit on Forth drivers in any Linux scenario currently existing, but not in the scale that the term "interpreter" implies. Having a compiler running in kernel space would be pretty wacky. The unknowns that emerge is beyond my imagination. But due to the succinct, efficient, minimalist design of Forth, those unknowns are far less with Forth than anything else.
Rick Hohensee http://cqi.com/~humbubba colorg on EFnet IRC #linux chanop Forth C Linux Perl graphics music Md., USA This is your brain on colorg --> (@#*%@#() <---~~~_()()( Any questions?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
--