| Date Of Receipt: 12-SEP-1995 17:18:04.02
From: SMURF::QUARRY::lueck "Greg Lueck Development Environment 12-Sep-1995 1716"
To: jjchen@DEC:.zko.quarry
CC: fenster@DEC:.zko.quarry, buildhelp@DEC:.zko.quarry,
kernel_submit@DEC:.zko.quarry, ktools_submit@DEC:.zko.quarry,
lueck@DEC:.zko.quarry
Subj: Re: -ncr flag
> Is there any reason that the -ncr flag always has to be used?
The -ncr switch just prevents the linker from creating "compact relocations"
in the kernel. If you do not specify -ncr, the on-disk kernel image
will be slightly bigger (less that 0.2% bigger, if I recall). The size
difference only affects the on-disk file size. It does not make the
in-memory size any bigger. In fact, the -ncr switch does not affect the
gnerated code at all.
Compact relocations are required in order to run Atom. Therefore, you
need to remove the -ncr switch when you want to build a kernel that you
will process with Atom.
I added the -ncr switch to the kernel makefile when I extended the linker
to create compact relocation by default. I felt we wouldn't want the
compact relocations in the kernels we shipped to our customers.
I agree with Yaacov. It would be a good idea to put -ncr switch in a NCR
macro, so kernel developers could easily build Atomizable kernels.
-- Greg
|
| Date Of Receipt: 20-SEP-1995 09:32:43.12
From: SMURF::TLAZA::duane "Andrew Duane USG/PE"
To: [email protected]
CC: fenster@DEC:.zko.tlaza (Yaacov Fenster USG),
jjchen@DEC:.zko.tlaza (Jin-Jwei Chen USG), buildhelp@DEC:.zko.tlaza,
ktools_submit@DEC:.zko.tlaza
Subj: Re: -ncr flag
I have run some tests on kernels with and without -ncr, and here's
what I've found.
name bytes_ncr bytes_no_ncr compressed_ncr compressed_no_ncr
----------- --------- ------------ -------------- -----------------
ALCOR 9510808 9550464 6270450 6294358
ALPHAPC64 8816680 8855536 5841667 5865113
AVANTI.LITE 5919600 5950032 3842645 3860480
AVANTI 9531192 9570944 6307200 6331263
AXPPCI33 8905000 8943520 5904004 5927178
AXPVME64 8312376 8347936 5497991 5519140
COBRA 8377800 8411872 5539415 5559616
EB164 8765184 8804048 5800344 5823770
EB66PLUS 9048104 9087504 6000924 6024665
FLAMINGO 11347320 11391824 7359121 7386132
GAMMA 9361528 9402752 6193017 6217962
GENERIC 12420144 12500000 8200647 8248733
INSTALL 10696776 10767392 6961168 7003305
JENSEN 8683616 8720240 5760332 5782308
MIKASA 9224352 9263808 6127887 6151684
PELICAN 11015800 11059280 7118323 7144537
RUBY 9110280 9159248 5953306 5981791
SABLE 9806816 9848544 6476053 6501332
SAS 16408840 16483536 7935484 7980280
TLASER 10034960 10091344 6567972 6601149
The size differences are somewhat less than 0.5% (about 20-60K bytes
for regular kernels, 15-30K bytes for compressed kernels).
Functionality and debugging seem unimpaired without -ncr.
If this is an enabler for OM/ATOM, I vote we turn it off.
Is there any drawback in having some compact relocations
in the symbol table? Does ladebug have a problem?
--
Andrew L. Duane DTN 381-1294 [email protected]
USG Kernel Scalability alpha::duane
ZKO3-3/U14
|
| Date Of Receipt: 2-OCT-1995 10:21:59.17
From: SMURF::QUARRY::lueck "Greg Lueck Development Environment 02-Oct-1995 1020"
To: [email protected]
CC: fenster@DEC:.zko.quarry, jjchen@DEC:.zko.quarry, buildhelp@DEC:.zko.quarry,
ktools_submit@DEC:.zko.quarry, lueck@DEC:.zko.quarry
Subj: Re: -ncr flag
Andrew,
I've been away on vacation, so I was unable to respond sooner. The size data
you generated for -ncr in the kernel link looks about as I expect. I think
you and the other kernel developers need to decide if you want -ncr in the
default kernel link. I will support any decision you make.
You ask if this is an enabler for OM/ATOM. In order to use Atom, you must
link the kernel without -ncr. The -ncr switch has no effect at all on OM.
The -ncr switch does not affect the symbol table at all, so there should be
no problem using ladebug or any other debugger.
Here are the advantages I see of removing the -ncr switch from the default
kernel link:
1) It makes it easier for developers (and others) to run Atom on
a kernel. However, kernels need to be linked with a different
TEXTBASE anyway in order to use Atom. Therefore, you still won't
be able to run Atom on a kernel without relinking.
2) We will avoid shipping a makefile that uses an undocumented
linker switch. (The -ncr switch is undocumented.)
Here are some disadvantages:
1) Default kernels are somewhat larger than necessary. However, the
increase is very small and it only affects the on-disk size.
-- Greg
From: Andrew Duane USG/PE <[email protected]>
Message-Id: <[email protected]>
Subject: Re: -ncr flag
To: [email protected]
Date: Wed, 20 Sep 1995 09:30:57 -0500 (EDT)
Cc: [email protected] (Yaacov Fenster USG),
[email protected] (Jin-Jwei Chen USG),
[email protected], [email protected]
In-Reply-To: <[email protected]> from
"[email protected]" at Sep 12, 95 05:16:23 pm
Reply-To: [email protected]
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 2041
I have run some tests on kernels with and without -ncr, and here's
what I've found.
name bytes_ncr bytes_no_ncr compressed_ncr compressed_no_ncr
----------- --------- ------------ -------------- -----------------
ALCOR 9510808 9550464 6270450 6294358
ALPHAPC64 8816680 8855536 5841667 5865113
AVANTI.LITE 5919600 5950032 3842645 3860480
AVANTI 9531192 9570944 6307200 6331263
AXPPCI33 8905000 8943520 5904004 5927178
AXPVME64 8312376 8347936 5497991 5519140
COBRA 8377800 8411872 5539415 5559616
EB164 8765184 8804048 5800344 5823770
EB66PLUS 9048104 9087504 6000924 6024665
FLAMINGO 11347320 11391824 7359121 7386132
GAMMA 9361528 9402752 6193017 6217962
GENERIC 12420144 12500000 8200647 8248733
INSTALL 10696776 10767392 6961168 7003305
JENSEN 8683616 8720240 5760332 5782308
MIKASA 9224352 9263808 6127887 6151684
PELICAN 11015800 11059280 7118323 7144537
RUBY 9110280 9159248 5953306 5981791
SABLE 9806816 9848544 6476053 6501332
SAS 16408840 16483536 7935484 7980280
TLASER 10034960 10091344 6567972 6601149
The size differences are somewhat less than 0.5% (about 20-60K bytes
for regular kernels, 15-30K bytes for compressed kernels).
Functionality and debugging seem unimpaired without -ncr.
If this is an enabler for OM/ATOM, I vote we turn it off.
Is there any drawback in having some compact relocations
in the symbol table? Does ladebug have a problem?
--
Andrew L. Duane DTN 381-1294 [email protected]
USG Kernel Scalability alpha::duane
ZKO3-3/U14
|