Dictionary Compression vs eXecute In Place

[Stefan Reinauer]

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

[Wookey]

+++ Stefan Reinauer [03-11-19 22:40 +0100]:
> Hi,.
>
> 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.

It also doesn't work on systems which boot from nand flash, (increasing
numbers of arm-based devices for example). XIP is possible on NOR flash (but
pretty slow), but not NAND, in the same way that it's not possible from
Disk. This may not be terribly relevant as I'm not sure how much use
openBIOS is likely to see on such devices, but I thought I should point it
out.

Wookey