[PATCH] ppc boot: replace string labels with numbers

Replacing the string labels with numbers saves 117 bytes in the final zImage.
These local labels are not discared.

Signed-off-by: Olaf Hering <redacted>

 arch/powerpc/boot/crt0.S |   23 +++++++++++------------
 1 files changed, 11 insertions(+), 12 deletions(-)

Index: linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S
===================================================================

--- linux-2.6.15-rc1-olh.orig/arch/powerpc/boot/crt0.S
+++ linux-2.6.15-rc1-olh/arch/powerpc/boot/crt0.S

@@ -14,43 +14,42 @@
 	.text
 	.globl	_zimage_start
 _zimage_start:
-	bl	reloc_offset
+	bl	1f
 
-reloc_offset:
+1:
 	mflr	r0
-	lis	r9,reloc_offset@ha
-	addi	r9,r9,reloc_offset@l
+	lis	r9,1b@ha
+	addi	r9,r9,1b@l
 	subf.	r0,r9,r0
-	beq	clear_caches
+	beq	3f
 
-reloc_got2:
 	lis	r9,__got2_start@ha
 	addi	r9,r9,__got2_start@l
 	lis	r8,__got2_end@ha
 	addi	r8,r8,__got2_end@l
 	subf.	r8,r9,r8
-	beq	clear_caches
+	beq	3f
 	srwi.	r8,r8,2
 	mtctr	r8
 	add	r9,r0,r9
-reloc_got2_loop:
+2:
 	lwz	r8,0(r9)
 	add	r8,r8,r0
 	stw	r8,0(r9)
 	addi	r9,r9,4
-	bdnz	reloc_got2_loop
+	bdnz	2b
 
-clear_caches:
+3:
 	lis	r9,_start@h
 	add	r9,r0,r9
 	lis	r8,_etext@ha
 	addi	r8,r8,_etext@l
 	add	r8,r0,r8
-1:	dcbf	r0,r9
+4:	dcbf	r0,r9
 	icbi	r0,r9
 	addi	r9,r9,0x20
 	cmplwi	0,r9,8
-	blt	1b
+	blt	4b
 	sync
 	isync
 

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Olaf Hering wrote:

[snip]

OK, I've waited for someone dumber than me to ask, but I guess I'm the bottom guy on the totem pole here.

How does changing a local ascii label to a temporary label _but using the same machine instructions_ affect the output image size????  Why would "lis r9,reloc_offset@ha" generate a smaller (!) instruction than "lis r9,1b@ha"????

My first thought was that the symbol section of the ELF output is bigger, but the labels are not globals.  Even if the local labels end up in the symbol section (which the comment on the original patch message sort of implies), that isn't going to make a (stripped) binary any bigger.  If that is the case, isn't a better cure to strip the ELF file?

While I'm being dumb, I gotta ask, how big is zImage and why does 117 bytes make a difference?

My 2c: if you are going to use inscrutable labels (1,2,3,4), please put comments in.  At least the previous labels gave hints as to what was happening.

Puzzled,
gvb

 On Thu, Nov 17, Jerry Van Baren wrote:

While I'm being dumb, I gotta ask, how big is zImage and why does 117 
bytes make a difference?

Because we can.

My 2c: if you are going to use inscrutable labels (1,2,3,4), please put 
comments in.  At least the previous labels gave hints as to what was 
happening.

The code should be obvious.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

On Nov 18, 2005, at 1:42 AM, Olaf Hering wrote:

 On Thu, Nov 17, Jerry Van Baren wrote:

quoted

While I'm being dumb, I gotta ask, how big is zImage and why does 117
bytes make a difference?

Because we can.

quoted

My 2c: if you are going to use inscrutable labels (1,2,3,4), please put
comments in.  At least the previous labels gave hints as to what was
happening.

The code should be obvious.

I hope the above was a joke, Olaf.

I too am wondering where the savings come from. Regardless, IMHO 117 bytes is not a worthwhile tradeoff for less maintainable assembly.

BTW, Jerry, the size of the instructions themselves will not change. I suspect the savings is from things like the symbol table, but I can't replicate it with a simple "hello world" testcase.

-Hollis

 On Fri, Nov 18, Hollis Blanchard wrote:

quoted

The code should be obvious.

I hope the above was a joke, Olaf.

Not really. Perhaps I have been working on that code for too long now.
Its the string table that makes a difference.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

On Thu, Nov 17, 2005 at 10:09:02PM +0100, Olaf Hering wrote:

Replacing the string labels with numbers saves 117 bytes in the final zImage.
These local labels are not discared.

Signed-off-by: Olaf Hering <redacted>

And kicks easy-understanding right in the, somethings...

NAK.  If it's not too late, of course (vacation catchup is fun!)

-- 
Tom Rini
http://gate.crashing.org/~trini/