Hi,.
since the openbios dictionary is growing and growing as it becomes more
complete, I've looked at different ways to optimize the dictionary
handling. There's two methods of "safing" memory: compression and
execute in place.
1) Compression
Some numbers, taking 32bit dictionary (x86)
method | size/bytes
---------------+-------------
uncompressed | 62668
nrv2b | 22466
gzip | 20982
bzip2 | 19388
The current kernel is slightly below 8k (8172 bytes)
* pro: small(er) flash parts can be used.
* con: code has to be decompressed to memory first,
higher memory usage.
2) XIP (eXecute In Place)
If not compressing the dictionary, it could be changed so that
all but the readwriteable data can be executed directly from ROM.
This would decrease the use of RAM in embedded systems noticeably,
but it is also slower on about every system.
* pro: extremely low memory usage ( < code size)
* con: slow execution.
Looking at the amount of code this is about, (2) is pretty much
neglectable for most systems whereas (1) is an interesting option.
Comments?
Stefan
Hi,
the current openbios cvs contains a lot of new code from the device
interface. We have a device tree now and can evaluate FCode on device
option ROMs.
Now OpenBIOS lacks a whole lot of Open Firmware "support packages" like the
deblocker, tftp booting for network interfaces, the terminal emulator,
filesystem support, etc etc.
And of course: OpenBIOS needs device drivers! Open Source drivers,
vendor FCode, everything that helps OpenBIOS to support a wide range of
hardware ;-)
I started setting the framework for the support packages in
openbios/forth/packages, find one source file per support package.
Also, there's an example fcode driver coming with the QT-Plugin of the
openbios kernel: openbios/kernel/plugins/plugin_qt/qt_rom.fs
I'll attach a simple example to this mail that executes the QT Plugins
FCode. To test it, do:
~/openbios $ make
~/openbios $ make rungui < device-example.fs
It will use the FCode binary built into the plugin to initialize the
virtual graphics hardware and output a character.
Next thing I'm going to work on is to finish the terminal emulator and
other support packages, then facing the client interface code to finally
boot an operating system
For the client interface it should make sense to reuse a lot of existing
code, i.e filesystem drivers (GRUB), elf booting (Filo, LinuxBIOS),
etc. by using the calling interfaces from forth to C and the other way round.
Stefan
Hi all,
Does anyone have a datasheet for APIC 82489 chip? I could not find it
anywhere..
I understand that this chip is a replacement for I8259 used till now as
an interrupt controller on a PC/AT. I would like to learn more, and to play
with extra IRQs (IRQ15+) it provides.
Most modern PC chipsets support this chip am I correct?
Thanks for help.
Janusz
Hi,
good news. The fcode evaluator is working.
init-fcode-table probably needs some work (table.fs) since iirc a
child node should be able to see fcode words defined by the parent.
At least byte-load now cleanly creates an fcode lookup table in
alloc-mem'ed memory and frees it after evaluation which it did not do
at all before.
The verbosity of the fcode evaluator can be switched on/off with the
value ?fcode-verbose. This also enables warnings about missing words
during fcode table initialization.
The latest code is in CVS.
Test with following test-fcode.fs:
-------------
10 30 pci-l@
/n 8 = if
10 34 pci-l@
20 << or
then
0 byte-load
bye
------------
After doing a make in the toplevel, do a
make rungui < test-fcode.fs
bye,
Stefan
Hi,
This patch adds variable instantiation support. It is intended to
be used for device node instantiation.
Some implementational details:
- all template data is put into the dictionary. The thought behind this
is to make it possible to put both methods and template data in
a single wordlist.
- instantiated variables are stored in a continuous block of memory
(in contrast to the template data which is spread out in the dictionary).
A small example file is also attached to this e-mail.
Regards,
/Samuiel
