On Tue, Apr 10, 2012 at 18:43, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2012-Apr-10 13:41 , Blue Swirl wrote:
Yes, but again, image size savings are not very interesting. Savings in image loading time is easily lost during decompression.
Why do you think image size saving aren't interesting? Certainly in the past couple of decades of Openboot development, we've several times been severely squeezed by prom sizes - in some cases, we had to rip out functionality to be able to fit in our PROM.
Yes, but in the virtual world, the images are just files. Not even very big files these days, a million PROM images could fit in a hard disk. The sizes of boot flash memories (executable) are also several orders of magnitude larger than PROMs of old times.
The CPU cycles used for decompression waste time, energy and thus money each time the (virtual or real) machine is booted. Maybe using this logic, it would be worthwhile to invest in larger PROMs in real machines, for some customers at least.
For what it's worth, Openboot currently compresses the "dropin" images (FCode standalone images for devices) before assembling them into the PROM image, and decompresses those when they are brought in with find-dropin.
IIRC PC BIOS was often banked, with only a part of the flash visible at end of memory. That way for example POST (not needed after boot) could be hidden. The reason was not PROM size, but the size of the address space window available in real mode, 128k.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you