From: mjn3@codepoet.org (Manuel Novoa III)
To: linux-8086@vger.kernel.org
Subject: approx 2k reduction in kernel code size -- 300 bytes in data (patch)
Date: Tue, 18 Jun 2002 13:12:30 -0600 [thread overview]
Message-ID: <20020618191230.GA18693@codepoet.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
Hello all,
Sunday afternoon I felt like taking I break so I started looking at the
elks kernel. After doing lots of repetitive bcc-specific optimizations,
as well as reworking a few things (arch/i86/lib/memmove.c and kernel/sys.c
in particular -- I'd appreciate a second pair of eyes on those), this is
what I have for the config file below.
cvs source (with fs/minix/bitmap.c fix):
Root device is (0, 0)
Boot sector 512 bytes.
Setup is 1772 bytes.
System is 120672 B (61456 B code, 7940 B data and 51276d B bss)
System is 69428
cvs source with attached patch:
Root device is (0, 0)
Boot sector 512 bytes.
Setup is 1772 bytes.
System is 118380 B (59472 B code, 7640 B data and 51268d B bss)
System is 67144
So, a savings of just under 2k in code and 300 bytes in data.
bcc optimizations used mainly fell under the following categories:
1) Reworked codeflow for better bcc code generation.
2) Use of "register char *"s as counters, as bcc can't seem to place
ints in registers. (yes, this is ugly, but it is effective)
3) Allocation of different register variables in different blocks in
on subroutine, as bcc seems to limit you to two register variables
active at a time (di/si).
4) Collection of common work.
Hopefully in a couple of weeks I'll have some time to look at the
driver files as well.
Enjoy.
Manuel
Modified files:
arch/i86/lib/
bitops.c memmove.c
arch/i86/mm/
init.c malloc.c
fs/
block_dev.c devices.c exec.c fcntl.c
file_table.c inode.c ioctl.c namei.c
open.c pipe.c read_write.c readdir.c
select.c stat.c super.c
fs/minix/
bitmap.c file.c inode.c namei.c
symlink.c
kernel/
exit.c fork.c printk.c sched.c
signal.c sleepwake.c sys.c time.c
lib/
chqueue.c string.c
Config file - activated options:
CONFIG_ARCH_AUTO=y
CONFIG_PC_AUTO=y
CONFIG_CONSOLE_DIRECT=y
CONFIG_DCON_VT52=y
CONFIG_DCON_ANSI=y
CONFIG_KEYMAP_US=y
CONFIG_CHAR_DEV_RS=y
CONFIG_CHAR_DEV_LP=y
CONFIG_CHAR_DEV_MEM=y
CONFIG_PSEUDO_TTY=y
CONFIG_BLK_DEV_BIOS=y
CONFIG_BLK_DEV_BFD=y
CONFIG_BLK_DEV_BHD=y
CONFIG_GENDISK=y
CONFIG_BLK_DEV_CHAR=y
CONFIG_MINIX_FS=y
CONFIG_FS_EXTERNAL_BUFFER=y
CONFIG_PIPE=y
CONFIG_EXEC_MINIX=y
CONFIG_SOCKET=y
CONFIG_INET=y
CONFIG_INET_STATUS=y
CONFIG_SYS_VERSION=y
CONFIG_ROOTDEV_FD0=y
[-- Attachment #2: elks.diff-mjn3.gz --]
[-- Type: application/octet-stream, Size: 22293 bytes --]
reply other threads:[~2002-06-18 19:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020618191230.GA18693@codepoet.org \
--to=mjn3@codepoet.org \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox